GB/T 9387.2-1995 Information processing systems Open Systems Interconnection Basic Reference Model Part 2: Security Architecture
Some standard content:
National Standard of the People's Republic of China
Information processing system-Open Systems Interconnection
Basic Reference Model
Part 2: Security architecture
Information processing system-Open Systems Interconnection-Basic Reference Model-Part 2: Security architectureGB/T 9387.2-1995
ISO 7498-2-1989
This standard is equivalent to the international standard ISO7498-2-1989 "Information processing system-Open Systems Interconnection Basic Reference Model Part 2: Security architecture".
0 Introduction
GB9387--88 describes the basic reference model for Open Systems Interconnection (OSI), which establishes a framework for the coordinated development of existing and future system interconnection standards.
The purpose of the Open Systems Interconnection Basic Reference Model is to enable the interconnection of heterogeneous computer systems to achieve effective communication between application processes. Security controls must be established in various situations to protect the information exchanged between application processes. Such controls should make the cost of unauthorized access or modification of data greater than the potential value of such access or the time required to obtain the required data so long that the value of the data is lost.
This standard establishes general elements related to security architecture that can be applied to various scenarios where communication between open systems requires protection. This standard establishes some guidelines and constraints within the framework of the reference model for the improvement of existing standards related to open systems interconnection or the development of new standards for secure communications, thereby providing a consistent approach to addressing security issues in OSI. Some background on security issues is helpful in understanding this standard. Readers who are not familiar with security issues are recommended to read Appendix A (Reference) first.
This standard extends the basic reference model to address some aspects of security issues. These aspects are general elements of communication protocol architectures but are not discussed in the basic reference model. 1 Subject matter and scope of application
The tasks of this standard are:
a. To provide a general description of security services and related mechanisms that can be provided for the GB9387-88 reference model,
b. To determine where these services and mechanisms can be provided within the reference model. This standard expands the application area of GB9387-88 to include secure communications between open systems. The basic security services and mechanisms and their appropriate configuration are described layer by layer according to the basic reference model. In addition, the architectural relationship of these security services and mechanisms to the reference model is described. In some end systems, devices and organizational structures, some additional security measures may be required, which are also applicable to various application contexts. It is not within the scope of this standard to determine the security services required to support such additional security measures. The security functions of Open Systems Interconnection (OSI) only involve the visible aspects of communication paths that enable the secure transmission of information between end systems, and do not consider the security measures required within the end system, device or organization, unless it involves the selection and positioning of visible security services in OSI. These aspects of security structure issues can also be standardized, but are not within the scope of OSI standards. This standard supplements the concepts and principles defined in GB9387-88, but does not change them. This standard is neither an implementation specification nor a benchmark for evaluating the consistency of actual implementation plans. 2 Referenced standards
Basic reference model of information processing system open system interconnection GB 9387--88
GB/T15274 Information processing system Open Systems Interconnection Network Layer Internal Organizational Structure IS()7498-4 Information processing system Open Systems Interconnection Basic Reference Model Part 4: Management Framework IS0)7498/Supplement 1 Information processing system Open Systems Interconnection Basic Reference Model Supplement 1: Connectionless Mode Transport 3 Definitions and Abbreviations
This standard is based on the concepts established in GB9387---88 and uses the following terms defined in that standard; 3.1
(N) connection;
(N) Data transmission;
(N) Entity;
(N) Service;
(N) Layer;
Open system;
Peer entity;
(N) Protocol;
(N) Protocol data unit;
(N) Relay;
Routing;
Sequencing;
(N) Service;
(N) Service data unit;
(N) User data;
Subnet;www.bzxz.net
OSI resource;
Transfer syntax.
The following terms used in this standard are taken from the corresponding national standards (GB) and international standards (ISO): 3.2
Connectionless mode transmission
End system
Relay and routing functions
Unit data
Management information base
(ISO7498 Supplement 1)
(GB 9387—88)
(GB/T 15274)
(GB 9387~-88)
(ISO 7498-4)
In addition, the following abbreviations are also used: OSI: Open Systems Interconnection;
SDU: Service Data Unit;
SMIB: Security Management Information Base;
MIB: Management Information Base.
3.3 This standard adopts the following definitions:
3.3.1 Access control access control571
GB/T 9387.2—1995
Preventing unauthorized use of resources, including preventing the use of a resource in an unauthorized manner. 3.3.2 Access control list access control list A list of entities with access rights that grant them access to a resource. 3.3.3 Accountability
A property that ensures that the role of an entity can be uniquely traced to that entity. 3.3.4 Active threat active threat
This threat is a deliberate unauthorized change to the state of the system. Note: Examples of active threats related to security may be: tampering with messages, resending messages, inserting false messages, impersonating authorized entities, and denial of service. 3.3.5 Audit audit
See "security audit".
3.3.6 audit trail See "security audit trail".
3.3.7 authentication See "data origin authentication" and "peer entity authentication". NOTE: In this standard, the term "authentication" is not used when referring to data integrity, but the term "data integrity" is used instead. 3.3.8 authentication information Information used to establish the validity of an identity.
3.3.9 authentication exchange A mechanism to ensure the identity of an entity through the exchange of information. 3.3.10 authorization Granting rights, including allowing access based on access rights. 3.3.11 availability Access and use available upon request by an authorized entity. 3.3.12 capability Token used as a resource identifier, which gives the right to access the resource. 3.3.13 channel Channel Information transmission path.
3.3.14 Ciphertext
Data produced by encryption, whose semantic content is unavailable. Note: Ciphertext itself can be the input to an encryption algorithm, in which case it produces a super-encrypted output. 3.3.15 Cleartext
Intelligible data, whose semantic content is available. 3.3.16 Confidentiality
The property of preventing information from being disclosed to or used by unauthorized individuals, entities, or processes. 3.3.17 credentials
Data transmitted to establish the required identity of an entity. 3.3.18 cryptanalysis
Analysis of a cryptographic system or its input and output in order to obtain confidential variables or sensitive data including plain text. 3.3.19 Cryptographic check value Information obtained by performing a cryptographic transformation (see "cryptography") on a data unit. Note: A cryptographic check value can be obtained after one or more operations. It is the result of a mathematical function that depends on the key and the data unit and is often used to verify the integrity of the data unit.
3.3.20 Cryptography
GB/T 9387.2—1995
This discipline includes the principles, means and methods of transforming data, with the purpose of hiding the content of the data and preventing it from being tampered with without being detected or used without authorization.
Note: Cryptography determines the methods used in encryption and decryption. An attack on cryptographic principles, techniques, or methods is cryptanalysis. 3.3.21 Data integrity This property indicates that data has not been altered or destroyed in an unauthorized manner. 3.3.22 Data origin authentication Confirms that the source of the received data is the requested source. 3.3.23 Decipherment
The reverse process of a reversible encryption process. 3.3.24 Decryption
See "decryption".
3.3.25 Denial of service Preventing authorized access to a resource or delaying a time-limited operation. 3.3.26 Digital signature Some data attached to a data unit, or a cryptographic transformation of a data unit (see "Cryptology"), which allows the recipient of the data unit to confirm the source and integrity of the data unit and protect the data from being forged by others (such as the recipient).
3.3.27 Encipherment
Cryptographic transformation of data (see "Cryptology") to produce ciphertext. Note: Encryption can be irreversible, in which case the corresponding decryption process cannot be actually implemented. 3.3.28 Encryption
See "Encryption".
3.3.29 End-to-end encipherment Data is encrypted in the source system, and the corresponding decryption occurs only in the destination system. (See "Chain-by-chain encryption") 3.3.30 Identity-based security policy identity-based securitypolicyThe security policy based on the identity or attributes of a user or group of users, or the entity acting on behalf of the user, and the identity or attributes of the resources or objects being accessed.
3.3.31 integrity
See "data integrity".
3.3.32 key
A sequence of symbols that controls encryption and decryption operations. 3.3.33 key managementkey managementThe generation, storage, distribution, deletion, archiving and application of keys under the guidance of a security policy. 3.3.34 link-by-link enciphermentThe encryption of data on each link in a communication system. (See "end-to-end encryption\) Note: Link-by-link encipherment means that the data will appear in plain text in the relay entity. 3.3.35 manipulation detectionA mechanism used to detect whether a data unit has been modified. (This modification may be accidental or intentional.) 3.3.36 masquerade
An entity pretends to be a different entity. 3.3.37 notarization
Registration of data by a trusted third party to ensure that the accuracy of data characteristics such as content, origin, time, delivery, etc. will not be changed.
3.3.38 passive threat passive threat GB/T 9387.2
This threat is the unauthorized disclosure of information without changing the system state. 3.3.39 password password
Confidential identification information, usually composed of a string of characters. 3.3.40 peer-entity authentication confirms that the relevant peer entity is the required entity. 3.3.41 physical security physical security—1995
Measures taken to provide physical protection for resources to prevent intentional and accidental threats. 3.3.42 policy policy
See "security policy".
3.3.43 Privacy
The right of an individual to control and influence what information about those individuals may be collected, stored, and disclosed by and to whom.
Note: Because this term refers to private rights, it is impossible to precisely qualify and should be avoided except as a motivation for security protection.
3.3.44 Repudiation
The denial by one of those entities involved in a communication of all or part of that communication. 3.3.45 Routing control The application of rules to the routing process in order to specifically select or avoid certain networks, links, or relays. 3.3.46 Rule-based security policy The basis of this security policy is general rules imposed on all users. These rules often rely on comparing the sensitivity of the resources being accessed with corresponding attributes of the user, group of users, or entity acting on behalf of the user. 3.3.47 security audit independent observation and assessment of system records and activities to test the adequacy of system controls, to ensure compliance with established policies and operating procedures, to detect gaps in security, and to recommend any specified changes in controls, policies and procedures.
3.3.48 security audit trail data collected and used to facilitate security audits. 3.3.49 security label a label associated with a resource (which may be a data unit) that names or specifies security attributes for the resource. NOTE Such labels or constraints may be explicit or implicit. 3.3.50 security policy a set of criteria for providing security services. (See "identity-based security policy" and "rule-based security policy") NOTE A complete security policy will inevitably involve many issues beyond the scope of OSI. 3.3.51 security service a service provided by the layers of an open system participating in communication, which ensures that the system or data transmission has adequate security. 3.3.52 Selective Field Protection selectivefieldprotection Protection of specific fields in a message to be transmitted. 3.3.53 Sensitivity sensitivity
A characteristic of a resource that indicates its value or importance and may also include its vulnerability. 3.3.54 Signature signature
See "digital signature".
3.3.55 Threat threat
A potential violation of security.
GB/T9387.2—1995
3.3.56 Traffic Analysis trafficanalysis Inferences about information are made by observing traffic flows (appearance, disappearance, total volume, direction and frequency). 3.3.57 Traffic Flow Confidentiality A confidentiality service that resists traffic analysis. 3.3.58 Raffic padding Creates a false instance of communication, generates a fraudulent data unit or fake data in a data unit. 3.3.59 Trusted functionality This functionality is considered to be correct with respect to a certain standard, such as the criteria established by a security policy. 4 Notation
The hierarchical notation used in this standard is the same as that defined in GB9387-88. Unless otherwise specified, the term "service" is used to refer to security services. 5 General description of security services and security mechanisms 5.1 Overview
This chapter discusses the security services included in the OSI security architecture and the mechanisms for implementing these services. The security services described below are basic security services. In practice, in order to meet security policies or user requirements, they will be applied at the appropriate functional layer and usually combined with non-OSI services and mechanisms. Some specific security mechanisms can be used to implement a combination of these basic security services. For the convenience of direct reference, the actual system can implement some specific combinations of these basic security services. 5.2 Security services
The following list is considered to be optional security services that can be provided within the framework of the OSI reference model. The authentication service requires authentication information, which includes information stored locally for authentication and data (credentials) obtained through transmission. 5.2.1 Authentication
This security service provides authentication of the peer entities and data sources in the communication, as described below: "5.2.1.1 Peer Entity Authentication
When provided by the (N) layer, this service will ensure that the (N+1) entity is dealing with the (N+1) entity it expects.
This service is provided at certain times during connection establishment or during data transfer to verify the identity of one or more connected entities. Use of this service can provide assurance (for the duration of use only) that an entity is not attempting to impersonate another entity or to re-enact a previous connection without authorization. It is possible to implement one-way or two-way peer entity authentication, with or without validity checks. This service can provide various degrees of protection. 5.2.1.2 Data Origin Authentication
When provided by the (N) layer, this service will ensure that The (N+1) entity is assured that the source of the data is the required peer (N+1) entity. The data origin authentication service provides confirmation of the source of the data unit. This service does not provide protection against duplication or tampering of data units. 5.2.2 Access Control
This service provides protection against unauthorized use of OSI accessible resources. These resources can be OSI resources or non-OSI resources accessed via OSI protocols. This protection service can be applied to various types of access to resources (for example: use of communication resources; reading, writing or deleting information resources; execution of processing resources) or to all access to a resource. This access control must be coordinated with different security policies (see Section 6.2.1.1). 5.2.3 Data Confidentiality
This service provides protection for data from unauthorized disclosure; described as follows: 5.2.3.1 Connection Confidentiality
GB/T 9387.2—1995
This service ensures confidentiality for all (N)-user data on an (N)-connection. NOTE: In some uses and levels, it may not be appropriate to protect all data, such as expedited data or data in a connection request. 5.2.3.2 Connectionless Confidentiality
This service ensures confidentiality for all (N)-user data in a single connectionless (N)SDU. 5.2.3.3 Selected Field Confidentiality
This service ensures confidentiality for selected fields that are either in the (N)-user data of a (N)-connection or in a single connectionless (N)SDU.
5.2.3.4 Traffic Flow Confidentiality
This service provides protection such that confidential information cannot be inferred from observation of the traffic flow. 5.2.4 Data Integrity
This service protects against active threats and may take one of the forms described below. NOTE: On a connection, the use of the peer entity authentication service at connection start and the use of the data integrity service for the lifetime of the connection can be combined to provide assurance of the origin of all data units transmitted on the connection, assurance of the integrity of these data units, and, for example, the detection of duplication of data units using sequence numbers. 5.2.4.1 Connection Integrity with Recovery
This service ensures the integrity of all (N) user data on the (N) connection and detects any tampering, insertion, deletion or replay of data in a complete SDU sequence (while attempting recovery). 5.2.4.2 Connection Integrity without Recovery
Same as the service in 5.2.4.1, except that no remedial recovery is performed. 5.2.4.3 Connection Integrity of Selected Fields
This service provides integrity assurance for selected fields in the (N) user data of an (N)-SDU transmitted on a connection, in the form of determining whether the selected fields have been tampered with, inserted, deleted, or replayed. 5.2.4.4 Connectionless Integrity
When provided by the (N) layer, this service provides integrity assurance to the (N+1) entity that issued the request. This service provides integrity assurance for a single connectionless SDU, in the form of determining whether a received SDU has been modified. In addition, replay detection is provided to a certain extent. 5.2.4.5 Connectionless Integrity of Selected Fields
This service provides integrity assurance for selected fields in a single connectionless SDU, in the form of determining whether the selected fields have been tampered with.
5.2.5 Non-repudiation
This service may take one of the following two forms, or either of them. 5.2.5.1 Non-repudiation with proof of origin of data provides the recipient of the data with evidence of the origin of the data. This will make it impossible for the sender to falsely claim that he did not send the data or to deny its content.
5.2.5.2 Non-repudiation with proof of delivery
Provides the sender of the data with evidence of delivery of the data. This will make it impossible for the recipient to falsely claim that he did not receive the data or to deny its content later.
5.3 Specific security mechanisms
The security mechanisms listed below may be set up at the appropriate (N) layer to provide some of the services described in clause 5.2. 5.3.1 Encryption
5.3.1.1 Encryption can provide confidentiality for both data and traffic flow information, and may also be part of or supplement some of the other security mechanisms described below. 5.3.1.2 Encryption algorithms can be reversible or irreversible. There are two major categories of reversible encryption algorithms: 579
GB/T 9387.2—1995
a. Symmetric (i.e. secret key) encryption. For this type of encryption, knowing the encryption key also means knowing the decryption key, and vice versa. b. Asymmetric (i.e. public key) encryption. For this type of encryption, knowing the encryption key does not mean knowing the decryption key, and vice versa. Such two keys of this system are sometimes called "public key" and "private key". Irreversible encryption algorithms may or may not use a key. If a key is used, it may be public or secret. 5.3.1.3 Except for certain cases of irreversible encryption algorithms, the existence of an encryption mechanism implies the use of a key management mechanism. Some guidelines on key management methods will be given in Section 8.4. 5.3.2 Digital Signature Mechanism
This mechanism determines two processes:
a. Signing a data unit;
b Verifying the signed data unit.
The first process uses information that is private (i.e., unique and confidential) to the signer. The second process uses procedures and information that are publicly available, but the signer's private information cannot be inferred from them. 5.3.2.1 The signing process involves using the signer's private information as a private key to either encrypt the data unit or to generate a cryptographic check value for the data unit.
5.3.2.2 The verification process involves using public procedures and information to determine whether the signature was generated using the signer's private information. 5.3.2.3 The essential feature of the signature mechanism is that the signature can only be generated using the signer's private information. Therefore, when the signature is verified, it can be proved to a third party (such as a judge or arbitrator) at any time thereafter that only the sole owner of the private information could have generated the signature.
5.3.3 Access Control Mechanisms
5.3.3.1 To determine and enforce the access rights of an entity, the access control mechanism may use the entity's authenticated identity, or use information about the entity (such as its affiliation with a known set of entities), or use the entity's powers. If the entity attempts to use an unauthorized resource, or to use an authorized resource in an improper manner, the access control function will deny the attempt and may also generate an alarm or log it as part of a security audit trail to report the event. For connectionless data transmission, notification of access denial to the sender can only be provided as a result of access control imposed on the originator. 5.3.3.2 The access control mechanism may be based on the use of one or more of the following means: a. Access control information base, where the access rights of peer entities are stored. This information may be maintained by an authorization center or by the entity being accessed. This information may be in the form of an access control list or a matrix of hierarchical or distributed structures. It is also assumed that the authentication of the peer entity has been ensured: b. Authentication information, such as a password, the possession and presentation of which proves that the entity making the access is authorized; c. Authority: the possession and presentation of which establishes the right to access the entity or resource specified by the authority; NOTE: Authority shall be unforgeable and conveyed in a trustworthy manner. d. Security tag: when associated with an entity, such security tag may be used to indicate granting or denying access, usually in accordance with security policy;
e. time of attempted access;
f. route of attempted access;
g. duration of access.
5.3.3.3 Access control mechanisms may be applied at an endpoint in a communication connection, or at any intermediate point. Access control involving the originating point or any intermediate point is used to determine whether the sender is authorized to communicate with the intended recipient, or to use the requested communication resources. The requirement for a hierarchical access control mechanism at the destination of a connectionless data transmission shall be known in advance at the originating point and shall be recorded in the security management information base (see clauses 6.2 and 8.1). 5.3.4 Data integrity mechanisms
GB/T 9387.2-1995
5.3.4.1 There are two aspects of data integrity: the integrity of individual data units or fields and the integrity of data unit streams or field streams. In general, the mechanisms used to provide these two types of integrity services are different, although without the first type of integrity service, the second type of service cannot be provided.
5.3.4.2 Determining the integrity of a single data unit involves two processes, one at the sending entity and one at the receiving entity. The sending entity appends a quantity to the data unit, which is a function of the data. This quantity can be supplementary information such as a block check code, or a cryptographic check value, and it can itself be encrypted. The receiving entity generates a corresponding quantity and compares it with the received quantity to determine whether the data has been tampered with in transit. This mechanism alone cannot prevent the replay of a single data unit. At the appropriate layer of the network architecture, manipulation detection may lead to recovery actions at this layer or at a higher layer (for example, through retransmission or error correction). 5.3.4.3 For connection-mode data transfer, protection of the integrity of the sequence of data units (i.e., protection against reordering, loss, replay, insertion, and tampering) additionally requires some form of explicit ordering, such as sequence numbers, time stamps, or cryptographic chains. 5.3.4.4 For connectionless data transfer, time stamps may be used to provide a degree of protection against replay of individual data units. 5.3.5 Authentication Exchange Mechanisms
5.3.5.1 Some techniques that may be used for authentication exchanges are: a. Use of authentication information, such as a password, provided by the sending entity and verified by the receiving entity; b. Cryptographic techniques;
c. Use of characteristics or possession of the entity. 5.3.5.2 Such mechanisms may be provided at layer (N) to provide peer entity authentication. If the mechanism yields a negative result in authenticating the entity, this may result in rejection or termination of the connection and may also result in the addition of a record to the security audit trail or a report to the security management center.
5.3.5.3 When cryptographic techniques are used, they can be combined with the "handshake" protocol to prevent replay (i.e., ensure liveness). 5.3.5.4 The choice of authentication exchange techniques depends on the environment in which they are used. In many cases, they will have to be used in combination with: a. time stamping and synchronized clocks;
b. two-way handshakes and three-way handshakes (corresponding to unilateral authentication and mutual authentication, respectively); c. non-repudiation services implemented by digital signatures and notarization mechanisms. 5.3.6 Traffic padding mechanisms
Traffic padding mechanisms can be used to provide various levels of protection against traffic analysis. Such mechanisms are only effective when traffic padding is protected by confidentiality services. 5.3.7 Routing control mechanisms
5.3.7.1 Routes can be selected dynamically or pre-determined so that only physically secure subnetworks, relays, or links are used. 5.3.7.2 In the event of a persistent operational attack, an end system may wish to instruct the provider of the network service to establish the connection via a different route. 5.3.7.3 Data with certain security markings may be prohibited by security policy from passing through certain subnetworks, relays, or links. The initiator of a connection (or the sender of a connectionless data unit) may specify routing instructions by which it requests that certain specific subnetworks, links, or relays be avoided. 5.3.8 Notarization Mechanism
The properties of data communicated between two or more entities, such as its integrity, origin, time, and destination, can be ensured with the help of a notarization mechanism. This assurance is provided by a third-party notary. The notary is trusted by the communicating entities and possesses the necessary information to provide the required assurance in a verifiable manner. Each communication instance may use digital signatures, encryption, and integrity mechanisms to suit the service provided by the notary. When this notarization mechanism is used, data is communicated between the participating entities via a protected communication instance and the notary.
5.4 General security mechanisms
Several security mechanisms described in this clause are not specific to any particular service and are therefore not explicitly described in any particular layer in the following clause 7. Some of these general security mechanisms may be considered to belong to the security management aspect (see clause 8). The importance of these mechanisms is generally directly related to the required security level. 5.4.1 Trusted functionality
GB/T9387.2—1995
5.4.1.1 Trusted functionality is necessary to extend the scope of other security mechanisms or to establish the effectiveness of these security mechanisms. Any functionality that directly provides security mechanisms or provides access to security mechanisms should be trusted. 5.4.1.2 The means used to ensure that trust can be placed in such hardware and software are beyond the scope of this standard and, in any case, vary with the level of perceived threat and the value of the information being protected. 5.4.1.3 In general, these approaches are expensive and difficult to implement. This difficulty can be greatly simplified by choosing an architecture that allows security functions to be implemented in modules that can be built separately from, and provided by, non-security functions.
5.4.1.4 Any protection applied to a layer and to the connections above that layer must be provided by other means, such as through appropriate trust functionality.
5.4.2 Security Labels
Resources containing data items may have security labels associated with those data, such as labels indicating the sensitivity level of the data. Appropriate security labels must often be carried with the data in transit. Security labels may be additional data associated with the data being transmitted, or they may be implicit information, such as information implied by the use of a particular key to encrypt the data, or information implied by the context of the data, such as the origin or routing of the data. Explicit security labels must be clearly recognizable so that they can be properly verified. In addition, they must be securely attached to the data with which they are associated. 5.4.3 Event Detection
5.4.3.1 Detection of security-related events includes detection of obvious security violations and may also include detection of "normal" events, such as a successful access (or registration). Detection of security-related events may be performed by entities within OSI that contain security mechanisms. The technical specifications that constitute an event are maintained by the event handling management (see Section 8.3.1). Detection of various security events may result in one or more of the following actions:
Report the event locally,
Report the event remotely;
c. Record the event (see Section 5.4.3); Perform recovery (see Section 5.4.4).
Examples of such security events are:
a. specific security violation;
b. specific selected events;
c. overflow of the count of the number of times an event occurs. 5.4.3.2 Standardization in this area will consider the transmission of information related to event reports and event records, as well as the definition of syntax and semantics used for the transmission of event reports and event records. 5.4.4 Security Audit Trail
5.4.4.1 Security audit trail provides a security mechanism that cannot be ignored. Its potential value lies in the detection and investigation of security vulnerabilities through post-event security audits. Security audit is an independent evaluation of the records and behaviors of the system. The purpose is to test whether the control of the system is appropriate, ensure consistency with established policies and operating procedures, help make damage assessments, and evaluate changes specified in controls, policies and procedures. Security audit requires recording security-related information in the security audit trail, and analyzing and reporting information obtained from the security audit trail. This logging or recording is considered a security mechanism and is described in this clause, while analysis and reporting are considered a security management function (see clause 8.3.2). 5.4.4.2 The information collected in the audit trail can be adapted to different needs by listing the categories of security events recorded (such as obvious violations of security requirements or successful completion of operations). The existence of a known security audit can serve as a deterrent to certain potential sources of attack that violate security. 5.4.4.30S1 The security audit trail will consider the selection of what information to record, under what conditions to record the information, and the syntax and semantic definitions used for exchanging security audit trail information. 5.4.5 Security recovery
GB/T9387.2—1995
5.4.5.1 Security recovery processes requests from mechanisms such as event handling and management functions and regards recovery actions as the result of applying a set of rules. There are three possible types of such recovery actions: a.
Immediate;
Temporary;
Long-term.
For example:
Immediate action may result in an immediate abort of an operation, such as disconnection. Temporary action may render an entity temporarily inoperable. Long-term action may be to "blacklist" an entity, or to change a key. 5.4.5.2 Subjects for standardization include protocols for recovery actions, and protocols for security recovery management (see clause 8.3.3). 5.5 Examples of relationships between security services and security mechanisms For each provision of a service, Table 1 indicates which mechanisms are considered sometimes appropriate, either provided by a single mechanism or by a combination of mechanisms. This table shows an overview of these relationships, and is not set in stone. The services and mechanisms referenced in the table are described in clauses 5.2 and 5.3. These relationships are described more fully in clause 6. Table 1
Peer Entity Authentication
Data Origin Authentication
Access Control Service
Connection Confidentiality
Selected Fields Confidentiality
Traffic Flow Confidentiality
Connection Integrity with Recovery
Connection Integrity without Recovery
Selected Fields Connection Integrity
Connectionless Integrity
Selected Fields Connectionless Integrity
Non-repudiation with Proof of Data Origin
Non-repudiation with Proof of Delivery
Note: Y
Integrity
This mechanism is considered appropriate, either alone or in combination with other mechanisms. This mechanism is considered inappropriate.
6 Relationship between services, mechanisms and layers
6.1 Security layering principles
Communications
Service filling
6.1.1 The following principles are used to determine the allocation of security services to layers and the configuration of the accompanying security mechanisms on these layers: 2. The fewer different ways to implement a service, the better; 583
GB/T 9387.2—1995
b. It is advisable to provide security services on multiple layers to establish a secure system; c. The additional functionality required for security should not unnecessarily duplicate existing OSI functions; d. Avoid destroying the independence of layers;
e. The total amount of trusted functionality should be as small as possible; f. Whenever an entity relies on security mechanisms provided by entities located in lower layers, any intermediate layers should be constructed in a way that does not violate security;
g. Whenever possible, additional security functions of a layer should be defined in a way that does not exclude the ability to function as a self-contained module; h. This standard is intended for use in open systems consisting of end systems containing all seven layers, as well as relay systems. 6.1.2 The service definitions at each layer may need to be modified to satisfy security service requests, whether the security service is provided by that layer or below.
6.2 Invocation, management and use model of protection (N) services This clause should be read in conjunction with clause 8, which contains a general discussion of security management issues. This clause describes security services and mechanisms that can be activated by management entities through management interfaces or by service invocation. 6.2.1 Determination of protection characteristics for communication instances
6.2.1.1 Overview
This clause describes the invocation of protection for connection-oriented and connectionless communication instances. In the case of connection-oriented communication, protection is usually requested and granted at the time of connection establishment. In the case of connectionless service invocation, protection is requested and granted for each "unit data" request. To simplify the following description, the term "service request" will be used to refer to either the connection establishment or the unit data request. Protection of selected data invocations can be achieved by requesting protection of the selected fields. For example, it may be possible to establish several connections, each with a different type or level of protection.
This security architecture accommodates multiple security policies, including those that are rule-based, identity-based, or a combination of both. This security architecture also accommodates multiple types of protection: administratively imposed, dynamically selected, or a combination of both. 6.2.1.2 Service Requests
For each (N) service request, the (N+1) entity may request security protection to achieve the desired goal. The (N) service request shall specify the security service to achieve this goal along with parameters and additional relevant information (such as sensitivity information or security tags). Prior to each communication instance, the (N) layer must access the Security Management Information Base (SMIB) (see Section 8.1). The SMIB holds information about the administratively imposed protection requirements associated with the (N+1) entities involved. Trusted functionality is also required to enforce these administratively imposed security requirements.
When it comes to connection-oriented communication instances, the provision of security features may require negotiation of the required security services. The negotiation process of mechanisms and parameters can be performed as a separate process or as part of the normal connection establishment process. When the negotiation is performed as a separate process, the agreed results (i.e., the type of security mechanisms and security parameters required to provide such security services) are entered into the Security Management Information Base (see Section 8.1). When the negotiation is performed as part of the normal connection establishment process, the results of the negotiation between the (N) entities will be temporarily stored in the SMIB. Before the negotiation is carried out, the (N) entity will access the SMIB to obtain the information required for the negotiation. If the service request violates the administratively imposed requirements recorded in the SMIB for the (N+1) entity, the (N) layer will reject the service request.
The (N) layer will also add security services to the requested protection services, which are defined as "clients" in the SMIB to achieve the target security protection. If the (N+1) entity does not specify a target security protection, the (N) layer will follow the security policy consistent with the SMIB. This may be to continue communication using the default security protection in the section defined in the SMIB for this (N+1) entity. 6.2.2 Provision of Protection Services
Having determined the combination of administratively imposed and dynamically selected security requirements, as described in clause 6.2.1, the (N) layer shall attempt to achieve at least the required level of self-protection. This shall be achieved by one or both of the following methods. 58.41 Security audit trails provide a security mechanism that cannot be ignored. Their potential value lies in the ability to detect and investigate security vulnerabilities through post-event security audits. Security audits are independent evaluations of system records and behaviors. The purpose is to test whether the system controls are appropriate, ensure consistency with established policies and operating procedures, help make damage assessments, and evaluate changes specified in controls, policies and procedures. Security audits require recording security-related information in security audit trails, and analyzing and reporting information obtained from security audit trails. This logging or recording is considered a security mechanism and is described in this clause, while analysis and reporting are considered a security management function (see clause 8.3.2). 5.4.4.2 The information collected in the audit trail can be adapted to various needs by listing the categories of security events recorded (such as obvious violations of security requirements or successful completion of operations). The existence of known security audits can serve as a deterrent to certain potential sources of security violations. 5.4.4.30S1 The security audit trail will consider the selection of what information to record, under what conditions to record the information, and the syntax and semantic definitions used for exchanging security audit trail information. 5.4.5 Security Recovery
GB/T9387.2—1995
5.4.5.1 Security recovery processes requests from mechanisms such as incident handling and management functions, and takes recovery actions as the result of applying a set of rules. Such recovery actions may be of three types: a.
Immediate;
Temporary;
Long-term.
For example:
Immediate actions may result in the immediate abandonment of operations, such as disconnection. Temporary actions may temporarily invalidate an entity. Long-term actions may be to put an entity on a "blacklist" or change a key. 5.4.5.2 Subjects for standardization include protocols for recovery actions, as well as protocols for security recovery management (see 8.3.3). 5.5 Examples of relationships between security services and security mechanisms For each service provision, Table 1 indicates which mechanisms are considered to be sometimes appropriate, either provided by a single mechanism or by a combination of mechanisms. This table shows an overview of these relationships and is not set in stone. The services and mechanisms referenced in the table are described in clauses 5.2 and 5.3. These relationships are described more fully in clause 6. Table 1
Peer Entity Authentication
Data Origin Authentication
Access Control Service
Connection Confidentiality
Selected Fields Confidentiality
Traffic Flow Confidentiality
Connection Integrity with Recovery
Connection Integrity without Recovery
Selected Fields Connection Integrity
Connectionless Integrity
Selected Fields Connectionless Integrity
Non-repudiation with Proof of Data Origin
Non-repudiation with Proof of Delivery
Note: Y
Integrity
This mechanism is considered appropriate, either alone or in combination with other mechanisms. This mechanism is considered inappropriate.
6 Relationship between services, mechanisms and layers
6.1 Security layering principles
Communications
Service filling
6.1.1 The following principles are used to determine the allocation of security services to layers and the configuration of the accompanying security mechanisms on these layers: 2. The fewer different ways to implement a service, the better; 583
GB/T 9387.2—1995
b. It is advisable to provide security services on multiple layers to establish a secure system; c. The additional functionality required for security should not unnecessarily duplicate existing OSI functions; d. Avoid destroying the independence of layers;
e. The total amount of trusted functionality should be as small as possible; f. Whenever an entity relies on security mechanisms provided by entities located in lower layers, any intermediate layers should be constructed in a way that does not violate security;
g. Whenever possible, additional security functions of a layer should be defined in a way that does not exclude the ability to function as a self-contained module; h. This standard is intended for use in open systems consisting of end systems containing all seven layers, as well as relay systems. 6.1.2 The service definitions at each layer may need to be modified to satisfy security service requests, whether the security service is provided by that layer or below.
6.2 Invocation, management and use model of protection (N) services This clause should be read in conjunction with clause 8, which contains a general discussion of security management issues. This clause describes security services and mechanisms that can be activated by management entities through management interfaces or by service invocation. 6.2.1 Determination of protection characteristics for communication instances
6.2.1.1 Overview
This clause describes the invocation of protection for connection-oriented and connectionless communication instances. In the case of connection-oriented communication, protection is usually requested and granted at the time of connection establishment. In the case of connectionless service invocation, protection is requested and granted for each "unit data" request. To simplify the following description, the term "service request" will be used to refer to either the connection establishment or the unit data request. Protection of selected data invocations can be achieved by requesting protection of the selected fields. For example, it may be possible to establish several connections, each with a different type or level of protection.
This security architecture accommodates multiple security policies, including those that are rule-based, identity-based, or a combination of both. This security architecture also accommodates multiple types of protection: administratively imposed, dynamically selected, or a combination of both. 6.2.1.2 Service Requests
For each (N) service request, the (N+1) entity may request security protection to achieve the desired goal. The (N) service request shall specify the security service to achieve this goal along with parameters and additional relevant information (such as sensitivity information or security tags). Prior to each communication instance, the (N) layer must access the Security Management Information Base (SMIB) (see Section 8.1). The SMIB holds information about the administratively imposed protection requirements associated with the (N+1) entities involved. Trusted functionality is also required to enforce these administratively imposed security requirements.
When it comes to connection-oriented communication instances, the provision of security features may require negotiation of the required security services. The negotiation process of mechanisms and parameters can be performed as a separate process or as part of the normal connection establishment process. When the negotiation is performed as a separate process, the agreed results (i.e., the type of security mechanisms and security parameters required to provide such security services) are entered into the Security Management Information Base (see Section 8.1). When the negotiation is performed as part of the normal connection establishment process, the results of the negotiation between the (N) entities will be temporarily stored in the SMIB. Before the negotiation is carried out, the (N) entity will access the SMIB to obtain the information required for the negotiation. If the service request violates the administratively imposed requirements recorded in the SMIB for the (N+1) entity, the (N) layer will reject the service request.
The (N) layer will also add security services to the requested protection services, which are defined as "clients" in the SMIB to achieve the target security protection. If the (N+1) entity does not specify a target security protection, the (N) layer will follow the security policy consistent with the SMIB. This may be to continue communication using the default security protection in the section defined in the SMIB for this (N+1) entity. 6.2.2 Provision of Protection Services
Having determined the combination of administratively imposed and dynamically selected security requirements, as described in clause 6.2.1, the (N) layer shall attempt to achieve at least the required level of self-protection. This shall be achieved by one, or both, of the following methods. 58.41 Security audit trails provide a security mechanism that cannot be ignored. Their potential value lies in the ability to detect and investigate security vulnerabilities through post-event security audits. Security audits are independent evaluations of system records and behaviors. The purpose is to test whether the system controls are appropriate, ensure consistency with established policies and operating procedures, help make damage assessments, and evaluate changes specified in controls, policies and procedures. Security audits require recording security-related information in security audit trails, and analyzing and reporting information obtained from security audit trails. This logging or recording is considered a security mechanism and is described in this clause, while analysis and reporting are considered a security management function (see clause 8.3.2). 5.4.4.2 The information collected in the audit trail can be adapted to various needs by listing the categories of security events recorded (such as obvious violations of security requirements or successful completion of operations). The existence of known security audits can serve as a deterrent to certain potential sources of security violations. 5.4.4.30S1 The security audit trail will consider the selection of what information to record, under what conditions to record the information, and the syntax and semantic definitions used for exchanging security audit trail information. 5.4.5 Security Recovery
GB/T9387.2—1995
5.4.5.1 Security recovery processes requests from mechanisms such as incident handling and management functions, and takes recovery actions as the result of applying a set of rules. Such recovery actions may be of three types: a.
Immediate;
Temporary;
Long-term.
For example:
Immediate actions may result in the immediate abandonment of operations, such as disconnection. Temporary actions may temporarily invalidate an entity. Long-term actions may be to put an entity on a "blacklist" or change a key. 5.4.5.2 Subjects for standardization include protocols for recovery actions, as well as protocols for security recovery management (see 8.3.3). 5.5 Examples of relationships between security services and security mechanisms For each service provision, Table 1 indicates which mechanisms are considered to be sometimes appropriate, either provided by a single mechanism or by a combination of mechanisms. This table shows an overview of these relationships and is not set in stone. The services and mechanisms referenced in the table are described in clauses 5.2 and 5.3. These relationships are described more fully in clause 6. Table 1
Peer Entity Authentication
Data Origin Authentication
Access Control Service
Connection Confidentiality
Selected Fields Confidentiality
Traffic Flow Confidentiality
Connection Integrity with Recovery
Connection Integrity without Recovery
Selected Fields Connection Integrity
Connectionless Integrity
Selected Fields Connectionless Integrity
Non-repudiation with Proof of Data Origin
Non-repudiation with Proof of Delivery
Note: Y
Integrity
This mechanism is considered appropriate, either alone or in combination with other mechanisms. This mechanism is considered inappropriate.
6 Relationship between services, mechanisms and layers
6.1 Security layering principles
Communications
Service filling
6.1.1 The following principles are used to determine the allocation of security services to layers and the configuration of the accompanying security mechanisms on these layers: 2. The fewer different ways to implement a service, the better; 583
GB/T 9387.2—1995
b. It is advisable to provide security services on multiple layers to establish a secure system; c. The additional functionality required for security should not unnecessarily duplicate existing OSI functions; d. Avoid destroying the independence of layers;
e. The total amount of trusted functionality should be as small as possible; f. Whenever an entity relies on security mechanisms provided by entities located in lower layers, any intermediate layers should be constructed in a way that does not violate security;
g. Whenever possible, additional security functions of a layer should be defined in a way that does not exclude the ability to function as a self-contained module; h. This standard is intended for use in open systems consisting of end systems containing all seven layers, as well as relay systems. 6.1.2 The service definitions at each layer may need to be modified to satisfy security service requests, whether the security service is provided by that layer or below.
6.2 Invocation, management and use model of protection (N) services This clause should be read in conjunction with clause 8, which contains a general discussion of security management issues. This clause describes security services and mechanisms that can be activated by management entities through management interfaces or by service invocation. 6.2.1 Determination of protection characteristics for communication instances
6.2.1.1 Overview
This clause describes the invocation of protection for connection-oriented and connectionless communication instances. In the case of connection-oriented communication, protection is usually requested and granted at the time of connection establishment. In the case of connectionless service invocation, protection is requested and granted for each "unit data" request. To simplify the following description, the term "service request" will be used to refer to either the connection establishment or the unit data request. Protection of selected data invocations can be achieved by requesting protection of the selected fields. For example, it may be possible to establish several connections, each with a different type or level of protection.
This security architecture accommodates multiple security policies, including those that are rule-based, identity-based, or a combination of both. This security architecture also accommodates multiple types of protection: administratively imposed, dynamically selected, or a combination of both. 6.2.1.2 Service Requests
For each (N) service request, the (N+1) entity may request security protection to achieve the desired goal. The (N) service request shall specify the security service to achieve this goal along with parameters and additional relevant information (such as sensitivity information or security tags). Prior to each communication instance, the (N) layer must access the Security Management Information Base (SMIB) (see Section 8.1). The SMIB holds information about the administratively imposed protection requirements associated with the (N+1) entities involved. Trusted functionality is also required to enforce these administratively imposed security requirements.
When it comes to connection-oriented communication instances, the provision of security features may require negotiation of the required security services. The negotiation process of mechanisms and parameters can be performed as a separate process or as part of the normal connection establishment process. When the negotiation is performed as a separate process, the agreed results (i.e., the type of security mechanisms and security parameters required to provide such security services) are entered into the Security Management Information Base (see Section 8.1). When the negotiation is performed as part of the normal connection establishment process, the results of the negotiation between the (N) entities will be temporarily stored in the SMIB. Before the negotiation is carried out, the (N) entity will access the SMIB to obtain the information required for the negotiation. If the service request violates the administratively imposed requirements recorded in the SMIB for the (N+1) entity, the (N) layer will reject the service request.
The (N) layer will also add security services to the requested protection services, which are defined as "clients" in the SMIB to achieve the target security protection. If the (N+1) entity does not specify a target security protection, the (N) layer will follow the security policy consistent with the SMIB. This may be to continue communication using the default security protection in the section defined in the SMIB for this (N+1) entity. 6.2.2 Provision of Protection Services
Having determined the combination of administratively imposed and dynamically selected security requirements, as described in clause 6.2.1, the (N) layer shall attempt to achieve at least the required level of self-protection. This shall be achieved by one or both of the following methods. 58.45 Security Recovery
GB/T9387.2—1995
5.4.5.1 Security recovery processes requests from mechanisms such as incident handling and management functions, and treats recovery actions as the result of applying a set of rules. There may be three types of such recovery actions: a.
Immediate;
Temporary;
Long-term.
For example:
Immediate actions may result in immediate abandonment of operations, such as disconnection. Temporary actions may temporarily disable an entity. Long-term actions may include putting an entity on a "blacklist" or changing a key. 5.4.5.2 For standardized topics, protocols for recovery actions are included, as well as protocols for security recovery management (see 8.3.3). 5.5 Examples of relationships between security services and security mechanisms For each service provision, Table 1 indicates which mechanisms are considered to be sometimes appropriate, or provided by a mechanism alone, or by a combination of mechanisms. This table shows an overview of these relationships, and they are not all fixed. The services and mechanisms referenced in the table are described in clauses 5.2 and 5.3, and these relationships are described more fully in clause 6. Table 1
Peer Entity Authentication
Data Origin Authentication
Access Control Services
Connection Confidentiality
Connectionless Confidentiality
Selected Fields Confidentiality
Traffic Flow Confidentiality
Connection Integrity with Recovery
Connection Integrity without Recovery
Selected FieldsConnection Integrity
Connectionless Integrity
Selected FieldsConnectionless Integrity
Non-repudiation with Proof of Data Origin
Non-repudiation with Proof of Delivery
Comment: Y
Integrity
This mechanism is considered appropriate, either alone or in combination with other mechanisms. This mechanism is considered inappropriate.
6 Relationship between services, mechanisms and layers
6.1 Security layering principles
Communications
Service filling
6.1.1 The following principles are used to determine the allocation of security services to layers and the configuration of the accompanying security mechanisms on these layers: 2. The fewer different ways to implement a service, the better; 583
GB/T 9387.2—1995
b. It is advisable to provide security services on multiple layers to establish a secure system; c. The additional functionality required for security should not unnecessarily duplicate existing OSI functions; d. Avoid destroying the independence of layers;
e. The total amount of trusted functionality should be as small as possible; f. Whenever an entity relies on security mechanisms provided by entities located in lower layers, any intermediate layers should be constructed in a way that does not violate security;
g. Whenever possible, additional security functions of a layer should be defined in a way that does not exclude the ability to function as a self-contained module; h. This standard is intended for use in open systems consisting of end systems containing all seven layers, as well as relay systems. 6.1.2 The service definitions at each layer may need to be modified to satisfy security service requests, whether the security service is provided by that layer or below.
6.2 Invocation, management and use model of protection (N) services This clause should be read in conjunction with clause 8, which contains a general discussion of security management issues. This clause describes security services and mechanisms that can be activated by management entities through management interfaces or by service invocation. 6.2.1 Determination of protection characteristics for communication instances
6.2.1.1 Overview
This clause describes the invocation of protection for connection-oriented and connectionless communication instances. In the case of connection-oriented communication, protection is usually requested and granted at the time of connection establishment. In the case of connectionless service invocation, protection is requested and granted for each "unit data" request. To simplify the following description, the term "service request" will be used to refer to either the connection establishment or the unit data request. Protection of selected data invocations can be achieved by requesting protection of the selected fields. For example, it may be possible to establish several connections, each with a different type or level of protection.
This security architecture accommodates multiple security policies, including those that are rule-based, identity-based, or a combination of both. This security architecture also accommodates multiple types of protection: administratively imposed, dynamically selected, or a combination of both. 6.2.1.2 Service Requests
For each (N) service request, the (N+1) entity may request security protection to achieve the desired goal. The (N) service request shall specify the security service to achieve this goal along with parameters and additional relevant information (such as sensitivity information or security tags). Prior to each communication instance, the (N) layer must access the Security Management Information Base (SMIB) (see Section 8.1). The SMIB holds information about
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.