We all know the propensity of organisations to jam things into the compliance/mandatory bucket, and security/compliance projects for IT are no exceptions. While this is a vendor (rather unfortunate name I would have said) driven white paper, its refreshingly pragmatic and tells it how it is in terms of what can be required and what areas to see when the IT folks walk in asking for funding or sponsorship. Similarly, if we want to setup something which is good and relevant for our applications and security, some guidance needs to be given to the IT folks. This paper can assist COO's, auditors, PMO's, service delivery and change management folks who frequently have to deal with this from an up or downstream perspective. I quote the top piece :
Top Five Compliance Myths
Myth #1: Compliance equals regulations with speci!c actions
The reality: Most regulations have fuzzy or no detail about IT
implementation. And many compliance demands arise from
internal assessments of risk of business disruption or litigation. You
need to engineer for compliance just as you engineer for availability.Myth #2: Compliance is an IT security issue.
The reality: Sure, a lot of compliance mandates have a security
dimension because they are trying to control the risk of things like
information leakage and sabotage. But just as many mandates are
concerned with the integrity and availability of mission-critical
applications, and so preventing, detecting and responding to
ordinary failures matters just as much. And beyond that, there are a
lot of mandates that govern business issues such as use of insider
information, which are really outside the realm of IT although IT
systems play a role in recording the evidence.
Myth #3: I have to store my original logs for 7 years.
The reality: Where does it say that? Almost no mandates, and
certainly not the most common ones concerning IT departments,
specify log retention times. Log retention times are driven by
assessments of what it will take to service other requirements such
as the need to investigate incidents, detect long term patterns, and
prosecute intruders. You may want to keep 7 years available, but you
may choose different strategies for more recent vs archived data.
Myth #4: A speci!c set of reports will make me compliant.
The reality: See Myth #1. The regulations almost never list a specific
report. There are reports that can clearly assist with particular
requirements, such as the need to review failed logins, but they
require a lot of fine-tuning for each unique environment. At best, a
set of standard reports is a starting place. The dirty secret: most
compliance report packs are developed by product managers
reading the regulations and taking a guess at what kinds of reports
might be helpful.
Myth #5: I need to buy a commercial solution to be compliant.
The reality: Your decision to buy a log management system rather
than roll your own logging infrastructure should be based on ROI. A
well designed system should save you on initial development and
integration as well as make ongoing log reporting, ad-hoc analysis
and alerting more efficient. But the regulations don’t say you have to
buy a commercial system, and the vendors of these systems don’t
have any special insight into what it takes to make you compliant.
So if these are myths, what’s the truth?
No comments:
Post a Comment