SERVICES

“COBIT provides good practices across a domain and process framework and presents activities in a manageable and logical structure” (COBIT, 2006, p.6).  The four domains are comparable to the life cycle of a system (see Appendix).  Components of these domains are the 34 processes to plan, build, run, maintain and monitor the system.  The high-level objectives align with business objectives.  Managing changes is the sixth process under the Acquire and Implement (AI) Domain (COBIT, 2006). The high-level control objective for AI6 states:

All changes, including emergency maintenance and patches, relating to infrastructure and applications within the production environment must be managed in a control manner.  Changes (including procedures, process, system and service parameters) must be logged, assessed and authorized prior to implementation and reviewed against planned outcomes following implementation.  This assures mitigation of the risks of negatively impacting the stability or integrity of the production environment. (p.93)

Note the very broad scoping for this definition of managing changes.  Only an organization with a reasonable level of maturity could fulfill it.  Resistance from within can arise from the lack of organizational structure and assignment of responsibility.

After the control objective, techniques are offered to meet the objective.  These techniques direct technological auditors, management, users or any stakeholder in the direction of fulfilling the objective.  IT goals, key controls and key metrics provide techniques to satisfy the objectives.  For example, an IT goal is to halt the implementation of unauthorized changes by: 

• Defining and communicating change procedures, including emergency changes
• Assessing, prioritizing and authorizing changes and
• Tracking status and reporting on changes.

The process for Manage Change concludes with its benchmarks in terms of a maturity model.  Note its maturity model starts at the zero level, non-existent, where there is no defined change management process and there are virtually no controls for changes (COBIT, 2006 p. 93-96).

Humphrey (1990) presents more specifics for the maturity models and managing the software change process in his book Managing the Software Process published by the Software Engineering Institute.  (Note that from a sociological perspective that soft was referring to people whereas to the technical minded it is referring to the written logic of technology, the code).  A reasonable solution to this dilemma is to fully involve people in the software process, which SEI attempts to do.  The code is not just technical manifestation of technology but a carefully designed product of human intervention.  Humphrey presents six principles to manage the software change process:

Adhering to such principles can help effectively manage the change process and prevent crisis mode management.

            The SANS Institute presents concepts to address and implement changes, although their perspective is from a network view.  According to Milroy, all network environments change over time whether planned or not.  Just as the COBIT and the SEI look for policy to govern the change process, so does Milroy, a contributing writer for the SANS Institute.  Thus, Milroy expects change control policies to help minimize the inadvertent creation of security openings.  An exposure is recognized when implementing planned, unplanned, or recovery changes to a company’s network environment (Milroy, 2001).