Standards and best practices
All about best practices
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
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
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
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.
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.
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.
This is another offering from Software Engineering Institute, Carnegie Mellon
University (SEI-CMU) dealing with the interesting subject of evaluating threats
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
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
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.
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
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