These days, when the news talks about IT, the topic is usually security, and more specifically, security related incidents that have compromised the network or data storage of a major corporation, with massive data losses and significant negative impacts on the organization’s credibility and reputation.  Why is it that responses to these incidents, in many cases, are extremely slow?

Within IT departments, many chief information security officers (CISOs) are focused on prevention—and rightfully so.  However, as most CISOs know, achieving 100 % protection is not realistic, because many of the biggest security threats are internal—from the phishing of employees to insecure laptops and missing security patches.  What separates well-secured organizations from the rest of the pack is how quickly their security teams respond when an actual security-related incident occurs.  Luckily, many of the best practices from the incident management process within IT service management frameworks, such as ITIL, can be followed.  However, security incident response is not as simple as responding to a typical non-security-related incident.

Since many of the most difficult to handle incidents come from internal th
reats, it is first critical to restrict access to security-related data to the “need to know” personnel within an IT department.  Another problem is that many security organizations handle  incidents using antiquated methods like  logging and spreadsheets and don’t take advantage of the same intelligence that standard and major incident processes do.  When security-related incidents are managed in standalone spreadsheets and applications, investigators do not have easy access to the relationships available within the CMDB.  With access to the CMDB, significant amounts of time can be saved in:

• Responding to and getting to the resolution of a security incident
• Relating security-related incidents to non-security-related incidents
• Following the problem management process to determine the root cause of security-related problems

The big news is that, over the course of the past year, some of the more progressive software vendors have figured out this need and are allowing their customers to separate security-related incidents while taking advantage of other IT service management processes, data, and reporting within their technologies.  However, software alone doesn’t fix this growing problem.  Think people and process first!  The keys to getting this right is to make sure the people within security organizations (1) understand how leveraging the CMDB can help them, (2) follow an agreed upon incident management process, and (3) are held accountable to incident response targets dictated by the business.

So if you are focused on ITSM or IT operations for your day to day role, start having conversations with the security teams within your organization, as they are probably already trying to figure this out on their own and, in many cases, are in the dark when it comes to the art of the possible.