- Email: [email protected]
Security of open systems
Computers
& Security,
8 (1989) 139-147
Refereed Article
Security of Open Systems Jan P. Kruys* NCR Corporalion, Nieuwegein, The Netherlands
As an enhancement to ISo’s Open Systems Interconnection Reference Model, ECMA defines a security framework for distributed systems which is based on the concepts of security domains and security facilities. This paper describes a functional decomposition of the security of distributed systems, thus providing building blocks which can be specified and analysed in detail and can be used to establish a secure distributed processing environment for both private application software and public communication services such as electronic mail. The aim is to achieve both interoperability (openness) and a high level of confidence. Keywords: Distributed tecture, 0%.
1. Sea
processing, Open systems, Security archi-
‘ty of Open Systems
T
he International Standards Organization (ISO) started the development of a set of standards for open systems some IO years ago. This set has been based on the Open Systems Interconnection (OSI) reference model [3, 4, 1 l]. The parties involved in developing the standards were the IS0 Technical Committee TC97, the European Computer Manufacturers Association (ECMA) TC32, and the CCITT SG VII. Currently, the OS1 reference model has been accepted by many major manufacturers and has resulted in implementation of a multitude of standard services such as electronic mail, filing and directory services. The communication facilities for these services have been defined via a layered interconnection architecture which now forms the most mature part of the OS1 reference model. *This paper reflects the personal views of the author, which should not be interpreted as ECMA’s position on the security of distributed systems.
0167-4048/89/$3.50
The entire complex of computers, communication facilities and networks is termed a distributed system. As long as all components of the distributed system are used by a single department or organization, one system owner and his staff, including a security administrator, can manage the entire system. However, if parts are owned by independent departments or different organizations, matters become more complicated. One must then define security domains reflecting the ownership of particular resources such as terminals, network connections, processors, disks, tape drives and data. In order to allow interactions between these domains, common subsets of functions are defined containing those inter-domain operations applicable to groups of domains. In the absence of a higher security authority, domain cooperation must be negotiated bilaterally between the owners of domains. As soon as the resulting agreement becomes binding, it establishes a legal framework which can be used to indict parties violating the agreed rules. One of the binding agreements is, for example, the standard IS0 8730 used for high value electronic funds transfers. When dealing with distributed systems, one must define adequate measures to fulfil privacy requirements and to guarantee the security, integrity and confidentiality of both data and data processin . Moreover, one also needs commonly applicab He terms of reference allowing effective negotiations on security aspects. The security of distributed systems is an extremely complex issue and we still lack off-the-shelf solutions. A first step towards secure distributed systems is drafting a reference
0 1989, Elsevier Science Publishers Ltd.
139
J. P. KruyslSecurity
of Open Systems
the end systems (the computers) and the applications (both private and public). Each of these components has an owner, a number of users and a security policy which covers issues such as security domain partitioning and access control requirements. An organizational grouping of distributed components is termed a security domain and is controlled by a security administrator. The relation between security domains is very similar to the relation between organizational entities involved in distributed processing. As shown in Fig. 1, a network may be represented by a network security domain which connects all end systems. Each of these end systems, owned by a group or a department, can be seen as an end system security domain, and may be further divided in subdomains each containing one or more applications.
model for security as an enhancement to the OS1 reference model. In order to avoid confusion on nomenclature, WC will refer to this security reference model as the security framework. Task Group 9 of ECMA’s Technical Committee 32 started to develop such a framework in 1986. It aims to establish a secure, distributed processing and data exchange cnvironmcnt for the execution of private applications and for public services such as electronic mail, filing, directory services and data retrieval [5, 61. In principle, this framework is based on two concepts, security domains and security facilities. These two concepts arc outlined below, thus drafting a common basis for the development of security models for specific systems. 2. The Security
Domain
The network security domain deals with the security aspects common to all end systems and
The major components of a distributed system arc the network connections including the gateways,
End
System
Security
Domain
Application A
X
End System X
Application B
Application Security Application Security pi
F/
End System End System
Domain Y
Domain Z
I I
I
Network Security Domain Gateway ,
WIDE AREA NETWORK Fig. 1. Different
140
LOCAL AREA NETWORK
types of security domains in a distributed environment.
Computers and Securiv,
applications, and to their data exchange activities. Particular elements of network control may be delegated to one or more individual end systems which then act as representatives of the network owner. The security policy of the network is principally directed towards controlled access to objects at the network level such as end systems and applications, and towards securing the data flow between these objects.
Each end system domain may have its own, local objects such as applications, public services, system software and data sets, controlled in accordance with a local security policy. While each given subject or object is owned by a single domain, it might be used by a number of domains as part of a resource-sharing policy.
NETWORK VIEW
Vol. 8, No. 2
If necessary, a further division may be established by defining application security domains, each containin one or more applications and dealing with the a ow of data between them. In the current paper, the name application is also used for public services such as compilers, electronic mail software and other generally applicable servers. To quote but one example, in the case of a database application, the domain policy will cover the type of transactions available to a given user, the set of individual data items which he may retrieve or‘ modify, and rules for transferring this data to other applications, servers and printers within the same domain. The scope of the ECMA framework is limited to the network security domain. As shown in Fig. 2, the security policy at the network level deals with
APPLICATION
END-SYSTEM VIEW
VIEW
SUBJECT: User with specified access authorities SUBJECT:
SUBJECT: End system application)
(or
‘data
sets
Application
or
data
->
Access
requirements
Data item or data exchange activity Fig. 2. An example of three levels of security policies: each object may be a security domain which, in its turn, may contain domains. Note: the end system level is optional, in some cases the user may directly enter the application level.
sub-
141
J. P. KruyslSecurity
of Open Systems
subjects - the users - and their specified authorities, with the end system or application access requirements, and with the objects - both end systems and applications. All lower levels are considered to be the principal responsibility of the designers of these end systems, services and applications. It is obvious that the lower level policies must be subordinate to the overall architecture as provided by the ECMA framework.
3. The Security
Facilities
Security is not an entity, but a combination of functions, processes, procedures and resources. Using decomposition, the ECMA framework breaks down “security” into a set of indivisible, logically complete elements termed security facilities. (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
authentication association management security state access authorization security attributes inter-domain security audit security recovery cryptographic support subject sponsor
The advantage of using these elementary facilities is that each of them can be specified exactly and independently of their use in a given system. They thus become building blocks to be used in designing secure systems. 3.1 Authentication Facility Once a user attempts to establish a session with an end system or an application, he must identify himself by entering his user identification (user-id). In order to verify whether he is really,the owner of this userid, an authentication facility (AF) is required. A simple example is the password check More sophisticated schemes are, for example, a challenge and response exchange supplemented by biometric information. Other approaches use chip cards [9] or one-time password generators.
142
In a network the authentication function may be delegated to a single network node acting as the authentication server. As an alternative, the function may be distributed over a number of nodes or over all nodes. In some networks, no network security is provided and the check must be integrated into the end systems and applications. If the user has to interact with more than one application, it is required, for reasons of both userfriendliness and security, to unify the authentication function [8]. Leading the user through a set of different or similar authentication procedures when accessing multiple end systems and applications should be avoided (see Fig. 3). This requirement obviously extends beyond the scope of a single security domain: when accessing a peer domain the user should not have to go through the other domain’s authentication procedure, but the originating domain should inform the destination domain about the successfully performed authentication during the initial log-on. The desire for unification points to the need to formalize the procedures and implies a formalization of the interaction between AF and the other security facilities. 3.2 Association Management Facility
A user’s only purpose when accessing a network is to create, via this network, a session with a selected end system or application. In order to limit the number of eligible end systems and applications to only those for which he is explicitly authorized, we introduce the association management facility (AMF) (see Fig. 4). This facility takes both the authenticated userid and the name of the end system or application as input and then verifies, with the aid of the access authorization facility, whether the access request should be granted. Additional input is obtained from the security attribute facility, such as the access rights (clearance) of the user and the security requirements for both the requested destination and the path to it. For instance, the user might be entitled to use a requested application, but is not allowed to access it from his current terminal which is located in an
Computers and Security, Vol. 8, No. 2
Authentication >- Facility
User
>i End System ABC
Fig. 3. Common authentication for access to multiple destinations: different end systems, private applications and public services.
only
one authentication
1
facility
is involved
in accessing
I
User-Communication Facility
.Communicationsecure association Facility Fig. 4. Management
areawithout access limitation and is connected via a non-encrypted line. Only if the user goes to a terminal in a secure area connected via an encrypted line, is he allowed to enter the application. It should be noted that AMF may also support the user by providing end-to-end authentication information to the application with which the association has been established. The protocol elements required for this authentication process
of secure associations.
may well bc carried via the association protocol which is integrated into the reference model for starting a session between two parties. In this context, the reference model does not differentiate between users and applications, so allowing both user-user, user-application and application-application sessions. Another major function of AMF is to assure that the appropriate communication security functions such as encryption are applied to the association.
143
J. P. Kru yslSecurity of Open Systems
3.3 Security State Facility
The current situation of the security domains is continuously reflected by the security state facility (SSF) which records the current “security state.” SSF provides an overview of all security-related activities since it always reflects the current situation (in contrast to the security audit facility which records what has happened), and its information is used by some other security facilities. For example, if a user starts a session, the fact that he has been authenticated is recorded by the authentication facility in SSF, so allowing other facilities to use this information. For example, the association management facility may ask SSF for this information during its association verification process. In fact, SSF represents an abstraction of reality. In actual implementations, the information constituting the security state of the entire system is spread over a domain. This highlights a major problem in protecting distributed systems, namely synchronization between the independent distributed processes. The exchange of security state information is a function of all security processes that together form the distributed security system.
The AAF models a function which is used by other security facilities, by end system functions and by applications. The management of AAF requires specific rule definitions and a protocol for their distribution and for synchronization of their use. 3.5 Security Attributes Facility
The separation between security attributes and them requires a dedicated rules for handlin security attributes I!acility (SAF). Security attributes d&e the characteristics of the subjects and the objects they relate to; they span a spectrum that ranges from complex capabilities issued to subjects to simple access control lists. A unification of the extremes of the attribute spectrum uses “privilege attributes” for subjects and “control attributes” for objects. Both may have secondary attributes such as type of access, context of access etc. Conceptually, SAF acts as a repository for attributes and provides services such as generation, storage, modification, distribution, deactivation and archiving of attributes. The fact that these security attributes are used throughout the entire network makes SAF a distributed process using specific protocols for distributing and managing the attributes.
3.4 Access Authorization Facility
The access authorization facility (AAF) embodies the rules for taking access control decisions using the “security attributes” presented to it. The authorization rules must be separated from the attributes on which they operate, especially because rules tend to change slowly whereas the attributes may change relatively quickly. Hence, the management of rules is quite different from that of attributes. Access authorization takes place at multiple levels such as at the network level, the end system level and the application level. At each of these levels, one may have to deal with different rules. For instance, the network can apply a mandatory policy using subject roles and levels of authorization, while the application uses a discretionary policy thus allowing users to control the objects they own.
144
It should be noted that security attributes are protected objects which can be accessed for, e.g. retrieve and change purposes. Such accesses must be controlled, thus implying that these attributes have their own security attributes. The implied recursion stops where an attribute refers to itself.
3.6 Inter-domain Facility
If two domains have to exchange data, an interdomain session must be established which is controlled by the inter-domain facility (IDF). This allows one domain to use security attributes understood by another domain, or to use mappings of them. The major function of IDF is to implement the “agreement” on security policy between two domains and to control all exchanges of security data between domains. For instance, if a user in
Computers and Security, Vol. 8, No. 2
domain ABC wants to access an application located in domain XYZ and he has been authenticated within ABC, the IDF of domain ABC may pass the result of this authentication process to domain XYZ (see Fig. 5). One should note that each domain has its own IDF and that in each intcrdomain operation two IDFs are involved. Each IDF implements its own domain’s policy supplemented by some or all of the common inter-domain policies. A widely accepted set of security attributes and a syntax for their exchange arc required to allow interaction between open systems located in different security domains. The implication of incompatible rules and incompatible techniques for, for example, auditing and recovery needs further investigation. 3.7 Security
Audit
Facility
In addition to the short-term memory of the security state facility, a long-term memory has been defined, permanently recording all security cvcnts for immediate or later analysis and report-
-J DOPI
ing. It is termed the security audit facility (SAF). This facility is principally a tool for the security administrator to verify the proper operation of all other security facilities. The SAF models the collection and processing of audit data as well as the management mechanisms for controlling the audit process. This includes specification, distribution and modification of rules for events to be rccordcd, rules for processing the audit data, and rules for generating alerts and reports. Inspection of audit data may reveal potential breaches of security, integrity and privacy so that appropriate action may be taken promptly. If performed in real time, the results are passed to the security recovery facility (see Fig. 6) so that fast, automated recovery becomes possible. Access to audit data must be subject to strict access control -not even a security auditor should be able to change it. The SAF has its own protocol for exchanging audit data and for distributing management information. A high degree of standardization is required for the format and con-
--IDOMAIN
Fig. 5. Inter-domain
interactions
via the inter-domain
B
facility.
J. P. Km yslSecurity
of Open Systems
other data related to security management, authentication, protection of audit data etc. The cryptographic support facility (CSF) provides services such as encryption, decryption, integrity verification, message authentication, non-repudiation and the management of cryptographic keys [ 121. 3.10 corrective act ion
Facilit;
I I I
Fig. 6. Interactions of the security audit facility.
tents of audit records and for the exchange protocol in order to guide system developers, users developing their own audit mechanisms and application developers. 3.8 Security
Recovery
Facility
A set of pre-determined rules are specified by the security administrator about how to react to any (suspected) breach of security and how to recover thereafter. These rules arc entered into the security recovery facility (SRF). In the same way as a network can recover from loss of a link or gateway, a secure system can recover from a security breach. For instance, assume that a suspect access to a data set of the accounting department is detected. All accesses to these data sets can now be blocked until the owner can be identified and all conditions have been investigated by, for example, further inspection of audit records. Then normal operation can be resumed. This example highlights the difference between recovery - which represents a temporary, automated action - and policy management: some classes of breaches may require permanent policy changes which are not automatically implemented via SRF, but through intervention of the security administrator via changing attributes and rules in, for example, the security attribute facility. 3.9 Cryptographic
Support
Facility
Cryptography is widely used in secure systems to protect information. In addition, it may be applied to protect the distribution of security attributes and
146
Subject
Sponsor
Facility
One aspect not yet addressed is the way in which users and applications interact with the security facilities. The fact that each user may access concurrently more than one application requires special provisions. For instance, automatic log-off triggered by an application now becomes impossible since this application does not know in which other applications the user is still active. A similar problem arises with automated re-authentication during the course of a session. Both activities must now be initiated by a mechanism which is common to all applications. In the ECMA framework, this common function is modeled by the subject sponsor facility (SSF), which mediates all user interactions with the system and performs common user-monitoring functions. Through a management interface, timers may be set for automated log-off and reauthentication. In addition, it handles the initial dialogue between the user and the security facilities during the authentication and association process. Also, it may need to protect user credentials during the log-on phase. 4. Architectural
Synthesis
The ECMA framework can be understood as a secure environment which enforces separation between users, applications, application data and end system functions such as access to storage, data sets and communication facilities. In this way, a “shell” of security facilities has been defined. Which functions actually arc implemented in a particular shell is a matter of local policy and of the policies of these domains with which an interaction occurs. The security facilities must be uniform across a network both in the functionality they
Computers and Security, Vol. 8, No. 2
offer and in the way they interact. Since the security services themselves are distributed, one needs protocols for their interaction and for exchange of security attributes. Such protocols must be described in terms of the OS1 reference model (see refs. [3, 41). This synthesis thus provides a security framework as a first step to the actual implementation secure open systems.
of
No system should be trusted if its desi n cannot be evaluated and if the effectiveness o I! its security measures cannot be tested. For this reason, security functions and protocols should be kept simple and compact. By means of formal specification of interfaces and protocols we can assure interoperability (openness) between different implementations and formal verification of its efficacy becomes possible
PI.
Acknowledgments This paper is based on the work of ECMA TC32/ TG9. The participants who contributed to the concepts presented are Kare Presstun (Alcatel STK), Dave Roberts (British Telecom), Brian Robson (Digital Equipment), Robert Cole (Hewlett Packard), Dcnis Pinkas (Honeywell Bull), Tom Parker (ICL), Jan Kruys (NCR), Per Kaijser (Siemens), Stefan Hellberg (Swedish Telecom) and Denis Brink (Xerox).
References
[ll DOD
trusted computer evaluation criteria, U.S. Department of Defense, lY83, Rep. CSC-STD-001-83. Electronic funds transfer and securities transfer policy message authentication, U.S. Department of the Treasury, 1984. 131Information processing systems - OS1 rcfcrence model, IS0 International Standard 7498/t. Information processing systems - OS1 reference model part 2, security architecture, IS0 Draft Proposal 7498/Z. Open systems interconnection, management framework, ECMA Rep. 7R3 7, December 1986. Security in open systems, a security framework, ECMA Rep. TR46, August 1988.
PI
PI Fl
PI
(For further reading see) [7] E. Amsel, Network security and access controls, Compur. Secur., 7 (I) (1988) 53-57. [8] J. P. Anderson, A unification of computer and network security concepts, Proc. 1985 Symp. on Security and Privacy, Oakland, CA, IEEE, 1985 pp. 77-87 (ISBN 0-81860629-0). [9] K. Rihaczek, TclcTrusT-OSIS and communication security, Comput. Secur., 6 (3) (1987) 206-2 18. [lo] J. Rushby, Networks are systems, a discussion paper, Tutorial Computer and Network Security, by M. D. Abrams and H. J. Podcll, IEEE, lY86, pp. 300-316 (ISBN 0-81860756-4). Ill] W. Stallings, Local Networks, an Introduction, Macmillan, 2nd edn., 1987 (ISBN o-02-41 5520-9). [ 121 S. T. Walker, Network security overview, Proc. 1985 Symp. on Security and Privacy, Oakland, CA, IEEE, 1985, pp. 62-76 (ISBN O-8 186-0620-O).
/ Jan P. Kruys is a senior consultant at NCR Corporation. He has an Associate Degree in computer engineering and has held a number of development and consultant positions within NCR in fields such as communication engineering, public data networks, EFT/POS and computer security. He is chairman of ECMA TC32/TGY, and participates in ANSI XY and IS0 SC21 committees on security.
147
& Security,
8 (1989) 139-147
Refereed Article
Security of Open Systems Jan P. Kruys* NCR Corporalion, Nieuwegein, The Netherlands
As an enhancement to ISo’s Open Systems Interconnection Reference Model, ECMA defines a security framework for distributed systems which is based on the concepts of security domains and security facilities. This paper describes a functional decomposition of the security of distributed systems, thus providing building blocks which can be specified and analysed in detail and can be used to establish a secure distributed processing environment for both private application software and public communication services such as electronic mail. The aim is to achieve both interoperability (openness) and a high level of confidence. Keywords: Distributed tecture, 0%.
1. Sea
processing, Open systems, Security archi-
‘ty of Open Systems
T
he International Standards Organization (ISO) started the development of a set of standards for open systems some IO years ago. This set has been based on the Open Systems Interconnection (OSI) reference model [3, 4, 1 l]. The parties involved in developing the standards were the IS0 Technical Committee TC97, the European Computer Manufacturers Association (ECMA) TC32, and the CCITT SG VII. Currently, the OS1 reference model has been accepted by many major manufacturers and has resulted in implementation of a multitude of standard services such as electronic mail, filing and directory services. The communication facilities for these services have been defined via a layered interconnection architecture which now forms the most mature part of the OS1 reference model. *This paper reflects the personal views of the author, which should not be interpreted as ECMA’s position on the security of distributed systems.
0167-4048/89/$3.50
The entire complex of computers, communication facilities and networks is termed a distributed system. As long as all components of the distributed system are used by a single department or organization, one system owner and his staff, including a security administrator, can manage the entire system. However, if parts are owned by independent departments or different organizations, matters become more complicated. One must then define security domains reflecting the ownership of particular resources such as terminals, network connections, processors, disks, tape drives and data. In order to allow interactions between these domains, common subsets of functions are defined containing those inter-domain operations applicable to groups of domains. In the absence of a higher security authority, domain cooperation must be negotiated bilaterally between the owners of domains. As soon as the resulting agreement becomes binding, it establishes a legal framework which can be used to indict parties violating the agreed rules. One of the binding agreements is, for example, the standard IS0 8730 used for high value electronic funds transfers. When dealing with distributed systems, one must define adequate measures to fulfil privacy requirements and to guarantee the security, integrity and confidentiality of both data and data processin . Moreover, one also needs commonly applicab He terms of reference allowing effective negotiations on security aspects. The security of distributed systems is an extremely complex issue and we still lack off-the-shelf solutions. A first step towards secure distributed systems is drafting a reference
0 1989, Elsevier Science Publishers Ltd.
139
J. P. KruyslSecurity
of Open Systems
the end systems (the computers) and the applications (both private and public). Each of these components has an owner, a number of users and a security policy which covers issues such as security domain partitioning and access control requirements. An organizational grouping of distributed components is termed a security domain and is controlled by a security administrator. The relation between security domains is very similar to the relation between organizational entities involved in distributed processing. As shown in Fig. 1, a network may be represented by a network security domain which connects all end systems. Each of these end systems, owned by a group or a department, can be seen as an end system security domain, and may be further divided in subdomains each containing one or more applications.
model for security as an enhancement to the OS1 reference model. In order to avoid confusion on nomenclature, WC will refer to this security reference model as the security framework. Task Group 9 of ECMA’s Technical Committee 32 started to develop such a framework in 1986. It aims to establish a secure, distributed processing and data exchange cnvironmcnt for the execution of private applications and for public services such as electronic mail, filing, directory services and data retrieval [5, 61. In principle, this framework is based on two concepts, security domains and security facilities. These two concepts arc outlined below, thus drafting a common basis for the development of security models for specific systems. 2. The Security
Domain
The network security domain deals with the security aspects common to all end systems and
The major components of a distributed system arc the network connections including the gateways,
End
System
Security
Domain
Application A
X
End System X
Application B
Application Security Application Security pi
F/
End System End System
Domain Y
Domain Z
I I
I
Network Security Domain Gateway ,
WIDE AREA NETWORK Fig. 1. Different
140
LOCAL AREA NETWORK
types of security domains in a distributed environment.
Computers and Securiv,
applications, and to their data exchange activities. Particular elements of network control may be delegated to one or more individual end systems which then act as representatives of the network owner. The security policy of the network is principally directed towards controlled access to objects at the network level such as end systems and applications, and towards securing the data flow between these objects.
Each end system domain may have its own, local objects such as applications, public services, system software and data sets, controlled in accordance with a local security policy. While each given subject or object is owned by a single domain, it might be used by a number of domains as part of a resource-sharing policy.
NETWORK VIEW
Vol. 8, No. 2
If necessary, a further division may be established by defining application security domains, each containin one or more applications and dealing with the a ow of data between them. In the current paper, the name application is also used for public services such as compilers, electronic mail software and other generally applicable servers. To quote but one example, in the case of a database application, the domain policy will cover the type of transactions available to a given user, the set of individual data items which he may retrieve or‘ modify, and rules for transferring this data to other applications, servers and printers within the same domain. The scope of the ECMA framework is limited to the network security domain. As shown in Fig. 2, the security policy at the network level deals with
APPLICATION
END-SYSTEM VIEW
VIEW
SUBJECT: User with specified access authorities SUBJECT:
SUBJECT: End system application)
(or
‘data
sets
Application
or
data
->
Access
requirements
Data item or data exchange activity Fig. 2. An example of three levels of security policies: each object may be a security domain which, in its turn, may contain domains. Note: the end system level is optional, in some cases the user may directly enter the application level.
sub-
141
J. P. KruyslSecurity
of Open Systems
subjects - the users - and their specified authorities, with the end system or application access requirements, and with the objects - both end systems and applications. All lower levels are considered to be the principal responsibility of the designers of these end systems, services and applications. It is obvious that the lower level policies must be subordinate to the overall architecture as provided by the ECMA framework.
3. The Security
Facilities
Security is not an entity, but a combination of functions, processes, procedures and resources. Using decomposition, the ECMA framework breaks down “security” into a set of indivisible, logically complete elements termed security facilities. (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
authentication association management security state access authorization security attributes inter-domain security audit security recovery cryptographic support subject sponsor
The advantage of using these elementary facilities is that each of them can be specified exactly and independently of their use in a given system. They thus become building blocks to be used in designing secure systems. 3.1 Authentication Facility Once a user attempts to establish a session with an end system or an application, he must identify himself by entering his user identification (user-id). In order to verify whether he is really,the owner of this userid, an authentication facility (AF) is required. A simple example is the password check More sophisticated schemes are, for example, a challenge and response exchange supplemented by biometric information. Other approaches use chip cards [9] or one-time password generators.
142
In a network the authentication function may be delegated to a single network node acting as the authentication server. As an alternative, the function may be distributed over a number of nodes or over all nodes. In some networks, no network security is provided and the check must be integrated into the end systems and applications. If the user has to interact with more than one application, it is required, for reasons of both userfriendliness and security, to unify the authentication function [8]. Leading the user through a set of different or similar authentication procedures when accessing multiple end systems and applications should be avoided (see Fig. 3). This requirement obviously extends beyond the scope of a single security domain: when accessing a peer domain the user should not have to go through the other domain’s authentication procedure, but the originating domain should inform the destination domain about the successfully performed authentication during the initial log-on. The desire for unification points to the need to formalize the procedures and implies a formalization of the interaction between AF and the other security facilities. 3.2 Association Management Facility
A user’s only purpose when accessing a network is to create, via this network, a session with a selected end system or application. In order to limit the number of eligible end systems and applications to only those for which he is explicitly authorized, we introduce the association management facility (AMF) (see Fig. 4). This facility takes both the authenticated userid and the name of the end system or application as input and then verifies, with the aid of the access authorization facility, whether the access request should be granted. Additional input is obtained from the security attribute facility, such as the access rights (clearance) of the user and the security requirements for both the requested destination and the path to it. For instance, the user might be entitled to use a requested application, but is not allowed to access it from his current terminal which is located in an
Computers and Security, Vol. 8, No. 2
Authentication >- Facility
User
>i End System ABC
Fig. 3. Common authentication for access to multiple destinations: different end systems, private applications and public services.
only
one authentication
1
facility
is involved
in accessing
I
User-Communication Facility
.Communicationsecure association Facility Fig. 4. Management
areawithout access limitation and is connected via a non-encrypted line. Only if the user goes to a terminal in a secure area connected via an encrypted line, is he allowed to enter the application. It should be noted that AMF may also support the user by providing end-to-end authentication information to the application with which the association has been established. The protocol elements required for this authentication process
of secure associations.
may well bc carried via the association protocol which is integrated into the reference model for starting a session between two parties. In this context, the reference model does not differentiate between users and applications, so allowing both user-user, user-application and application-application sessions. Another major function of AMF is to assure that the appropriate communication security functions such as encryption are applied to the association.
143
J. P. Kru yslSecurity of Open Systems
3.3 Security State Facility
The current situation of the security domains is continuously reflected by the security state facility (SSF) which records the current “security state.” SSF provides an overview of all security-related activities since it always reflects the current situation (in contrast to the security audit facility which records what has happened), and its information is used by some other security facilities. For example, if a user starts a session, the fact that he has been authenticated is recorded by the authentication facility in SSF, so allowing other facilities to use this information. For example, the association management facility may ask SSF for this information during its association verification process. In fact, SSF represents an abstraction of reality. In actual implementations, the information constituting the security state of the entire system is spread over a domain. This highlights a major problem in protecting distributed systems, namely synchronization between the independent distributed processes. The exchange of security state information is a function of all security processes that together form the distributed security system.
The AAF models a function which is used by other security facilities, by end system functions and by applications. The management of AAF requires specific rule definitions and a protocol for their distribution and for synchronization of their use. 3.5 Security Attributes Facility
The separation between security attributes and them requires a dedicated rules for handlin security attributes I!acility (SAF). Security attributes d&e the characteristics of the subjects and the objects they relate to; they span a spectrum that ranges from complex capabilities issued to subjects to simple access control lists. A unification of the extremes of the attribute spectrum uses “privilege attributes” for subjects and “control attributes” for objects. Both may have secondary attributes such as type of access, context of access etc. Conceptually, SAF acts as a repository for attributes and provides services such as generation, storage, modification, distribution, deactivation and archiving of attributes. The fact that these security attributes are used throughout the entire network makes SAF a distributed process using specific protocols for distributing and managing the attributes.
3.4 Access Authorization Facility
The access authorization facility (AAF) embodies the rules for taking access control decisions using the “security attributes” presented to it. The authorization rules must be separated from the attributes on which they operate, especially because rules tend to change slowly whereas the attributes may change relatively quickly. Hence, the management of rules is quite different from that of attributes. Access authorization takes place at multiple levels such as at the network level, the end system level and the application level. At each of these levels, one may have to deal with different rules. For instance, the network can apply a mandatory policy using subject roles and levels of authorization, while the application uses a discretionary policy thus allowing users to control the objects they own.
144
It should be noted that security attributes are protected objects which can be accessed for, e.g. retrieve and change purposes. Such accesses must be controlled, thus implying that these attributes have their own security attributes. The implied recursion stops where an attribute refers to itself.
3.6 Inter-domain Facility
If two domains have to exchange data, an interdomain session must be established which is controlled by the inter-domain facility (IDF). This allows one domain to use security attributes understood by another domain, or to use mappings of them. The major function of IDF is to implement the “agreement” on security policy between two domains and to control all exchanges of security data between domains. For instance, if a user in
Computers and Security, Vol. 8, No. 2
domain ABC wants to access an application located in domain XYZ and he has been authenticated within ABC, the IDF of domain ABC may pass the result of this authentication process to domain XYZ (see Fig. 5). One should note that each domain has its own IDF and that in each intcrdomain operation two IDFs are involved. Each IDF implements its own domain’s policy supplemented by some or all of the common inter-domain policies. A widely accepted set of security attributes and a syntax for their exchange arc required to allow interaction between open systems located in different security domains. The implication of incompatible rules and incompatible techniques for, for example, auditing and recovery needs further investigation. 3.7 Security
Audit
Facility
In addition to the short-term memory of the security state facility, a long-term memory has been defined, permanently recording all security cvcnts for immediate or later analysis and report-
-J DOPI
ing. It is termed the security audit facility (SAF). This facility is principally a tool for the security administrator to verify the proper operation of all other security facilities. The SAF models the collection and processing of audit data as well as the management mechanisms for controlling the audit process. This includes specification, distribution and modification of rules for events to be rccordcd, rules for processing the audit data, and rules for generating alerts and reports. Inspection of audit data may reveal potential breaches of security, integrity and privacy so that appropriate action may be taken promptly. If performed in real time, the results are passed to the security recovery facility (see Fig. 6) so that fast, automated recovery becomes possible. Access to audit data must be subject to strict access control -not even a security auditor should be able to change it. The SAF has its own protocol for exchanging audit data and for distributing management information. A high degree of standardization is required for the format and con-
--IDOMAIN
Fig. 5. Inter-domain
interactions
via the inter-domain
B
facility.
J. P. Km yslSecurity
of Open Systems
other data related to security management, authentication, protection of audit data etc. The cryptographic support facility (CSF) provides services such as encryption, decryption, integrity verification, message authentication, non-repudiation and the management of cryptographic keys [ 121. 3.10 corrective act ion
Facilit;
I I I
Fig. 6. Interactions of the security audit facility.
tents of audit records and for the exchange protocol in order to guide system developers, users developing their own audit mechanisms and application developers. 3.8 Security
Recovery
Facility
A set of pre-determined rules are specified by the security administrator about how to react to any (suspected) breach of security and how to recover thereafter. These rules arc entered into the security recovery facility (SRF). In the same way as a network can recover from loss of a link or gateway, a secure system can recover from a security breach. For instance, assume that a suspect access to a data set of the accounting department is detected. All accesses to these data sets can now be blocked until the owner can be identified and all conditions have been investigated by, for example, further inspection of audit records. Then normal operation can be resumed. This example highlights the difference between recovery - which represents a temporary, automated action - and policy management: some classes of breaches may require permanent policy changes which are not automatically implemented via SRF, but through intervention of the security administrator via changing attributes and rules in, for example, the security attribute facility. 3.9 Cryptographic
Support
Facility
Cryptography is widely used in secure systems to protect information. In addition, it may be applied to protect the distribution of security attributes and
146
Subject
Sponsor
Facility
One aspect not yet addressed is the way in which users and applications interact with the security facilities. The fact that each user may access concurrently more than one application requires special provisions. For instance, automatic log-off triggered by an application now becomes impossible since this application does not know in which other applications the user is still active. A similar problem arises with automated re-authentication during the course of a session. Both activities must now be initiated by a mechanism which is common to all applications. In the ECMA framework, this common function is modeled by the subject sponsor facility (SSF), which mediates all user interactions with the system and performs common user-monitoring functions. Through a management interface, timers may be set for automated log-off and reauthentication. In addition, it handles the initial dialogue between the user and the security facilities during the authentication and association process. Also, it may need to protect user credentials during the log-on phase. 4. Architectural
Synthesis
The ECMA framework can be understood as a secure environment which enforces separation between users, applications, application data and end system functions such as access to storage, data sets and communication facilities. In this way, a “shell” of security facilities has been defined. Which functions actually arc implemented in a particular shell is a matter of local policy and of the policies of these domains with which an interaction occurs. The security facilities must be uniform across a network both in the functionality they
Computers and Security, Vol. 8, No. 2
offer and in the way they interact. Since the security services themselves are distributed, one needs protocols for their interaction and for exchange of security attributes. Such protocols must be described in terms of the OS1 reference model (see refs. [3, 41). This synthesis thus provides a security framework as a first step to the actual implementation secure open systems.
of
No system should be trusted if its desi n cannot be evaluated and if the effectiveness o I! its security measures cannot be tested. For this reason, security functions and protocols should be kept simple and compact. By means of formal specification of interfaces and protocols we can assure interoperability (openness) between different implementations and formal verification of its efficacy becomes possible
PI.
Acknowledgments This paper is based on the work of ECMA TC32/ TG9. The participants who contributed to the concepts presented are Kare Presstun (Alcatel STK), Dave Roberts (British Telecom), Brian Robson (Digital Equipment), Robert Cole (Hewlett Packard), Dcnis Pinkas (Honeywell Bull), Tom Parker (ICL), Jan Kruys (NCR), Per Kaijser (Siemens), Stefan Hellberg (Swedish Telecom) and Denis Brink (Xerox).
References
[ll DOD
trusted computer evaluation criteria, U.S. Department of Defense, lY83, Rep. CSC-STD-001-83. Electronic funds transfer and securities transfer policy message authentication, U.S. Department of the Treasury, 1984. 131Information processing systems - OS1 rcfcrence model, IS0 International Standard 7498/t. Information processing systems - OS1 reference model part 2, security architecture, IS0 Draft Proposal 7498/Z. Open systems interconnection, management framework, ECMA Rep. 7R3 7, December 1986. Security in open systems, a security framework, ECMA Rep. TR46, August 1988.
PI
PI Fl
PI
(For further reading see) [7] E. Amsel, Network security and access controls, Compur. Secur., 7 (I) (1988) 53-57. [8] J. P. Anderson, A unification of computer and network security concepts, Proc. 1985 Symp. on Security and Privacy, Oakland, CA, IEEE, 1985 pp. 77-87 (ISBN 0-81860629-0). [9] K. Rihaczek, TclcTrusT-OSIS and communication security, Comput. Secur., 6 (3) (1987) 206-2 18. [lo] J. Rushby, Networks are systems, a discussion paper, Tutorial Computer and Network Security, by M. D. Abrams and H. J. Podcll, IEEE, lY86, pp. 300-316 (ISBN 0-81860756-4). Ill] W. Stallings, Local Networks, an Introduction, Macmillan, 2nd edn., 1987 (ISBN o-02-41 5520-9). [ 121 S. T. Walker, Network security overview, Proc. 1985 Symp. on Security and Privacy, Oakland, CA, IEEE, 1985, pp. 62-76 (ISBN O-8 186-0620-O).
/ Jan P. Kruys is a senior consultant at NCR Corporation. He has an Associate Degree in computer engineering and has held a number of development and consultant positions within NCR in fields such as communication engineering, public data networks, EFT/POS and computer security. He is chairman of ECMA TC32/TGY, and participates in ANSI XY and IS0 SC21 committees on security.
147