In my three-part discussion on change management, I've covered its importance as a formalized strategy, and how to deal with security event volume. This last section will briefly touch on the role of change management in identifying unauthorized change.

The value of this capability for risk control is very high. A single case of file change without a corresponding change authorization can highlight troubling issues and generate activities in relation to them.

Scenarios that generate unauthorized change events are numerous.  Is it a policy breach where someone neglected change management? Then education is applied. Has an attacker modified a vulnerable web site? Then an incident response plan is engaged and protection put in place.

The same model works for other security software, as well. Intrusion detection systems (IDS) are notorious for being event generators. Being able to match IDS events to a recent change drastically reduces the investigation time.  An example could be the installation of a new product that includes a browser "help" bar, which is also spyware. This example would generate both IDS and anti-spyware alerts, both of which would be matched back to the approved installation of new software. The administrator working the event can use this information to directly address the issue.

Change management is classically an operational tool for preventing system outage. It should also be well-respected by the savvy security professional as another tool for reducing risk and acting as a force multiplier.

Further Reading

Change Management: A Hidden Security Tool - Part 1 of 3
Change Management: Event Volume - Part 2 of 3

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

This is the first of three postings I will share pertaining to change management.

The importance of change management for the stable operation of data support systems cannot be denied. Data center operations literature, such as ITIL guidelines, have change management looming large as part of any solution. One of the metrics I have heard is that 80% of system outages can be attributed to a change event.

As a hosting services company, GSI takes change to any environment very seriously. Controlling that change can, literally, affect our bottom line. Even so, change management is one of the "behind-the-scenes" services and processes that is rarely advertised directly or attributed with value. A system outage will bring attention to a lack of change management, but never is change management mentioned when it prevents outages. Much like a utility provider being discussed when a home's power is on, but let the power go out and the first discussion is about the provider.

Since becoming Director of Security and Compliance at GSI, I have become familiar with GSI's role in securing our client's data. I realize that change management and the well-designed implementation of it, are a critical piece of my security software suite. Of course, the PCI DSS includes a requirement (6.4) for change management, but it could be more emphasized and has missed the true security value.

How important is implementation?

I will take a few lines here to briefly discuss GSI's implementation of our change management methods. The implementation, in many ways, is as important as the use of the result.

Who
Any operational staff or client can generate a change request. It is very important that accessibility to the change management system be open. Restricting it to special access would prevent its usage which defeats the purpose of its existence. Power to approve changes is purposefully kept to a small number of management staff, but submitting a change is open.

When
Everyday. A selected team at GSI reviews change requests every day. An hour of every day is set aside by operations managers and me to review change requests for approval. It can be tedious given that any client or operational staff member can submit requests, but the value of discussing, understanding and debating changes is well worth it. Scheduling the review for every day allows us to granularly adjust the amount of impact in data systems due to change. It also supports security efforts.

What
All hosts. The structure and restrictions for controlling change are applied to data systems with regards to their criticality. The change management support systems and procedures are built to accommodate that need. This flexibility allows GSI to apply levels of change management even when tolerance for the control is very low. Compliant systems are held to strict standards of control, and the procedure provides that capability, as well.

Obviously there is more to the entire system than described here, but you should get the notion that implementation must be robust.

Next week, I'll share another article where I talk about the role of change management in dealing with security event volume.

Further Reading

Change Management: Event Volume - Part 2 of 3
Change Management: Identifying Unauthorized Changes - Part 3 of 3