Recently in Governance Category

Last week was the last week of my SANS mentor class for Hacker Techniques, Exploits and Incident Handling. Hopefully my students will try out for certification and pass gloriously.

As always, we wrapped the 10-week teaching cycle up with the ever-entertaining capture-the-flag (CtF) session that really drives home a few key points. In a previous blog post (computer security badness hierarchy. January 13, 2009), I argued that when we focus on our responsibility for securing information technology (as part of a much larger socio-economic information system), information security practitioners really only have to worry about a few types of things: Bad Users, Bad Configuration, and Bad Software.

Most CtF's are completely in line with my hierarchy and by using tools such as nmap and metasploit and by leveraging exploit code that is readily available in places like the Offensive Security Exploit Database (formerly known as Milw0rm), most challenges in "hack labs" can be solved easily.

The major exploitable categories are typically credential re-use (bad users), unpatched software (bad software), running unnecessary services (bad configuration) and lack of port filtering (bad configuration), and can be found on most (if not all) enterprise networks. Of course, there are many more attack vectors (think "Web" and "end-point").

As a security practitioner, there are few tools more valuable than a well-designed and fully implemented vulnerability management program. When possible, it is nice to drop the $100K+ to purchase one of the commercial suites, but by ensuring that all your computers (servers, desktops and laptops) are configured according to a hardening template and that they receive all patches in a timely fashion is already a major gain. Put on top of that a decent (current) anti-malware package, and you have a nice start.

Do not underestimate the complexity of "just" doing this. If you haven't started this yet, get going. If you have started, but don't think you're done: welcome to the club ;)

If you are embarking on such a project, think about collecting some metrics about how well you are doing it so you can measure progress and define success. Think of numbers like: percentage of end-points that have been patched appropriately, percentage of end-points with current anti-malware software, average lag between publication of vulnerabilities and completion of roll-out, number of end-points in compliance with the hardening template, etc.

As information security professionals, a lot of what we do revolves around the concept of an incident. Most of my time is spent trying to prevent a deviation from the norm that may cause harm to take place in the first place, but sometimes things happen and we need to respond to such an occurrence. Having the appropriate planning in place to know what you will be doing helps tremendously. All plans are subject to what happens to the real world, and those real-world events will influence the execution of the plan.

As many security professionals, I often find it very hard to justify making certain expenditures. Especially when money must be spent before a real incident has taken place (or rather, before a real incident has been identified), fully developed detailed justifications are often hard to capture.

As a result, I am truly looking forward to what Rich and Adrian over at Securosis are working on. Today, they put up--what will hopefully be--the first post of many on business justifications for data security spending.

The approach appears to be based on a thoughtful combination of quantification and qualification and consists of the following four steps:

"We are at an interesting juncture today; there are no threats to information technology for which we do not have the tools to combat them" Reliable Security, Steven J Ross. Information Systems Control Journal, Volume 5, 2008, pp 9-10.

Whether or not the author truly believes that this statement is true, it is a definite attention-getter. Other phrase in the article reads "[...]it appears that we know what to do to achieve information security, but we are not doing it". 

My first thought after reading these statements was that the author has no idea what he is talking about, or that he is trying to start a flame war. However, given that the author holds a director position at Deloitte, his thoughts may deserve more consideration.

After giving it some thought, I realized what the flaw in this logic is.

I actually agree with the point-of-view that most (if not all) technology-borne threats can be mitigated or removed.

However, what must never be forgotten is that preventive controls come at a price. And while it may be true that all technology-based vulnerabilities can be mitigated (for example, by stopping to use the technology altogether), the cost of doing so might simply not outweigh the risk of doing it.