Provläsningsexemplar / Preview
TECHNICAL
REPORT
ISO/IEC
TR
19791
First edition
2006-05-15
Information technology — Security
techniques — Security assessment
of operational systems
Technologies de l'information — Techniques de sécurité — Évaluation
de la sécurité des systèmes opérationnels
Reference number
ISO/IEC TR 19791:2006(E)
© ISO/IEC 2006
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
Contents
Page
Foreword............................................................................................................................................................. v
Introduction ....................................................................................................................................................... vi
1
Scope ..................................................................................................................................................... 1
2
Normative references ........................................................................................................................... 1
3
Terms and definitions........................................................................................................................... 2
4
Abbreviated terms ................................................................................................................................ 4
5
Structure of this Technical Report...................................................................................................... 4
6
6.1
6.2
6.3
6.4
Technical approach .............................................................................................................................. 5
The nature of operational systems ..................................................................................................... 5
Establishing operational system security.......................................................................................... 5
Security in the operational system life cycle ..................................................................................... 7
Relationship to other systems ............................................................................................................ 9
7
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
Extending ISO/IEC 15408 evaluation concepts to operational systems ......................................... 9
Overview ................................................................................................................................................ 9
General philosophy .............................................................................................................................. 9
Operational system assurance.......................................................................................................... 11
Composite operational systems ....................................................................................................... 13
Types of security controls ................................................................................................................. 16
System security functionality............................................................................................................ 17
Timing of evaluation ........................................................................................................................... 18
Use of evaluated products................................................................................................................. 19
Documentation requirements............................................................................................................ 20
Testing activities................................................................................................................................. 20
Configuration management ............................................................................................................... 21
8
8.1
8.2
8.3
8.4
Relationship to existing security standards .................................................................................... 22
Overview .............................................................................................................................................. 22
Relationship to ISO/IEC 15408........................................................................................................... 23
Relationship to non-evaluation standards ....................................................................................... 24
Relationship to Common Criteria development .............................................................................. 24
9
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
Evaluation of operational systems ................................................................................................... 24
Introduction ......................................................................................................................................... 24
Evaluation roles and responsibilities ............................................................................................... 24
Risk assessment and determination of unacceptable risks .......................................................... 26
Security problem definition ............................................................................................................... 27
Security objectives ............................................................................................................................. 27
Security requirements ........................................................................................................................ 27
The system security target (SST)...................................................................................................... 29
Periodic reassessment....................................................................................................................... 31
Annex A (normative) Operational system Protection Profiles and Security Targets................................ 32
A.1
Specification of System Security Targets ........................................................................................ 32
A.2
Specification of System Protection Profiles .................................................................................... 39
Annex B (normative) Operational system functional control requirements .............................................. 46
B.1
Introduction ......................................................................................................................................... 46
B.2
Class FOD: Administration ................................................................................................................ 48
B.3
Class FOS: IT systems ....................................................................................................................... 56
B.4
Class FOA: User Assets..................................................................................................................... 66
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
iii
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
B.5
B.6
B.7
B.8
Class FOB: Business.......................................................................................................................... 68
Class FOP: Facility and Equipment .................................................................................................. 70
Class FOT: Third parties .................................................................................................................... 75
Class FOM: Management ................................................................................................................... 77
Annex C (normative) Operational system assurance requirements ........................................................... 81
C.1
Introduction ......................................................................................................................................... 81
C.2
Class ASP: System Protection Profile evaluation ........................................................................... 88
C.3
Class ASS: System Security Target evaluation ............................................................................. 100
C.4
Class AOD: Operational system guidance document................................................................... 113
C.5
Class ASD: Operational System Architecture, Design and Configuration Documentation ...... 121
C.6
Class AOC: Operational System Configuration Management...................................................... 128
C.7
Class AOT: Operational System Test ............................................................................................. 134
C.8
Class AOV: Operational System Vulnerability Analysis ............................................................... 145
C.9
Class AOL: Operational system life cycle support........................................................................ 153
C.10
Class ASI: System security installation and delivery.................................................................... 154
C.11
Class ASO: Records on operational system.................................................................................. 158
Annex D (informative) Relationship to Common Criteria development.................................................... 162
Bibliography ................................................................................................................................................... 165
iv
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report
of one of the following types:
⎯
type 1, when the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts;
⎯
type 2, when the subject is still under technical development or where for any other reason there is the
future but not immediate possibility of an agreement on an International Standard;
⎯
type 3, when the joint technical committee has collected data of a different kind from that which is
normally published as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether
they can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to
be reviewed until the data they provide are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 19791, which is a Technical Report of type 2, was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 27, IT Security techniques.
The technical content of this Technical Report has been published as a Common Criteria Supporting
Document by the Common Criteria Development Board.
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
v
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
Introduction
This support document defines extensions to ISO/IEC 15408 to enable the security assessment (evaluation)
of operational systems. ISO/IEC 15408, as currently defined, provides support for specifying the IT security
functionality that exists in products and systems. However, it does not capture certain critical aspects of an
operational system that must be precisely specified in order to effectively evaluate such a system.
This Technical Report provides extended evaluation criteria and guidance for assessing both the information
technology and the operational aspects of such systems. The document is primarily aimed at those who are
involved in the development, integration, deployment and security management of operational systems, as
well as evaluators seeking to apply ISO/IEC 15408 to such systems. It will be relevant to evaluation authorities
responsible for approving and confirming evaluator actions. Evaluation sponsors, and other parties interested
in operational system security, will be a secondary audience, for their background information.
Considering the complexity of this project and the need for additional work, the target has been defined to be
a type 2 Technical Report. In the future, once additional experience has been gained in this area, it is hoped
that it may be possible to convert this Technical Report into an International Standard to support
ISO/IEC 15408 specifically for evaluations of operational systems. Until some formalisation of an approach is
performed, it is considered unlikely that many operational system evaluations of this nature will be undertaken
due to the lack of specific guidance available, a gap that this TR is designed to fill.
There are fundamental issues in regard to the definition and use of the term system. ISO/IEC 15408, with its
focus on product evaluation, uses the term to include only the information technology (IT) aspects of the
system. The term operational system, as used within this Technical Report, covers the combination of
personnel, procedures and processes integrated with technology-based functions and mechanisms, applied
together to establish an acceptable level of residual risk in a defined operational environment.
vi
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
TECHNICAL REPORT
ISO/IEC TR 19791:2006(E)
Information technology — Security techniques — Security
assessment of operational systems
1
Scope
This Technical Report provides guidance and criteria for the security evaluation of operational systems. It
provides an extension to the scope of ISO/IEC 15408, by taking into account a number of critical aspects of
operational systems not addressed in ISO/IEC 15408 evaluation. The principal extensions that are required
address evaluation of the operational environment surrounding the TOE, and the decomposition of complex
operational systems into security domains that can be separately evaluated.
This Technical Report provides
a)
a definition and model for operational systems;
b)
a description of the extensions to ISO/IEC 15408 evaluation concepts needed to evaluate such
operational systems;
c)
a methodology and process for performing the security evaluation of operational systems;
d)
additional security evaluation criteria to address those aspects of operational systems not covered by the
ISO/IEC 15408 evaluation criteria.
This Technical Report permits the incorporation of security products evaluated against ISO/IEC 15408 into
operational systems evaluated as a whole using this Technical Report.
This Technical Report is limited to the security evaluation of operational systems and does not consider other
forms of system assessment. It does not define techniques for the identification, assessment and acceptance
of operational risk.
2
Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 15408-1:2005, Information technology — Security techniques — Evaluation criteria for IT security —
Part 1: Introduction and general model
ISO/IEC 15408-2:2005, Information technology — Security techniques — Evaluation criteria for IT security —
Part 2: Security functional requirements
ISO/IEC 15408-3:2005, Information technology — Security techniques — Evaluation criteria for IT security —
Part 3: Security assurance requirements
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
1
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
3
Terms and definitions
For the purposes of this document, terms and definitions given in ISO/IEC 15408-1:2005 and the following
apply.
3.1
component
identifiable and distinct portion of an operational system that implements part of that system’s functionality
3.2
external operational system
separate operational system which interfaces to the operational system that is the subject of evaluation
3.3
management controls
security controls (i.e., safeguards and countermeasures) for an information system that focus on the
management of risk and the management of information system security
[NIST SP 800-53]
3.4
operational controls
security controls (i.e., safeguards and countermeasures) for an information system that primarily are
implemented and executed by people (as opposed to systems)
[NIST SP 800-53]
3.5
operational system
information system, including its non-IT aspects, considered in the context of its operating environment
3.6
residual risk
risk that remains after risk treatment
[ISO/IEC 13335-1:2004]
3.7
risk
potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm
to the organization
NOTE
Risk is measured in terms of a combination of the probability of an event and its consequence.
[ISO/IEC 13335-1:2004]
3.8
risk analysis
systematic approach of estimating the magnitude of risks
[ISO/IEC 13335-1:2004]
3.9
risk assessment
process of combining risk identification, risk analysis and risk evaluation
[ISO/IEC 13335-1:2004]
2
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
3.10
risk management
total process of identifying, controlling and eliminating or minimizing uncertain events that may affect system
resources
NOTE
Adapted from ISO/IEC 13335-1:2004. Risk management typically includes risk assessment, risk treatment,
risk acceptance and risk communication (exchange or sharing of information about risk between the decision-maker and
other stakeholders).
3.11
risk treatment
process of selection and implementation of security controls to modify risk
NOTE
Adapted from ISO/IEC 13335-1:2004.
3.12
security controls
management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an
information system to protect the confidentiality, integrity, and availability of the system and its information
[NIST SP 800-53]
NOTE
This definition is intended to include controls that provide accountability, authenticity, non-repudiation, privacy
and reliability, which are sometimes considered as distinct from confidentiality, integrity and availability.
3.13
security domain
portion of an operational system that implements the same set of security policies
3.14
subsystem
one or more operational system components that are capable of execution separately from the rest of the
system
3.15
system target of evaluation
operational system that is being operated in accordance with its operational guidance, including both technical
and operational controls
NOTE
Operational controls form part of the operational environment. They are not evaluated in ISO/IEC 15408
evaluation.
3.16
technical controls
security controls (i.e., safeguards and countermeasures) for an information system that are primarily
implemented and executed by the information system through mechanisms contained in the hardware,
software, or firmware components of the system
[NIST SP 800-53]
3.17
verification
assessment processes used to confirm that the security controls for an operational system are implemented
correctly and are effective in their application
3.18
vulnerability
flaw, weakness or property of the design or implementation of an information system (including its security
controls) or its environment that could be intentionally or unintentionally exploited to adversely effect an
organization’s assets or operations
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
3
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
4
Abbreviated terms
For the purposes of this document, the abbreviated terms given in ISO/IEC 15408-1:2005 and the following
apply.
COTS
Commercial Off The Shelf
ETR
Evaluation Technical Report
ISMS
Information Security Management System
OSF
Operational Security Functionality
SP
Special Publication
SPP
System Protection Profile
SSA
System Security Assurance
SSF
System Security Functionality
SST
System Security Target
STOE
System Target of Evaluation
5
Structure of this Technical Report
Clauses 1 to 4 contain introductory and reference material, and are followed by this overview of the contents
of the Report (Clause 5).
Clause 6, Technical approach, describes the technical approach to operational systems assessment used in
this Technical Report.
Clause 7, Extending ISO/IEC 15408 evaluation concepts to operational systems, describes
ISO/IEC 15408 evaluation concepts have been extended for use in operational system evaluation.
how
Clause 8, Relationship to existing security standards, describes the relationship between this Technical
Report and other security standards which have been used in its development.
Clause 9, Evaluation of operational systems, contains requirements for specification of security problems,
security objectives, security requirements, SST contents and periodic reassessment which are needed in
order to evaluate operational systems.
Annex A, Operational system Security Targets and System Protection Profiles, defines the security
requirement specifications needed for operational systems.
Annex B, Operational system functional control requirements, defines the additional security functional
requirements needed for operational systems.
Annex C, Operational system assurance requirements, defines the additional security assurance requirements
needed for operational systems.
Annex D, Relationship to Common Criteria development, identifies necessary differences between the
evaluation of operational systems and product evaluation based upon proposed changes to the Common
Criteria.
4
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
6
6.1
Technical approach
The nature of operational systems
For the purposes of this Technical Report, an operational system is defined as an information system,
including its non-IT aspects, considered in the context of its operating environment.
Many operational systems are complex in nature, made up of a combination of subsystems that are partially
proprietary and unique in nature, and partially constructed using bought-in general products. They interact
with and have dependencies upon other systems. An operational system is typically built using components
from multiple vendors. These components may be integrated to compose the operational system by an
integrator that does not perform any development functions, only configuration and interconnection.
However, operational systems typically:
⎯
are under the control of a single entity, the operational system owner;
⎯
are built against specific needs, for a specific type of operation;
⎯
change frequently; either in technical set-up and/or in operational requirements;
⎯
contain a considerable (or even large) number of components;
⎯
contain bought-in components that possess a large number of possible configuration alternatives;
⎯
enable the operational system owner to balance technical (and specifically IT) and non-technical security
measures;
⎯
contain components with different degrees and types of security assurance.
6.2
Establishing operational system security
Secure products offer an important contribution to operational system security and indeed the use of products
evaluated against ISO/IEC 15408 may be preferable in construction of a secure operational system. However,
security problems in operational systems are caused not only from product problems but also from operational
system problems in a real operational environment, such as poor application of bug fixes, poor setting of
access control parameters or filtering rules of a firewall, poor linking of files directories, etc. Furthermore, in
the case of a network, the security level of an operational system connected to the network might be of
concern to other operational systems that have to communicate with it.
This Technical Report is based upon a three step approach to establishing the necessary level of security for
an operational system:
a)
risk assessment, to determine the security risks applicable to a system;
b)
risk reduction, to counter or eliminate security risks by the selection, application and assessment of
security controls;
c)
accreditation, to confirm that the residual risks remaining within the system after the controls are applied
are appropriate for the system to be used in live operation.
Conceptually, this three step process is shown in Figure 1 following.
This Technical Report addresses only the middle step of the three step process, namely risk reduction through
the selection, application and assessment of security controls. To do this, it uses a security evaluation
approach, based upon the security evaluation model for IT security controls defined in ISO/IEC 15408, but
extended to deal with all types of security controls.
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
5
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
Techniques and methods for risk assessment are beyond the scope of this report. For more information on
risk assessment, see part 3 of ISO/IEC 13335 [1].
NOTE
Note that part 3 of ISO/IEC 13335-3 is a Technical Report. International Standard ISO/IEC 27005, when
published, will supersede ISO/IEC TR 13335.
Techniques and models for accreditation are a management responsibility, beyond the scope of this report.
For more information on one possible approach, see NIST SP 800-37 [2].
The security evaluation model of ISO/IEC 15408 excludes consideration of the operational environment
surrounding the IT portion of the information system. The operational environment is treated as assumptions
in ISO/IEC 15408 evaluation, but cannot be discounted for operational systems. Typically, operational
systems are reliant on non-IT security measures, e.g. measures of an administrative or physical nature. There
is therefore a need to define ways to express and evaluate such requirements and controls, as an extension
to the ISO/IEC 15408 specification criteria. This Technical Report extends ISO/IEC 15408 to do this.
Risk Assessment
Risk identification
Risk analysis
Risk evaluation
Selection of controls
Specification of controls in the System
Security Target (SST)
Application of controls
Application of security controls to the
System Target of Evaluation (STOE)
Risk Reduction
(Scope of this
Technical Report)
Assessment of controls
Evaluation of compliance with the SST
Accreditation
Acceptance of residual risks
Figure 1 — Process for establishing operational system security
6
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
In total, the extensions to ISO/IEC 15408 within this Technical Report include, but are not limited to:
a)
Positioning security evaluation within an overall methodology for the security assessment of operational
systems including their operational environment.
b)
A methodology for specifying the internal structure of operational systems, including details of internal
and external interfaces, to the extent necessary to understand how the various portions of an operational
system interoperate.
c)
A catalogue of assurance criteria to express the extensions to the scope of evaluation (see Annex A).
d)
A catalogue of functional criteria to express additional operational security controls (see Annex B).
e)
A catalogue of assurance criteria to express the additional evaluation tasks needed to assess operational
systems (see Annex C).
Extending the ISO/IEC 15408 approach to the evaluation of complete operational systems has the advantage
of using a defined existing metric so that common and mutual understanding of evaluation results is possible.
For a specific operational system, advertising the evaluation result in a way that is compatible with
ISO/IEC 15408 might bring business advantage to customers, not only for service provider systems such as
internet banking systems, but also from the view point of social responsibility.
Operational system evaluation requires that a prior risk assessment has identified the security risks applicable
to an operational system, and determined those risks that are unacceptable and must be reduced or
eliminated through technical and operational controls. It then consists of the following steps:
a)
Setting security objectives for the operational system that will reduce the unacceptable risks to a level
which is tolerable.
b)
Selecting and specifying technical and operational security controls that satisfy the security objectives for
the operational system, taking due account of controls that already exist.
c)
Defining concrete, measurable assurance requirements for both the technical and operational controls to
gain the requisite level of confidence that the operational system meets its security objectives.
d)
Recording the decisions made in a System Security Target (SST).
e)
Evaluating the actual operational system to judge compliance with the SST.
f)
Periodically reassessing both the security risks to the operational system and the operational system’s
ability to address those risks.
Although this model is an extension of the ISO/IEC 15408 model, it is consistent with that model so that
ISO/IEC 15408 evaluation results can be reused.
6.3
6.3.1
Security in the operational system life cycle
Overview
The life cycle of an operational system is considered to have four phases, namely development/integration,
installation, system operation and modification. The security controls of an operational system must be
assessed throughout the lifetime of the system.
6.3.2
Development/integration phase
During the development/integration phase, the first security activity is to identify the risks to the operational
system. Those risks that are considered unacceptable must be reduced or eliminated by security measures
built into the system. Following the risk assessment and identification of risks to be eliminated, an authorized
officer of the organization, the Accreditor, must consider the anticipated residual risks, and the sum of the
residual risks, and confirm that they will be acceptable.
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
7
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
The operational system will then be designed, including the use of software and hardware products, the
physical facilities required, the business application programs needed and the technical security controls
required. The design of the operational system must be recorded in the SST. The SST will contain a
description of the system security requirements, including the risks to be countered and the security objectives
to be achieved by technical and operational controls. The list of technical and operational controls
documented in the SST will represent an instantiation of the system security objectives.
For the purposes of correctness, security objectives should be specified in the SST that address all risks
identified as unacceptable. The SST should specify security requirements that completely satisfy the security
objectives without any additions or omissions. The design documentation for the operational system should
identify precise security countermeasures within the operational system that meet all of the security
requirements specified in the SST. The countermeasures might be security functions, facilities, procedures or
rules. The countermeasures should be adequately controlled, managed and applied to the system. The
security countermeasures should be implemented without any unauthorized addition, elimination or
modification. The implementation should be verified with testing of the system or checking of documents. The
operation of security countermeasures should be adequately described in the guidance documents.
For effectiveness, the selected security requirements should reduce all security risks identified by risk
assessment as unacceptable to a level that can be tolerated as residual risks. Each security countermeasure
should work effectively in combination with other countermeasures to satisfy the overall security requirements
for the operational system. The strength of the security mechanisms should be sufficient to match the
expected attack potential. Vulnerability analysis and penetration testing might be required with the expected
attack potential.
Evaluators should be involved in the development/integration phase, early in the system life cycle, to facilitate
their understanding of the system and its intended environment, as well as to provide input from review of
design documentation, and to provide guidance on evaluation and guidance documentation to be used as part
of assurance evidence. Ideally the full SST should be evaluated in a preliminary evaluation to confirm that
there are no inconsistencies or omissions in the security requirements and proposed controls.
The business applications and systems software, including the technical security controls, are then produced
or purchased, and the system is integrated, configured, and tested by the developer. At the same time, the
operational security organization is created and security policies, rules and procedures produced and
integrated into the system. The proper security configuration settings should be identified and implemented.
Following integration testing, the operational system should be security tested as part of the developer’s
requirements verification testing. Typically, system specific security controls such as access controls can be
verified by the developer prior to deployment at the operational site. Testing of site specific security controls
(both technical and operational) is deferred until the system is installed in its intended operational environment.
Verification testing will confirm the strength of security mechanisms, as well as the correct operation of the
security controls.
The operational system will then be evaluated. The evaluation should confirm that all risks, as detailed in the
SST, that have to be countered by security controls are addressed by the system at an acceptable level. The
result of the evaluation is an independent confirmation to the system owner that this is the case.
The Certification Report will list any confirmed vulnerabilities found in evaluation, and identify any
recommended corrective actions, as required. The system owner will then prepare a corrective action plan to
reduce or eliminate the identified vulnerabilities, as deemed appropriate. The result of the certification of the
system will be presented to the Accreditor for determination that the actual residual risk to operations and
system assets is acceptable. The output of this phase will be an authorization for the system to operate.
6.3.3
Installation phase
During the installation phase, the technical and operational controls will be implemented and prepared for use
in the operational environment. Site specific controls will be tested, and other controls retested to confirm that
they perform correctly in the actual operational environment.
For the purposes of correctness, the controls should be compliant with the security requirements documented
in the SST and authorized for use by a competent person. To be effective, all persons should be trained in use
of the security controls and procedures.
8
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
6.3.4
System operation phase
In the system operation phase, records of the operation of technical controls and operational controls should
be collected and assessed. Audit trails and monitoring records for all access to assets should be logged.
Security countermeasures should be confirmed as operating as intended. It should be verified that
unauthorized operations and unacceptable risks have not occurred. Secure states should be recovered from
insecure states within the required time. Changes due to routine maintenance should be monitored and
assessed for security problems. Records of actual access and utilization of assets should be inspected.
Security problems should be reported, reviewed and analyzed.
The purpose of these activities is to provide feedback to the Accreditor when changes occur that may have an
impact on operational system security. Typically, in systems operation, a critical subset of the operational
system security controls should be identified for regular monitoring to determine their continued effectiveness.
Additionally, the system owner should have in place a configuration management, control, and reporting
system that documents the current operational system assets, its configuration, and presents that information
to the responsible parties.
6.3.5
Modification phase
During the system modification phase, any proposed or actual operational system changes beyond the scope
of routine maintenance should be reviewed, analysed and, if necessary, tested to determine their impact on
operational system security before being implemented in live operation. This includes changes to procedures
and policies. Penetration testing of modified controls should be performed to verify their effective operation.
The results of impact analysis and testing should be presented to the Accreditor to determine the need for
security re-evaluation. Where modifications are deemed not to have significantly increased the residual risks,
perhaps because they have already been assessed as part of a product assurance maintenance process, reauthorization may be given without re-evaluation. However, if the evaluation results have been invalidated, reevaluation may be required.
The final act of system modification is decommissioning, where a system is closed down and its data archived,
destroyed or transferred to other systems. The Accreditor will be required to confirm that the system has been
successfully terminated.
6.4
Relationship to other systems
An operational system may interact with other related systems and may form part of a larger whole. The
STOE of the evaluated operational system is defined to be that portion of the group of systems that is
evaluated, including both IT systems and their operational environment. The remainder is considered to be
external operational systems. An operational system may have security objectives that are met by the external
operational systems, but these are not analysed or evaluated.
7
7.1
Extending ISO/IEC 15408 evaluation concepts to operational systems
Overview
The purpose of this clause is to document the philosophy that underpins the ISO/IEC 15408 approach to
security evaluation and then to extend it to operational systems. ISO/IEC 15408 addresses only technical
controls and their related management controls; in operational systems, technical controls and operational
controls combine to protect the information and other assets of the organization.
7.2
General philosophy
For many organizations, information is the primary asset and requires protection against the threats of
unauthorised release, modification, or destruction. Those assets are protected using a combination of
technical controls and supporting operational control infrastructures of personnel, policy, procedures and
physical protection measures. The overall ISO/IEC 15408 philosophy is that threats to organizational assets
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
9
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
should be clearly articulated and countered using a combination of technical control and operational control
infrastructures. The technical control requirements for addressing threats are included in ISO/IEC 15408-2.
Under ISO/IEC 15408, the requirements for the operational controls were considered separately as part of an
external accreditation process and therefore were not directly addressed by the security evaluation. This
document seeks to formalise those requirements so that they may be assessed as part of the operational
system evaluation.
ISO/IEC 15408 conceptually divides security measures into security-related services that must be provided
and measures taken to have confidence that those measures are implemented correctly and effectively. In a
product evaluation, the security-related services are those functions in the IT implemented to meet the
objectives for that piece of technology. In an operational systems context, the procedural and physical
contributions to the security can also be assessed. They are similar to IT functionality because they are
security capabilities of the operational system that together meet the security objectives. However, they are
not normally technology-based and are more suited to assessment during the operational control portion of
the operational system life cycle than the development portion. Therefore, they are considered to be separate
from functional requirements.
The measures taken to ensure that the security capabilities perform as expected are termed “assurance” in
ISO/IEC 15408 and consist of evidence being generated and independent assessment of the suitability of
those capabilities. This can be extended to cover the operational controls portion of the operational system
through documentation describing the operational controls as implemented.
The process used to develop, implement and maintain both the operational system itself and more specifically
the security related services has a considerable influence on the correctness and effectiveness of the security
related service and its overall contribution to the total security of the operational system. This influence also
contributes to the confidence in the performance of the security related service. Thus the process contributes
to the overall assurance of the complex operational system. More specifically the greater the level of capability
of the process, the greater the confidence that can be had in the correctness and effectiveness of the security
related service and thus the overall assurance provided.
In summary, operational security functional requirements are those non-technical security controls
implemented in the operational system contributing to the overall security objectives, while operational
security assurance requirements reflect the evidence that those requirements are satisfied.
Evaluation of security in an operational system can therefore be decomposed into a series of steps:
a)
The security problem is articulated as a set of risks to be reduced or mitigated, and a set of organizational
security policies to be enforced. This requires prior analysis to determine the purpose of the operational
system, and risk assessment to determine those risks that must be countered by technical and
operational controls. The results of the analysis are recorded in the SST.
b)
The security problem is partitioned into a high-level security solution, represented by a set of security
objectives. These objectives are recorded in the SST.
c)
The security objectives are further refined into security requirements that can be assessed by an
independent evaluator. Some security objectives will be allocated to the technical controls and others to
operational controls. Some may require both technical and operational controls. For example, controlling
unauthorized access to an information asset will often be accomplished both by providing physical
security to the facility holding the asset (e.g. locks, guards) and by IT functionality (e.g. user
authentication and access control mechanisms). The security requirements are recorded in the SST.
d)
A set of activities for the evaluator to follow during the assessment is defined, based on the overall
objectives and the overall assurance in the protection measures required. These assurance requirements
are recorded in the SST.
e)
An independent evaluator assessment determines that the operational system meets its security
requirements, based on the requirements documented in the SST.
10
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
f)
Continuing assessments can also take place to gain confidence that the operational system meets its
requirements during operation. These will focus mostly on the operational control portion of the
operational system because these controls depend on human behaviour, which is less controllable and
consistent than IT behaviour.
g)
Periodic re-evaluation of the operational system can assess that the operational system continues to
meet its requirements despite changes to the operational system or its environment. This consists of
determining what changes have taken place, assessing the security impact of those changes, updating
the SST as required, and determining that security has been maintained during this process.
This process is very similar to the ISO/IEC 15408 evaluation process. The typical difference between an
operational system evaluation and an ISO/IEC 15408 product evaluation is that in an operational system
evaluation the actual operational environment is fully considered, whereas in a product evaluation the
operational environment is not defined in detail, it is described purely as assumptions which are not verified
during the evaluation.
The primary goal of an operational system evaluation is to gain assurance that the security objectives for the
operational system are implemented correctly and effectively. However, evaluation of security controls,
whether technical or operational, can never provide absolute assurance that those controls will always
function as intended, at all times and in all circumstances. Evaluation produces a pass or fail verdict. Even if
evaluation identifies no unacceptable vulnerabilities, there will always be a residual risk that the controls do
not perform as intended. This risk can be reduced by adding additional assurance controls or using different
assurance measures that give greater confidence. The residual risk of incorrect or ineffective performance of
controls can only be identified through continuous monitoring and assessment.
This residual risk must be taken into account when deciding if an operational system can be accredited for live
operation.
Environmental factors may result in differing criticality/threat environments for different operational system
components. It is possible that some portions of the operational system may require greater assurance while
other portions require less assurance. Because risk assessment can establish different levels of acceptability
of risk for different portions of the operational system, an operational system can be divided into security
domains with different assurance requirements. The risk assessment will determine acceptability of risk for
different parts of the operational system and will aid in determining appropriate assurance measures for each
part of the operational system.
7.3
Operational system assurance
The ISO/IEC 15408 paradigm for assurance centres on the provision of evidence that the security functions
exist and are implemented correctly and effectively. Higher levels of assurance place more detailed
requirements on the content and presentation style of the evidence. In addition, higher assurance sometimes
requires increasing rigour of analysis of the evidence by both the developer and the evaluator.
An ISO/IEC 15408 product evaluation is conducted in a manner that assumes a generic operational
environment in which the product might be employed. The product evaluation focuses on verifying the security
capabilities implemented by the product, independent of any specific operational context. The product
evaluation utilises various specification, design and test documentation to substantiate the verdict of
correctness.
The primary goal of a product evaluation is to gain assurance that the security capabilities of the product are
implemented correctly. The basis for correctness is established by the security requirements that are
contained in the product’s Security Target (ST). The ST includes some traceability on the security problem
being solved by the resulting set of security requirements. The security problem stated in the ST is assumed
to be based on a threat assessment for the types of environments suitable for deployment of the product. The
scope of the product evaluation is limited to the IT security requirements allocated to the product by this threat
assessment. In addition, the product evaluation sets bounds for “secure values” for configurable aspects of
the product: termed the “evaluated configuration”. However, these configurations do not take into account any
specific environment as this in unknown at the time of evaluation. Upon completion of the product evaluation,
it remains necessary to properly integrate the evaluated product with other products to compose an
operational system, and finally, to verify that the operational system provides the desired security properties
and behaviour in its operational environment and operational configuration.
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
11
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
Product evaluations generally have the same assurance measures applied across all the security functionality
defined. Although it is technically possible to have different security domains in products, this is not usually
applied for generic product evaluations.
The evaluation evidence and evaluation reports generated from a product evaluation may be used to support
the operational system integration and verification effort.
In principle, there is little difference between the properties of an IT product and an operational system for the
purposes of security evaluation. However, operational system evaluation may be significantly more complex
than ISO/IEC 15408 product evaluation for a number of reasons:
a)
An operational system may comprise many bought-in products and custom IT developments grouped into
security domains. The composition of each system security domain may be based upon several factors,
such as the technology employed, the functionality provided and the criticality of the assets protected.
b)
An operational system may contain multiple instances of the same product (e.g., multiple copies of an
operating system provided by the same vendor) or multiple different product instances of the same
product type (e.g., multiple firewalls provided by several different vendors).
c)
An operational system may have security policies that apply to some security domains while not applying
to others.
d)
Different residual risks may be acceptable within different domains of an operational system, whereas a
product counters specific threats to specific types of asset without consideration of risk.
The main distinction between an ISO/IEC 15408 product evaluation and an operational system evaluation is
that an operational system evaluation must fully consider all security controls, including those implemented in
the operational environment, which are treated as assumptions in a product evaluation. In general, the type of
assurance requirements for technical controls documented in ISO/IEC 15408-3 can be directly applied or
easily extended to apply to operational controls. For example, the concept of assessment of design
documentation for technical controls becomes assessment of the description of operating procedures for
operational controls. The actions of people implementing operational controls can be tested in a similar way to
the way that the actions of programs implementing technical controls are tested.
A particular issue concerns assurance of the effectiveness of the controls implementing the SSF. Assurance
in this aspect of technical controls is achieved by architectural design techniques such as domain separation,
non-interference and non-bypassability of controls. For operational controls, analogous but somewhat different
techniques are used, such as separation of duties, inspection and monitoring.
Areas where additional assurance components are needed to handle operational systems are:
a)
the overall security architecture and placement of components within the architecture;
b)
the configuration of the components that comprise the operational system;
c)
the management policies, rules and procedures that govern operation of the operational system;
d)
the requirements and rules for interaction with other trusted and untrusted operational systems;
e)
the monitoring of the non-IT controls during the operational phase of the system life cycle.
Because of its product focus, ISO/IEC 15408 assumes that a TOE will be developed in a single development
environment which is distinct from the intended operational environment. This assumption is unlikely to hold
true for most operational systems. Even if the operational system is developed in a separate test environment,
the final stage of operational system development will be integration into the operational environment, when
the operational control measures are added into the operational system. Some subsystems or components,
particularly bought-in products, may also be developed in distinct and different development environments
from the main development environment.
This means that some ISO/IEC 15408-3 development environment assurance requirements may not be
achievable when developing some operational systems, or their application must be delayed until the system
installation life cycle phase. Similarly, assurance in operational controls can only be fully achieved in the
operational environment.
12
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
Provläsningsexemplar / Preview
ISO/IEC TR 19791:2006(E)
7.4
Composite operational systems
Many operational systems are large and complex, offering multiple functions and with a complicated internal
structure. Often they are made up of many distinct components and subsystems. Each component may
comprise a single function provided by a single product, a single product with multiple functions, or a set of
functions implemented by customised software and operational procedures. Some components may be
grouped into subsystems, capable of independent execution. Such subsystems might comprise a single client
or server constructed from multiple products, multiple servers and/or clients and networks, or heterogeneous
clients and/or servers. Some components and subsystems may already be security evaluated; others not.
System owners may have specific time and cost restrictions when deploying new composite operational
systems. Thus the processes involved when doing the technical part of the approval to operate (sometimes
called site certification as part of an operational system accreditation) need to be adaptable to actual needs.
Typically, composite operational systems:
a)
Contain several subsystems or components, with different degrees and types of assurance.
b)
Have a well defined control structure. This may be a single operational system “owner” or a defined set of
management relationships on the various portions of the operational system.
c)
Are built against specific needs for specific operation.
d)
Individual components carry a large number of possible configuration options, some of which are
inconsistent with the operational system security policies.
e)
Enable the operational system owner to implement a different balance of technical controls and
operational controls in different parts of the operational system.
The security policy may be different for the different combinations above, except for the rare case in which the
operational system has a single function. Logically, all the portions of the operational system under the same
set of security policies can be termed a security domain. This operational system decomposition of
subsystems and components that are governed by the same security policy(s) is then characterized in the
security policy in accordance with the appropriate risks to that domain. Functional and assurance security
requirements may be identified for each security domain. As such, each security domain will have its own
security policy, security problem definition, security objectives, security requirements and security
documentation. However, each of these security domains operates within the larger operational system-level
set of policies, security problems, objectives, requirements, and documentation. Each security domain may
have its own assurance requirements based on the degree of confidence needed in that security domain and
its overall contribution to the operational system. The operational system security target will specify the
operational system security requirements, which will be a representative compilation of the security domains
that comprise the operational system from an operational system context. The security domain concept is
illustrated in Figure 2.
© ISO/IEC 2006 – All rights reserved
Copyright © IEC, 2006, Geneva, Switzerland. All rights reserved. Sold by SIS under license from IEC and SEK.
No part of this document may be copied, reproduced or distributed in any form without the prior written consent of the IEC.
13
Download PDF
Similar pages