ISOvFISMA.031207

This document includes data that shall not be disclosed or duplicated in whole or in part for any purpose other than to evaluate this document without permission of the author. The data which is subject to this restriction is contained on pages marked with "Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this document."

Reaching Out To Protect Within: A Global Security Compliance Strategy

Combining ISO and NIST Standards for Security Best Practice

Ted Ritter, CISSP iTRitter Global Security Compliance

703-403-1505 [email protected] www.itritter.com

ii "Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this document."

Table Of Contents

1. Introduction .........................................................................................................................3

2. A High-Level View ................................................................................................................4

2.1. Critical Success Factors .....................................................................................................5

3. A Risk-Based Approach.........................................................................................................7

3.1. Definition of Scope and Selection of Controls ...................................................................8

3.2. Redefining the Boundary Concept ....................................................................................9

3.3. Control Selection As A Key Aspect of Risk Treatment ......................................................11

3.4. A Combined Approach To Controls Selection ..................................................................12

4. Final Thoughts....................................................................................................................14

4.1. New Technologies ..........................................................................................................15

4.2. External Parties ..............................................................................................................15

5. Conclusion .........................................................................................................................16

6. Background ........................................................................................................................17

6.1. FISMA .............................................................................................................................17

6.2. ISO..................................................................................................................................17

7. Comparison of ISO 27001/17799 and NIST SP800-30/53 ....................................................19

3 "Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this document."

1. INTRODUCTION

We live in a world where information security is a top priority for every CIO. One of the

greatest challenges with information security is the fact that success is measured by what

doesnt happen as opposed to what does happen. How much is enough security? Whats

necessary? Whats sufficient? Whats necessary and sufficient? How is cost factored into the

risk assessment? There are no uniform answers to these questions. All one can do is

implement what are considered the best practices of the time and hope that the measures

taken are both necessary and sufficient to successfully protect the enterprise in a cost-effective

manner.

Unfortunately, hope is not a plan so organizations look to plans from standards bodies for

guidance on best practices. Best practices themselves come with their own challenges. The

whole idea behind a best practice is that its the best. But, which best practice is the best

practice? Is one best-practice best for everyone? Of course the answer is no.

A series of best practices and methodologies have evolved as internationally accepted

standards. The best known are the ISO standards. As discussed below the current ISO security

standards have evolved over the past 12 years to become a well thought-out, well laid-out and

well accepted set of security best practices. Organizations around the world are following ISO

27001 and ISO 17799:2005 with the goal of achieving the necessary and sufficient security

practices to protect the organization. Over the same time period another set of security best

practices from the National Institute of Standards and Technology (NIST) have evolved and

been accepted as the standard for security for US federal government agencies Federal

Information Security Management Act (FISMA). The security standards are broad in scope and

scale and they must be adhered to by all federal agencies and third-party providers of services

to those agencies. Outside of the federal agencies and the systems integrators that provide

support to the agencies there is very little attention paid to these federal standards. The point

of this paper is that there are strong similarities between NIST and ISO guidance and more

importantly, they should be used to support each other. Its time that organizations take off

their regulatory blinders and start looking outward to better protect within.


2. A HIGH-LEVEL VIEW

Both standards have a process that they follow. ISO follows the Plan, Do, Check, Act (PDCA)

process and NIST follows a Systems Development Lifecycle (SDLC) approach (Initiation,

development acquisition/implementation, Operation/Maintenance and Disposal). Figure 1.0

compares the two processes:

Figure 1.0 Comparison of ISO 27001 PDCA and NIST SDLC Frameworks

There is clear overlap between the two frameworks and the phases line-up relatively well. Of

the two models the SDLC model is more closely aligned with system planning and development

cycles. In contrast, ISO PDCA appears more oriented to systems that are already in production.

The bottom-line is that both models provide a structure within which one may successfully

plan, implement, operate and monitor a risk-based security solution.

Both standards leave a lot of room for interpretation. This is both good and bad. Room for

interpretation facilitates flexibility and a level of rationality that isnt found with more

prescriptive standards. However, with interpretation comes confusion since many times whats

not stated is of greater concern than what is stated. It turns out that there is excellent synergy

between ISO and NIST guidance so that one may draw from one standard to help interpret the

other.


2.1. CRITICAL SUCCESS FACTORS

Both ISO and NIST define numerous success factors. ISO guidance tends to be high level and

generic with an emphasis on communication and cooperation and NIST guidance tends to be

more tactical with an emphasis on individual responsibility, team members competence and

cooperation between members of the IT organization. Both sets of guidance are of value since

successful risk management requires strategic planning, strong communications, support,

project management, execution and follow-through. Table 1.0 is a consolidation and

compilation of success factors taken from both ISO and NIST documentation. There are many

more factors for success but these are the top 10 based on analysis of both standards:

Top 10 Critical Success Factors

Success Factor Comments

1 Information security policy tied to

the objectives of the business

(source ISO)

Information security must be discussed in business terms

otherwise its impossible to measure the success or failure of the

policy in relation to the success or failure of the business

2 Develop and follow a risk

management approach and

framework consistent with the

organizational culture (source ISO)

Different organizations approach and solve problems in different

ways. The information culture is rarely discussed in NIST

documentation but it must be considered, regardless of the

organization being private or public

3 Obtain and show visible support and

commitment from all levels of

management (source ISO)

Management must show ongoing visible support for the

information security plan through written and verbal means

4 Senior management must be

committed to the information

security plan and committed to fund

information security management

activities (source ISO) (source NIST)

If senior management is not supporting the project than the

project will fail or at best will limp along until there is a change in

senior management. NIST and ISO offer little funding guidance. A

prescient statement in ISO is Action to prevent nonconformities

is often more cost-effective than corrective action

5 Its critical to get the full support and

participation of the IT team (source

NIST)

The IT team bares the brunt of the work associated with the

assessment, audit and remediation aspects of information

security. Constant communication is critical for achieving and

maintaining buy-in by team members

6 The competence of the risk

assessment team is critical for

success (source ISO and NIST)

The team involved in the risk assessment must have the expertise

needed to assess systems, identify risks and provide cost-effective

solutions to mitigate the risk.

7 Effective marketing and distribution

of information security guidance to

The security guidance, standards and polices must be distributed

and sold to all managers and employees. The plan may be the


Top 10 Critical Success Factors

Success Factor Comments

all parties to achieve awareness

(source ISO)

best in the world but without successful sales and marketing

within the organization it will fail

8 Providing appropriate security

awareness training to members of

the user community (source NIST)

When users understand the implications of their actions and that

they do have the power to make a difference, acceptance of the

security plan is greatly enhanced

9 Establishing an effective information

security incident management

process is a key to success (source

ISO and NIST)

ISO and NIST both define incident response as a critical

component of risk management. NIST SP800-53 defines incident

response in the IR section of controls. ISO 17799:2005 section 13

is dedicated to incident response

10 Develop your own guidelines (ISO) Both standards state repeatedly the need to customize the plan

to the unique requirements of the business or agency

Table 1.0 Top Ten Critical Success Factors


3. A RISK-BASED APPROACH

Both ISO and NIST define a risk-based approach to security management. Both standards focus

on assessing the potential impact on Confidentiality, Integrity and Availability as the basis for all

security discussion. Figure 2.0 depicts the basic risk management process followed by both

standards:

Figure 2.0 Typical Risk-Based Approach to Information Assurance

As mentioned previously ISO is more focused on higher level processes and management

practices and FISMA is more focused on tactical, organizational issues. Together, the guidance

provided offers a comprehensive approach to risk management for IT assets.

All six steps are critical for successful risk management and at each step there is significant

overlap of ISO and NIST guidance. A complete head-to-head comparison of the risk

management process is found in Tables 2.0 and 3.0. Table 2.0 compares ISO 27001

(Establishment of ISMS) against NIST SP 800-30 (Risk Management Framework) and Table 3.0

compares the security controls defined in ISO 17799:2005 and NIST SP 800-53.

While success at each step wont guarantee overall success, failure at any step guarantees

failure of the project. Therefore, anything that may be done to increase success at each step

increases the likelihood of success of the entire project. Two steps where integration of the

guidance is particularly beneficial are Definition of Scope and Risk Treatment. The following

1. Define Scope

Assets

Boundaries

Roles

2. Define Vulnerabilities

Exploits

Threats

3. Define Risks

Exploit Risk Potential

Potential Cost of exploit

4. Risk Treatment

Controls

Modifications To Systems

Acceptance of Risk

Transfer of Risk

5. Assess & Accept Residual Risk

Determine exposure

Document acceptance

6. Ongoing Management

Continuous Monitor

Enhancement


The concept of an

accreditation boundary is

not unique to NIST.

Interestingly, Certification

and Accreditation (C&A),

where accreditation

boundaries are defined, is

never explicitly mentioned in

ISO 27001 though it is

implied as a component of

the ISMS audit. NIST

dedicates a document, NIST

SP 800-37 Guide for The

Security Certification &

Accreditation of Federal

Information Systems to

describe the C&A process.

This guide provides excellent

value to CISO and

Compliance Officers

attempting ISO compliance.

section is a discussion of these two areas and how integrating NIST and ISO guidance provides

significant value to a CISO or Compliance Officer attempting to comply with either standard.

3.1. DEFINITION OF SCOPE AND SELECTION OF CONTROLS

Definition of scope includes establishment of the boundaries for, and classification of the IT

environment and its assets. A well defined boundary leads to well defined risks and

vulnerabilities which lead to well defined risk treatments, etc. Conversely, poorly defined

boundaries set the stage for a difficult and high-risk risk management process.

ISO offers a high level starting point by providing excellent guidance for defining the risk

management boundaries in relation to the business:

Define the scope and boundaries of the ISMS in terms of the characteristics of the

business, the organization, its location, assets and technology, and including details of

and justification for any exclusions from the scope. (ISO27001, 4.21.a)

The scope of a risk assessment can be either the whole

organization, parts of the organization, an individual information

system, specific system components, or services where this is

practicable, realistic, and helpful. Examples of risk assessment

methodologies are discussed in ISO/IEC TR 13335-3 (Guidelines for

the Management of IT Security: Techniques for the Management of

IT Security). (ISO1779:2005, 4.1)

NIST also defines management of risk in relation to the enterprise;

however NISTs unit of measure for defining boundaries is the System.

System Characterization - focus on accreditation boundaries and

establish ownership. (NIST SP 800-30, 3.1)

In both frameworks boundary decisions are left to the discretion of the

authorized officials. This puts more pressure on the officials to establish

boundaries while at the same time it gives them more flexibility in the

process. For government agencies a System is usually defined by mission

or application. For example, the Personnel Management application and

all of the associated servers, workstations and employees access may be considered a

System. Systems may be defined by security classification, location, operating system, or in

the case of a small agency there may just be one System. Similarly, commercial organizations

define ISMS boundaries with the same criteria though ISO provides less guidance than NIST on

this issue.


For government networks System boundaries are directly tied to System classification. NIST

publications FIPS-PUB 199 and SP 800-60 define the process of System classification. At the

highest level there are three classes of System impact: low,

moderate and high. Classifications are directly related to the

potential impact of losing a System.

NIST offers far more guidance than ISO on this topic. NIST SP-

800-60 defines a comprehensive list of information types with

associated levels of impact on Confidentiality, Integrity and

Availability:

If the potential impact is limited with a minimal impact than the System may be

classified as being low impact

If the potential impact is serious then the System may be classified as being

moderate impact

If the potential impact is severe or catastrophic than the System may be classified as

being high impact

System classification can be very complex since a System may process many different types of

information, each with its own C, I, A impact levels. To simplify matters NIST employs the high

water mark concept so a Systems impact level is always tied to the highest impact information

type classification. For example, if a System processes ten information types with nine low

impact and one high impact then the entire System must be considered high impact.

Similarly, ISO 27001 accounts for information sensitivity when assessing the controls that are

needed to minimize risk. In comparison, ISO doesnt offer the level of guidance that NIST

provides. The end-result for ISO is the same a series of controls that are related to minimizing

impact on C, I and A. However, the process of getting to the end result is much more logical

and well supported in FISMA than in ISO 27001.

3.2. REDEFINING THE BOUNDARY CONCEPT

As mentioned earlier, one of the most critical steps in risk management is boundary definition.

In the past, boundaries were considered static, defined by physical demarcation points:

mainframe, server, firewall, router, intranet, extranet, etc. As applications have become more

distributed, firewalls have become more transparent and the boundaries between intranet,

extranet and internet have dissolved, physical demarcation points offer no value in todays risk

management discussion. Todays boundaries must be defined in dynamic terms: fluid, flexible,

resilient, intelligent, business driven, etc. Likewise, the depiction of the boundaries needs to

evolve. Rather than visualizing boundaries as thin lines dividing in and out, us and

Many people assume that low, moderate

and high impact levels refer to secrecy levels

and therefore this classification system is

unique to the government environment.

This is incorrect. In fact, its possible that a

high impact System might be processing

unclassified information.


them, etc. they need to be seen more like the doughnut shape depicted in figure 3.0. The

outer edges are defined by management, policy and business mission and the inner edges are

defined by lower-level characteristics such as information type, classification, access

requirements, hosting requirements, etc.

From a practical perspective using NIST and ISO guidance works very well to define this type of

dynamic System/ISMS boundary. As shown in Figure 3.0, ISO guidance may be used to define

the outer edge and NIST guidance may be used to define the inner edge. Together, the

combined guidance provides a boundary definition that is broad enough to meet the high level

business requirements and yet detailed enough to meet the more tactical, technical

requirements of risk management.

Figure 3.0 Boundary Definition ISO and NIST

ISO

Defines

Outer

Edge

ISMS and System

Boundary

NIST

Defines

Inner

Edge


3.3. CONTROL SELECTION AS A KEY ASPECT OF RISK TREATMENT

Along with boundary definition, risk treatment is a make-or-break component of risk

management. The choices for risk treatment as defined by ISO and NIST are the same:

Implement Security Controls

Modify Systems to Reduce Risk

Accept Risk

Transfer Risk (Insurance, Outsource, etc.)

Typically, the majority of energy expended in risk treatment is the definition and selection of

security controls. After all, its easier to implement a control than it is to redesign a system,

CISOs are reluctant to accept risk if there is a control to reduce it and off-loading risk through

insurance is usually an option of last resort. This is more true for federal CISOs than for

commercial CISOs since the federal CISO has fewer options for transfering or accepting risk.

As shown in Table 3.0 NIST and ISO recommendations for security controls are almost identical.

The categorization is different with NIST defining 17 classes of controls and ISO defining nine

classes of controls. There are some areas of divergence that are discussed in the Final Thoughts

section of this paper. Table 3.0 maps the NIST SP 800-53 Controls against the ISO 17799:2005

controls. The controls in SP800-53 and ISO 17799:2005 are defined by three components: a

control section, a supplemental guidance section and a control enhancements section (other

information in ISO 17799:2005). The control section defines the control and provides a place

holder for user specific control-related information. For example the control might be related

to audit logs and the user specific information is the type of audit logs to be monitored. The

supplemental guidance section provides more background information on the control as well as

cross-references with other Federal regulations and standards. Finally, the control

enhancements section (other information for ISO) provides recommendations to strengthen

the control, if necessary.

Both ISO and NIST recommend the set of publshed controls as a starting point with the need to

use additional controls based on the unique aspects of the Systems being protected. ISO

provides excellent guidance by distilling a small set of essential controls from the much larger

group of common controls:

Controls considered to be essential to an organization from a legislative point of view

include, depending on applicable legislation: (ISO 17799:2005)

data protection and privacy of personal information (see 15.1.4);

protection of organizational records (see 15.1.3);

intellectual property rights (see 15.1.2).


Controls considered to be common practice for information security include: (ISO

17799:2005)

information security policy document (see 5.1.1);

allocation of information security responsibilities (see 6.1.3);

information security awareness, education, and training (see 8.2.2);

correct processing in applications (see 12.2);

technical vulnerability management (see 12.6);

business continuity management (see 14);

management of information security incidents and improvements (see 13.2).

NIST too offers control groupings and separation of universal controls from unique controls but

nowhere in the NIST documentation is selection of security controls for information protection

defined as succinctly as it is in ISO 27001 and ISO 17799:2005.

As ISO does an excellent job defining high-level categories for controls, NIST provides excellent

guidance at a tactical level by grouping controls into three categories: operational, technical

and management. The division of controls into different functional areas is quite helpful,

particularly in light of NISTs recommendation that controls be selected from all three

categories. Typically, the type of person assessing and recommending controls is a technical

person and the requirement to select controls from each category avoids the tendency of

technical people to solve problems via technical means. After all, if ones toolbox only contains

a hammer than everything starts looking like a nail. By dividing the controls into the three

functional areas it forces the auditor, CISO or Compliance Officer to consider both technical and

non-technical approaches to risk mitigation.

3.4. A COMBINED APPROACH TO CONTROLS SELECTION

The successful selection of security controls is a critical component of IT risk management.

Considering that ISO and NIST rely upon the same set of controls, control selection should be a

straight-forward process. With 133 (ISO 17799:2005) controls to consider and the added need

to measure performance of each control, the process is quite complex and time consuming. Its

easy to get bogged down in the details and lose sight of the overall goals of the project. Whats

required is a top-down approach to control selection. As shown in Figure 5.0, combining ISO

and NIST guidance for control selection fits well into a top-down approach. ISO provides

guidance for essential and common controls while NIST offers more detailed perspective on the

division of the controls into operational, management and technical categories. Together,

CISOs and Compliance Officers can use this guidance to create a tool selection framework that


meets the overall risk management goals while providing a level of detail needed to make a

balanced control selection.

Figure 5.0 Integration of ISO and NIST Security Controls Guidance

Essential Controls (ISO)

Data Protection/Privacy

Protection of Orgizational Records

Intellectual Property Rights Protection

Common Controls (ISO)

Infosec Policy

Allocation of Responsibilities

Infosec Awareness

Correct Application Processing

Technical Vulnerability Management

Business Continuity

Management of Incidents

Type of Controls (NIST)

Technical

Preventive - i.e. Authentication

Detective - i.e. IDS, Audit Trails

Management

Preventive - i.e. Sep. of Duty

Detective - i.e. Clearance, Audit

Operational

Preventive - i.e. COOP

Detective - i.e. Physical Security


4. FINAL THOUGHTS

The previous discussion has focused on ISO emphasizing high level risk management guidance

in comparison with NIST offering more focused, tactical guidance. Another way of looking at

this is that ISO is far less prescriptive than NIST by keeping the discussion at a higher level. This

raises the question, how prescriptive should a standard be? How much guidance should be

provided by the standards body? Is it better to lay-out a menu of all options or pre-select

options into templates?

In general, NIST tends to offer pre-selection of options while ISO tends to follow a clean slate

approach where each engagement starts from scratch. Possibly, this reflects the inherent

differences between an international standard that must support all organizations, regardless

of local laws and customs and a federal standard that only needs to support federal agencies.

However, IT systems are IT systems, regardless of the owner. Risks are universal as are the

methods for risk mitigation. Therefore, this issue of clean slate versus template isnt a

federal or commercial issue but rather an issue of preference.

There are arguments for going either way. Both approaches are designed to get the CISO or

Compliance Officer to the same end-point a successful risk-based approach to security. This

authors preference is for template over clean slate. The reasons for this are threefold:

1) CISO Are Very Busy CISOs and Compliance Officers are very busy with operational,

management and compliance responsibilities. Anything that streamlines the process

without introducing additional risk is a good thing. If a pre-set baseline template shortens

the time to selecting appropriate controls than this is the way to go

2) Its Not Rocket Science - Despite what vendors and consultants may say this is not rocket

science. If anything, risk management is more of an art than a science. Threats and

vulnerabilities tend to be universal as are the approaches to protecting against them. The

science and the art should be applied to the adjustments required to meet the unique

characteristics of the organization as opposed to defining the common requirements of

protecting common elements. Using pre-set templates and baselines facilitates the

Compliance Officer or CISO spending their time focused on the adjustments needed to the

baseline as opposed to building the baseline from scratch

3) Knowledge Is Limited The amount of knowledge required to build an ISMS from scratch

including definition of the information system, assessment of risk, treatment of risk and

implementation of a risk management plan is extremely high. There are people who have

this level of knowledge, many of whom are providing ISO 27001 and FISMA compliance

consulting to government and commercial organizations today. Most Compliance Officers

and CISOs rely upon outside consultants to guide them through the process. The more pre-

defined templates and baselines that are available, the less the requirement for outside


consultants. Another way of looking at this is the template-based approach keeps the

consulting relationship focused on the hard work adjusting for the unique requirements of

the organization

4.1. NEW TECHNOLOGIES

How is management of risk associated with new technologies addressed in ISO and NIST

standards? In theory, the standards are open-ended and the disclaimer that additional

controls may be required leaves the door open for protecting new technologies. This is

another area where following both standard helps in complying with either one. For example,

no where in ISO 27001 or ISO 17799:2005 is VoIP mentioned. In contrast SP 800-53 has a

specific security control for VoIP and a reference to NIST SP 800-58 for additional security

considerations for VoIP. Wireless is another area where NIST has more support than ISO. Both

standards reference wireless but NIST has specific controls for wireless access and SP800-48 is a

document that discusses wireless access with a particular emphasis on 802.11x and Bluetooth.

Finally, the US Governments emphasis on migration to IPv6 is driving the development of a set

of security controls for FISMA. These controls will provide value to organizations complying

with ISO.

4.2. EXTERNAL PARTIES

Both ISO and NIST discuss the need to protect information systems that are either hosted by,

managed by, located at or belong to third parties. Both ISO 17799:2005 and NIST SP800-53

offer specific security controls for third-party relationships. Of the two, ISO 17799:2005 Section

6.2 provides far more guidance than NIST on risk management of third-party relationships.

Federal CISOs should draw from the ISO guidance especially given the governments motivation

and mandate to outsource competitive IT services.


5. CONCLUSION

Its encouraging to discover that using both standards (ISO and NIST) as a reference point

provides more guidance to the security professional than using either standard alone.

Individually, each standard offers guidance that is necessary but not necessarily sufficient to

achieve compliance. Achieving regulatory compliance is a complex, time-consuming and many

times all encompassing task that usually combines reference to the standard coupled with

significant help from outside consultants.

The initial intent of this research was to better understand the standards by focusing on their

differences. After all, one would assume that the unique requirements of government agencies

should mandate a very different package of standards and controls than that of a commercial-

oriented organization. What became clear during the research process was that ISO and NIST

information security standards are very closely aligned. This either means that the security

problems faced by government agencies are not that different than those faced by commercial

organizations or there is a serious disconnect between federal IT executives and the NIST.

Given the openness of the NIST standards development process and the professionalism and

experience of the NIST team its highly unlikely that there is a disconnect. Therefore, the risk

management requirements must be similar.

The similarity in requirements between commercial and government organizations leads the

discussion down two paths: integration and consolidation. This paper focused on integration

and the issue of consolidation will be a discussion topic for a later paper. Why should the

federal government develop and maintain its own set of security standards when there is such

similarity between ISO and NIST? Why not accept ISO as the standard and then focus on

specific guidance that augments or modifies the ISO standards to meet the unique aspects of

managing risk in a federal IT environment? Clearly, the answering of these questions goes well

beyond the focus of this paper - offering supportive guidance to federal and commercial CISOs

and Compliance Officers. However, these are questions that must be answered, particularly in

light of the points raised throughout this paper:

ISO and NIST information security requirements for risk management are very closely

aligned

There are sections of ISO that provide much more guidance than NIST and vice versa

These areas of complementary depth form the basis for the argument that relying on

both standards provides significantly more guidance than using either standard alone

Its time that organizations take off their regulatory blinders and reach outward to better

protect within.


6. BACKGROUND

6.1. FISMA

FISMA (Federal Information Security Management Act) originated as Title III of the 2002 E-

Government Act. FISMA mandates that government agencies develop, document and

implement information security to protect the assets of the agency including assets that are

provided or managed by another agency, contractor or other party. FISMA is often referenced

in conjunction with the Office of Management and Budget (OMB) Circular A-130 Appendix III:

Security of Federal Automated Information Resources. FISMA and A-130 emphasize a risk-

based approach to protection of assets. FISMA references a series of documents that are

written and managed by the National Institute of Standards and Technology (NIST). Core

documents include:

FIPS Publication 199(Security Categorization)

FIPS Publication 200(Minimum Security Requirements)

NIST Special Publication 800-18(Security Planning)

NIST Special Publication 800-30(Risk Management)

NIST Special Publication 800-37(Certification & Accreditation)

NIST Special Publication 800-53(Recommended Security Controls)

NIST Special Publication 800-53A(Security Control Assessment)

NIST Special Publication 800-59(National Security Systems)

NIST Special Publication 800-60(Security Category Mapping)

The bulk of this paper is focused on SP800-53 (recommended security controls) and SP800-30

(risk management).

6.2. ISO

The ISO documents for information security include ISO 27001 and ISO 17799:2005. ISO

17799:2005 was first published as BS7799 in 1995 by the British Standard Institute (BSI). After

review and discussions BS7799 was adopted as ISO 17799:2000 in 2000. ISO 17799:2000 has

evolved and the current version, ISO 17799:2005 Code of Practice For Information Security

Management was released in June, 2005.

The original BS7799 was divided into two sections: risk management process and security

controls. In October, 2005 the risk management component (revised BS7799 Part2:2005) was


adopted as ISO/IEC 27001 ISMS Requirements. Essentially, ISO 27001 defines the Information

Security Management System (ISMS) requirements and references ISO 17799:2005 for suitable

information security controls.

Later this Spring (target April 2007) ISO 17799:2005 will become ISO 27002:2007. From a

nomenclature viewpoint this will be a good thing since everything will be an ISO 2700x

document. From a content viewpoint there should be no change to the current ISO 17799:2005

and ISO 27001 pairing.

As with NIST there are a series of documents related to the information security process:

ISO/IEC 27000 Fundamentals and vocabulary

ISO/IEC 27001 ISMS - Requirements (revised BS 7799 Part 2:2005) - Published 15th Oct

2005

ISO/IEC 27002 Code of practice for information security management as from April 2007

-currently ISO/IEC 17799:2005, published 15th June 2005

ISO/IEC 27003 ISMS implementation guidance (under development)

ISO/IEC 27004 Information security management measurement (under development)

ISO/IEC 27005 Information security risk management (based on and incorporating

ISO/IEC 13335 MICTS Part 2) (under development)

ISO/IEC 27006 Requirements for bodies providing audit and certification of information

security management systems


7. COMPARISON OF ISO 27001/17799 AND NIST SP800-30/53

The following tables compare the ISO and NIST standards for information security. Table 2.0 is

a direct comparison of ISO 27001 (establishing an ISMS) against NIST SP800-30 (risk

management framework) with supplemental information from ISO 17799:2005 and NISP

SP800-53. Table 3.0 is a direct comparison of ISO 17799:2005 (security controls) and NIST

SP800-53 (security controls).

Its encouraging to see the direct overlap between NIST and ISO standards and controls. The

documents use different numbering schemes and the processes tend to diverge and converge

due to the underlying structural differences: PDCA versus SDLC models. However, if one is

willing to look past the structural differences, the actual requirements in both scope and scale

are quite similar.

Toward the back of the NIST SP800-53 document is a table that cross references SP800-53

controls with ISO 17799:2005 controls. Tables 1.0 and 2.0 offers a reverse comparison;

referencing ISO to NIST versus NIST to ISO. Interestingly, relationships that dont exist in the

NIST 800-53 cross reference do become evident when going the other way and vice versa;

some relationships that are in the NIST table dont make sense when cross referencing in the

reverse direction. Its important to be able to look at the standards from both directions to

better support CISOs and Compliance Officers, regardless of which standard they are focused

on. The end-result is that which ever way one compares the two, there is significant overlap

between ISO 17799:2005 and NIST 800-53. However, there isnt complete overlap and the

holes that exist are highlighted as areas needing further attention and discussion.

ISOvFISMA.031207

Documents

Transcript of ISOvFISMA.031207