Technically Accurate, But Not Politically Astute

The support team for a security appliance I use recently responded to a periodic lockup issue by informing me that "When the appliance starts to overload, random processes are killed to free up memory". A co-worker noted that this was "technically accurate, but not politically astute" - he's entirely right. While we would be upset if the vendor didn't provide a reasonable answer, this one causes worries. Why?

In part, because the answer is somewhat technically accurate for a Linux based appliance, and it may even be related to the actual issue. It isn't, however, something that a customer wants to hear, particularly for a hopefully bulletproof, nominally trusted security appliance. One imagines that the vendor has done various clever things, like protecting their critical processes, and has taken steps to ensure that if they do die, that they come back automatically. In this case, a partial answer wasn't reassuring.

I didn't expect an in depth lecture on oom_kill.c, but I will expect a follow up with a good answer as to why the device can hard lock without the central control system notifying me.

Mac Full Disk Encryption: CheckPoint delivers first

CheckPoint announced their MacOS full disk encryption product, making them the first vendor out gate with a MacOS FDE product that I've seen. Their product supports central management and lists enterprise scale growth capacity, meaning that it may fill the currently empty FDE niche for Mac using organizations.

List pricing for the FDE standalone product ranges from $120-$60 per install, depending on volume. The datasheet has not been updated to include MacOS, so actual street pricing may vary. With that said, the price appears competitive with existing competitive enterprise level products.

I expect the price of full disk encryption packages to fall as it becomes an enterprise commodity rather than a specialized tool for high security environments - the availability of single system solutions using BitLocker or TrueCrypt's FDE make small scale FDE free already.

Freebie: Qualys FreeScan

Qualys offers a free sample scan of a single public facing IP using their QualysGuard software as a service vulnerability scanner. It's worth a try if you're looking at vulnerability scanning products, and is an easy way to take a look at a machine using a commercial scanner.

You can sign up here for a 14 day trial - they'll want to sell you their product, of course:

http://www.qualys.com/forms/?lsid=7

An alternate option is their single IP Freescan:

http://www.qualys.com/forms/?lsid=7002

Qualys provides two related, and quite useful products - PCI scanning, and general vulnerability scanning. Their software as a service approach is different than many, although more companies are adopting it, and it is useful, as it cuts out system and software maintenance costs, and makes scaling easy by simply adding small appliances. You can literally throw a scanner in your briefcase, plug it into a network with outbound network access, and use it. That's pretty neat, particularly for auditors. I really like the ability to have a scanner that doesn't require system hardware and software maintenance. The entirety of the support for the devices is either the Dogbert solution (shut up and reboot!), or having Qualys drop ship you a new one if something fails.

The current implementation does have limitations as you scale up - their hierarchical user and system management definitely needs work, but in my experience, it is one of the best vulnerability scanner systems I've used. Better, system administrators and security operations staffers that I work with have generally found it easier to use, and of course easier to maintain than open source products.

The real gotcha? Qualys prices their product at the high end of the range. That's a hard pill to swallow in small and mid-size environments, but may be justifiable in larger organizations. If you are already using Qualys, their PCI compliance scans are quite reasonable, and may help to allay the cost.

Security Metaphors: The Good, The Bad, and the Ugly

Security analysts try to explain security concepts via metaphors on a daily basis - putting our technical language into a more approachable form is part of the job. Sometimes we manage to do a great job, and our audience picks up the idea easily. At other times, we either confuse them, or worse, we create more issues than our metaphor was intended to solve.

"But, why doesn't the security guard hear the burglar?" "Well, hackers don't make noise when they're breaking in and..."

Many security metaphors are overused, or are poor representations of the actual concept. How often do you see a lock used as a security metaphor? Security - particularly IT security, is rarely conceptually equivalent to a lock, yet almost every security program uses a lock as a visual metaphor. Some even use an unlocked lock. Should we be concerned that we are subliminally suggesting that security isn't there to our audience?

Another over used comparison is one that Anton Chuvakin complained about last year: our overuse of the castle metaphor. His points are very valid - we're not building castles, and we need to explain what we're doing more carefully. Defense in depth is relatively easy to explain - but how do you explain more complex concepts effectively? Often, we attempt to come up with a spur of the moment comparison, and sometimes we fail. In at least a few circumstances, this habit has become a running joke in organizations I've worked with.

The habit of creating spur of the moment metaphor can be ugly. Metaphors can fail quite horribly, as shown by this recent example quoting a police officer talking about fake checks and check fraud in an article in the South Bend Tribune:

"Fake checks are like that chainsaw.

"There’s always got to be that one guy that says, "I don’t hear the chainsaw, I don’t feel the chainsaw,’" he said. "Trust me, it’s there. Don’t open that door."

When you do, you’re putting others at risk.

"You’re allowing (a) whole bank to be susceptible," Zultanski said. "And our whole banking industry."

So what is your favorite security metaphor? Have you seen any huge successes, or any huge failures?

Creative Commons licensed Flickr credit to: AMagill

Reminder: Your Third Part Certificates May Need Replaced

If you have certificates issued from one of the major Certificate Authorities, you may have received an email as a follow-up to the ongoing issue with Debian and Ubuntu OpenSSL certificate generation.

Per Verisign's letter:

If you are running Debian operating systems and derivatives (such as Ubuntu) released between September 17, 2006 and May 12, 2008 you should deploy a recently replaced Debian patch and revoke and replace all SSL and Code Signing certificates for which the keys were created on these operating systems.

It looks like Thawte and Verisign are replacing certificates at no charge - and Comodo is using it as an opportunity to attract more customers by offering to replace other's certificates free of charge.

Twenty Encryption Devices In Pictures

Oobject has a great pictorial collection of twenty encryption devices - everything from an Enigma machine to a wheel cipher. Well worth a look if you're a cryptography fan.

If you're interested in crypto machines, you can build an electronic Enigma machine, or you can go the paper Enigma route.

Acceptable False Positive Rates: Sky Marshalls on the No Fly list?

Bruce Schneier linked to a Washington Times article about Sky Marshalls whose names match names on the No Fly list. The first thing that came to mind for me was "Well, what is the acceptable false positive rate?".

The system currently primarily causes issues for individuals, rather than groups. When you take a Sky Marshall off of a plane, one would tend to believe that you increase the risk to the entire plane - they're there as another layer of security. Most security analysts would first get a good chuckle, then start worrying if they found out that their security system was actually stripping away a different layer.

What happens when we get pilots on the No Fly list?