Thursday, July 14, 2005

Auditors in Charge, but 0wn3d Anyway

I read in the latest SC Magazine this comment from Lloyd Hession, CSO of Radianz.

"'What is really happening is the head of security is losing control over the security agenda, which is being co-opted by audit and this umbrella of controls...

The ability to decide which security projects get funded is being taken out of the security officer's hands...

This focus on regulatory issues is causing a loss of control over the security agenda, which is being pushed and dictated by the audit and controls group and meeting the requirements of the regulation."

I see this focus on "controls" as more of the "prevention first and foremost" strategy that ignores the importance of detection and response. I had this reaction when I saw Dr. Ron Ross of NIST speak at a recent ISSA meeting. The NIST documents seem to focus on prevention through controls, and then they stop.

The unfortunate truth is that prevention eventually fails, as readers of the blog and my books know. While researching the Institute of Internal Auditors Web site, I came across this article which supports my theory. Here are the findings of Does Risk Management Curb Security Incidents? in brief.

  • Are organizations that have conducted an information security risk assessment less, more, or equally likely to have a documented information security policy? Yes.

  • Are organizations that have a documented information security policy less, more, or equally likely to implement system security measures? Yes.

  • Are organizations that have a documented information security policy less, more, or equally likely to implement information security compliance measures? Yes.

  • Are organizations that have a documented information security policy less, more, or equally likely to have an information security awareness program? Yes.

  • Are organizations that employ information security compliance measures, an information security awareness program, and system security measures less, more, or equally likely to experience security incidents? An analysis of variance (ANOVA) test failed to support the hypothesis (H5) that businesses that employ such programs and measures suffered fewer security incidents.


This is pathetically amusing. So, perform a risk assessment, document security policy, be compliant, teach awareness, and still be 0wn3d. It seems to me that, at the very least, some attention needs to be paid to the detection and response functions. Otherwise, a lot of money will continue to be spent on prevention, and organizations won't be any more "secure."

PS: The reference cited by the IIA article is available here. I originally visited the IIA to learn more about their Global Technology Audit Guides.

6 comments:

Phil Hollows said...

Great find! I couldn't agree more. Compliance!=Security. Absent trackbacks, I reference this at "Correlation Central" here:

http://www.openservice.com/blogs/2005/07/institute-of-internal-auditors-agrees.jsp

Chris Walsh said...

Compliance (with something silly) doesn't equal security. Of course. However, any auditor would point out that an extremely important category of controls is, you guessed it, detective controls. Maybe what I call the "checklist mentality" is more pervasive than it should be, but there's not reason that a control framework has to be at odds with a good (and that means effective) security regime.

Now, on the matter of still being 0wnd despite risk management practices being used. I haven't read the paper, but could it not be true that firms with more incidents (incidence of incidents?) are attacked more because they have more goodies (like PII or cash), and that absent risk management they'd be attacked even more? Could it be that firms with good risk management practices DETECT more attacks than those w/out such practices?

Keydet89 said...

The focus on prevention doesn't cover nearly as comprehensive a solution as one would think, particularly given the nature of some of the auditors I've had the...pleasure...of dealing with.

Prevent all you want...but I would suggest the results will be skewed due to the lack of attention to "detection". After all, how are the statistics populated, but by incidents that are revealed. Incidents that are not detected are by their very nature not revealed.

H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com

Joe said...

Sad but true. I agree that compliance goes not guarantee security.

On the bright side, once the policies and procedures required by compliance to various controls/standards are implemented, we can get back on track.

In some cases where companies have been very lax or have relatively insecure environment, these controls and requirements have been a blessing in disguise.

Trevor said...

I just came off a 3 week tool control testing engagement at a very large financial in the DC area. This is one of those gigs that leaves you jaded that the business world does not care about security.

Most of the controls I saw only worked as long as you were playing by the rules. For example:

App: Web based enterprise change control tool.

Control: Does the application enforce segregation of duties.

Status: Pass.

The application did not allow developers to promote code. However, I happened to notice that the web app had several *really* bad parameter manipulation issues that allowed a malicious user to bypass the functional controls. This broke compliance with the control.

When I asked the app owner "What if I manipulated input parameters?" the answer was "Who would ever do that???" The control testing proceedure did not cover electronic security testing. Just functional testing.

Most of the controls I was testing for keep great track of authorized and authenticated users. However, subvert application logic and all controls would technically fail.

Shirkdog said...

I would say negative reinforcement. The controls for NIST-026/NIST-053 are just a thorn in the side of a system owner until they are taken care of. In my stint as an ISSO, the main objective was compliance, not responsive posture. And like Trevor pointed out with his testing, the controls in place may not protect the system (i.e., they can be subverted), but at least they meet FISMA requirements :-)

(PS: test the quality of your third party auditors)