RE: SIM solution - Objectives ? (Firewall logging)
"Fenwick, Wynn" <[email protected]>
| Newsgroups | gmane.comp.sysutils.loganalysis |
|---|---|
| Message-ID | <4F9A5A48980E1B41A5CA803AA01961A001E61823@MTL-MSG-01.cgiclients.com> |
Paul, I am not suggesting that because 17799 is not prescriptive to period that we should not define a reasonable period. The fact that the standard is not prescriptive doesn't mean it shouldn't be. If you aggregate, archive, but monitor only over a ridiculously long period or do it with underqualified resources, then you are only "playing the game" to the letter of rule, not the spirit of the utilitarian ethic that created it. Compliance is often independent of effective safeguards. I am actually pointing out the fact that compliance does not manage any risk but the risks of being non-compliant, and that is regulation specific. Doing something useful should be mappable to all reasonable regulations. I personally like the pragmatic and prescriptive-where-necessary nature of PCI DSS for setting security objectives. They have to be, because people need to USE it TODAY. "A good plan executed today is better than a perfect plan executed at some indefinite point in the future." - Patton. Big three or not, the organization performing the audit are only as good as the subcontractors they use to perform activity. W -- Wynn Fenwick, GCIH, GCIA, ITIL Chief Techincal Architect, Managed Security Services CGI ISMC -----Original Message----- From: Paul Melson [mailto:[email protected]] Sent: Wednesday, May 30, 2007 5:26 PM To: Fenwick, Wynn; [email protected] Subject: RE: [logs] SIM solution - Objectives ? (Firewall logging) > If you look at ISO 17799 for log monitoring (where a lot of things > like COSO, CoBIT, and )they are not > prescriptive on the period of reconciliation. > > ISO17799-s10.10.2 (this could be old) calls for the creation of > procedures to monitor system use, and > review of the results of this monitoring shall happen regularly, including: > * Authorized access, > * Privileged operations, > * Unauthorized access attempts, > * System alerts or failures, and > * Changes to, or attempts to change, system security settings and controls. > > And yes, unless you wash the feet of the auditors after they step over > the palm branches laid before > them, "good enough" should suffice. I have to disagree and say that BS/ISO 17799 requires time frames (SLA's/OLA's) for both monitoring and review to take place and that a response to any exceptions be initiated. This is covered in 8.1.3 in the context of incident response and investigation. If you go the CoBIT/ITIL route, you will have to build additional controls around those time frames to prove that you're performing the review and the response and that you're doing both within the windows that you say you are. And at least where I work, both our internal auditors and our third-party auditors (from a Big 3 firm) ask for this proof. So, can you build something that is brainlessly 'compliant' using a rigidly literal interpretation of a standard combined with very weak internal P&P documents? Of course. But it's just teaching to the test. You're not accomplishing anything. You're doing work solely to make auditors happy. At that point your cart is so far out ahead that your horse can't see it anymore. PaulM