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.
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.
"'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.
Comments
http://www.openservice.com/blogs/2005/07/institute-of-internal-auditors-agrees.jsp
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?
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
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.
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.
(PS: test the quality of your third party auditors)