About O-ISM3

O-ISM3 is an information security management maturity standard published by The Open Group, a leader in the development of open, vendor-neutral IT standards and certifications. The O-ISM3 Standard defines security processes for managing an enterprise’s Information Security Management System (ISMS). The O-ISM3 Standard places the onus on the business to define its required business security targets in its Security Policy, and then offers a set of security management processes from which the business selects which ones to deploy in a coherent ISMS. Each security control process in the ISMS then returns metrics to indicate how well that process is contributing towards achieving the business's security targets. The O-ISM3 Standard metrics feedback is a major differentiating feature compared with other ISMS systems, because it enables the ISMS manager to present quantitative evidence (as opposed to qualitative subjective judgements) to show:

  • Which security control processes are revealing IT operational areas that are under-achieving regarding security targets
  • Which processes need to be tuned to improve performance to achieve or exceed critical targets
  • Which processes are not contributing sufficient to justify continuing to use them

The ISMS manager is thereby informed on which processes to retire and which to add to their ISMS. (More) Importantly, they are also informed with metrics that they can report as objective evidence to their CxO-level management on how well their ISMS is performing (based) on their security targets, and how effective their investment in security is.

Background
The original motivation behind O-ISM3 development was to narrow the gap between theory and practice for information security management systems, and the trigger was the idea of linking security management and maturity models. O-ISM3 strove to keep clear of the pitfalls pointed out in the article “Designing Secure Information Systems and software: Critical Evaluation of the Existing Approaches and a New Paradigm,” by Mikko Siponen. The project looked at CMMI, ISO9001, COBIT, ITIL, ISO27001, and other standards, and found some potential for improvement in several fields, such as linking security to business needs, using a process based approach, providing some additional details (who, what, why) for implementation and suggesting specific metrics, while preserving compatibility with current IT and security management standards.

The Core
The core idea of O-ISM3 is that information security is not just about the prevention of attacks to information systems, it is about achieving the organisation’s mission despite attacks, accidents and errors. There is no alignment between security objectives (the traditional confidentiality, integrity, availability) and business goals; but in O-ISM3, they are one and the same. If a company makes pastries, quality would be to deliver pastries that customers find tasty for the price they are willing to pay, while security would be to continue delivering pastries despite accidents (fire, earthquake), attacks (denial of service, viruses) and errors (administrator or operator error).

This core idea leads to defining confidentiality, availability, integrity and related concepts in great detail. O-ISM3 security objectives depend on technical, business and compliance needs and limitations. For example, the requirements of an invoicing system can be specified as follows using O-ISM3:

  • Invoices should only be accessible to the accounting and collection departments.
  • Paid invoices are to be kept for three years and destroyed after no more than four.
  • The invoicing system has to register the user account at the date and time of creation, and needs to be available 9 a.m.-5 p.m. Monday through Friday, with no more than five interruptions per week, and a duration of no more than one hour in total, and cause no more than 15 Invoices to be reentered.
  • There must be less than five errors per hundred invoices. More than 99.8 percent of products served must be invoiced.
  • Since the invoicing system is a third-party application, the license must be kept current.
  • As the invoicing system keeps personal information, according to the law, the database must be registered at the Data Protection Agency. The invoicing system must not be visible to systems from outside the company or have any remote access. It must be kept in the Data Center under controlled environmental conditions and company safeguards against fire, flood, etc.
    Implement TOGAF and SABSA architectures.

Maturity Levels
The second main concept of O-ISM3 is designing the system using maturity levels. Having maturity levels (ISM3 has five) helps organisations that can only afford to invest 20 percent, achieving 80 percent of results, (this is the 80/20 rule). The highest return from security investment comes from the initial investment, as the Mayfield’s paradox and a study from Carnegie Mellon. Different levels of maturity let organisations choose a baseline for their initial Information Security Management (ISM) system, and use the rest of the levels as milestones to higher (and more resource-consuming) O-ISM3 levels as the organisation evolves. With maturity levels the organisation can prioritise investment and measure progress. CMMI and ISO 14001 are examples of standards that use maturity levels.

Process vs. Controls Orientation
Using a process-oriented approach toward ISM is another main idea. The principle followed is, “What you can’t measure, you can’t manage, and what you can’t manage, you can’t improve.” O-ISM3-based management systems are based on processes with well-defined outputs that can be measured. This allows for a continuous improvement of the processes, as there are criteria to measure the performance of the ISMS. ISO 9001, COBIT and ITIL use a process-oriented approach.

The focus of O-ISM3 management is not limited to risk assessment and audit. O-ISM3 process orientation covers the following management activities:

  • Risk assessment—Consider assets, threats, vulnerabilities and impacts to get a picture of security, and prioritise design and improvements.
  • Audit—Compare the actual management system with the documented management system.
  • Compliance audit—Compare the actual management system with a externally defined management system (e.g. ISO 27001).
  • Monitor—Use metrics to watch processes outputs, detect abnormal conditions and assess the effect of changes in the process.
  • Test—Check if inputs to the process produce the expected outputs.
  • Design and improvement—Find ways to produce outputs better fit to their purpose, fewer false positives and false negatives (including faster outputs).
  • Optimization—Find ways to produce the same outputs with fewer resources.

This helps chief information security officers (CISOs) to manage their ISM systems when an audit is not under way.

Processes and controls are different, but both can be tested by auditing them. Processes’ results are defined (outputs), so it is very clear what to do to implement the process and the process can be improved using the process metrics. On the other hand, controls do not have a defined result, which makes them less management friendly, as a malfunctioning control does not produce information (results) necessary to learn what went wrong and take a management decision to fix it.

Controls are associated with an objective. For example, the question “What is the objective of a firewall?” has an answer: “To protect the perimeter of a network.” The next logical question in sequence is to check whether or not the objective is fulfilled by asking, “What is the result of using a firewall?” This can be answered only by measuring the result of a process which uses the firewall. By implementing processes, information security becomes more wholesome and holistic. The focus shifts from the control to the whole environment.

Metrics
Information security processes are manageable using metrics. This lets managers show the results, how results benefit the organisation, and check what changes in the process make the process improve and by how much. It also facilitates accountability.

It seems common sense that there is a direct link between what the organisation does (outputs) and what the organisation wants to achieve (goals). This belief is supported by real-life experiences, for example making a cheese sandwich. One buys the ingredients, goes home, arranges them, and perhaps toasts them, voilá: a warm cheese sandwich ready to eat. The output, cheese sandwich, and the goal, eating a homemade cheese sandwich, match beautifully.

Unfortunately, common sense fails more often than expected. A good example is research. The goal (i.e., discovery) and the activity (i.e., experiments, documentation) are not directly linked. One can try hundreds of experiments and still not find the answer. The same thing happens with security. The goals (i.e., trust, confidence, risk) and the activity (i.e., controls, processes) are not directly linked. For this reason O-ISM3 emphasises measuring what one can control, the outputs of one’s processes, specifically:

  • Activity: The number of outputs produced, their mean age, the mean time between outputs submissions, mean time to produce an output, following input, and worst case time to produce an output, following input.
  • Scope: The proportion of the environment or system that is protected by the process and the percentage of the scope sampled.
  • Unavailability: The time since a process has performed as expected upon demand (uptime), the frequency and duration of interruptions.
  • Effectiveness: Number of inputs, mean time between inputs, and percentage of inputs that produce an output.
  • Efficiency: Ratio between the number of outputs submitted and the available resources for this process in actual use.
  • Load: Percentage of resources in actual use.
  • Quality: Accuracy, precision, or other measurements of fitness for purpose of the output, when applicable.

Results of processes within O-ISM3, called “outputs” are defined. For example, in the case of the access control process, the expected outputs of the system could be defined as:

  • Grant of access to authorized users;
  • Denial of access to unauthorised users;
  • Logs of password changes;
  • Logs of authorised access to information;
  • Unauthorised access attempt reports.

The process could be tested in two ways. The first method is similar to testing the control, but this would reflect only the current state of the system. A more comprehensive way to test the process is to measure the results of the process by using the metrics.

From the above metrics, the values obtained under scope and availability would be used to improve security directly, and those obtained under activity and update would be used indirectly to improve security by improving the process. For example, if 100 access rights are normally granted every month, but in one month it is noticed that only 10 access rights were granted, an investigation of the process would be appropriate.

This could indicate different scenarios. Either people are not asking for access rights any longer and are sharing them, the person responsible for the access control system is not doing his/her job properly, or the second condition could be the cause of the first condition.

A common problem with metrics is finding criteria that tell when the metrics deserve attention. O-ISM3 recommendations are borrowed from quality management, using control charts. Control charts help managers distinguish simply random, important changes from noteworthy abnormalities that should be investigated.

O-ISM3 and Other Standards
O-ISM3 protects existing investment in ISM systems, as O-ISM3 describes processes in such a way that current practices can be easily adapted to O-ISM3 requirements.

ISO 9001 users will find that O-ISM3’s document management requirements are the same; the same document management system can be used to handle ISO9001 and O-ISM3 documents. The PDCA principle used in ISO 9001 is used extensively in O-ISM3, and if familiar with ISO9001 management principles, that knowledge can be used for ISM systems. (The PDCA principle is used by O-ISM3 in a process-by-process fashion, not just for the whole ISM systems.) O-ISM3 recommends the use of control charts for the interpretation of O-ISM3 metrics.

COBIT users will find that the O-ISM3 concept of security fits naturally with security, quality and fiduciary requirements. key goal indicators (KGIs) and key performance indicators (KPIs) can be measured by using O-ISM3’s metrics The level of detail that O-ISM3 brings can make ISM system design easier.

Although ITIL process approach is congruent with O-ISM3, ITIL security management is not very specific. O-ISM3 can reinforce ITIL’s ISMS practices, and setting metrics thresholds is probably the best way to specify underpinning contracts and service level agreements.

There is a natural fit between O-ISM3’s business goals, security objectives (technical, business and compliance objectives) and IT governance concepts. O-ISM3 uses a clear division of responsibilities between leaders, managers and technical personnel by using the concepts of strategic, tactical and operational management. Strategic managers are involved with the long-term alignment of IT with business needs. Tactical managers are involved in the allocation of resources and configuration and management of the ISM system. Operational Managers are involved in setting up, operating and monitoring the operational (technical) processes. In the implementation of O-ISM3, it is easy to determine security responsibilities due to the division of the O-ISM3 processes. This division represents a way of thinking about what results are to be achieved and to whom the results will be reported.

O-ISM3 is ISO 27001-compatible to the point that O-ISM3 can be used as a tool to aid the implementation of ISO 27001 or to certify an organisation by both standards. O-ISM3 is a specification for creating ISM systems, so O-ISM3 itself does not need to be ISO27001 compliant. Certification is performed on specific ISM systems, thus O-ISM3 can be used to create ISO 27001-compliant ISM systems that will have to use risk analysis/assessment and implement all applicable ISO 27001 controls. The O-ISM3 Consortium provides certification in collaboration with ISO 9001 and ISO 27001 certification bodies.

O-ISM3 provides a risk analysis methodology, which is compatible with the use of all widely recognized risk analysis standards, like OCTAVE, MEHARI, EBIOS or MAGERIT.

Certification of ISM systems is very important, as organisations use certification to show their commitment to information security and build trust relationships. An ISM system based in O-ISM3 is creditable under ISO 9001 or ISO 27001 schemes, which means that O-ISM3 can be used to implement an ISO 27001-based ISMS.

Conclusion
If an organisation already has an ISM system in place, O-ISM3 is compatible with this approach, and can help enhance current ISM systems beyond compliance with current standards to higher, and more difficult to achieve, maturity levels. If an organisation does not yet have an ISMS and is familiar with process-based management approaches such as ISO 9001, COBIT or ITIL; if an organisation needs a top-down approach that roots on its business mission; if the organisation has limited resources; or if the organisation plans to outsource parts of its ISMS or is looking for an accredited ISM system, then O-ISM3 is right for the organization.