Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Modelo de referência para uma arquitetura de segurança
Tipologia: Notas de estudo
1 / 48
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Geneva, 1991
The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the International Telecommunication Union (ITU). CCITT is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.
The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves Recommendations prepared by its Study Groups. The approval of Recommendations by the members of CCITT between Plenary Assemblies is covered by the procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988).
Recommendation X.800 was prepared by Study Group VII and was approved under the Resolution No. 2 procedure on the 22nd of March 1991.
CCITT NOTE
In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication Administration and a recognized private operating agency.
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU.
OSI security functions are concerned only with those visible aspects of a communications path which permit end systems to achieve the secure transfer of information between them. OSI security is not concerned with security measures needed in end systems, installations, and organizations, except where these have implications on the choice and position of security services visible in OSI. These latter aspects of security may be standardized but not within the scope of OSI Recommendations.
This Recommendation adds to the concepts and principles defined in Recommendation X.200; it does not modify them. It is not an implementation specification, nor is it a basis for appraising the conformance of actual implementations.
2 References
Rec. X.200 – Reference Model of open systems interconnection for CCITT applications.
ISO 7498 – Information processing systems – Open systems interconnection – Basic Reference Model (1984).
ISO 7498-4 – Information processing systems – Open systems interconnection – Basic Reference Model –Part 4: Management framework (1989).
ISO 7498/AD1 – Information processing systems – Open systems interconnection – Basic Reference Model – Addendum 1: Connectionless-mode transmission (1987).
ISO 8648 – Information processing systems – Open systems interconnection – Internal organization of the network layer (1988).
3 Definitions and abbreviations
3.1 This Recommendation builds on concepts developed in Recommendation X.200 and makes use of the following terms defined in it:
a) (N)-connection;
b) (N)-data-transmission;
c) (N)-entity;
d) (N)-facility;
e) (N)-layer;
f) Open system;
g) Peer entities;
h) (N)-protocol;
j) (N)-protocol-data-unit;
k) (N)-relay;
l) Routing;
m) Sequencing;
n) (N)-service;
p) (N)-service-data-unit;
q) (N)-user-data;
r) Sub-network;
s) OSI resource; and
t) Transfer syntax.
3.2 This Recommendation uses the following terms drawn from the respective Recommendations/International standards:
Connectionless-mode transmission (ISO 7498/AD1)
End system (Rec. X.200/ISO 7498)
Relaying and routing function (ISO 8648)
Management information base (MIB) (ISO 7498-4)
In addition, the following abbreviations are used:
OSI open systems interconnection;
SDU for service data unit;
SMIB for security management information base; and
MIB for management information base.
3.3 For the purpose of this Recommendation, the following definitions apply:
3.3.1 access control
The prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner.
3.3.2 access control list
A list of entities, together with their access rights, which are authorized to have access to a resource.
3.3.3 accountability
The property that ensures that the actions of an entity may be traced uniquely to the entity.
3.3.4 active threat
The threat of a deliberate unauthorized change to the state of the system.
Note – Examples of security-relevant active threats may be: modification of messages, replay of messages, insertion of spurious messages, masquerading as an authorized entity and denial of service.
3.3.5 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 Recommendation the term “authentication” is not used in connection with data integrity; the term “data integrity” is used instead.
3.3.8 authentication information
Information used to establish the validity of a claimed identity.
3.3.9 authentication exchange
A mechanism intended to ensure the identity of an entity by means of information exchange.
3.3.23 decipherment
The reversal of a corresponding reversible encipherment.
3.3.24 decryption
See decipherment.
3.3.25 denial of service
The prevention of authorized access to resources or the delaying of time-critical operations.
3.3.26 digital signature
Data appended to, or a cryptographic transformation (see cryptography) of a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient.
3.3.27 encipherment
The cryptographic transformation of data (see cryptography) to produce ciphertext.
Note – Encipherment may be irreversible, in which case the corresponding decipherment process cannot feasibly be performed.
3.3.28 encryption
See encipherment.
3.3.29 end-to-end encipherment
Encipherment of data within or at the source end system, with the corresponding decipherment occurring only within or at the destination end system. (See also link-by-link encipherment.)
3.3.30 identity-based security policy
A security policy based on the identities and/or attributes of users, a group of users, or entities acting on behalf of the users and the resources/objects being accessed.
3.3.31 integrity
See data integrity.
3.3.32 key
A sequence of symbols that controls the operations of encipherment and decipherment.
3.3.33 key management
The generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy.
3.3.34 link-by-link encipherment
The individual application of encipherment to data on each link of a communications system. (See also end-to- end encipherment.)
Note – The implication of link-by-link encipherment is that data will be in cleartext form in relay entities.
3.3.35 manipulation detection
A mechanism which is used to detect whether a data unit has been modified (either accidentally or intentionally).
3.3.36 masquerade
The pretence by an entity to be a different entity.
3.3.37 notarization
The registration of data with a trusted third party that allows the later assurance of the accuracy of its characteristics such as content, origin, time and delivery.
3.3.38 passive threat
The threat of unauthorized disclosure of information without changing the state of the system.
3.3.39 password
Confidential authentication information, usually composed of a string of characters.
3.3.40 peer-entity authentication
The corroboration that a peer entity in an association is the one claimed.
3.3.41 physical security
The measures used to provide physical protection of resources against deliberate and accidental threats.
3.3.42 policy
See security policy.
3.3.43 privacy
The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.
Note – Because this term relates to the right of individuals, it cannot be very precise and its use should be avoided except as a motivation for requiring security.
3.3.44 repudiation
Denial by one of the entities involved in a communication of having participated in all or part of the communication.
3.3.45 routing control
The application of rules during the process of routing so as to chose or avoid specific networks, links or relays.
3.3.46 rule-based security policy
A security policy based on global rules imposed for all users. These rules usually rely on a comparison of the sensitivity of the resources being accessed and the possession of corresponding attributes of users, a group of users, or entities acting on behalf of users.
3.3.47 security audit
An independent review and examination of system records and activities in order to test for adequacy of system controls, to ensure compliance with established policy and operational procedures, to detect breaches in security, and to recommend any indicated changes in control, policy and procedures.
3.3.48 security audit trail
Data collected and potentially used to facilitate a security audit.
5 General description of security services and mechanisms
5.1 Overview
Security services that are included in the OSI security architecture and mechanisms which implement those services are discussed in this section. The security services described below are basic security services. In practice they will be invoked at appropriate layers and in appropriate combinations, usually with non-OSI services and mechanisms, to satisfy security policy and/or user requirements. Particular security mechanisms can be used to implement combinations of the basic security services. Practical realizations of systems may implement particular combinations of the basic security services for direct invocation.
5.2 Security services
The following are considered to be the security services which can be provided optionally within the framework of the OSI Reference Model. The authentication services require authentication information comprising locally stored information and data that is transferred (credentials) to facilitate the authentication.
5.2.1 Authentication
These services provide for the authentication of a communicating peer entity and the source of data as described below.
5.2.1.1 Peer entity authentication
This service, when provided by the (N)-layer, provides corroboration to the (N + 1)-entity that the peer entity is the claimed (N + 1)-entity.
This service is provided for use at the establishment of, or at times during, the data transfer phase of a connection to confirm the identities of one or more of the entities connected to one or more of the other entities. This service provides confidence, at the time of usage only, that an entity is not attempting a masquerade or an unauthorized replay of a previous connection. One-way and mutual peer entity authentication schemes, with or without a liveness check, are possible and can provide varying degrees of protection.
5.2.1.2 Data origin authentication
This service, when provided by the (N)-layer, provides corroboration to an (N + 1)-entity that the source of the data is the claimed peer (N + 1)-entity.
The data origin authentication service provides the corroboration of the source of a data unit. The service does not provide protection against duplication or modification of data units.
5.2.2 Access control
This service provides protection against unauthorized use of resources accessible via OSI. These may be OSI or non-OSI resources accessed via OSI protocols. This protection service may be applied to various types of access to a resource (e.g., the use of a communications resource; the reading, the writing, or the deletion of an information resource; the execution of a processing resource) or to all accesses to a resource.
The control of access will be in accordance with various security policies (see § 6.2.1.1).
5.2.3 Data confidentiality
These services provide for the protection of data from unauthorized disclosure as described below.
5.2.3.1 Connection confidentiality
This service provides for the confidentiality of all (N)-user-data on an (N)-connection.
Note – Depending on use and layer, it may not be appropriate to protect all data, e.g. expedited data or data in a connection request.
5.2.3.2 Connectionless confidentiality
This service provides for the confidentiality of all (N)-user-data in a single connectionless (N)-SDU.
5.2.3.3 Selective field confidentiality
This service provides for the confidentiality of selected fields within the (N)-user-data on an (N)-connection or in a single connectionless (N)-SDU.
5.2.3.4 Traffic flow confidentiality
This service provides for the protection of the information which might be derived from observation of traffic flows.
5.2.4 Data integrity
These services counter active threats and may take one of the forms described below.
Note – On a connection, the use of the peer entity authentication service at the start of the connection and the data integrity service during the life of the connection can jointly provide for the corroboration of the source of all data units transfered on the connection, the integrity of those data units, and may additionally provide for the detection of duplication of data units, e.g. by the use of sequence numbers.
5.2.4.1 Connection integrity with recovery
This service provides for the integrity of all (N)-user-data on an (N)-connection and detects any modification, insertion, deletion or replay of any data within an entire SDU sequence (with recovery attempted).
5.2.4.2 Connection integrity without recovery
As for § 5.2.4.1 but with no recovery attempted.
5.2.4.3 Selective field connection integrity
This service provides for the integrity of selected fields within the (N)-user data of an (N)-SDU transferred over a connection and takes the form of determination of whether the selected fields have been modified, inserted, deleted or replayed.
5.2.4.4 Connectionless integrityx
This service, when provided by the (N)-layer, provides integrity assurance to the requesting (N + 1)-entity.
This service provides for the integrity of a single connectionless SDU and may take the form of determination of whether a received SDU has been modified. Additionally, a limited form of detection of replay may be provided.
5.2.4.5 Selective field connectionless integrity
This service provides for the integrity of selected fields within a single connectionless SDU and takes the form of determination of whether the selected fields have been modified.
5.3.3 Access control mechanisms
5.3.3.1 These mechanisms may use the authenticated identity of an entity or information about the entity (such as membership in a known set of entities) or capabilities of the entity, in order to determine and enforce the access rights of the entity. If the entity attempts to use an unauthorized resource, or an authorized resource with an improper type of access, then the access control function will reject the attempt and may additionally report the incident for the purposes of generating an alarm and/or recording it as part of a security audit trail. Any notification to the sender of a denial of access for a connectionless data transmission can be provided only as a result of access controls imposed at the origin.
5.3.3.2 Access control mechanisms may, for example, be based on use of one or more of the following:
a) Acess control information bases, where the access rights of peer entities are maintained. This information may be maintained by authorization centres or by the entity being accessed, and may be in the form of an access control list or matrix of hierarchical or distributed structure. This presupposes that peer entity authentication has been assured.
b) Authentication information such as passwords, possession and subsequent presentation of which is evidence of the accessing entity’s authorization;
c) Capabilities, possession and subsequent presentation of which is evidence of the right to access the entity or resource defined by the capability.
Note – A capability should be unforceable and should be conveyed in a trusted manner.
d) Security labels, which when associated with an entity may be used to grant or deny access, usually according to a security policy.
e) Time of attempted access.
f) Route of attempted access, and
g) Duration of access.
5.3.3.3 Access control mechanisms may be applied at either end of a communications association and/or at any intermediate point.
Access controls involved at the origin or any intermediate point are used to determine whether the sender is authorized to communicate with the recipient and/or to use the required communications resources.
The requirements of the peer level access control mechanisms at the destination end of a connectionless data transmission must be known a priori at the origin, and must be recorded in the security management information base (see §§ 6.2 and 8.1).
5.3.4 Data integrity mechanisms
5.3.4.1 Two aspects of data integrity are: the integrity of a single data unit or field; and the integrity of a stream of data units or fields. In general, different mechanisms are used to provide these two types of integrity service, although provision of the second without the first is not practical.
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 to a data unit a quantity which is a function of the data itself. This quantity may be supplementary information such as a block check code or a cryptographic checkvalue and may itself be enciphered. The receiving entity generates a corresponding quantity and compares it with the received quantity to determine whether the data has been modified in transit. This mechanism alone will not protect against the replay of a single data unit. In appropriate layers of the architecture, detection of manipulation may lead to recovery action (for example, via retransmissions or error correction) at that or a higher layer.
5.3.4.3 For connection-mode data transfer, protecting the integrity of a sequence of data units (i.e. protecting against misordering, losing, replaying and inserting or modifying data) requires additionally some form of explicit ordering such as sequence numbering, time stamping, or cryptographic chaining.
5.3.4.4 For connectionless data transmission, time stamping may be used to provide a limited form of protection against replay of individual data units.
5.3.5 Authentication exchange mechanism
5.3.5.1 Some of the techniques which may be applied to authentication exchanges are:
a) use of authentication information, such as passwords supplied by a sending entity and checked by the receiving entity;
b) cryptographic techniques; and
c) use of characteristics and/or possessions of the entity.
5.3.5.2 The mechanisms may be incorporated into the (N)-layer in order to provide peer entity authentication. If the mechanism does not succeed in authenticating the entity, this will result in rejection or termination of the connection and may also cause an entry in the security audit trail and/or a report to a security management centre.
5.3.5.3 When cryptographic techniques are used, they may be combined with “handshaking” protocols to protect against replay (i.e. to ensure liveness).
5.3.5.4 The choices of authentication exchange techniques will depend upon the circumstances in which they will need to be used with:
a) time stamping and synchronized clocks;
b) two and three way handshakes (for unilateral and mutual authentication respectively); and
c) non-repudiation services achieved by digital signature and/or notarization mechanisms.
5.3.6 Traffic padding mechanism
Traffic padding mechanisms can be used to provide various levels of protection against traffic analysis. This mechanism can be effective only if the traffic padding is protected by a confidentiality service.
5.3.7 Routing control mechanism
5.3.7.1 Routes can be chosen either dynamically or by prearrangement so as to use only physically secure sub- networks, relays or links.
5.3.7.2 End-systems may, on detection of persistent manipulation attacks, wish to instruct the network service provider to establish a connection via a different route.
5.3.7.3 Data carrying certain security labels may be forbidden by the security policy to pass through certain sub- networks, relays or links. Also the initiator of a connection (or the sender of a connectionless data unit) may specify routing caveats which request that specific sub-networks, links or relays be avoided.
5.3.8 Notarization mechanism
5.3.8.1 Properties about the data communicated between two or more entities, such as its integrity, origin, time and destination, can be assured by the provision of a notarization mechanism. The assurance is provided by a third party notary, which is trusted by the communicating entities, and which holds the necessary information to provide the required assurance in a testifiable manner. Each instance of communication may use digital signature, encipherment, and integrity mechanisms as appropriate to the service being provided by the notary. When such a notarization mechanism is invoked, the data is communicated between the communicating entities via the protected instances of communication and the notary.
5.4.4 Security audit trail
5.4.4.1 Security audit trails provide a valuable security mechanism as potentially they permit detection and investigation of breaches of security by permitting a subsequent security audit. A security audit is an independent review and examination of system records and activities in order to test for adequacy of system controls, to ensure compliance with established policy and operational procedures, to aid in damage assessment, and to recommend any indicated changes in controls, policy and procedures. A security audit requires the recording of security-relevant information in a security audit trail, and the analysis and reporting of information from the security audit trail. The logging or recording is considered to be a security mechanism and is described in this section. The analysis and report generation is considered a security management function (see § 8.3.2).
5.4.4.2 Collection of security audit trail information may be adapted to various requirements by specifying the kind(s) of security-relevant events to be recorded (e.g. apparent security violations or completion of successful operations).
The known existence of a security audit trail may serve as a deterrent to some potential sources of security attacks.
5.4.4.3 OSI security audit trail considerations will take into account what information shall optionally be logged, under what conditions that information shall be logged, and the syntactic and semantic definition to be used for the interchange of the security audit trail information.
5.4.5 Security recovery
5.4.5.1 Security recovery deals with requests from mechanisms such as event handling and management functions, and takes recovery actions as the result of applying a set of rules. These recovery actions may be of three kinds:
a) immediate;
b) temporary; and
c) long term.
For example:
Immediate actions may create an immediate abort of operations, like disconnection.
Temporary actions may produce temporary invalidation of an entity.
Long term actions may be an introduction of an entity into a “black list” or the changing of a key.
5.4.5.2 Subjects for standardization include protocols for recovery actions and for security recovery management (see § 8.3.3).
5.5 Illustration of relationship of security services and mechanisms
Table 1/X.800 illustrates which mechanisms, alone or in combination with others, are considered to be sometimes appropriate for the provision of each service. This table presents an overview of these relationships and is not definitive. The services and mechanisms referred to in this table are described in §§ 5.2 and 5.3. The relationships are more fully described in § 6.
TABLE 1/X.
Illustration of relationship of security services and mechanisms
· The mechanism is considered not to be appropriate.
Y Yes: the mechanism is considered to be appropiate, either on its own or in combination with other mechanisms.
Note – In some instances, the mechanism provides more than is necessary for the relevant service but could nevertheless be used.
6 The relationship of services, mechanisms and layers
6.1 Security layering principles
6.1.1 The following principles were used in order to determine the allocation of security services to layers and the consequent placement of security mechanisms in the layers:
a) the number of alternative ways of achieving a service should be minimized;
b) it is acceptable to build secure systems by providing security services in more than one layer;
c) additional functionality required for security should not unnecessarily duplicate the existing OSI functions;
d) violation of layer independence should be avoided;
Mechanism
Service
Encipherment
Digital signature
Acces control
Data integrity
Authenti- cation exchange
Traffic padding
Routing control
Notari- zation
Peer entity authentication Y Y · · Y · · · Data origin authentication Y Y · · · · · · Access control service · · Y · · · · · Connection confidentiality Y. · · · · Y · Connectionless confidentiality Y · · · · · Y · Selective field confidentiality Y · · · · · · · Traffic flow confidentiality Y · · · · Y Y · Connection Integrity with recovery Y · · Y · · · · Connection integrity without recovery Y · · Y · · · · Selective field connection integrity Y · · Y · · · · Connectionless integrity Y Y · Y · · · · Selective field connectionless integrity Y Y · Y · · · · Non-repudiation. Origin · Y · Y · · · Y Non-repudiation. Delivery · Y · Y · · · Y
When the negotiation is carried out as a separate procedure, the results of the agreement (i.e. on the type of security mechanisms and the security parameters that are necessary to provide such security services) are entered in the security management information base (see § 8.1).
When the negotiation is carried out as an integral part of the normal connection establishment procedure, the results of the negotiation between the (N)-entities, will be temporarily stored in the SMIB. Prior to the negotiation each (N)-entity will access the SMIB for information required for the negotiation.
The (N)-layer will reject the service request if it violates administratively-imposed requirements that are registered in the SMIB for the (N + 1)-entity.
The (N)-layer will also add to the requested protection services any security services which are defined in the SMIB as mandatory to obtain the target security protection.
If the (N + 1)-entity does not specify a target security protection, the (N)-layer will follow a security policy in accordance with the SMIB. This could be to proceed with communication using a default security protection within the range defined for the (N + 1)-entity in the SMIB.
6.2.2 Provision of protection services
After the combination of administratively-imposed and dynamically selected security requirements has been determined, as described in § 6.2.1, the (N)-layer will attempt to achieve, as a minimum, the target protection. This will be achieved by either, or both, of the following methods:
a) invoking security mechanisms directly within the (N)-layer; and/or
b) requesting protection services from the (N − 1)-layer. In this case, the scope of protection must be extended to the (N)-service by a combination of trusted functionality and/or specific security mechanisms in the (N)-layer.
Note – This does not necessarily imply that all the functionality in the (N)-layer has to be trusted.
Thus, the (N)-layer determines if it is able to achieve the requested target protection. If it is not able to achieve this, no instance of communication occurs.
6.2.2.1 Establishment of a protected (N)-connection
The following discussion addresses the provision of services within the (N)-layer, (as opposed to relying on (N − 1)-services).
In certain protocols, to achieve a satisfactory target protection, the sequence of operations is crucial.
a) Outgoing Access Control
The (N)-layer may impose outgoing access controls, i.e. it may determine locally (from the SMIB) whether the protected (N)-connection establishment may be attempted or is forbidden.
b) Peer Entity Authentication
If the target protection includes Peer Entity Authentication, or if it is known (from the SMIB) that the destination (N)-entity will require Peer Entity Authentication, then an authentication exchange must take place. This may employ two- or three-way handshakes to provide unilateral or mutual authentication, as required.
Sometimes, the authentication exchange may be integrated into the usual (N)-connection establishment procedures. Under other circumstances, the authentication exchange may be accomplished separately from (N)-connection establishment.
c) Access Control service
The destination (N)-entity or intermediate entities may impose access control restrictions. If specific information is required by a remote access control mechanism then the initiating (N)-entity supplies this information within the (N)-layer protocol or via management channels.
d) Confidentiality
If a total or selective confidentiality service has been selected, a protected (N)-connection must be established. This must include the establishment of the proper working key(s) and negotiation of cryptographic parameters for the connection. This may have been done by prearrangement, in the authentication exchange, or by a separate protocol.
e) Data Integrity
If integrity of all (N)-user-data, with or without recovery, or integrity of selective fields has been selected, a protected (N)-connection must be established. This may be the same connection as that established to provide the confidentiality service and may provide authentication. The same considerations apply as for the confidentiality service for a protected (N)-connection.
f) Non-repudiation services
If Non-repudiation with Proof of Origin has been selected, the proper cryptographic parameters must be established, or a protected connection with a notarization entity must be established.
If Non-repudiation with Proof of Delivery is selected, the proper parameters (which are different from those required for non-repudiation with proof of origin) must be established, or a protected connection with a notarization entity must be established.
Note – The establishment of the protected (N)-connection may fail due to the lack of agreement on cryptographic parameters (possibly including the non-possession of the proper keys) or through rejection by an access control mechanism.
6.2.3 Operation of a protected (N)-connection
6.2.3.1 During the data transfer phase of a protected (N)-connection, the protection services negotiated must be provided.
The following will be visible at the (N)-service boundary:
a) Peer Entity Authentication (at intervals);
b) Protection of Selective Fields; and
c) Reporting of Active Attack (for example, when a manipulation of data has occurred and the service being provided is “connection integrity without recovery” – see § 5.2.4.2).
In addition, the following may be needed:
a) security audit trail recording, and
b) event detection and handling.
6.2.3.2 Those services which are amenable to selective application are:
a) Confidentiality;
b) Data Integrity (possibly with authentication); and
c) Non-repudiation (by receiver or by sender).
Note 1 – Two techniques are suggested for marking those data items selected for the application of a service. The first involves using strong typing. It is anticipated that the presentation layer will recognize certain types as those which require certain protection services to be applied. The second involves some form of flagging the individual data items to which specified protection services should be applied.
