Standards and best practices

All about best practices

ISO/BS is not the only source for security best practices. There are other standards organizations, which sometimes offer much more detailed and elaborate practices for enterprises. A look at some of them. by Avinash Kadam

Every security forum seems to be extolling the virtues of following the best practices framed by ISO 17799. The icing on the cake is that if your organization follows this code of practice for security management, you can also be certified as conforming to the BS 7799 guidelines.

This assures the prospective clients, customers, and employees that you are not only following the best practices in information security, but also seen to be following them in the eyes of third-party auditing organizations.

Is ISO/BS the only source to tell you the best practices? The answer is no. There are others, which are sometimes much more detailed and elaborate. The major difference is that the British Standards Institute has defined BS 7799 Part 2 as a standard, which 'can be used by internal and external parties including certification bodies, to assess an organization's ability to meet its own requirements, as well as any customer or regulatory demands'.

Other organizations, which issued information security best practices, limited themselves to providing guidelines for the practice of information security and did not issue 'an auditable standard'. A guideline usually uses the term 'should', which merely suggests a particular security practice, whereas the auditable standard uses the verb 'shall', making it mandatory to use the security practice.

The use of ‘should’ or ‘shall’ is not just a play of words but it makes a great difference to an implementor. A 'shall' is the dreaded order from top, a 'should' is a friendly suggestion.

In the next few articles, we shall (should?) take a look at the best practices, which are being followed worldwide. You should be aware of the philosophy and approach of each of them as each addresses the same problem, but may be, with a slightly different approach. This article gives an overview of these approaches and subsequent articles will explain each of them in more details.

1. COBIT (Control Objectives for Information and Related Technologies)

2. SSE-CMM (System Security Engineering - Capability Maturity Model)

3. OCTAVE (Operationally Critical Threat, Assets and Vulnerability Evaluation)

4. IT Baseline Protection Model

5. Common Criteria for Information Technology Security Evaluation

1. COBIT

COBIT from the IT Governance Institute, which is a part of ISACA (Information Systems Audit and Control Association) is not exactly meant for security best practices alone, but for IT best practices.

COBIT is meant to guide an organization in effective management of information and related IT, and is referred to as an IT governance standard. COBIT takes a high-level view of identifying the goals an organization has and how IT helps in achieving these goals. It then comes down to details like requirements of planning and organization of information, based on various business-oriented criterion like effectiveness, efficiency, compliance, and security-oriented criterion like confidentiality, integrity, availability, and reliability.

This is where COBIT differentiates itself from other best practices by taking a holistic view of the enterprise requirements of information and not just a security-focused view.

Once the tone is set for achieving business objectives through proper planning and organization, the next step is acquiring and implementing appropriate solutions, technologies, and infrastructure.

A third domain of COBIT takes up the management of all the resources, which need to be acquired and implemented. The concern here is managing their performance, capacity, service levels, security level, continuity, and problem management while managing data, facilities, and operations.

The final domain of COBIT deals with monitoring various processes, adequacy of controls, assurance, and audit.

The best practices for information security are thus embedded in overall IT governance practices defined by COBIT.

IS auditors

COBIT is followed extensively by all IS Auditors. This is the de facto standard in the world of information systems. With a large number of Certified Information Systems Auditors (CISAs) who comprise the main force evaluating and auditing information systems for large organizations, government bodies and banks, it is no wonder that most of the security practices highlighted in COBIT are also implemented in practice by these organizations.

What COBIT lacks is a third-party certification process. The second feature of COBIT that intimidates a new entrant is the vast scope of COBIT. An organization setting its goal to become COBIT compliant, undertakes a huge task, involving very serious commitment from the top management and a dedicated team ready to work for two to three years.

At the end of this, there will be visible improvement in the maturity of the organization as defined by the IT Governance Maturity Model, but there will be no third-party certification, so the commercial competitive benefits that an external certificate might bring, are absent.

SSE-CMM

The next important model is the SSE-CMM from Carnegie Mellon University, which earlier gave us Software Engineering - Capability Maturity Model (SE-CMM). Keeping in line with the approach of SE-CMM, the SSE-CMM also defines Capability Maturity in terms of 5 levels.

It begins at level 1 identified with processes 'performed informally' to level 5, which denotes that the organization has process orientation and is 'continuously improving'. The only difference here is that the processes are not software engineering processes but security engineering processes.

SSE-CMM has defined two types of processes. First is the security engineering process area and second is the project and organization process area. Each of these has 11 distinct processes. An organization has to implement each of these 22 processes and evaluate their maturity levels.

The 5 levels of maturity are further split into 12 sub-levels. So a process could be between level 3 and level 4, and to be absolutely precise it may be at level 3.2. SSE-CMM has given good measurement criterion to identify this hair-splitting of levels in a convincing manner.

SSE-CMM has the same potential of becoming a piece-de-resistance as SE-CMM, where all the software developers having ISO 9001 rushed to achieve SE-CMM Level 5 status. It may so happen that all the BS 7799 certified organizations will aspire to become SSE-CMM Level 5 organizations.

OCTAVE

This is another offering from Software Engineering Institute, Carnegie Mellon University (SEI-CMU) dealing with the interesting subject of evaluating threats and vulnerabilities.

It gives a methodology for identifying and documenting threats by preparing threat trees and creating asset-based threat profiles. The next phase is to identify infrastructure vulnerabilities. And the last phase is to develop security strategy and plans. The approach defined in OCTAVE is meant to enable organizations to form a small, interdisciplinary, in-house team, which could carry out a self-directed evaluation focusing on the organization's assets and the risks to those assets.

The Octave and SSE-CMM both seem to address the same topics of security risk evaluation and having well defined processes to identify, evaluate, and mitigate the risks. Octave is focused on a three-phase approach leading to security strategy and plans for the critical threats and vulnerabilities the organization faces, whereas SSE-CMM defines an elaborate method for security maturity process improvement and measurement.

A striking thing is that there is no cross-reference to each other in these two approaches although they come from the same stable.

IT Baseline Protection ModeL

This comes from Federal Office for Information Security, Germany (Bundesamt für Sicherheit in der Informationstechnik).

From a totally US-centric view of information security, let us now look at another source of best practices, which is German. And luckily, most of it is available in English.

The IT Baseline Protection Model has been defined with a simple assumption that there are a number of threats existing in the environment. There is no need to re-establish the fact by doing a time-consuming exercise of risk assessment to identify the threats and vulnerabilities and estimate the probability of the threat exploiting a vulnerability and causing a loss to the organization.

We need to look at a standard set of security measures that need to be present to guarantee a minimum (baseline) level of security. Compare the actual security measures with the standard security measures and just fill the gaps. This is easier said than done because the baseline levels of security measures defined by the standard are themselves very strict.

Above that, the suggestion is, if the protection requirement is significantly higher, by all means, do a thorough risk assessment and implement additional security measures.

The IT Baseline Protection Manual gives a comprehensive threats catalog and a safeguards catalog listing every possible item from buildings and cabling to OSs and databases. You have simply to choose the safeguards missing from your implementation and ensure that these are implemented to avoid the list of threats, which are associated with the particular asset.

An organization could get IT Baseline Protection Certification from the Federal Office for Information Security, Germany.

The IT Baseline Model is a refreshing change from the other models as it is very practical, although very stringent.

Common Criteria

The last standard we will look at is Common Criteria, which is also an ISO standard, ISO 15408. The best practices that we covered so far pertained to information security management. These involved security processes and not security products.

Common Criteria is for security products and security systems that perform a security function. So Common Criteria evaluation is for a firewall, or for a smart card as well as for an OS. But why do we need to know about all this? For the simple reason that, if we select a security product or system, we should have some assurance that it will perform the security functions that it is supposed to perform.

Common Criteria has a long history of evolution. It is difficult for any two countries or organizations to agree on a particular standard. Common Criteria, as the name suggests, is a common security evaluation criterion, which has been agreed upon by seven major organizations worldwide and has also been adopted as an ISO standard.

It defines at great detail, the security functional requirements and security assurance requirements. Based on these two, it finally allocates Evaluation Assurance Level (EALs) to the 'Target of Evaluation' against a 'Protection Profile'.

This makes the Common Criteria a complex standard to understand because a product manufacturer may claim the highest EAL level for his product, while the EAL may have been assigned against a Protection Profile, which describes the product to be used in a harmless environment. We shall understand this sleight of hand, which could be performed while quoting the Common Criteria, EALs in a future article on Common Criteria.

To summarize, there is more than one option for a security management practice. And in each case, the core principles remain the same.

Avinash Kadam is Director of MIEL e-Security, Pvt. Ltd. He can be reached at awkadam@mielesecurity.com