I dont want DLP – I trust my employees May 27, 2008

I am sure people by now are getting used to the constant string of vendors talking about how they solve the data leak prevention issue. They have presented their sales pitch so many times that it comes out almost involuntary at the slightest whiff of the topic during a conversation. You want to see a sales account managers brain snap. Tell him you are not interested in DLP because you trust your employees, they are just not use to hearing such a response.  If we don’t trust our employees, then why are they employed.

This thinking will reduce the DLP issue down to a couple of risks:

• Accidental leakage through bad judgement, error, misconfiguration or uninformed end users

• Opportunistic information theft (DLP is not going to stop someone getting the information if they really want it)

If you have identified, marked and appropriately secured your sensitive information, then you are left with the risk of loss of lesser value information. This may have an impact, but does the loss of this information justify the cost of deploying and ongoing maintenance/configuration of a DLP solution?

If you can justify the cost of a DLP project, how about redirecting those funds instead at something to try treat the root cause of one of the risks identified above. Provide appropriate training and support tools so your employees understand the value of their companies information, how the loss of the information may effect them personally (gives them ownership) and how they, as employees, can reduce the possibility of accidental leakage. And then if you wish to use DLP,  target  only those systems that contain the sensitive information, and the people who are authorised to access them,   to reduce the risk of sensitive data leakage.

My belief is that you will get a  better long term benefit this way, rather than implementing another technical solution that is only going to increase complexity in the environment, annoy end users, increase operating costs, and stretch support resources. All of which is likely to introduce bigger risks then the DLP risk you are trying to mitigate in the first place.

update: USB port blocking May 12, 2008

I did some basic google searching tonight to see if I could find a product that would lock authorised USB devices to a computer to complement the USB port fillers I blogged about previously. What I found was that a company call PC Guardian has also created physical USB port blockers, and the complementary USB cable lock so you can secure authorised devices like keyboards and mice.

Nifty USB port block solution May 10, 2008

While drifting around the Internet tonight I came across this product. http://tinyurl.com/6f8rpn

I was very impressed with the idea on my first impression.  You use the grey colour coded keys (the colour coded key only works in the corresponding coloured USB filler adapter).  Now this is not the ultimate locking device because anyone can go buy the correct grey adapter key to remove the fillers, however for those terminals that undertake sensitive processing, or a public terminal, it is a great way secure against attaching unwanted devices by convience.  The side benefit from an employee discpline point of view, if an employee removes the filler adapter, they cant claim they didnt know they shouldnt be attaching unapproved USB devices.

The biggest downfall I see with this devices is that most keyboards and mice are now USB. So you obviously cant use this to fill those ports. What is to stop someone pulling the keyboard USB cord, plugging in a USB hub, and then plugging the keyboard into this. Therefore to make this product useful it needs to be supported by another adapter. This could be a two-way locking adapter so you can lock a USB device/cord into a port and it cant be unplugged easily (which stop office theives borrowing your keyboard/mouse/webcam when theirs break). In the public spaces this would also protect against the hardware based keylogging adapters. If anyone knows of such an adapter please let me know.

Evolution of Firewall Architecture May 7, 2008

During the last couple of weeks I have had an interesting questioned posed to me. After some thinking I have expanded and evolved the thought to: At what point does the risk require you to evolve a single UTM enforcement gateway architecture to a more complex architecture.

This architecture may envolve seperating the UTM features out into dedicated services (e.g. AV scanning, proxying, VPN) or to duplicate the firewall services (maybe heading down the mutli-vendor path) and seralising the enforcement path (i.e. putting one firewall behind the other).

While there are some very good technical reasons why you would implement certain architectures, it can be the un-thought of risk considerations that drive some of the long term operational costs. I would consider that evolving the gateway solutions into separate dedicated services, and multiple vendor enforcement devices (i.e. firewalls)  would ultimately mitigate a significant amount of the threats (that could be realized by known and unknown vulnerabilities), AS LONG AS, you have the appropriate technically mature resources to support those devices, effective change control and strong governance procedures. Without these, the complex architecture would likely increase risk rather then reduce it. It is because of this that UTM’s are a good solution for certain situations which would involve the considerations like the size of the network/company that you are trying to protect, the resources available, and their technical competency.

While I would likely always try to evolve gateway enforcement services into seperate parts (i.e. pick a box that does its particual enforcement service well, with no overlap enforcement on another OSI layer/network protocol), the limit of that evolution would be bounded by the risk introduced by having not enough resources, or those resources not technical competent enough able to maintain a number of services.

The issue could be summaries using pitting two sayings against each other:

“KISS – Keep IT Simple Stupid” vs “Don’t put all your eggs in one basket”