Back in 2004, Forrester paper called "The Natural Order Of Security Yields The Greatest Benefits" proclaimed that "the adoption of security has a natural order: 1) authentication; 2) authorization; 3) administration and 4) audit." Note that audit which, in this case, broadly includes audit, monitoring and detection, comes last. It seems to be fairly in line with common sense: you audit the controls after you put them in place; you monitor after you have authentication and authorization taken care of and you detect the violations after you organized your administration.
The paper even had the following picture, which is presented here to illustrate the point:
(source: Forrester paper named above)
The paper clarifies: "With people and contexts defined, protective controls in place, and policies outlined, the
fourth set of questions [i.e. regarding the audit] includes: “What happened?”, “What is happening?” or, especially, “Is
it working?”
However, is this really so? Or, is this always so? First, when reality collided with plans, many of the organizations that followed that wisdom got mired in one phase (e.g. in trying to get authentication under control) and ended up having no audit whatsoever: in other words, they are flying blind while implementing controls! Second, in some cases controls (authentication, authorization, administration) will actually be impossible to implement, while audit will be possible. Imagine retrofitting a legacy application for granular authorization? Third, in some cases implementing prevention/control will be much more complicated, compared to implementing audit: thus, people will face a choice between a half-baked control to a full-blown audit capability? An example will be managing which file each user can access vs monitoring/auditing which file each user have accessed. The latter is doable, while the former is next to impossible. Another way to phrase it is "reactive but possible" vs "proactive but impossible" (hint: pick the former :-))
I think the idea of putting audit first in some cases is the way we'd need to progress. "Wow, what a blasphemy!", some might say ... After all, if you have not defined controls, what are you going to audit? But remember that audit is meant broadly in this context and thus the opposite question is very relevant: what are you going to control if you have no idea what is going on? People sometimes define a security policy based on how things should be (and then WSJ happens :-) - refresh your memory of the "WSJ saga" here), but then spent years trying to bring policy and reality together (and end up with an environment which is "half-controlled") Won't it be better to audit first, then control?
Obviously, "do IDS before IPS" falls under the same principle: monitor first, [try to] control second. Here is another example: implement log management before identity management. Looking at logs will tell you what privileges the users actually use for doing their daily jobs. Then you can mix it up with what the idea access policy will be.
So, think about it! Questioning the common wisdom does often bring interesting insights.
4 comments:
Hi Anton.
I agree with you to some extent. There is certainly value in audit involvement at or even before the design phase of a development project, for example, and I'm personally a fan of longitudinal audits in this case - tracking and contributing to the project from business case through to post-implementation review, basically providing consultancy advice on project and information security risk management etc. while also providing an independent check on the project's progress for management. I'm well aware of the risk of getting too involved in the project but so long as those involved keep in mind that the auditors are working on behalf of management and other stakeholders, not the project manager, and so long as the auditors follow standard audit working practices, it's fine by me.
But I guess one could argue that this is auditing in parallel with controls implementation, neither before nor after.
Kind regards,
Gary
PS Your closing remark perhaps indicates that you are an auditor: 'questioning the common wisdom' is one of audit's functions. Other ways to put it include 'robust challenge' and, of course, 'independent review'.
That's a good point! I tried to argue that it is NOT after (which kinda means before), but in reality it is in parallel.
And, I am not an auditor, but maybe spent too much time around them :-)
Auditing is becoming an oft-used term for lots of things.
Auditing, to me, is not necessarily about monitoring. Monitoring is an information-gathering function that can and should be done before, during, and after. It's like reading logs, just hopefully after all of the other steps you're reading logs more efficiently.
Auditing, to me, is synonymous with scoring. You score yourself before to see how bad you are or what you need to do. You then score yourself after. Another way to explain it would be verifying your intentions. You audit to make sure you're doing what you said you'd do, or to check controls. When I leave my house I lock the door then audit the knob. When I lock my car, my eyes audit the process by looking for the flash of the running lights.
Monitoring is used by the audit (scoring) function.
That's just kind of how I look at it.
Unconsciously ignorant, consciously ignorant, consciously informed, unconsciously informed... The above paper kinda leaves out the Unconscious parts book-ending the process.
Good comment - I am happy that you guys don't fully disagree :-)
Post a Comment