CMM And ISO 27001

CMM (Capability Maturity Model) is a model of process maturity for software development - an evolutionary model of the progress of a company’s abilities to develop software.

In November 1986, the American Software Engineering Institute (SEI) in cooperation with Mitre Corporation created the Capability Maturity Model for Software.

Development of this model was necessary so that the U.S. federal government could objectively evaluate software providers and their abilities to manage large projects.

Many companies had been completing their projects with significant overruns in schedule and budget. The development and application of CMM helps to solve this problem.

The key concept of the standard is organizational maturity. A mature organization has clearly defined procedures for software development and project management. These procedures are adjusted and perfected as required.

In any software development company there are standards for processes of development, testing, and software application; and rules for appearance of final program code, components, interfaces, etc.

The CMM model defines five levels of organizational maturity:

1.Initial level is a basis for comparison with the next levels. In an organization at the initial level, conditions are not stable for the development of quality software. The results of any project depend totally on the manager’s personal approach and the programmers’ experience, meaning the success of a particular project can be repeated only if the same managers and programmers are assigned to the next project. In addition, if managers or programmers leave the company, the quality of produced software will sharply decrease. In many cases, the development process comes down to writing code with minimal testing.

2.Repeatable level. At this level, project management technologies have been introduced in a company. That project planning and management is based on accumulated experience and there are standards for produced software (these standards are documented) and there is a special quality management group. At critical times, the process tends to roll back to the initial level.

3.Defined level. Here, standards for the processes of software development and maintenance are introduced and documented (including project management). During the introduction of standards, a transition to more effective technologies occurs. There is a special quality management department for building and maintaining these standards. A program of constant, advanced training of staff is required for achievement of this level. Starting with this level, the degree of organizational dependence on the qualities of particular developers decreases and the process does not tend to roll back to the previous level in critical situations.

4.Managed level. There are quantitative indices (for both software and process as a whole) established in the organization. Better project management is achieved due to the decrease of digression in different project indices. However, sensible variations in process efficiency may be different from random variations (noise), especially in mastered areas.

5.Optimizing level. Improvement procedures are carried out not only for existing processes, but also for evaluation of the efficiency of newly introduced innovative technologies. The main goal of an organization on this level is permanent improvement of existing processes. This should anticipate possible errors and defects and decrease the costs of software development, by creating reusable components for example.

The Software Engineering Institute (SEI) constantly analyzes the results of CMM usage by different companies and perfects the model taking into account accumulated experience.

ISO 27001

How the standard works

Most organizations have a number of information security controls. Without an ISMS however, the controls tend to be somewhat disorganized and disjointed, having been implemented often as point solutions to specific situations or simply as a matter of convention. Maturity modelstypically refer to this stage as "ad hoc". The security controls in operation typically address certain aspects of IT or data security, specifically, leaving non-IT information assets (such as paperwork and proprietary knowledge) less well protected on the whole. Business continuity planning and physical security, for examples, may be managed quite independently of IT or information security while Human Resources practices may make little reference to the need to define and assign information security roles and responsibilities throughout the organization.

ISO/IEC 27001 requires that management:

§  Systematically examine the organization's information security risks, taking account of the threats, vulnerabilities and impacts;

§  Design and implement a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable; and

§  Adopt an overarching management process to ensure that the information security controls continue to meet the organization's information security needs on an ongoing basis.

While other sets of information security controls may potentially be used within an ISO/IEC 27001 ISMS as well as, or even instead of,ISO/IEC 27002 (the Code of Practice for Information Security Management), these two standards are normally used together in practice. Annex A to ISO/IEC 27001 succinctly lists the information security controls from ISO/IEC 27002, while ISO/IEC 27002 provides additional information and implementation advice on the controls.

Organizations that implement a suite of information security controls in accordance with ISO/IEC 27002 are simultaneously likely to meet many of the requirements of ISO/IEC 27001, but may lack some of the overarching management system elements. The converse is also true, in other words, an ISO/IEC 27001 compliance certificate provides assurance that the management system for information security is in place, but says little about the absolute state of information security within the organization. Technical security controls such as antivirus and firewalls are not normally audited in ISO/IEC 27001 certification audits: the organization is essentially presumed to have adopted all necessary information security controls since the overall ISMS is in place and is deemed adequate by satisfying the requirements of ISO/IEC 27001. Furthermore, management determines the scope of the ISMS for certification purposes and may limit it to, say, a single business unit or location. The ISO/IEC 27001 certificate does not necessarily mean the remainder of the organization, outside the scoped area, has an adequate approach to information security management.

Other standards in the ISO/IEC 27000 family of standards provide additional guidance on certain aspects of designing, implementing and operating an ISMS, for example on information security risk management (ISO/IEC 27005).

 

OR

ISO/IEC 27001:2005  Information technology — Security techniques — Information security management systems - Requirements

ISO/IEC 27001 is the formal set of specifications against which organizations may seek independent certification of their Information Security Management System (ISMS).

ISO/IEC 27001 specifies requirements for the establishment, implementation, monitoring and review, maintenance and improvement of a management system - an overall management and control framework - for managing an organization’s information security risks.  It does not mandate specific information security controls but stops at the level of the management system.

The standard covers all types of organizations (e.g. commercial enterprises, government agencies and non-profit organizations) and all sizes from micro-businesses to huge multinationals.  This is clearly a very wide brief.

Bringing information security under management control is a prerequisite for sustainable, directed and continuous improvement.  An ISO/IEC 27001 ISMS therefore incorporates several Plan-Do-Check-Act (PDCA) cycles: for example, information security controls are not merely specified and implemented as a one-off activity but are continually reviewed and adjusted to take account of changes in the security threats, vulnerabilities and impacts of information security failures, using review and improvement activities specified within the management system.

According to JTC1/SC27, the ISO/IEC committee responsible for ISO27k and related standards, ISO/IEC 27001 “is intended to be suitable for several different types of use, including:

Use within organisations to formulate security requirements and objectives;

Use within organisations as a way to ensure that security risks are cost-effectively managed;

Use within organisations to ensure compliance with laws and regulations;

Use within an organisation as a process framework for the implementation and management of controls to ensure that the specific security objectives of an organisation are met;

The definition of new information security management processes;

Identification and clarification of existing information security management processes;

Use by the management of organisations to determine the status of information security management activities;

Use by the internal and external auditors of organisations to demonstrate the information security policies, directives and standards adopted by an organisation and determine the degree of compliance with those policies, directives and standards;

Use by organisations to provide relevant information about information security policies, directives, standards and procedures to trading partners and other organisations that they interact with for operational or commercial reasons;

Implementation of a business enabling information security; and

Use by organisations to provide relevant information about information security to customers.”

The information security controls from ISO/IEC 27002 are noted in an appendix (annex) to ISO/IEC 27001, rather like a menu.  Organizations adopting ISO/IEC 27001 are free to choose whichever specific information security controls are applicable to their particular information security situations, drawing on those listed in the menu and potentially supplementing them with other a la carte options (sometimes known as extended control sets).  As with ISO/IEC 27002, the key to selecting applicable controls is to undertake a comprehensive assessment of the organization’s information security risks, which is one vital part of the ISMS.

History of ISO/IEC 27001

ISO/IEC 27001 was born as BS 7799 Part 2 in 1999.  It was revised by BSI in 2002, explicitly incorporating Deming’s Plan-Do-Check-Act cyclic process concept, and was adopted by ISO/IEC in 2005.

Along with ISO/IEC 27002, ’27001 is currently being revised.  Comments and contribution from national standards bodies are welcomed by SC27.  Please contact your national standards body (e.g. BSI, NIST) or ISO directly for further information or to offer your assistance with the standards development process and ISO/IEC JTC 1/SC 27 in particular.  This is your big chance to get involved and influence the future direction of this well-respected information security standard!

The revised standard seems likely to be published in 2012.

 Since ISO/IEC 27001 is an active certification standard, major/structural changes will be difficult and even minor changes will have to be justified in order to retain “backwards compatibility” with the existing standard wherever possible.  Nevertheless, there is pressure within SC27 to realign 27001 with 27000, 27002, 27003 and 27005, reducing duplication and potential conflict.  Furthermore, the ISO TMB JTCG Task Force on Management System Standards wishes to align all the ISO management systems standards for information security, quality management, environmental management etc. to a common structure, using common text for identical clauses (albeit with explanatory notes to clarify their interpretation in the specific context of each management system).  The common structure and text is still in draft but looks set to become “ISO Guide 83”.

In addition to detailed comments on the contents of the main text of ‘27001, Annex A prompted many comments from national standards bodies.  The question of what if anything ‘27001 should specify regarding information security policies and/or policies or strategies for the ISMS is also under discussion.  SC27’s decision to remove explicit description of the “PDCA model” from ‘27001 has not been universally welcomed, but it looks as if the PDCA coverage in ‘27000 may be increased in order not to lose the value of the structured approach to periodically reassessing infosec risks and controls and hence continually refining the ISMS.

Latest available status info

The revision to ’27001 is progressing well.  SC27 will  give feedback to JTC1/TMB regarding the proposed alignment of all the ISO  management systems standards.  With a lot of  work, the imposed structure and text has mostly been incorporated successfully into ’27001, with just a few areas of concern.  The first CD of the revised standard is due to be released to SC27 in the middle of 2011.

Structure and content of ISO/IEC 27001

ISO/IEC 27001:2005 has the following sections:

0  Introduction - the standard uses a process approach.

1  Scope - it specifies generic ISMS requirements suitable for organizations of any type, size or nature.

2  Normative references - only ISO/IEC 27002:2005 is considered absolutely essential to the use of ’27001.

3  Terms and definitions - a brief, formalized glossary, soon to be superseded by ISO/IEC 27000.

4  Information security management system - the ‘guts’ of the standard, based on the Plan-Do-Check-Act cycle where Plan = define requirements, assess risks, decide which controls are applicable; Do = implement and operate the ISMS; Check = monitor and review the ISMS; Act = maintain and continuously improve the ISMS.  Also specifies certain specific documents that are required and must be controlled, and states that records must be generated and controlled to prove the operation of the ISMS (e.g. certification audit purposes).

5  Management responsibility - management must demonstrate their commitment to the ISMS, principally by allocating adequate resources to implement and operate it.

6  Internal ISMS audits - the organization must conduct periodic internal audits to ensure the ISMS incorporates adequate controls which operate effectively.

7  Management review of the ISMS - management must review the suitability, adequacy and effectiveness of the ISMS at least once a year, assessing opportunities for improvement and the need for changes.

8  ISMS improvements - the organization must continually improve the ISMS by assessing and where necessary making changes to ensure its suitability and effectiveness, addressing nonconformance (noncompliance) and where possible preventing recurrent issues.