The Control Objectives for Information and related Technology -- or, COBIT -- were first released in 1996 by ISACA and have since been revised several times, the current version being 4.1. The full version of COBIT is available for free on ISACA's website.
COBIT is a management framework, not a technology framework. That is to say, it provides control objectives as opposed to the controls themselves (i.e., "Here's what you need to do," not "here's how you do it."). As a result, at no point does COBIT specify which technologies an organization should or shouldn't use. Rather, it gives a high-level framework that can be used to evaluate an enterprise's existing or planned controls: be they policies, processes or technologies. Also note that COBIT is not specific to information security, but is rather a general IT-oriented standard. COBIT helps auditors to know how inline an IT organization is with business requirements of all sorts, security included.
Each of the 10 sections of COBIT consists of four subsections: description, control objectives, management guidelines and maturity model. The description is a high-level overview of the section that follows; examples of sections include "Manage the IT Investment," "Define the IT Processes," "Organization and Relationships" and the most relevant section of COBIT for security practitioners, PO9, "Assess and Manage IT Risks." The control objectives are a high-level list of requirements. Samples of this in PO9 are:
Establish an IT risk management framework that is aligned to the organization's (enterprise's) risk management framework.
PO9.3 Event Identification
Identify events (an important realistic threat that exploits a significant applicable vulnerability) with a potential negative impact on the goals or operations of the enterprise, including business, regulatory, legal, technology, trading partner, human resources and operational aspects. Determine the nature of the impact and maintain this information. Record and maintain relevant risks in a risk registry.
PO9.5 Risk Response
Develop and maintain a risk-response process designed to ensure that cost-effective controls mitigate exposure to risks on a continuing basis. The risk-response process should identify risk strategies such as avoidance, reduction, sharing or acceptance and determine associated responsibilities and consider risk tolerance levels.
Note the lack of specificity in terms of policies, processes and technologies. It's up to each organization to determine what's necessary to meet the requirements COBIT lays out, then convince its auditor that what it's doing is sufficient.
After COBIT covers control objectives, next is management guidelines. This takes the control objectives and maps them according to which members of an organization should be responsible, accountable, consulted or informed (RACI) on how each control objective is actually implemented. This subsection additionally takes the control objectives and breaks them down into goals and high-level metrics to measure how close the enterprise is to achieving those goals. Two of the goals pertinent to information security teams are:
- To establish and reduce the likelihood and impact of IT risks.
- To establish cost-effective action plans for critical IT risks.
And these goals correspond to the following metrics:
- Percent of identified critical IT events that have been assessed.
- Number of newly identified IT risks (compared to previous exercise).
- Number of significant incidents caused by risks that were not identified by the risk assessment process.
- Percent of identified critical IT risks with an action plan developed.
Note that the goals are still high level , while the corresponding metrics, though high level, are more specific. The third metric is particularly telling, because it gives an idea of how good the risk profiles are.
Finally comes the maturity model, which gives auditors a framework for determining how mature an organization is in regard to a specific section. This is similar to the capability maturity model (CMM) used by programmers, and the new security maturity models, such as BSIMM and OpenSAMM. In COBIT, an organization gets ranked on a scale of 0-5 with 5 being the best. Case in point, compare levels 0, 3 and 5 from COBIT 4.1 for PO9:
3 Defined: When an organization-wide risk management policy defines when and how to conduct risk assessments. Risk management follows a defined process that is documented. Risk management training is available to all staff members. Decisions to follow the risk management process and receive training are left to the individual's discretion. The methodology for the assessment of risk is convincing and sound, and ensures key risks to the business are identified. A process to mitigate key risks is usually instituted once the risks are identified. Job descriptions consider risk management responsibilities.
5 Optimized: When risk management develops to the stage where a structured, organization-wide process is enforced and well managed. Good practices are applied across the entire organization. The capture, analysis and reporting of risk management data are highly automated. Guidance is drawn from leaders in the field, and the IT organization takes part in peer groups to exchange experiences. Risk management is truly integrated into all business and IT operations, is well accepted and extensively involves the users of IT services. Management detects and acts when major IT operational and investment decisions are made without consideration of the risk management plan. Management continually assesses risk mitigation strategies.
At this point, you're probably saying, "That's all well and good, but when I deal with the auditors, they aren't talking about control objectives or maturity models, they're asking me about firewalls, IDSes and access control lists. What does that have to do with COBIT?" And that's a great question. COBIT was designed to be combined with other popular frameworks such as ISO 27001, CMM and ITIL, which are more specific in their control recommendations, and ISACA has published guidelines on how to integrate these with COBIT.
Essentially, each audit company selects the list of controls that it feels best provides for an assessment of whether the COBIT control objectives are being met. They may pull or generate their controls from ISO 27001, SEC requirements, PCI DSS, or they may have their own preferred best practices. As a result, many, if not most, of the controls being requested by your auditors are negotiable either in terms of the degree to which you need to report on them, or if they're even necessary. So while you don't want to have an antagonistic relationship with your auditor, that doesn't mean auditors are always right or that you have to give them everything they ask for.
If you are looking for a framework on which to base your security program, COBIT is a great choice, particularly if you are going to pair it with ISO 27001 or another security standard. COBIT can provide the necessary context to ensure your program is properly addressing the business needs, while an accompanying standard, such as ISO 27001, will ensure the security program has the necessary maturity and the appropriate controls to actually secure the business. Either one without the other just isn't sufficient.
About the author:
David Mortman is a contributing analyst with Securosis LLC. Formerly the Chief Information Security Officer for Siebel Systems, Inc., David and his team were responsible for Siebel's worldwide IT security infrastructure, both internal and external. He also worked closely with Siebel's product groups and the company's physical security team and led up Siebel's product security and privacy efforts. A CISSP, Mr. Mortman sits on a variety of advisory boards including Qualys and Applied Identity and Reflective, amongst others. He holds a BS in Chemistry from the University of Chicago.
This was first published in March 2010