In my first article, I introduced how companies can benefit from a formalized change management strategy. This week, I want to talk about a second important factor related to change management – dealing with security event volume.
Every serious information security wonk understands that security software can generate large numbers of events. The volume can be staggering with just a few systems, and for each increase in the number of systems, the event volume grows exponentially.
Logins, object access, file changes, internet attacks, virus alerts and intrusion detection events can have the combined effect of disabling a security team's capability to detect risk. Highly secure or compliant environments could easily require a security staff similar in size to operational teams just to control risk while providing for regulatory compliance. GSI takes a delegated approach.
It turns out that most data center operational teams have significant amounts of down time. GSI is more than just a data center operator; we are more of a secure data systems management company that happens to run a few data centers. Even so, the operations staff still has floating downtime when all they do is monitor system status. So I use that time for security events.
Every operations member is obsessively focused on our support ticketing system and rightly so. It is the primary mechanism for supporting our clients. Additionally, operations must respond and address every support ticket within time limits to meet service level agreements. It turns out that if I can put security tool events into the support system and provide specific instructions, then my capability to work events is equal to that of a security team the size of operations. A discussion of the need to engage an entire IT staff in security functions is not for this posting, but you get the idea.
So we have our security software events and we have a staff of folks to review and work them. How does change management affect how the events are worked?
The easiest example to explain is File Integrity Monitoring (FIM). GSI currently uses TripWire for FIM to detect changes in files deemed critical for risk control. The file list is long and amounts to operating system files, configuration files and website source files. A single MS patch cycle can generate thousands of events across hundreds of servers at once.
We use our change management system to track and approve patches to systems. Before the first file change occurs, the change management team will review and record approval for it to happen. When the FIM system generates alerts about file changes directly into the support ticket system, any team member on duty can check for "approved" changes associated with the affected system. A positive identification of authorized change stops the investigation with no more time dedicated to the issue. More poignant, for security at least, is that an unauthorized change is just as quickly identified. Stay tuned for next week's posting, when I talk about the value of change management in identifying unauthorized changes.
Further Reading
Change Management: A Hidden Security Tool - Part 1 of 3
Change Management: Identifying Unauthorized Changes - Part 3 of 3