“How I can communicate the value of an ISO implementation to non-security management?”

This question came to me after one of the posters on the ISO Google Group asked about KPIs for ISO implementation.  Got great responses in email, blog comments, and on Twitter from current/former CISO folks and consultants and analysts.  Some really great thought and effort, by the way - thank you.  It’s really great to be able to have these sorts of conversations online.

First, I have to point out some resources Brian Honan linked to from Gary Hinson, just because they’re so cool.  Gary has invested gobs of time and effort to become one of the defacto resources on the ISO (you might also want to read or re-read Gary’s web post on the 7 myths of metrics).   Brian links to an implementation guidance document(pdf) and a metrics example(pdf) document.

As full of awesomeness as they are, though, these are simply metrics “mapped” to the ISO (i.e. the ISO isn’t a pre-requisite for generating this information).  They are not KPI’s that express the value of ISO implementation.  Problem is the metrics created here still require some level of “translation” in order to create some value statement that data owners can understand.  As Myrcurial twittered me “27001 is orthoganal to process” meaning (I hope) that metrics have their foundation in events that are generated by processes.  27001 by itself was never meant to create metrics (see above), and so we’re asking a question the ISO can’t answer.  But the desire, the need to measure still exists.  To that extent we can google “ISO compliance” (whatever that means) and if something can be certifiable or deemed “compliant” we can and are “measuring”.  But does that have value? Rybolov (my favorite Guerilla CISO) wrote:

“Whatever you do, don’t start measuring percentage of compliance. Eventually, that’s what all metrics efforts around a framework devolve into.”

I have to agree.  Being ISO “compliant/certified” has little expressive business value prima facia. I find that one KPI that absolutely asserts value when expressed properly is risk - and similarly  Shrdlu wrote:

“I really have no idea. I personally wouldn’t try to justify an ISO implementation by itself. If I could show traceability on how it affected our overall security risk, then that’s what I’d do.”

And that’s a delightful answer.  That “traceability” (geeze-louise Shrdlu - what a word!) is absolutely what I’m after here.  How do I get that?  

If you’re going to do something with corporate budget (time, money - and goodness knows an ISO implementation is time & money) you better be able to communicate the value.  And while the zealotry for ISO implementation differs from person to person, I have yet to come across someone who says that ISO adoption is totally without value.  It’s just not apparent what that value of adoption is and how we can measure (metrics) and express it (KPIs).

Jenean Paschalidis wrote what he thought that value was in a very nice email in which he puts a qualitative name on the value of adoption:

“Transparency and accountability-this is what all executive/senior management (the company) is on the hook for. ISO provides that. If you want to understand and have confidence in your operations as supported by security (because you will know the who, what, where, when, why and how of a system (human, technical etc.) and you want to be able to trace back why a decision (risk-vetted) had been made - then adoption of this best international practice will assist in providing these answers.”

So working with our above thoughts a little here - if we agree with Shrdlu that the only value of an ISO implementation can only be expressed if we can say how said implementation affected our overall security risk - and we agree with Jenean that the primary benefit is an ability to have confidence in operations as supported by security, then….

The value of the ISO should be expressed as a KPI or set of KPIs that cleary explain how the confidence it generates helps us understand (and then reduce) our risk.

If risk is a probability issue,  ISO adoption helps generate confidence in our predictive analytics.  The dollar value the ISO generates (the ultimate KPI) is part of the cost of being able to make wise risk decisions.

So what is that (making wise risk decisions) worth to you?

SOME CONCLUDING THOUGHTS

First, it occurs to me that this is a real shame.  In a sense, an inability to generate a quantitative value statement for ISO use is simply more witch-doctory (“use it because we, the wise men of the tribe say you should”).  In some future version, the ISO should include some mechanism for measuring and expressing the worth of adoption to the organization (a better reason to use the ISO than “because we said so”).

Second, It should be noted that of Jack Jones’ 3 true value statements from which all metrics/KPIs should point to - we’re only talking about one of those value statements - the ability to reduce risk.  Using the ISO in an organization most certainly could create operational efficiencies (help us do more with less) - but the ISO isn’t a standard that creates operational efficiencies as a primary goal, nor does it give implicit direction on how to create operational efficincies.    The ISO folks do, however, play fast and loose with the idea of “risk” and “risk management” so it’s within this context that I interpreted our conversation.

Finally if you’re going to hire someone to help you with ISO adoption in your organization, the deliverables you ask for in your RFP/SOW/what-have-you should include quantitative (probability) statments about risk reduction and the creation of operational efficiencies.  If the firms answering can’t tell you what value their work will be to your company, then drop me a note and I’ll gladly point you to some friends of RMI’s that know FAIR & all our Risk Management frameworks and also do great ISO work.

She wiped out her husband's retirement account, mortgaged the house and took a lien out on the family car. Both were already paid for.

For more than two years, Spears sent tens and hundreds of thousands of dollars. Everyone she knew, including law enforcement officials, her family and bank officials, told her to stop, that it was all a scam. She persisted.

Spears said she kept sending money because the scammers kept telling her that the next payment would be the last one, that the big money was inbound. Spears said she became obsessed with getting paid.

An undercover investigator who worked on the case said greed helped blind Spears to the reality of the situation, which he called the worst example of the scam he's ever seen.

Before we delve into the intricacies of individual methods of anti-debugging let’s use this post to define the classes of anti-debugging that we will be discussing. While other classes may exist, the definition of these classes is an attempt to include the majority of anti-debugging methods in use today. There is some overlap between classifications and we may have left out some methods due to limited exposure or effectiveness.

API Based Anti-Debugging
API based anti-debugging is the most straightforward and possibly the easiest to understand for a typical developer. Using both documented and undocumented API calls, these methods query process and system information to determine the existence or operation of a debugger. From single line calls such as IsDebuggerPresent() and CheckRemoteDebugger() to slightly more complex methods including debugger detaching and CloseHandle() checks. These methods are generally trivial to add to an existing code base and many can even be implemented in as few as two or three lines.

Exception Based Anti-Debugging
Exception based anti-debugging is slightly different than your basic API based techniques. Many times when a debugger is attached to a process, exceptions are trapped and handled by the debugger without regard to passing the exception back to the application for continued execution. Occasionally these exceptions can even crash or terminate a process when run under a debugger and be handled gracefully when running clean. It is these discrepancies that makes exception based anti-debugging techniques possible.

Process and Thread Block Anti-Debugging
Some of the API based anti-debugging methods use published functions to query information from within the process and thread blocks for our running code. Many API based detections can be subverted within a debugger by hooking the API call and returning values that indicate a clean process. One way around this subversion is to directly query the process and thread blocks, bypassing the API calls. Direct analysis of the process and thread blocks, while more complex, can lead to a more accurate and high assurance result.

Modified Code Anti-Debugging
One of the methods that a debugger uses to signal a breakpoint is to insert a break byte into the running code at the location that it wishes to stop execution. The process execution breaks when this value is seen, giving control to the debugger. When the program is resumed, the breakpoint value is removed and replaced with the original byte, the execution backed up one byte, and the program is resumed. Detection of software based breakpoints can be achieved by analyzing the process for modifications from the expected norm.

Hardware and Register Based Anti-Debugging
A second way that a debugger can break the execution of a process is by using a hardware breakpoint. A hardware breakpoint relies upon CPU registers to store the pertinent information and to detect when the target break addresses are seen on the bus. A break interrupt is triggered at the appropriate time based on these register values. Reading or modifying the hardware can allow for the detection of a debugger.

Timing and Latency Anti-Debugging
Finally timing and latency can be used as an effective anti-debugging method. When executing a program within a debugger, specifically when single stepping, a much larger latency occurs between execution of instructions. This latency can be detected and compared against a reasonable threshold to detect the existence of a debugger attached to our process.

Each of the classes of anti-debugging outlined above has merit when used individually to protect a process. While none of them can be assured to ever protect a program from a determined reverse engineer or debugger, implementation of these techniques (or many of them if appropriate) can sufficiently slow down the debugging process and hopefully make the attacker spend his time on other, easier, ventures. In the remainder of this series on anti-debugging we will review in depth some of the more interesting methods of each of the above classes. So bring along your debugger and your development environment and let the games begin.

The Gartner Data Center Conference kicked off this morning in Las Vegas. Despite the completely packed plane coming out here, Vegas seems quieter and not so crowded. The bartender at Wolfgang Puck’s Bistro told me they were looking forward to the 1800 people coming to this show to fill the hotel up. As we’ve noted, the economic crisis is impacting business travel all around.

22% of the attendees at Data Center come from the public sector and government, with 44% coming from very large enterprises of 20K+ employees.

During the Gartner IOM conference in June, some of the most interesting info coming out of it was the quick polls of the audience on a variety of infrastructure and operations management topics. What are enterprises doing? Where are they headed? What’s important to them? Here are some quick takes from the opening session:

1) What is the largest data center challenge that you currently face?

• Smaller Budgets: 21%
• Power & Cooling: 20%
• Dealing with the Rate of Technology Change: 15%
• Aligning Activities with the Business: 15%
• Modernizing Legacy Applications: 10%
• Lack of Data Center Space because of Equipment Spread: 9%
• How to Source IT Services: 5%
• How to Find and Retain Talent: 5%

Well, it’s taken almost a year to be “official”, but the National Bureau of Economic Research just announced that the US has been in a recession since December of 2007. It should come as a surprise to no one that dealing with smaller budgets is top of mind, even for the predominantly larger enterprises attending here.

2) What projects will receive the most funding in 2009?

• Virtualization/Consolidation: 31%
• Data Center Facilities – new builds: 17%
• IT Operations Process Improvement: 12%
• IT Modernization: 7%
• Green IT: 5%

Virtualization and (server) consolidation projects are clearly a priority for larger enterprises in 2009. What’s interesting here is the relatively very low priority of Green IT projects – in spite of the importance to attendees of getting power and cooling costs under control. Perhaps there’s a gap here between what’s often the hype of Green IT and practical considerations for data center managers when it comes to power and cooling management.

3) Where are you with server consolidation projects?

• No Plans: 3%
• Looking at it now and will start in next 2 years: 13%
• In process now: 58%
• Have already completed server consolidation project: 26%

Larger enterprises are consolidating servers with a quarter of attendees already having gone through the process at least once. And according to poll #2, this trend will definitely continue.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts/topics.

1. Amazingly, this month by far the #1 post is my “'Blogging from DeepSec 2008 in Vienna.” DeepSec was indeed an awesome conference.
2. Last month, I said that “SIEM bashing reached a new high.” OMFG. What should I say now? I dunno. In any case, “11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!" is on the top list. BTW, “On Open Source in SIEM and Log Management” is also again on the top list, to much of my amazement.
3. Again and again, PCI compliance is obviously still all the rage: MUST-DO Logging for PCI? post was again propelled to a place in my monthly Top5 list.
4. Get a firewall AND a fire extinguisher, now, will ya? Is it too much to ask? :-) The post “On Small Companies and PCI Compliance” is on the Top list.
5. Shockingly, AGAINx2 :-) this month, the "Top 11 Reasons to Secure and Protect Your Logs" came up as on the Top list.  BTW, see my other logging polls and my other “top 11” lists.

See you in December. Also see my annual “Top Posts” (2007)

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - October 2008
• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007