Improving Security with ITIL: How to Respond to Security Incidents Part I
ITIL includes practices for incident response. Since the framework is broadly focused on IT management, it includes more than just security incidents covering topics like application errors, hardware failures and service requests. The basic parts of incident response from an ITIL perspective are good starting points for security incident response but some elements are more complex in the security area than in others.
For starters, ITIL’s incident response covers:
• Detection and reporting
• Classification of incidents
• Investigation and diagnosis
• Resolution and recovery
• Incident closures
• Incident monitoring
This is an obvious and methodical approach; perhaps its biggest attribute is that it lays out the logical sequence of how to respond to incidents. From a security perspective, the payoff comes in the details.
For example, how are security breaches detected? Do security measures like firewalls, anti-virus software, and network devices log events that are automatically filtered and then analyzed by system administrators? The justification for this is obvious. How would you like to have a data breach like the one at TJX and not know about it right away?
Classification of incidents should be based on information classifications. Organizations should know which data is public, sensitive, confidential and private. (For more on this kind of classification see the SANS Insititute’s example information sensitivity policy. The breach of a server housing public data warrants timely response but you don’t need to bring the same resource to bear as if private customer financial data had just been stolen. Again, the key is to know how to respond based on the threat to the organization and its customers, clients, and others who have data within its systems.
There will be more on incident response in the next post.
Email This!
Digg it!
Sphere it!
Del.icio.us
Reddit!
Newsvine
