Monday, May 7, 2012

Don't Push the Red Button

I have a certain level of knowledge about the issues security professionals face and the incidents they cause.

First some background on this incident. A piece of hardware was reset and the encryption keys it contained were "zeroized". Then a message was sent out to the entire section informing them not only of the exploit but also underlying vulnerabilities which carry the risk of a denial of service. Because this incident report came through internal channels, it contains too much secure information to post here. There wouldn't be enough left after redaction. I will, however, discuss the incident in generic terms as a case study. Of course, the risk has been addressed.

Up front, let's address the sender of the message. The message was sent from the Information Management Office, a higher level function than over-titled secretary but that's a distinction that's easy to be confused over.  Not that the IMO is unauthorized to distribute information about incidents in the office, but as a general rule nobody should be distributing information on exploits or vulnerabilities. So that's who sent it, but where did it go? To a large office full of non-security job functions. Read that as "potential threats".

Let's move on to the content of the message. The message reveals a successful, yet inadvertent, exploit of a vulnerability with a security device in the office. It clearly describes how to "zeroize" the device and also how long to return to operation. Reading between the lines, additional indicators are revealed. There is a piece of critical equipment in an unsecured location. Anyone in the field should immediately ask what else is in that location. Keeping in mind that these devices will not pass traffic unless it's encrypted, the victim was under a complete denial of service. That operational state could be further exploited while personnel are distracted by recovery efforts.

As a security professional, how do you protect your office from this?

First, educate the threats. This incident was caused by an untrained user accidentally resetting the device. Flat out, every user needs to be properly trained to operate the equipment they have contact with. Also, educate your users about information security. Disclosing the incident could have deeper repercussions than the incident itself. An attacker should rightly assume that the risks here have been addressed and they should look for another vector. Or an attacker might just try to replicate the exploit anyway in the chance that it hasn't been addressed.

Secondly, lock up the vulnerabilities. I mean that literally. Lock up any hardware that doesn't require user contact. That's everything but the keyboard and mouse. And not just the physical hardware but also the software. Employ "least user privilege" by only giving users the amount of access they need for their jobs. An employee who's job description does not include "reset the encryption device" should not have access to that button.

Third, finish your risk assessment. Tally up the costs in dealing with your threats and vulnerabilities. Put it in real dollar amounts so you can do a quantitative comparison. In this case, a security container and user education. Now tally up the costs of a threat meeting a vulnerability to become an exploit. Again, in dollars out of the company budget. For this incident, it was one week of lost work by one office being unable to do secure business plus the cost of rekeying the encryption device. Finally, compare those dollar amounts. Assume the risk only if the cost of mitigation, in actual company money, is too high.