Choose from several options for complete web, email and data security.
Learn more
Evaluate Websense products by watching demos and installing evaluation software.
Learn how Websense solutions help keep our customer safe, secure and productive
Get information on product updates, support resources and more.
Get the most out of support in five simple steps.
Find tools and assets to help sell Websense solutions.
Stay informed on the latest security exploits, industry news, research, solutions, and more.
Maybe allow the SHA1 hash value or something similar as the unique identifier. The way it now works, it looks like if I rename ultrasurf.exe to ultra-surf.exe my renamed file is going to work just fine.
It would also be superb if you could hook into a netstat-like feature and detect applications trying to use certain destination ports regardless of what the source application is.
For example, less than 1% of our users should be using a file transfer program so 21 and 22 should be unused almost all of the time by all of the users.
All users use a proxy server on a non-standard port. So any traffic to a destination port of 80 or 443 and a public IP address could be a piece of malware trying to find a way out.
Applications can be added to DSS in two ways, firstly through the web management interface which as you state only looks at the file name. The other way is to use a utility which identifies the application by its metadata, this is the more secure method but takes a bit more time to configure. You can find this utility (DSSRegApps.exe) in the "Program files\Data Security Suite" directory, see page 510 of the Data Security Help manual.
Thanks! I did not know about that. Unfortunately it seems to require that you download a prohibited file if it's one you want to block, like UltraSurf. It would be much nicer to look at port activity or to be able to input a hash manually since there are a lot of sites that list them.
Or even if there was an offline version of the utility, one that would create an XML or something similar that I could then import.
I would have thought we could alert or act upon a simple file execution, like UltraSurf.exe but I don't see that capability. DLP only seems to work if File access/copy/paste is part of the application, not just the application running.
The functions you mention, like blocking certain applications from launching, would generally be considered as an application control solution not a DLP solution.
Maybe yes and maybe no. For example, some users have the ability to FTP to specific vendor addresses. But not all vendors restrict their access by source IP. So the PCI QSA is concerned that these people could FTP some card numbers to a vendor and then pick them up from another location or a mobile device a short time later. Certainly a valid point. But they also could download a single-file FTP client and run it from their desktop and we'd have no idea it happened. Many FTP clients don't work with an FTP proxy, including some commercial apps we have, so the Data Protector is out of the picture.
I'm not sure how the "clear text" part of the Endpoint agent is supposed to work but it doesn't seem to. We've tried telnet and FTP from a desktop with the agent and it doesn't catch a thing. That's why the port-based detection would be a real help.
Data Protector does not act as a proxy, it uses a span port to monitor traffic so it would actually be able to inspect the FTP traffic in your example. You could also enable LAN monitoring on the Endpoint, although in my experience that can often cause problems.
I guess I was thinking of the WCG which can run an FTP proxy on TCP 2121.
Yeah, LAN monitoring really clobbered our endpoint performance. On the low end desktops a file save went from 7 seconds to over 17 minutes for one large file.
