Category Archives: Processes

Process, Process, Process

Security is not a state. It is instead a process, a method by which you operate. Today I will be starting a series explaining several of the important processes that are critical for information security. First will be change control, the process by which technology and their derivative processes are modified. It is a formal method of control by which you ensure that changes that are introduced to a system in a coordinated method.

This process, when correctly utilized, apply to any configuration modification. The obvious requirement to begin the process is a desire to implement something that will increase value to whomever utilizes it. Once something exists that can do so, the following steps can begin.

Change management is typically seen as a process involving six steps. Each of them is a clear checkpoint that can be used to not only evaluate how the given change is progressing, but how to undo it when necessary.

Step 1: Record

In the first step, a proposal is made. This proposal will result in the modification in one or more configuration items, or CIs. These are identified as anything under the control of the change management system, which should in theory be the entirety of an information infrastructure. Included in the proposal should be the importance of the change, the complexity of implementing it, and the impact of doing so.

Step 2: Access

The proposal should be directed to change management. Management should be an individual or team that will then determine the risk of implementing the proposal as well as who will be responsible for doing so. Teams should involve anyone with any stake of the involved CI(s) should be involved in these determinations, although not necessarily with veto.

Step 3: Plan

Once the determination is made to move forward with a change, the person(s) determine to have ownership of the change take over. They will determine the specific implementation of the change in question, step by step, in detail. Additionally, a plan for rolling back the change must be prepared before it can go further. This is because any modification of a system can have something go wrong either in the planning or implementation stages. For instance, what would be done if the change effects something that wasn’t anticipated, or during the change a power outage occurs and the modification breaks?

Step 4: Build

With the plan completed, it is sent to the stakeholders identified in step two. With their approval, or modifications based on critique, the plan can begin. In this stage, any work necessary prior to its installation is done. This can include creating any configurations that are necessary for the change and staging them. Additionally, testing is done on anything staged to ensure that when installed the change will function as desired. This is where having reliable unit testing is invaluable.

Step 5: Implement

With testing complete, the change is ready for implementation. Once again, the implementors work with stakeholders to plan for the time to do so. The change is then implemented according to that schedule. If necessary, the regression plan decided upon in step three is activated and the change rolled back. Otherwise, a post-implementation assessment is done, and stakeholders report on any adjustments that need to be made either to the change or the change process in the future.

Step 6: Close

The final stage is the simplest to explain, but sometimes the most complex. This is where stakeholders agree that the change has been successfully implemented. While easy in theory, with poor planning in stage three this stage can go on for some time. With proper planning, however, this stage can be as short as a single meeting.

What makes this process important is that it introduces regularity to updates. Patches are necessary for maintaining a technically secure environment. Without regularity, security updates become few and far between as a result of the trauma it can cause.

Vulnerabilities are defined through Common Vulnerability and Exposure numbers, or CVEs. In 2009, the average time between a CVE and exploitation was a mere ten days (warning: PDF). By the end of 2012, some exploitations were found within hours of vulnerability discoveries. Faster change management procedures allow for minimizing exposure, and make it fundamentally important to security.