ISO/IEC 10181-7:1996
(Main)Information technology — Open Systems Interconnection — Security frameworks for open systems: Security audit and alarms framework
Information technology — Open Systems Interconnection — Security frameworks for open systems: Security audit and alarms framework
Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Cadres de sécurité pour les systèmes ouverts: Cadre d'audit et d'alarmes de sécurité
General Information
Buy Standard
Standards Content (Sample)
INTERNATIONAL
ISO/IEC
10181-7
STANDARD
First edition
1996-08-o 1
Information technology - Open Systems
Interconnection - Security frameworks for
open systems: Security audit and alarms
framework
Technologies de Yin formation - In terconnexion de s ys t&mes ouverts
(09) - Cadres pour la s&wit& dans les systemes ouverts: Cadre pour
I’audit de s6curit6 et les alarmes
Reference number
lSO/IEC 10181-7:1996(E)
---------------------- Page: 1 ----------------------
ISO/IEC 10181=7:1996(E)
CONTENTS
Page
1
1 Scope .
1
2 .
Normative references
2
........................................................................
2.1 Identical Recommendations I International Standards
2
..........................
2.2 Paired Recommendations I International Standards equivalent in technical content
2
3 Definitions .
2
.....................................................................................................
3.1 Basic Reference Model definitions
2
.........................................................................................................
32 Security architecture definitions
3
Management framework definitions .
3:3
3
...........................................................................................
34 Security framework overview definitions
3
3:5 Additional definitions .
4
.................................................................................................................................................
Abbreviations
4
..........................................................................................................................................................
Notation
4
............................................................................................
General discussion of security audit and alarms
4
61 . Model and functions .
.................................................................................. 6
6.2 Phases of security audit and alarms procedures
8
.........................................................................................................
63 . Correlation of audit information
8
....................................................................................
7 Policy and other aspects of security audit and alarms
8
7.1 Policy .
8
.......................................................................................................................................
7.2 Legal aspects
8
......................................................................................................................
7.3 Protection requirements
9
......................................................................................
8 Security audit and alarms information and facilities
9
.............................................................................................................
81 . Audit and alarms information
10
Security audit and alarms facilities .
82 .
11
..........................................................................................................
9 Security audit and alarms mechanisms
12
..............................................................................
10 Interaction with other security services and mechanisms
12
10.1 Entity authentication .
12
...................................................................................................................
10.2 Data origin authentication
12
....................................................................................................................................
10.3 Access Control
12
10.4 Confidentiality .
12
...............................................................................................................................................
10.5 Integrity
12
..................................................................................................................................
10.6 Non-repudiation
13
..........................................................................
Annex A - General security audit and alarms principles for OS1
............................................................................... 15
Annex B - Realization of the security audit and alarm model
17
Annex C - Security Audit and Alarms Facilities Outline .
18
......................................................................................................
Annex D - Time Registration of Audit Events
0 ISO/IEC 1996
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 micro-
film, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
@ ISO?IE@
ISO/IE@ 10181=7:l996(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 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.
IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISO/IEC JTC 1. 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.
International Standard ISO/IEC 1018 l-7 was prepared by Joint Technical Com-
mittee ISO/IEC JTC 1, Information technology, Subcommittee SC 21, @en
systems interconnection, data management and open distributed processing,
in collaboration with ITU-T. The identical text is published as ITU-T Recommen-
dation X.816.
ISO/IEC 1018 1 consists of the following parts, under the general title Information
technology - Open Systems Interconnection - Security frameworks for open
systems:
-Part I: Overview
-Part 2: Authentication framework
-Part 3: Access control framework
-Part 4: Non-repudiation framework
-Part 5: Confidentiality framework
-Part 6: Integrity framework
-Part 7: Security audit and alarms framework
Annexes A to D of this part of ISO/IEC 1018 1 are for information only.
. . .
111
---------------------- Page: 3 ----------------------
ISWIEC 10181=7:1996(E) @ ISO/IEC
Introduction
This Recommendation I International Standard refines the concept of security audit described in ITU-T Rec. X.810 I
ISO/IEC 1018 l-l. This includes event detection and actions resulting from these events The framework, therefore,
addresses both security audit and security alarms.
records and activities. The
it is an independent review and examination of system purposes of a security
A security aud
audit include:
-
assisting in the identification and analysis of unauthorized actions or attacks;
-
helping ensure that actions can be attributed to the entities responsible for those actions;
-
contributing to the development of improved damage control procedures;
confirming compliance with established security policy;
-
reporting information that may indicate inadequacies in system controls; and
-
identifying possible required changes in controls, policy and procedures.
.ng of various security-related events in
In this framework, a security audit consists of the detection, collection and recordi
a security audit trail and analysis of those events.
Both audit and accountability require that information be recorded. A security audit ensures that sufficient information is
recorded about both routine and exceptional events so that later investigations can determine if security violations have
occurred and, if so, what information or other resources have been compromised. Accountability ensures that relevant
information is recorded about actions performed by users, or processes acting on their behalf, so that the consequences
of those actions can later be linked to the user(s) in question, and the user(s) can be held accountable for his or her
actions. Provision of a security audit service can contribute to the provision of accountability.
A security alarm is a warning issued to an individual or process to indicate that a situation has arisen that may require
alarm service include:
timely action. The purposes of a security
to report real or apparent attempts to violate security;
-
to report various security-related events, including “normal” events; and
-
to report events triggered by threshold limits being reached.
iv
---------------------- Page: 4 ----------------------
ISO/IEC 10181-7 : 1996 (E)
INTERNATIONAL STANDARD
IT&T RECOMMENDATION
INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION -
SECURITY FRAMEWORKS FOR OPEN SYSTEMS:
SECURITY AUDIT AND ALARMS FRAMEWORK
1 Scope
This Recommendation I International Standard addresses the application of security services in an Open Systems
environment, where the term “Open Systems” is taken to include areas such as Database, Distributed Applications, Open
Distributed Processing and OSI. The Security Frameworks are concerned with defining the means of providing
protection for systems and objects within systems, and with the interactions between systems. The Security Frameworks
are not concerned with the methodology for constructing systems or mechanisms.
The Security Frameworks address both data elements and sequences of operations (but not protocol elements) which are
used to obtain specific security services. These security services may apply to the communicating entities of systems as
well as to data exchanged between systems, and to data managed by systems.
The purpose of security audit and alarms as described in this Recommendation I International Standard is to ensure that
open system-security-related events are handled in accordance with the security policy of the applicable security
authority.
In particular, this framework:
defines the basic concepts of security audit and alarms;
a>
provides a general model for security audit and alarms; and
b)
identifies the relationship of the Security Audit and Alarms service with other security services.
Cl
As with other security services, a security audit can only be provided within the context of a defined security policy.
The Security Audit and Alarms model provided in clause 6 supports a variety of goals not all of which may be necessary
or desired in a particular environment. The security audit service provides an audit authority with the ability to specify
the events which need to be recorded within a security audit trail.
A number of different types of standard can use this framework including:
standards that incorporate the concept of audit and alarms;
standards that specify abstract services that include audit and alarms;
2)
standards that specify uses of audit and alarms;
3)
standards that specify the means of providing audit and alarms within an open system architecture; and
4)
mechanism s.
standards that specify audit and alarms
5)
Such standards can use this framework as follows:
-
standard types l), 2), 3), 4) and 5) can use the terminology of this framework;
-
standard types 2), 3), 4) and 5) can use the facilities defined in clause 8; and
standard types 5) can be based upon the characteristics of mechanisms defined in clause 9.
2 Normative references
The following Recommendations and International Standards contain provisions, which through reference in this text,
constitute provisions of this Recommendation I International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
ITU-T Rec. X.816 (1995 E) 1
---------------------- Page: 5 ----------------------
ISO/IEC 10181-7 : 1996 (E)
Recommendation I International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards indicated below. Members of IEC and IS0 maintain registers of
currently valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of
currently valid ITU-T Recommendations.
21 . Identical Recommendations I International Standards
-
ITU-T Recommendation X.200 (1994) I ISOLIEC 7498-l : 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
-
CCITT Recommendation X.734 (1992) I ISO/IEC 10164-5:1993, Information technology - Open Systems
Systems management: Event report management function.
Interconnection -
-
CCITT Recommendation X.735 (1992) I ISO/IEC 10164-g: 1993, Information technology - Open Systems
Interconnection - Systems management: Log control function.
-
CCITT Recommendation X.736 (1992) I ISO/IEC 10164-7:1992, Information technology - Open Systems
Interconnection - Systems management: Security alarm reporting function.
-
CCITT Recommendation X.740 (1992) I ISOLIEC 10164-8: 1993, Information technology - Open Systems
Interconnection - Systems management: Security audit trail function.
-
ITU-T Recommendation X.8 10 (1995) I ISOLIEC 1018 1- 1: 1996, Information technology - Open Systems
Interconnection - Security frameworks for open systems: Overview.
22 . Paired Recommendations I International Standards equivalent in technical content
-
CCITT Recommendation X.700 (1992), Management framework for Open Systems Interconnection (OSZ)
for CCITT applications.
ISO/IEC 7498-4: 1989, Information processing systems - Open Systems Interconnection - Basic
Reference Model - Part 4: Management framework.
-
CCITT Recommendation X.80 (1991), Security Architecture for Open Systems Interconnection for
CCITT applications.
IS0 7498-2: 1989, Information processing systems - Open Systems Interconnection - Basic Reference
Model - Part 2: Security Architecture.
3 Definitions
For the purposes of this Recommendation I International Standard, the following definitions apply.
31 . Basic Reference Model definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.200 I
ISO/IEC 7498- 1.
entity;
a)
b) facility;
c) function;
d) service.
32 . Security architecture definitions
This Recommendation I International Standard makes use of the following terms defined in CCITT Rec. X.800 I
ISO/IEC 7498-2.
a) Accountability;
b) Availability;
c) Security Audit;
d) Security Audit Trail;
e) Security Policy.
2
IT&T Rec. X.816 (1995 E)
---------------------- Page: 6 ----------------------
ISOLIEC 30181-7 : 1996 (E)
33 0 Management framework definitions
This Recommendation I International Standard makes use of the following terms defined in CCI‘IT Rec. X.700 I
ISO/IEC 7498-4:
-
Managed Object.
34 0 Security framework overview definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.810 I
ISO/IEC 10181-l.
- Security Domain.
35 l Additional definitions
For the purposes of this Recommendation I International Standard, the following definitions apply.
alarm processor: A function which generates an appropriate action in response to a security alarm and
3.51
generates a security audit message.
3.5.2 audit authority: The manager responsible for defining those aspects of a security policy applicable to
conducting a security audit.
3.5.3 audit anaiyser: A function that checks a security audit trail in order to produce, if appropriate, security alarms
and security audit messages.
3.5.4 audit archiver: A function that archives a part of the security audit trail.
audit dispatcher: A function which transfers parts, or the whole, of a distributed security audit trail to the
3.5.5
audit trail collector function.
3.5.6 audit trail examiner: A function that builds security reports out of one or more security audit trails.
audit recorder: A function that generates security audit records and stores them in a security audit trail.
3.5.7
3.5.8 audit provider: A function that provides security audit trail records according to some criteria.
audit trail collector: A function that gathers records from a distributed audit trail into a security audit trail.
3.5.9
3.5.10 event discriminator: A function which provides initial analysis of a security-related event and, if appropriate,
generates a security audit and/or an alarm.
3.5.11 security alarm: A message generated when a security-related event that is defined by security policy as being
an alarm condition has been detected. A security alarm is intended to come to the attention of appropriate entities in a
timely manner.
3.5.12 security alarm administrator: An individual or process that determines the disposition of security alarms.
3.5.13 security-related event: Any event that has been defined by security policy to be a potential breach of security,
or to have possible security relevance. Reaching a pre-defined threshold value is an example of a security-related event.
3.5.14 security audit message: A message generated as a result of an auditable security-related event.
3.5.15 security audit record: A single record in a security audit trail.
3.5.16 security auditor: An individual or a process allowed to have access to the security audit trail and to build
audit reports.
3.5.17 security report: A report that results from the analysis of the security audit trail and that can be used to
determine whether a breach of security has occurred.
IT&T Rec. X.816 (1995 E) 3
---------------------- Page: 7 ----------------------
ISO/IEC 10181-7 : 1996 (E)
4 Abbreviations
OS1 Open Systems Interconnection
5 Notation
The terms “service” and “mechanism”, where not otherwise qualified, are used to refer to “‘security audit service” and
where not otherwise qualified, refers to a “security audit”.
“security audit mechanism” respectively. The term “audit”,
The term “alarm”, where not otherwise qualified, refers to a “security alarm”.
6
General discussion of security audit and alarms
This clause describes a model for handling security alarms and for conducting a security audit for open systems.
A security audit allows the adequacy of the security policy to be evaluated, aids in the detection of security violations,
facilitates making individuals accountable for their actions (or for actions by entities acting on their behalf), assists in the
detection of misuse of resources, and acts as a deterrent to individuals who might attempt to damage the system. Security
audit mechanisms are not involved directly in the prevention of security violations: they are concerned with the
detection, recording and analysis of events. This allows changes to operational procedures to be implemented in
response to abnormal events such as security violations.
A security alarm is generated following detection of any security-related event that has been defined by security policy
to be an alarm condition. This could include the case of a pre-defined threshold being reached. Some of these events
may require immediate recovery action while others may require further investigation to determine what, if any, action is
required.
An implementati ,on of the security aud it and alarms model may need to use other security services to support the securi
tY
, This subject is considered
audit and alarms service and to ensure its correct and assured operation. further in clause 10.
Although security audit trails and security audits have special characteristics, (non-security) audit trails and audits
may make use of the facilities and mechanisms described in this framework.
As with other aspects of security, maximum effectiveness is achieved by ensuring that specific security audit
requirements are designed into the system. Systems developers should, therefore, take account of the need for
auditability (i.e. ready examination and analysis) of both the design process and the system under development.
NOTE - The security audit and alarms model does not show how other system management and operational facilities
relate to this model.
61 . Model and functions
The model presented below illustrates the functions used in the provision of a security audit and alarms service.
6.1.1 Security audit and alarms functions
Various functions are necessary to support a security audit and alarm service. These are:
-
determines whether
the event discriminator which provides initial analysis of the event and to forward
the event to the audit recorder or the alarm processor;
-
the audit recorder which generates audit records from the messages received and stores the records in a
security audit trail;
-
the alarm processor which generates both an audit message and an appropriate action in response to a
security alarm;
the audit anaiyser which checks a security audit trail and, if appropriate, produces security alarms and
security audit messages;
-
the audit trail examiner which builds security reports out of one or more security audit trails;
-
the audit provider which provides audit records according to some criteria; and
the audit archiver which archives part of a security audit trail.
4 IT&T Rec. X.816 (1995 E)
---------------------- Page: 8 ----------------------
ISO/IEC 10181-7 : 1996 (E)
Additional functions may be necessary to support distributed security audit trails and alarms. These include:
-
the audit trail collector that gathers records from a distributed audit trail into a security audit trail; and
-
the audit dispatcher which transfers parts, or the whole, of a distributed security audit trail to the audit
trail collector function.
6.1.2 Security audit and alarms model
The security audit and alarms model depicted below involves several phases. Following detection of an event, a
determination must be made as to whether the event is security-relevant or not. The event discriminator assesses the
event to determine whether a security audit message and/or a security alarms message should be generated. Security
audit messages are forwarded to the audit recorder: security alarms are forwarded to the alarm processor for evaluation
and further action. Security audit messages are then formatted and transformed into security audit records to be included
in the security audit trail. The older parts of the security audit trail may be archived and both the security audit trail and
the security audit trail archives may be used to construct audit reports by selecting particular security audit trail records
according to specified criteria. That is, the security audit trail may be analysed and security audit reports and/or security
alarms generated. The security audit and alarms model is shown in Figure 1.
I
I I
Alarm
EWnt
r
Alarm Pmcessn b
. .-. . . . .-----.
Action
Discriminator
Audit
Alarm
Audit Recorder 4 A Audit Analyzer
security
Audi Trail Examiner
Reports
Audi Archiwr
Figure 1 - Security audit and alarms model
ITU-T Rec. X.816 (1995 E)
5
---------------------- Page: 9 ----------------------
ISO/IEC 10181-7 : 1996 (E)
6.1.3 Grouping of security audit and alarm functions
The functions depicted in the model may be colocated in one component of a system or distributed among several
components of the system. These functions may also be located in different end systems and they may be duplicated. In
some cases, such as for performance considerations, it will be advantageous for the functions to be grouped. In
particular, an audit recorder, an audit dispatcher, an audit provider and an audit analyser all working on the same
security audit trail may form a part of an unattended end-system.
Another grouping could be an audit trail examiner, and an audit analyser which may be useful for a security auditor.
There may be a chain of functions arranged in a hierarchical manner, particularly in a distributed security audit trail
(see Figure 2). Here an audit trail collector of one component collects audit messages from the audit dispatcher of
another component. This chain ends when a component does not support an audit dispatcher: in this case the component
must support an audit archiver to be able to archive its security audit trail.
The decision of what, if any, functions to group is an implementation issue. The above examples are given as
illustrations only.
\
1 Audit
Audit Trail Collector -
Trail
Audit Audit
Dispatcher
Trail
TISO6440-9Yc02
I I
Figure 2 - Distributed audit trail model
62 0 Phases of security audit and alarms procedures
The security audit service provides an audit authority with the ability to specify and select the events which need to be
detected and to be recorded within a security audit trail, and the events which need to trigger a security alarm and
security audit messages.
The following phases may occur in audit procedures:
-
detection phase, in which a security-related event is detected;
discriminati an initial determination
.on phase, in which as to whether it is necessary to record the
event in the security audit trail or to raise an alarm;
-
alarm processing phase, in which a security alarm or security audit message may be issued;
analysis phase, in which a security-related event is evaluated together with, and in the context of,
previously detected events logged in the audit trail, and a course of action determined;
6 ITU-T Rec. X.816 (1995 E)
---------------------- Page: 10 ----------------------
ISO/IEC 10181-7 : 1996 (E)
-
aggregation phase, in which distributed security audit trail records are collected into a single security
audit trail;
-
report generation phase, in which audit reports are built from security audit trail records; and
-
archiving phase, in which records from the security audit trail are transferred to the security audit trail
archive.
The phases described here are not necessarily distinct in time, i.e. they may overlap.
6.2.1 Detection phase
The detection phase involves determining that an event that may be security-related has occurred. Actual determination
of what, if any, action should be taken in response to this event is the task of the event discriminator (see 6.2.2) but, in
some cases, as determined by security policy, an immediate alarm may be raised.
6.2.2 Discrimination phase
When a security-related event has been detected, the event discriminator will determine the appropriate initial course of
action. The action will be one of:
take no action;
a>
generate a security audit message; or
b)
generate both a security alarm and a security audit message.
C)
The decision as to which of these courses of action should be taken for each event is dependent on the security policy
in effect.
6.2.3 Alarm processing phase
In the alarm processing phase, the alarm processor analyses the alarm to determine the correct course of action. The
action will be one of:
take no action;
a)
initiate recovery action; or
b)
initiate recovery action and generate a security audit message.
C)
The decision as to which of these courses of action should be taken for each event is dependent upon the security policy
in operation.
NOTE - b) and c) might involve bringing the event to the attention of a person such as a security officer or audit
administrator.
6.2.4 Analysis phase
In the analysis phase, a security-related event is processed to determine the appropriate course of action. This processing
can also make use of information about earlier security-related events, as recorded in the security audit trail. The action
will be one of the following:
take no action;
b) generate a security alarm;
c) generate a security audit record; or
generate both a security alarm and a security audit record.
(0
The decision as to which of these four courses of action should be taken for each event is dependent upon the security
policy in effect.
As part of the analysis process, reference may be made to previous events examining records in the security
audit trail
bY
and the security audit trail archive.
6.2.5 Aggregation phase
Individual security audit records f
...
NORME ISO/CEI
INTERNATIONALE 10181-7
Première édition
1996-08-o 1
Technologies de l’information -
Interconnexion de systèmes ouverts
- Cadres de sécurité pour les
(OSI)
systèmes ouverts: Cadre d’audit et
d’alarmes de sécurité
Information technology -
Open Sys tems In terconnection - Security
frameworks for open systems: Security audit and alarms framework
Numéro de référence
ISO/CEI 10181-7: 1996(F)
---------------------- Page: 1 ----------------------
ISOKEI 10181-7:1996(F)
Sommaire
Page
Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1
2
2 Références normatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommandations I Normes internationales identiques . . . . . . . . . . . . . . . . .~. 2
2.1
2
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique . . . . . . .
2
3 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.1 Définitions du modèle de reference de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Définitions de l’architecture de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2
Définitions du cadre de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3
3.4 Définitions de l’aperçu général du cadre de sécurite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Définitions additionnelles 3
3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4
Notation .
Présentation générale de l’audit et des alarmes de sécurité . 4
61 Modèle et fonctions . 5
612 Phases des procédures d’audit et d’alarmes de sécurite . 7
63 . Cor-relation des informations d’audit . 8
Politique et autres aspects de l’audit et des alarmes de sécurité . 9
7
7.1 Politique . 9
Aspects légaux . 9
7.2
7.3 Besoins de protection . 9
Informations et fonctionnalités de l’audit et des alarmes de sécurité . 10
8
8.1 Informations d’audit et d’alarmes . 10
8.2 Fonctionnalités d’audit et d’alarmes de sécurité . 11
9 Mécanismes d’audit et d’alarmes de sécurité . 12
Interaction avec d’autres services et mécanismes de sécurité . 13
10
10.1 Authentification d’entité . 13
13
10.2 Authentification de l’origine des données .
10.3 Contrôle d’accès . 13
10.4 Confidentialité . 13
10.5 Intégrité . 13
10.6 Non-repudiation . 13
Annexe A - Principes généraux d’audit et d’alarmes de sécurite pour l’interconnexion OS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Annexe B - Réalisation du modele d’audit et d’alarmes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
- Grandes lignes des fonctionnalités d’audit et d’alarmes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Annexe C
Annexe D - Heure d’enregistrement des événements d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
0 ISO/CEI 1996
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne
peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou
mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de l’éditeur.
ISOKEI Copyright Office l Case postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
---------------------- Page: 2 ----------------------
ISOKEI 10181-7: 1996(F)
@ ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de I’ISO ou de la CE1 participent au développement de Normes inter-
nationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de I’ISO et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 1018 l-7 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de I?nformation, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’UIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.8 16.
L’ISOKEI 1018 1 comprend les parties suivantes, présentées sous le titre général
Technologies de 1 ‘information
- Interconnexion de systèmes ouverts (OSI) -
Cadres de sécurité pour les systèmes ouverts:
- Partie I: Présentation
- Partie 2: Cadre d’authentification
- Partie 3: Cadre de contrôle d’accès
Partie 4: Cadre de non-répudiation
- Partie 5: Cadre de confidentialité
- Partie 6: Cadre d’intégrité
- Partie 7: Cadre d’audit et d’alarmes de sécurité
Les annexes A à D de la présente partie de I’ISOKEI 1018 1 sont données uni-
quement à titre d’information.
. . .
111
---------------------- Page: 3 ----------------------
0 ISOKEI ISO/CEI 10181-7:1996(F)
Introduction
La présente Recommandation I Norme internationale précise le concept d’audit de sécurité défini dans la
Rec. UIT-T X.8 10 I ISOKEI 101814. Cela comprend la détection d’événements ainsi que les actions resultantes de ces
événements. Le cadre couvre donc a la fois l’audit de sécurité et les alarmes de sécurité.
Un audit de sécurité est une analyse et un examen - effectués de façon indépendante - des enregistrements et activités du
Les objectifs d’un audit de sécurité sont les suivants:
système.
-
aider a l’identification et l’analyse d’actions non autorisées ou d’attaques;
aider à garantir que les actions peuvent être attribuées aux entités responsables de ces actions;
-
contribuer au développement de procédures améliorées de contrôle des dommages;
-
confirmer la conformite avec la politique de sécurité établie;
-
signaler l’information qui peut indiquer des inadéquations dans le contrôle du systeme;
-
identifier les changements possibles requis dans les contrôles, la politique et les procedures.
sécurité
Dans ce cadre, un audit de consiste en la détection, la collecte et l’enregistrement des événements liés à la
té des systèmes ouverts dans un journal d’audit de sécurite et en l’analyse de ces événements.
sécuri
L’audit mais aussi l’imputabilité nécessitent le stockage de l’information. Un audit de sécurité garantit que l’information
enregistrée concerne a la fois les evénements routiniers et les événements exceptionnels, de sorte que des investigations
ultérieures puissent déterminer si des violations de sécurité sont survenues et, si tel est le cas, quelles sont les
- - informations ou les autres ressources qui ont été compromises. L’imputabilité garantit que l’information relative aux
actions réalisées par les utilisateurs, ou par des processus agissant pour leur compte, est enregistrée, de telle sorte que les
conséquences de ces actions puissent être ultérieurement liées aux utilisateurs en question et que les utilisateurs puissent
être tenus responsables de ces actions. La fourniture d’un service d’audit de sécurité peut contribuer à assurer
l’imputabilité.
Une alarme de sécuri .té est une indication émise vers un individu ou un processus pour i .ndiquer qu’une situation pouvant
à temps est apparue. Les objecti .fs d’un service d’alarme de sécurité
nécessiter une action sont les suivants:
-
signaler des tentatives réelles ou apparentes de violer la sécurité;
-
signaler divers événements liés à la sécurité, y compris les événements «normaux»;
-
signaler les événements déclenchés par l’atteinte des limites de seuil.
iv
---------------------- Page: 4 ----------------------
ISOKEI 10181-7 : 1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE SYSTÈMES
CADRES DE SÉCURITÉ POUR LES SYSTÈMES OUVERTS:
OUVERTS (OSI) -
CADRE D’AUDIT ET D’ALARMES DE SÉCURITÉ
1 Domaine d’application
La présente Recommandation I Norme internationale couvre l’application des services de sécurité dans un environnement
de systèmes ouverts, ou le terme «systèmes ouverts» est utilisé pour des domaines tels que les bases de données, les
applications distribuées, le traitement ODP et l’interconnexion OSI. Les cadres de sécurité sont destinés à définir les
moyens d’offrir la protection pour les systèmes et les objets au sein des systèmes, ainsi que les interactions entre
systèmes. Les cadres ne couvrent pas la méthodologie de construction des systèmes ou méçanismes.
Les cadres couvrent à la fois les éléments de données et les séquences d’opérations (mais pas les éléments de protocole)
utilises pour obtenir des services spécifiques de sécurité. Ces services de sécurité peuvent s’appliquer aux entités
communicantes des systèmes aussi bien qu’aux données échangées entre systèmes, ainsi qu’aux données gérées par les
systèmes.
Le but de l’audit et des alarmes de sécurité décrits dans la présente Recommandation I Norme internationale est d’assurer
que les événements liés à la sécurité des systèmes ouverts sont manipulés en accord avec la politique de sécurité de
l’autorité de sécurité en vigueur.
En particulier, ce cadre de sécurité:
définit les concepts élémentaires d’audit et d’alarmes de sécurité;
a>
fournit un modèle général pour l’audit et les alarmes de sécurité;
b)
identifie les relations du service d’audit et d’alarmes de sécurité avec d’autres services de sécurité.
C)
Comme les autre services de sécurité, un audit de sécurité ne peut être fourni que dans le contexte d’une politique de
sécurité définie.
Le modèle d’audit et d’alarmes de sécurité indiqué dans l’article 6 de ce cadre répond à une variété d’objectifs qui peuvent
ne pas être tous nécessaires ou souhaités dans un environnement particulier. Le service d’audit de sécurité offre à une
autorité d’audit la possibilité de spécifier les événements qui doivent être enregistrés dans un journal d’audit de sécurité.
Plusieurs types de normes différents peuvent utiliser ce cadre, y compris:
1) les normes qui incorporent le concept d’audit et d’alarmes;
les normes qui spécifient des services abstraits comprenant l’audit et les alarmes;
2)
les normes qui spécifient les utilisations d’audit et d’alarmes;
3)
qui spécifient les moyens au sein d’une architecture de
les normes de fournir l’audit et les alarmes système
4)
ouvert;
les normes qui spécifient les mécanismes d’audit et d’alarmes.
5)
De telles normes peuvent utiliser ce cadre de la façon suivante:
-
les normes de types l), 2), 3), 4) et 5) peuvent utiliser la terminologie de ce cadre;
les normes de types 2), 3), 4) et 5) peuvent utiliser les fonctionnalités définies dans l’article 8 de ce cadre;
les normes de type 5) peuvent être basées sur les caracteristiques des mécanismes définis dans l’article 9
de ce cadre.
Rec. UIT-T X.816 (1995 F)
1
---------------------- Page: 5 ----------------------
ISOKEI 10181-7 : 1996 (F)
2 Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la référence qui
y est faite, constituent des dispositions valables pour la présente Recommandation I Norme internationale. Au moment
de la publication, les éditions indiquées étaient en vigueur. Toute Recommandation et Norme sont sujettes à révision et
les parties prenantes aux accords fondés sur la présente Recommandation I Norme internationale sont invitées à
rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de KJIT tient à jour une liste des Recommandations de I’UIT-T en vigueur.
21 0 Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I Norme ISOKEI 7498-l : 1994, Tt?chnologies de Z’information -
Interconnexion des systèmes ouverts - Modèle de référence de base: le modèle de référence de base.
-
Recommandation X.734 du CCITT (1992) I ISOKEI 10164-5: 1993, Technologies de Z’information -
Interconnexion des systèmes ouverts - Gestion-systèmes: fonction de gestion des rapports d’événement.
-
Recommandation X.735 du CCITT (1992) I ISOKEI 10164-6:1993, Technologies de Z’information -
Gestion-systèmes: fonction de commande des registres de
Interconnexion des systèmes ouverts -
consignation.
-
Recommandation X.736 du CCITT (1992) I ISOKEI 10164-7:1992, Technologies de Z’information -
Interconnexion des systèmes ouverts - Gestion-systèmes: fonction de signalisation des alarmes de
sécurité.
-
Recommandation X.740 du CCITT (1992) I ISOKEI 10164-8:1993, Technologies de Z’information -
Interconnexion des systèmes ouverts - Gestion-systèmes: fonction de piste de vérification de sécurité.
-
Recommandation UIT-T X.810 (1995) I ISOKEI 10181-1:1996, Technologies de Z’information -
Interconnexion des systèmes ouverts - Cadres de sécurité pour les systèmes ouverts: aperçu général.
22 l Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation X.700 du CCITT (1992), Cadre de gestion pour l’interconnexion de systèmes ouverts
pour les applications du CCITT.
Interconnexion des systèmes ouverts -
ISOKEI 7498-4:1989, Systèmes de traitement de l’information -
Partie 4: Cadre général de gestion.
Modèle de référence de base -
-
Recommandation X.800 du CCITT (1991), Architecture de sécurité pour Z’interconnexion en systèmes
ouverts d’applications du CCITT.
Interconnexion des systèmes ouverts -
ISO 7498-2: 1989, Systèmes de traitement de l’information -
Modèle de référence de base - Partie 2: Architecture de sécurité.
3 Définitions
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
31 . Définitions du modèle de référence de base
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.200 I
ISOKEI 7498- 1:
entité;
b) fonctionnalité;
fonction;
Cl
2 Rec. UIT-T X.816 (1995 F)
---------------------- Page: 6 ----------------------
ISOKEI 10181-7 : 1996 (F)
32 l Définitions de l’architecture de sécurité
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. X.800 du CCITT I
ISOKEI 7498-2:
a) imputabilité;
b) disponibilité;
audit de- sécurité;
C)
d) journal d’audit de sécurité;
e) politique de sécurité.
Définitions du cadre de gestion
33 0
La présente Recommandation I Norme internationale utilise le terme suivant défini dans la Rec. X.700 du CCITT I
ISOKEI 7498-4:
-
objet géré.
Définitions de l’aperçu général du cadre de sécurité
34 .
La présente Recommandation I Norme internationale utilise le terme suivant défini dans la Rec. UIT-T X.810 I
ISOKEI 10181-l:
-
domaine de sécurité.
Définitions additionnelles
35 l
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
3.5.1 processeur d’alarme: fonction qui, en réponse à une alarme de sécurité, génère une action appropriée et
génère un message d’audit de sécurité.
3.5.2 autorité d’audit: gestionnaire responsable de la définition des aspects d’une politique de sécurité applicables à
la conduite d’un audit de sécurité.
analyseur d’audit: fonction qui vérifie un journal d’audit de afin de produire, si cela est
3.5.3 sécurité approprié,
messages d’alarme de sécurité et des messages d’audit de sécurité.
3.5.4 archiviste d’audit: fonction qui archive une partie du journal d’audit de sécurité.
3.5.5 expéditeur d’audit: fonction qui transfère, à la fonction de collecte de journal de sécurité, des parties ou la
totalité d’un journal distribué d’audit de sécurité.
3.5.6 examinateur de journal d’audit: fonction qui, à partir d’un ou plusieurs journaux d’audit de sécurité, construit
des rapports.
enregistreur d’audit: fonction qui génère des enregistrements d’audit de sécurité et les stocke dans un journal
3.5.7
d’audit de sécurité.
3.5.8 fournisseur d’audit: fonction qui fournit des enregistrements de journal d’audit de sécurité en fonction de
certains critères.
3.5.9 collecteur de journal d’audit: fonction qui rassemble les enregistrements d’un journal distribué d’audit dans
un journal d’audit de sécurité.
3.5.10 filtre d’événement: fonction qui fournit une analyse initiale des événements liés à la sécurité et génère un
message d’audit de sécurité et/ou un message d’alarme.
3.5.11 alarme de sécurité: message généré lorsqu’un événement lié à la sécurité, défini par la politique de sécurité
comme étant une condition d’alarme, a été détecté. Une alarme de sécurité est destinée à être portée à temps à l’attention
d’entités appropriées.
Rec. UIT-T X.816 (1995 F)
---------------------- Page: 7 ----------------------
ISOKEI 10181-7 : 1996 (F)
3.5.12 administrateur d’alarme de sécurité: individu ou processus qui détermine la nature des alarmes de sécurité.
3.5.13 événement lié à la sécurité: tout évenement qui a et6 défini par la politique de sécurité comme une brèche
potentielle dans la politique de sécurité, ou comme ayant un intérêt potentiel pour la sécurité. L’arrivée à une valeur
prédefinie de seuil est un exemple d’événement lie à la sécurite.
3.514 message d’audit de sécurité: message généré à la suite d’un événement vérifiable lie à la sécurité.
3.5.15 enregistrement d’audit de sécurité: enregistrement unique dans un journal d’audit de sécurité.
3.5.16 agent d’audit de sécurité: individu ou processus autorisé à avoir accès au journal de sécurité et a bâtir des
rapports d’audit.
rapport de sécurité: rapport qui résulte d’une analyse du journal d’audit de sécurité et qui peut être utilise pour
3.5.17
déterminer si une breche est apparue dans la sécurité.
I
Abréviations
Interconnexion des systèmes ouverts (open systems interconnection).
os1
5 Notation
Sauf indication contraire, les termes «service» et «mécanisme» sont utilisés pour désigner, respectivement, le «service
d’audit de sécurité» et le «mécanisme d’audit de sécurité»; celui d’«audit» désigne un «audit de sécurité» et enfin, celui
d’«alarme» désigne une «alarme de sécurité».
6 Présentation générale de l’audit et des alarmes de sécurité
sécurité et de conduire un audit de sécurité pour les
Cet article decrit un modèle permettant de manipuler les alarmes de
systèmes ouverts
Un audit de sécurite permet d’évaluer l’adéquation de la politique de sécurité, d’aider à la détection des violations de
sécurité, de faciliter l’imputation de leurs actions aux individus (ou des actions des entités agissant pour leur compte),
d’aider à la détection de mauvaise utilisation des ressources, et agit comme élément préventif pour les individus qui
pourraient tenter d’endommager le système. Les mécanismes d’audit de sécurité ne sont pas directement mis en jeu dans
la prévention des violations de sécurité: ils sont impliqués pour la détection, l’enregistrement et l’analyse des événements.
Cela permet de mettre en œuvre des changements dans les procédures opérationnelles en réponse à des événements
anormaux comme des violations de sécurité.
Une alarme de sécurité est générée suite à la détection de tout événement lié à la sécurité qui a été défini par la politique
de sécurité comme étant une condition d’alarme. Cela pourrait inclure le cas de l’obtention d’un seuil prédéfini. Certains
de ces événements peuvent nécessiter une action immédiate alors que d’autres peuvent nécessiter une investigation plus
poussée pour déterminer si une action est requise.
Une mise en œuvre du modèle d’audit et d’alarmes de sécurité peut nécessiter l’utilisation d’autres services de sécurité
pour réaliser le service d’audit et d’alarmes de sécurité et pour assurer son fonctionnement correct et sûr. Ce sujet est
abordé plus loin dans l’article 10.
Bien que l’utilisation des journaux d’audit de sécurité et d’audits de sécurité ait des caractéristiques spéciales, d’autres
journaux d’audit et d’autres audits (autres que de sécurité) peuvent recourir aux fonctions et mécanismes décrits dans le
présent cadre.
Comme avec les autres aspects de la sécurité, on obtient une efficacité maximale en s’assurant que les besoins
spécifiques d’audit de sécurité sont conçus dans le système. Les concepteurs de système devraient donc tenir compte du
besoin de vérifier (par exemple, examen et analyse tout prêts) à la fois le processus de conception et le système en cours
de développement.
NOTE - Le mod&le d’audit et d’alarmes de s&urit6 n’indique comment les autres systèmes de gestion et les
Pas
caractéristiques opérationnelles sont liés h ce mod&le.
4 Rec. UIT-T X.816 (1995 F)
---------------------- Page: 8 ----------------------
ISOKEI 10181-7:1996 (F)
61 0 Modèle et fonctions
Le modèle présenté ci-dessous illustre les fonctions utilisées dans la fourniture du service d’audit et d’alarmes de sécurité.
6.1.1 Fonctions du service d’audit et d’alarmes de sécurité
Diverses fonctions sont nécessaires pour mettre en œuvre un service complet d’audit et d’alarmes de sécurité, a savoir:
-
le futre d’événement qui fournit une analyse initiale de l’événement et détermine s’il envoie l’événement
à l’enregistreur d’audit ou au processeur d’alarme;
-
l’enregistreur d’audit qui génère les enregistrements d’audit à partir des messages reçus et stocke les
enregistrements dans un journal d’audit de sécurité;
-
le processeur d’alarme qui génère à la fois un message d’audit et une action appropriée en réponse à une
alarme de sécurité;
.
-
l’analyseur d’audit vérifie un journal d’audit de sécurité et, si cela est approprié, produit des
w
messages d’alarme et des messages d’audit de sécurité;
.
-
l’examinateur de journal d’audit bâtit des rapports de sécurité à partir d’un ou de plusieurs journaux
Y1
d’audit de sécurité;
le fournisseur d’audit qui fournit des enregistrements d’audit de sécurité en fonction de certains critères;
-
d’audit qui archive une
l’archiviste partie du journal d’audit de sécurité.
Des fonctions supplémentaires peuvent s’avérer nécessaires pour mettre en œuvre des journaux
d’audit de sécurité
distribués et des alarmes. Parmi celles-ci:
.
- la fonction de collecteur de enregistrements d’un
journal d’audit rassemble les journal distribué
Wl
d’audit dans un journal d’audit de sécurite;
-
la fonction d’expéditeur d’audit qui transf’ere, à la fonction de collecte
de journal de sécurité, des parties
ou la totalite d’un journal distribue d’audit de sécurité.
Modèle d’audit et d’alarmes de sécurité
6.1.2
Le modèle d’audit et d’alarmes de sécurité decrit ci-dessous fait intervenir plusieurs phases. Suite à la detection d’un
événement, la détermination de son intérêt ou non pour la sécurité doit être effectuée. Le filtre d’événement évalue
l’Événement pour déterminer si un message d’audit de sécurité et/ou un message d’alarme de sécurité devrait être généré.
Les messages d’audit de sécurite sont envoyés à l’enregistreur d’audit: les alarmes de sécurité sont envoytes au
processeur d’alarme pour évaluation et action ultérieure. Les messages d’audit de sécurité sont alors formatés puis
transformés en enregistrements d’audit de sécurité pour être consignés dans le journal d’audit de sécurité. Les anciennes
parties du journal d’audit de sécurité peuvent être archivées et le journal d’audit de sécurité ainsi que les archives de
journal d’audit de sécurité peuvent être utilisés pour bâtir des rapports d’audit en sélectionnant, en fonction de critères
spécifiés, des enregistrements particuliers d’audit de sécurité. C’est ainsi que le journal d’audit de sécurité peut être
analysé et que des rapports et/ou des alarmes de sécurité peuvent être générés. Le modèle d’audit et d’alarmes de sécurité
est indiqué sur la Figure 1.
6.1.3 Groupement des fonctions d’audit et d’alarmes de sécurité
Les fonctions décrites dans le modèle peuvent être colocalisées dans un composant d’un système ou distribuées sur
plusieurs composants du système. Ces fonctions peuvent également être localisées dans des systèmes d’extrémité
differents et peuvent être dupliquées. Dans certains cas, comme pour des raisons de performances, il sera avantageux de
grouper ces fonctions. En particulier, un enregistreur d’audit, un expéditeur d’audit, un fournisseur d’audit et un
analyseur d’audit travaillant ensemble sur le même journal d’audit de sécurité peuvent constituer une partie d’un seul
système d’extremité.
constitue
Un autre groupement pourrait être d’un examinateur de journal d ‘audit et d’un analyseur d’audit qui peuvent
être utiles a un auditeur de sécurité.
Il peut y avoir une chame de fonctions arrangées de façon hiérarchique, en particulier dans un journal d’audit de sécurité
distribué (voir la Figure 2). Ici un collecteur de journal d’audit d’un composant collecte les messages d’audit de
l’expéditeur d’audit d’un autre composant. La cha2ne se termine lorsqu’un composant ne met pas en œuvre un expéditeur
d’audit: dans ce cas, le composant doit mettre en œuvre un archiviste d’audit pour être en mesure d’archiver son journal
d’audit de sécurité.
La décision des fonctions, s’il y en a, devant être groupées, est un exemples
problème de mise en œuvre. Les
...
NORME ISO/CEI
INTERNATIONALE 10181-7
Première édition
1996-08-o 1
Technologies de l’information -
Interconnexion de systèmes ouverts
- Cadres de sécurité pour les
(OSI)
systèmes ouverts: Cadre d’audit et
d’alarmes de sécurité
Information technology -
Open Sys tems In terconnection - Security
frameworks for open systems: Security audit and alarms framework
Numéro de référence
ISO/CEI 10181-7: 1996(F)
---------------------- Page: 1 ----------------------
ISOKEI 10181-7:1996(F)
Sommaire
Page
Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1
2
2 Références normatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommandations I Normes internationales identiques . . . . . . . . . . . . . . . . .~. 2
2.1
2
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique . . . . . . .
2
3 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.1 Définitions du modèle de reference de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Définitions de l’architecture de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2
Définitions du cadre de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3
3.4 Définitions de l’aperçu général du cadre de sécurite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Définitions additionnelles 3
3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4
Notation .
Présentation générale de l’audit et des alarmes de sécurité . 4
61 Modèle et fonctions . 5
612 Phases des procédures d’audit et d’alarmes de sécurite . 7
63 . Cor-relation des informations d’audit . 8
Politique et autres aspects de l’audit et des alarmes de sécurité . 9
7
7.1 Politique . 9
Aspects légaux . 9
7.2
7.3 Besoins de protection . 9
Informations et fonctionnalités de l’audit et des alarmes de sécurité . 10
8
8.1 Informations d’audit et d’alarmes . 10
8.2 Fonctionnalités d’audit et d’alarmes de sécurité . 11
9 Mécanismes d’audit et d’alarmes de sécurité . 12
Interaction avec d’autres services et mécanismes de sécurité . 13
10
10.1 Authentification d’entité . 13
13
10.2 Authentification de l’origine des données .
10.3 Contrôle d’accès . 13
10.4 Confidentialité . 13
10.5 Intégrité . 13
10.6 Non-repudiation . 13
Annexe A - Principes généraux d’audit et d’alarmes de sécurite pour l’interconnexion OS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Annexe B - Réalisation du modele d’audit et d’alarmes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
- Grandes lignes des fonctionnalités d’audit et d’alarmes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Annexe C
Annexe D - Heure d’enregistrement des événements d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
0 ISO/CEI 1996
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne
peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou
mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de l’éditeur.
ISOKEI Copyright Office l Case postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
---------------------- Page: 2 ----------------------
ISOKEI 10181-7: 1996(F)
@ ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de I’ISO ou de la CE1 participent au développement de Normes inter-
nationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de I’ISO et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 1018 l-7 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de I?nformation, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’UIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.8 16.
L’ISOKEI 1018 1 comprend les parties suivantes, présentées sous le titre général
Technologies de 1 ‘information
- Interconnexion de systèmes ouverts (OSI) -
Cadres de sécurité pour les systèmes ouverts:
- Partie I: Présentation
- Partie 2: Cadre d’authentification
- Partie 3: Cadre de contrôle d’accès
Partie 4: Cadre de non-répudiation
- Partie 5: Cadre de confidentialité
- Partie 6: Cadre d’intégrité
- Partie 7: Cadre d’audit et d’alarmes de sécurité
Les annexes A à D de la présente partie de I’ISOKEI 1018 1 sont données uni-
quement à titre d’information.
. . .
111
---------------------- Page: 3 ----------------------
0 ISOKEI ISO/CEI 10181-7:1996(F)
Introduction
La présente Recommandation I Norme internationale précise le concept d’audit de sécurité défini dans la
Rec. UIT-T X.8 10 I ISOKEI 101814. Cela comprend la détection d’événements ainsi que les actions resultantes de ces
événements. Le cadre couvre donc a la fois l’audit de sécurité et les alarmes de sécurité.
Un audit de sécurité est une analyse et un examen - effectués de façon indépendante - des enregistrements et activités du
Les objectifs d’un audit de sécurité sont les suivants:
système.
-
aider a l’identification et l’analyse d’actions non autorisées ou d’attaques;
aider à garantir que les actions peuvent être attribuées aux entités responsables de ces actions;
-
contribuer au développement de procédures améliorées de contrôle des dommages;
-
confirmer la conformite avec la politique de sécurité établie;
-
signaler l’information qui peut indiquer des inadéquations dans le contrôle du systeme;
-
identifier les changements possibles requis dans les contrôles, la politique et les procedures.
sécurité
Dans ce cadre, un audit de consiste en la détection, la collecte et l’enregistrement des événements liés à la
té des systèmes ouverts dans un journal d’audit de sécurite et en l’analyse de ces événements.
sécuri
L’audit mais aussi l’imputabilité nécessitent le stockage de l’information. Un audit de sécurité garantit que l’information
enregistrée concerne a la fois les evénements routiniers et les événements exceptionnels, de sorte que des investigations
ultérieures puissent déterminer si des violations de sécurité sont survenues et, si tel est le cas, quelles sont les
- - informations ou les autres ressources qui ont été compromises. L’imputabilité garantit que l’information relative aux
actions réalisées par les utilisateurs, ou par des processus agissant pour leur compte, est enregistrée, de telle sorte que les
conséquences de ces actions puissent être ultérieurement liées aux utilisateurs en question et que les utilisateurs puissent
être tenus responsables de ces actions. La fourniture d’un service d’audit de sécurité peut contribuer à assurer
l’imputabilité.
Une alarme de sécuri .té est une indication émise vers un individu ou un processus pour i .ndiquer qu’une situation pouvant
à temps est apparue. Les objecti .fs d’un service d’alarme de sécurité
nécessiter une action sont les suivants:
-
signaler des tentatives réelles ou apparentes de violer la sécurité;
-
signaler divers événements liés à la sécurité, y compris les événements «normaux»;
-
signaler les événements déclenchés par l’atteinte des limites de seuil.
iv
---------------------- Page: 4 ----------------------
ISOKEI 10181-7 : 1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE SYSTÈMES
CADRES DE SÉCURITÉ POUR LES SYSTÈMES OUVERTS:
OUVERTS (OSI) -
CADRE D’AUDIT ET D’ALARMES DE SÉCURITÉ
1 Domaine d’application
La présente Recommandation I Norme internationale couvre l’application des services de sécurité dans un environnement
de systèmes ouverts, ou le terme «systèmes ouverts» est utilisé pour des domaines tels que les bases de données, les
applications distribuées, le traitement ODP et l’interconnexion OSI. Les cadres de sécurité sont destinés à définir les
moyens d’offrir la protection pour les systèmes et les objets au sein des systèmes, ainsi que les interactions entre
systèmes. Les cadres ne couvrent pas la méthodologie de construction des systèmes ou méçanismes.
Les cadres couvrent à la fois les éléments de données et les séquences d’opérations (mais pas les éléments de protocole)
utilises pour obtenir des services spécifiques de sécurité. Ces services de sécurité peuvent s’appliquer aux entités
communicantes des systèmes aussi bien qu’aux données échangées entre systèmes, ainsi qu’aux données gérées par les
systèmes.
Le but de l’audit et des alarmes de sécurité décrits dans la présente Recommandation I Norme internationale est d’assurer
que les événements liés à la sécurité des systèmes ouverts sont manipulés en accord avec la politique de sécurité de
l’autorité de sécurité en vigueur.
En particulier, ce cadre de sécurité:
définit les concepts élémentaires d’audit et d’alarmes de sécurité;
a>
fournit un modèle général pour l’audit et les alarmes de sécurité;
b)
identifie les relations du service d’audit et d’alarmes de sécurité avec d’autres services de sécurité.
C)
Comme les autre services de sécurité, un audit de sécurité ne peut être fourni que dans le contexte d’une politique de
sécurité définie.
Le modèle d’audit et d’alarmes de sécurité indiqué dans l’article 6 de ce cadre répond à une variété d’objectifs qui peuvent
ne pas être tous nécessaires ou souhaités dans un environnement particulier. Le service d’audit de sécurité offre à une
autorité d’audit la possibilité de spécifier les événements qui doivent être enregistrés dans un journal d’audit de sécurité.
Plusieurs types de normes différents peuvent utiliser ce cadre, y compris:
1) les normes qui incorporent le concept d’audit et d’alarmes;
les normes qui spécifient des services abstraits comprenant l’audit et les alarmes;
2)
les normes qui spécifient les utilisations d’audit et d’alarmes;
3)
qui spécifient les moyens au sein d’une architecture de
les normes de fournir l’audit et les alarmes système
4)
ouvert;
les normes qui spécifient les mécanismes d’audit et d’alarmes.
5)
De telles normes peuvent utiliser ce cadre de la façon suivante:
-
les normes de types l), 2), 3), 4) et 5) peuvent utiliser la terminologie de ce cadre;
les normes de types 2), 3), 4) et 5) peuvent utiliser les fonctionnalités définies dans l’article 8 de ce cadre;
les normes de type 5) peuvent être basées sur les caracteristiques des mécanismes définis dans l’article 9
de ce cadre.
Rec. UIT-T X.816 (1995 F)
1
---------------------- Page: 5 ----------------------
ISOKEI 10181-7 : 1996 (F)
2 Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la référence qui
y est faite, constituent des dispositions valables pour la présente Recommandation I Norme internationale. Au moment
de la publication, les éditions indiquées étaient en vigueur. Toute Recommandation et Norme sont sujettes à révision et
les parties prenantes aux accords fondés sur la présente Recommandation I Norme internationale sont invitées à
rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de KJIT tient à jour une liste des Recommandations de I’UIT-T en vigueur.
21 0 Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I Norme ISOKEI 7498-l : 1994, Tt?chnologies de Z’information -
Interconnexion des systèmes ouverts - Modèle de référence de base: le modèle de référence de base.
-
Recommandation X.734 du CCITT (1992) I ISOKEI 10164-5: 1993, Technologies de Z’information -
Interconnexion des systèmes ouverts - Gestion-systèmes: fonction de gestion des rapports d’événement.
-
Recommandation X.735 du CCITT (1992) I ISOKEI 10164-6:1993, Technologies de Z’information -
Gestion-systèmes: fonction de commande des registres de
Interconnexion des systèmes ouverts -
consignation.
-
Recommandation X.736 du CCITT (1992) I ISOKEI 10164-7:1992, Technologies de Z’information -
Interconnexion des systèmes ouverts - Gestion-systèmes: fonction de signalisation des alarmes de
sécurité.
-
Recommandation X.740 du CCITT (1992) I ISOKEI 10164-8:1993, Technologies de Z’information -
Interconnexion des systèmes ouverts - Gestion-systèmes: fonction de piste de vérification de sécurité.
-
Recommandation UIT-T X.810 (1995) I ISOKEI 10181-1:1996, Technologies de Z’information -
Interconnexion des systèmes ouverts - Cadres de sécurité pour les systèmes ouverts: aperçu général.
22 l Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation X.700 du CCITT (1992), Cadre de gestion pour l’interconnexion de systèmes ouverts
pour les applications du CCITT.
Interconnexion des systèmes ouverts -
ISOKEI 7498-4:1989, Systèmes de traitement de l’information -
Partie 4: Cadre général de gestion.
Modèle de référence de base -
-
Recommandation X.800 du CCITT (1991), Architecture de sécurité pour Z’interconnexion en systèmes
ouverts d’applications du CCITT.
Interconnexion des systèmes ouverts -
ISO 7498-2: 1989, Systèmes de traitement de l’information -
Modèle de référence de base - Partie 2: Architecture de sécurité.
3 Définitions
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
31 . Définitions du modèle de référence de base
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.200 I
ISOKEI 7498- 1:
entité;
b) fonctionnalité;
fonction;
Cl
2 Rec. UIT-T X.816 (1995 F)
---------------------- Page: 6 ----------------------
ISOKEI 10181-7 : 1996 (F)
32 l Définitions de l’architecture de sécurité
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. X.800 du CCITT I
ISOKEI 7498-2:
a) imputabilité;
b) disponibilité;
audit de- sécurité;
C)
d) journal d’audit de sécurité;
e) politique de sécurité.
Définitions du cadre de gestion
33 0
La présente Recommandation I Norme internationale utilise le terme suivant défini dans la Rec. X.700 du CCITT I
ISOKEI 7498-4:
-
objet géré.
Définitions de l’aperçu général du cadre de sécurité
34 .
La présente Recommandation I Norme internationale utilise le terme suivant défini dans la Rec. UIT-T X.810 I
ISOKEI 10181-l:
-
domaine de sécurité.
Définitions additionnelles
35 l
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
3.5.1 processeur d’alarme: fonction qui, en réponse à une alarme de sécurité, génère une action appropriée et
génère un message d’audit de sécurité.
3.5.2 autorité d’audit: gestionnaire responsable de la définition des aspects d’une politique de sécurité applicables à
la conduite d’un audit de sécurité.
analyseur d’audit: fonction qui vérifie un journal d’audit de afin de produire, si cela est
3.5.3 sécurité approprié,
messages d’alarme de sécurité et des messages d’audit de sécurité.
3.5.4 archiviste d’audit: fonction qui archive une partie du journal d’audit de sécurité.
3.5.5 expéditeur d’audit: fonction qui transfère, à la fonction de collecte de journal de sécurité, des parties ou la
totalité d’un journal distribué d’audit de sécurité.
3.5.6 examinateur de journal d’audit: fonction qui, à partir d’un ou plusieurs journaux d’audit de sécurité, construit
des rapports.
enregistreur d’audit: fonction qui génère des enregistrements d’audit de sécurité et les stocke dans un journal
3.5.7
d’audit de sécurité.
3.5.8 fournisseur d’audit: fonction qui fournit des enregistrements de journal d’audit de sécurité en fonction de
certains critères.
3.5.9 collecteur de journal d’audit: fonction qui rassemble les enregistrements d’un journal distribué d’audit dans
un journal d’audit de sécurité.
3.5.10 filtre d’événement: fonction qui fournit une analyse initiale des événements liés à la sécurité et génère un
message d’audit de sécurité et/ou un message d’alarme.
3.5.11 alarme de sécurité: message généré lorsqu’un événement lié à la sécurité, défini par la politique de sécurité
comme étant une condition d’alarme, a été détecté. Une alarme de sécurité est destinée à être portée à temps à l’attention
d’entités appropriées.
Rec. UIT-T X.816 (1995 F)
---------------------- Page: 7 ----------------------
ISOKEI 10181-7 : 1996 (F)
3.5.12 administrateur d’alarme de sécurité: individu ou processus qui détermine la nature des alarmes de sécurité.
3.5.13 événement lié à la sécurité: tout évenement qui a et6 défini par la politique de sécurité comme une brèche
potentielle dans la politique de sécurité, ou comme ayant un intérêt potentiel pour la sécurité. L’arrivée à une valeur
prédefinie de seuil est un exemple d’événement lie à la sécurite.
3.514 message d’audit de sécurité: message généré à la suite d’un événement vérifiable lie à la sécurité.
3.5.15 enregistrement d’audit de sécurité: enregistrement unique dans un journal d’audit de sécurité.
3.5.16 agent d’audit de sécurité: individu ou processus autorisé à avoir accès au journal de sécurité et a bâtir des
rapports d’audit.
rapport de sécurité: rapport qui résulte d’une analyse du journal d’audit de sécurité et qui peut être utilise pour
3.5.17
déterminer si une breche est apparue dans la sécurité.
I
Abréviations
Interconnexion des systèmes ouverts (open systems interconnection).
os1
5 Notation
Sauf indication contraire, les termes «service» et «mécanisme» sont utilisés pour désigner, respectivement, le «service
d’audit de sécurité» et le «mécanisme d’audit de sécurité»; celui d’«audit» désigne un «audit de sécurité» et enfin, celui
d’«alarme» désigne une «alarme de sécurité».
6 Présentation générale de l’audit et des alarmes de sécurité
sécurité et de conduire un audit de sécurité pour les
Cet article decrit un modèle permettant de manipuler les alarmes de
systèmes ouverts
Un audit de sécurite permet d’évaluer l’adéquation de la politique de sécurité, d’aider à la détection des violations de
sécurité, de faciliter l’imputation de leurs actions aux individus (ou des actions des entités agissant pour leur compte),
d’aider à la détection de mauvaise utilisation des ressources, et agit comme élément préventif pour les individus qui
pourraient tenter d’endommager le système. Les mécanismes d’audit de sécurité ne sont pas directement mis en jeu dans
la prévention des violations de sécurité: ils sont impliqués pour la détection, l’enregistrement et l’analyse des événements.
Cela permet de mettre en œuvre des changements dans les procédures opérationnelles en réponse à des événements
anormaux comme des violations de sécurité.
Une alarme de sécurité est générée suite à la détection de tout événement lié à la sécurité qui a été défini par la politique
de sécurité comme étant une condition d’alarme. Cela pourrait inclure le cas de l’obtention d’un seuil prédéfini. Certains
de ces événements peuvent nécessiter une action immédiate alors que d’autres peuvent nécessiter une investigation plus
poussée pour déterminer si une action est requise.
Une mise en œuvre du modèle d’audit et d’alarmes de sécurité peut nécessiter l’utilisation d’autres services de sécurité
pour réaliser le service d’audit et d’alarmes de sécurité et pour assurer son fonctionnement correct et sûr. Ce sujet est
abordé plus loin dans l’article 10.
Bien que l’utilisation des journaux d’audit de sécurité et d’audits de sécurité ait des caractéristiques spéciales, d’autres
journaux d’audit et d’autres audits (autres que de sécurité) peuvent recourir aux fonctions et mécanismes décrits dans le
présent cadre.
Comme avec les autres aspects de la sécurité, on obtient une efficacité maximale en s’assurant que les besoins
spécifiques d’audit de sécurité sont conçus dans le système. Les concepteurs de système devraient donc tenir compte du
besoin de vérifier (par exemple, examen et analyse tout prêts) à la fois le processus de conception et le système en cours
de développement.
NOTE - Le mod&le d’audit et d’alarmes de s&urit6 n’indique comment les autres systèmes de gestion et les
Pas
caractéristiques opérationnelles sont liés h ce mod&le.
4 Rec. UIT-T X.816 (1995 F)
---------------------- Page: 8 ----------------------
ISOKEI 10181-7:1996 (F)
61 0 Modèle et fonctions
Le modèle présenté ci-dessous illustre les fonctions utilisées dans la fourniture du service d’audit et d’alarmes de sécurité.
6.1.1 Fonctions du service d’audit et d’alarmes de sécurité
Diverses fonctions sont nécessaires pour mettre en œuvre un service complet d’audit et d’alarmes de sécurité, a savoir:
-
le futre d’événement qui fournit une analyse initiale de l’événement et détermine s’il envoie l’événement
à l’enregistreur d’audit ou au processeur d’alarme;
-
l’enregistreur d’audit qui génère les enregistrements d’audit à partir des messages reçus et stocke les
enregistrements dans un journal d’audit de sécurité;
-
le processeur d’alarme qui génère à la fois un message d’audit et une action appropriée en réponse à une
alarme de sécurité;
.
-
l’analyseur d’audit vérifie un journal d’audit de sécurité et, si cela est approprié, produit des
w
messages d’alarme et des messages d’audit de sécurité;
.
-
l’examinateur de journal d’audit bâtit des rapports de sécurité à partir d’un ou de plusieurs journaux
Y1
d’audit de sécurité;
le fournisseur d’audit qui fournit des enregistrements d’audit de sécurité en fonction de certains critères;
-
d’audit qui archive une
l’archiviste partie du journal d’audit de sécurité.
Des fonctions supplémentaires peuvent s’avérer nécessaires pour mettre en œuvre des journaux
d’audit de sécurité
distribués et des alarmes. Parmi celles-ci:
.
- la fonction de collecteur de enregistrements d’un
journal d’audit rassemble les journal distribué
Wl
d’audit dans un journal d’audit de sécurite;
-
la fonction d’expéditeur d’audit qui transf’ere, à la fonction de collecte
de journal de sécurité, des parties
ou la totalite d’un journal distribue d’audit de sécurité.
Modèle d’audit et d’alarmes de sécurité
6.1.2
Le modèle d’audit et d’alarmes de sécurité decrit ci-dessous fait intervenir plusieurs phases. Suite à la detection d’un
événement, la détermination de son intérêt ou non pour la sécurité doit être effectuée. Le filtre d’événement évalue
l’Événement pour déterminer si un message d’audit de sécurité et/ou un message d’alarme de sécurité devrait être généré.
Les messages d’audit de sécurite sont envoyés à l’enregistreur d’audit: les alarmes de sécurité sont envoytes au
processeur d’alarme pour évaluation et action ultérieure. Les messages d’audit de sécurité sont alors formatés puis
transformés en enregistrements d’audit de sécurité pour être consignés dans le journal d’audit de sécurité. Les anciennes
parties du journal d’audit de sécurité peuvent être archivées et le journal d’audit de sécurité ainsi que les archives de
journal d’audit de sécurité peuvent être utilisés pour bâtir des rapports d’audit en sélectionnant, en fonction de critères
spécifiés, des enregistrements particuliers d’audit de sécurité. C’est ainsi que le journal d’audit de sécurité peut être
analysé et que des rapports et/ou des alarmes de sécurité peuvent être générés. Le modèle d’audit et d’alarmes de sécurité
est indiqué sur la Figure 1.
6.1.3 Groupement des fonctions d’audit et d’alarmes de sécurité
Les fonctions décrites dans le modèle peuvent être colocalisées dans un composant d’un système ou distribuées sur
plusieurs composants du système. Ces fonctions peuvent également être localisées dans des systèmes d’extrémité
differents et peuvent être dupliquées. Dans certains cas, comme pour des raisons de performances, il sera avantageux de
grouper ces fonctions. En particulier, un enregistreur d’audit, un expéditeur d’audit, un fournisseur d’audit et un
analyseur d’audit travaillant ensemble sur le même journal d’audit de sécurité peuvent constituer une partie d’un seul
système d’extremité.
constitue
Un autre groupement pourrait être d’un examinateur de journal d ‘audit et d’un analyseur d’audit qui peuvent
être utiles a un auditeur de sécurité.
Il peut y avoir une chame de fonctions arrangées de façon hiérarchique, en particulier dans un journal d’audit de sécurité
distribué (voir la Figure 2). Ici un collecteur de journal d’audit d’un composant collecte les messages d’audit de
l’expéditeur d’audit d’un autre composant. La cha2ne se termine lorsqu’un composant ne met pas en œuvre un expéditeur
d’audit: dans ce cas, le composant doit mettre en œuvre un archiviste d’audit pour être en mesure d’archiver son journal
d’audit de sécurité.
La décision des fonctions, s’il y en a, devant être groupées, est un exemples
problème de mise en œuvre. Les
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.