24 Nov

Change Management: Internally Initiated Changes & Control Environment

The Change Management Process (a.k.a CMLC) is one of the most vital processes for any IT Auditor or Security professional to understand when assessing an organization’s risk universe. In general, there are three key change management life cycles that exist within most organizations:

1. Internally Initiated Changes – Changes that are internally initiated and controlled (i.e., periodic software updates, scheduled patches, request from employees, etc.) What this post covers!

2. Externally Initiated Changes – Changes that are initiated from entities outside the company (i.e., software fixes, unscheduled security patches, requests from customers, customizations, etc.)

3. Infrastructure Changes – Changes to hardware and infrastructure (i.e., servers, computers, firewalls, etc.)

It is important to understand that each of these three processes may follow very different paths during the Change Management Life Cycle and present very different risks to the organization.

Risk Statements
1. The risk that changes to systems result in fraud or security breaches due to lack of testing and/or approval.
2. The risk of system downtime, operational failures due to invalid system changes.
3. The inability to perform data bench-marking and root-cause analysis due to not tracking or documenting changes.

 

Internally Initiated Changes and the Control Environment

Below is an example of a standard change management workflow and associated controls for internally initiated changes.

Graphic by Christian Hyatt. No use without credit.

Graphic by Christian Hyatt. No use without permission.

 Mitigation Strategies

Note: Updated 11/25/2014 from questions in comments.

Some small development teams do not have the staff to sufficiently enforce SoD so there are a variety of options that may mitigate the risks.

We’ll take the example of a developer having access to production:

1. Implement an alert system that alerts management and the development team any time there is a change implemented to production.
2. Implement a log and periodic review of changes implemented to production. The review should be frequent – such as weekly.
3. Implement a peer implementation system where a developer is never implementing their own work. This is enforced by policy and procedure and should be documented in the change management documentation for each change.
4. Consider requiring the developer packaging up the change and letting a manager “press the button” to implement into production. This allows the developer to do the technical “heavy-lifting” without having access to manipulate production or implement without approval.

6 thoughts on “Change Management: Internally Initiated Changes & Control Environment

  1. if there’s an SOD issue within the change management (i.e. developer has access to production), is there any other mitigating control that can be in place apart from monitoring the changes implemented in production? also, monitoring the implemented changes is different from the CAB meeting, right? (the former is after change had been migrated while the latter is before change is migrated.)

  2. Some small development teams do not have the staff to sufficiently enforce SoD so there are a variety of options that may mitigate the risks.

    We’ll take the example of a developer having access to production:

    1. Implement an alert system that alerts management and the development team any time their is a change implemented to production.
    2. Implement a log and periodic review of changes implemented to production. The review should be frequent – such as weekly.
    3. Implement a peer implementation system where a developer is never implementing their own work. This is enforced by policy and procedure and should be documented in the change management documentation for each change.

    Regarding the CAB, you are correct. The CAB is the committee that is typically responsible for final approval of changes prior to moving to production.

    • hey christian,

      thanks for your response. yeah, i was actually looking at other compensating controls just because SOD is not possible. i don’t think 1 is feasible on a cost perspective. 2 is what i’m proposing but i was looking at other possible controls. 3 is not possible in my client as well just because there’s only 1 developer. so yeah, i guess it’s just the review/monitoring then. thanks again!

      • They could also consider letting the developer packaging up the change and letting a manager “press the button” to implement into production. There being only one person to develop, test, and implement presents a lot of risk. It is worth asking what advantage they gain by giving the developer access to prod.

        Regarding the review, if there are frequent changes implemented to production the review of logs may be difficult yo execute because so many files change in the course of implementation. Also, I assume a non-developer would be performing the review so it raises questions as to of the review would be sufficient.

  3. Good post. Two other items you might want to adjust. 1) the arrow between the 2nd and 3rd box has 2 arrow heads; should only have one, going from box 2 to 3?

    2) In mitigation #1, change “their” to “there”.

    Mack

Leave a Reply