Abstract

Many organizations have a need to conduct security assessments and develop security architectures. It was recognized that a structured approach is needed. The Department of Defense Goal Security Architecture (DGSA) was already developed through considerable effort by knowledgeable security professionals. Our approach was to tailor the DGSA to fit many enterprise information system security profiles and meet the requirements of multiple organizations. This paper shows how the DGSA was applied across multiple program types, and demonstrate how it can be used for a wide variety of security tasks.

1. lntroduction

During the course of assisting organizations in working out the details of security assessments, security planning and security architectures for their enterprise information systems, it was evident that nearly everyone was struggling to find a structured approach to Security Architecture Development. These organizations needed system/enterprise security development and integration. They also had similar requirements and the services and mechanisms needed to satisfy these requirements were also similar. This was true across Government organizations, banks, other businesses and even research and development infrastructure programs.

Critical to the success of all our work was finding a systematic methodology for developing security architectures. We developed a number of requirements for this methodology, including the following:

1. It had to be applicable across a wide variety of information system architectures, to include client/server, mainframe based, and object oriented.
2. It had to provide a methodology for analyzing security requirements, developing security policies, and then determining where in the architecture security services were provided.
3. It had to be straight forward enough to be understood by our customer base of government and commercial organizations.

In each case it was evident that development of a home grown methodology would be rather expensive and was not practical due to the short time duration of most security assessment and architectural tasks, especially in the commercial sector. The DGSA was already developed. It was clear that the DGSA was developed through considerable effort by knowledgeable security professionals. The question to be answered was "could the DGSA be adapted as a general approach for a wide variety of security architecture and planning tasks?" We determined that the DGSA could be tailored to fit many enterprise information system security profiles and meet the requirements of multiple organizations.

1.1 Goals of Methodology

Early in our work we developed the following goals for a security architecture development methodology.

• The methodology should efficiently and effectively facilitate the development of an integrated security architectures and plans for enterprise networks.
• The methodology should facilitate an integrated solution across very complex heterogeneous information systems.
• The methodology must result in a final product that covers all customers requirements, policies and guidelines.
• The methodology must provide the customer with visibility into the process as well as the solutions.
• The methodology needs to facilitate incorporation of changes due to advances in technology and revisions of policies and guidelines.

1.2 Document Organization

This document is not meant to be a detailed examination of the DGSA. However, to aid in understanding our application of the DGSA, a short review of its structure and methodology is provided. This will set the stage for short discussions covering two security architecture projects where the DGSA was used as a methodology or model. These projects covered development of security architectures for two distinct organization/project types:

• The Distributed Object Computational Testbed (DOCT) R&D project jointly sponsored by DARPA and the Patent and Trademark Office (PTO)
• A major foreign financial institution.

2.0 DoD Goal Security Architecture (DGSA)

2.1 Description

The DGSA was developed as part of the Technical Architecture Framework for Information Management (TAFIM). In the DGSA four types of architectures were defined as follows:

Abstract Architecture which defines principles and fundamental concepts that guide the selection and organization of functions. This level of architecture cites principles, fundamental concepts and functions that satisfy the typical security requirements.

Generic Architecture which defines the general types of components and allowable standards to be used and identifies any necessary guidelines for their application.

Logical Architecture which is a design that meets a hypothetical set of requirements. It serves as a detailed example that illustrates the results of applying a generic architecture to specific circumstances.

Specific Architecture which addresses components, interfaces, standards, performance and cost. Specific architectures show how all the selected information security components and mechanisms combine to meet the security requirements of the systems under consideration.

2.2 Application of the DGSA

The DGSA provides a guide for system security architects in creating specific security architectures. We found that most tasks could begin with developing a Logical Security Architecture defining the security services and then allocating the security mechanisms to produce the Specific Security Architecture. This is because most of the organizations we support have an information system architecture so far advanced that no work is required on an Abstract Architecture. Also, we have not encountered a situation where the basic Generic Architecture, as defined in the DGSA, does not fit an organizations information system architecture.

The process is certainly not radically different from what would be used when following good engineering practices. However, the methodology adds a structured approach. First, data sensitivity, security requirements, security policies and organizational considerations are analyzed to develop the required security services. The security domains and domain policies are then developed and the services are assigned to each element within the domain. This results in the Logical Security Architecture.

In the next step security mechanisms are selected to provide the required services. The last step, which always proves to be the most difficult, is the integration of security mechanisms to meet the system and organizational requirements across all boundaries. This results in the Specific Security Architecture. A flow chart of the general methodology is shown in Figure 1.

2.3 Determination of Information Domains

Information domains are usually based on individuals and groups of people who create, collect, process, categorize, store, and transfer information in the normal course of performing their jobs. The sensitivity of the data is determined by the group and the protection is directed by established policies. Thus, conditions are placed on access to the information and the use of the information. Three elements are necessary for the concept of an information domain:

• A domain must have a defined membership
• Information objects must be uniquely identified within the domain
• The security policy regarding the protection of the information objects must be known and agreed to by the membership

An information domain is a set of users, their information objects, and a security policy. Information domains are not hierarchically related and do not necessarily imply a sensitivity category. Information domains are not bounded by systems or a network of systems. Information domains are bounded by the presence of the information objects and may be supported by any system that can meet the protection requirements of the information domain security policy.

Members of an information domain may have different security-relevant attributes. Some may have read-only permission, while others may have read and write privileges. Typically, all information objects in an information domain have the same security-relevant attributes. Thus, a user who has read and write permissions in an information domain usually has those permissions for every information object in the information domain.

Establishment of domains within an organizational structure can be difficult and is often somewhat arbitrary. However, it does provide a means for dealing with the diverse groups of people in an organization that have different security needs. These groups often use the same infrastructure for computer and communications services. Domains aid in the development of an architecture to accommodate the security needs of all groups within an organizational structure. Examples of how the domains were determined for two specific projects is included in this paper.

2.4 Description of Elements

The following element descriptions are taken from the DGSA and are provided here for the convenience of the reader. The individual elements are shown in Figure 2.

This basic structure is applicable to the vast majority of information system architectures. The elements as defined in the DGSA are:

Local Subscriber Environment (LSE): Include the devices and communications systems under user control. An LSE may contain a single end system such as a workstation or a complex interconnection of end systems and relay systems through local communications systems.

End System (ES): Consists of a single element such as a workstation, server, mainframe or supercomputer.

Local Communications System (LCS): Consists of the networks within an LSE.

Relay System (RS): Cconsists of communications devices such as network interface cards, multiplexers, routers, switches, cellular nodes and message transfer agents.

Communications Network (CN): Defines the communications network connecting the LSEs and may consist of networks entirely under control of the organization or include public communications entities such as the Internet.

Transfer Systems (TS): Can be viewed as the end-to-end application subsystems that make up the end-to-end transmission structure. The transfer system can be identified as the LCSs, CNs, and the communications protocols in end systems and relay systems.

The actual architecture structure can become extremely complex as multiple LSE's containing multiple ES,. LCS and RS elements are interconnected through multiple communications networks (CNs).

In the following sections of this paper we will demonstrate how the DGSA was applied to various security architecture development tasks. We will focus first on an advanced research and development project connecting supercomputer centers across the United States. Since the research is focused on the secure transfer of objects across a high speed test bed, the security issues involved provided very interesting research areas. A commercial banking architecture development project is also presented as another example of a DGSA application.

3.0 Application of DGSA for DOCT

Figure 3 shows the infrastructure of the Distributed Object Computational Test Bed (DOCT), the participating organizations and the physical connectivity. DOCT is sponsored jointly by the Defense Advanced Projects Agency (DARPA) and the U.S. Patent and Trademark Office (PTO). It is a broad agency research and development effort to advance the state-of-the-art in high performance computing, communications and complex document management. Its goal was to provided a basic high performance computing infrastructure useful to many organizations. It provides a high-performance infrastructure for use by organizations without the resources to build their own infrastructures. Basic connectivity between major sites is at OC3 (155 Mbps). Providing security at the object level within the environment was a major area of advanced research. Another was the practical application and demonstration of security mechanisms to protect the DOCT infrastructure.

3.2 Identification of Domains

Since the DOCT infrastructure could be useful to many different R&D efforts, the security architecture needed to accommodate a wide variety of requirements. At the present time the DOCT architecture calls for four Security Domains:

• Legal Document Processing Domain: This domain is focused on those applications where documents are submitted to government organizations and processed under a strict legal and regulatory framework. Research was initially focused on the security services and mechanisms required to protect patent applications as they were electronically filed and processed. It is important to state here that patent applications are not currently filed electronically, so all research under DOCT is carried out within the testbed and is focused on demonstrating how electronic filing could potentially be implemented. This is an example of applied research providing near term benefits to many government agencies during their modernization efforts. The research addressed documents that are very sensitive in nature and require strong security protection.
• Electronic Commerce Domain: This is another area where strong security measures are required. This is a promising research area needing a large computational test bed. It requires protection with strong confidentiality and integrity mechanisms. A separate domain was created for electronic commerce. This was done to allow separate research into the types of security mechanisms needed for advanced electronic commerce applications.
• Open Storage Domain: This domain includes data and users that do not require protection from strong security measures. However, objects in this domain must still be protected and require the use of security mechanisms to provide integrity and availability. Access control may not be highly restrictive, but the integrity of data objects must be insured and user activity may, in some instances, require audit services. Within the DOCT architecture, this domain contains the environmental data including models of the Chesapeake Bay and the coast line around San Diego.
• Restricted Storage Domain: This domain is required in DOCT to store and protect sensitive data objects separate from the sensitive documents processed within the first domain. This domain provides the capability to conduct research into the processing of defense related information within the DOCT architecture. At the present time the test bed only contains unclassified information, so this area of research was focused on security services and mechanisms without actually storing classified information. This domain will include strong authentication and access control mechanisms to enforce multiple levels of restrictions on user privileges.

3.3 Security Policies

A security policy for each domain was developed from a data sensitivity analysis for the domain. The policies were developed per the DGSA and provided the basic security service requirements levied against the security architecture. The security policy for the Legal Document Processing Domain is presented in Table 1.

3.3 Logical Architecture Services

The Generic Architecture defined for DOCT is shown in Figure 4. This Generic Architecture provided the framework for the development of the Logical Security Architecture across the diverse and complex DOCT infrastructure. The Logical Security Architecture was developed from Figure 4 by mapping security services required by the Security Policies to the major architecture elements of the Generic Architecture. Full consideration of each domain policy was needed during the Logical Architecture Development process. Within DOCT we had to accommodate the fact that many of the site resources allocated to DOCT Program were also shared resources within the participating organizations. For example, the supercomputer resources at SDSC and NCSA were not dedicated solely to DOCT. The basic rationale for allocation of security service to each architecture element are discussed below.

3.3.1 Communications Network (CN). The communications networks that support DOCT are outside the span of control of the participating organizations. The CN consists of multiple communications networks including ATDnet, AAInet and the Internet. It is not feasible to rely on these networks to provide any security services, and in the case of ATDnet availability is even in doubt. ATDnet is an experimental communications network and may be disrupted by advanced ATM experiments. CNs are not relied upon for either confidentiality or integrity of information transfers.

3.3.2 LSE Allocations. The protection of LSEs is accomplished by physical, administrative, and personnel security mechanisms. These services are left to the discretion of the individual DOCT participant organizations. However, due to the sensitive nature of the computing resources within the LSEs, these organizations provide strong physical access control to the computer areas.

3.3.3 LCS Allocations. Within the DoD environment the DGSA does not require any security service allocation to the LCS other than availability. This is to insure interoperability between widely dispersed DoD strategic and tactical sites. The model can be applied to similar conditions in the DOCT infrastructure. In the majority of cases, each LSE has an LCS that must support general applications within the organization. Therefore, the LCS can not be expected to provide a wide suite of security services. However, since each LCS is within the control of the individual organizations, these networks can be relied on to provide availability and integrity services.

3.3.4 RS Allocations. The relay systems within DOCT consist of the ATM network switches and Internet gateways. These elements can be expected to provide availability and integrity, but nothing more. In a production environment, these would be potential locations for link encryption devices. However, this is not a research area for DOCT.

3.3.5 ES Allocations. The end systems within DOCT, in conjunction with the transfer system architecture, provide the important security services. These are the elements under the control of the DOCT site managers. They provide security services to the specific DOCT applications. The end systems provide authentication, access control, confidentiality, integrity and availability services. The end systems are the point where much of the fault tolerance is implemented. Within the DOCT Security Architecture, Kerberos has been selected as one mechanism for cross-site authentication. Kerberos tickets are passed between domains and provided to the various end systems for their use in access control.

3.4 Transfer System Concept

Within DOCT, the transfer system takes on a unique perspective. DOCT uses Legion (the parallel processing object environment developed by the University of Virginia) as the object and processing management infrastructure. Legion can be considered a transfer system. In fact, it fits the model better than most other examples in the DGSA. Legion provides the ability to implement authentication and access control down to the object level. Confidentiality and integrity are provided through encryption of information transfers. The diverse nature of Legion makes it ideal for implementing flexible security concepts. Through Legion, authentication, access control, confidentiality, integrity and availability are allocated to the transfer system.

3.5 DOCT Security Service Mappings

The complete set of security services mappings across the DOCT distributed environment is still being completed and will be the subject of an advanced research report published by the Project Team. However, the work is well underway and the structure of the Logical Security Architecture can be seen by examining the data transfer between the ES's residing within two LSE's. Within the DOCT architecture each of the LSEs will appear much the same from the security services point-of-view. Therefore, examining the interrelationship of two LSE's will give the reader excellent insight into the complete Logical Security Architecture. (See Figure 5)

The end systems are responsible for enforcing the authentication and access control policies for all data objects within DOCT. The user and object authentication data required to implement these services are kept in a distributed meta-data catalog system. The meta-data catalog is based on the SDSC MDAS advanced research project, also under the sponsorship of DARPA. Legion provides the infrastructure needed to transfer throughout the DOCT infrastructure with confidentiality and integrity. On the end systems, confidentiality and integrity of the stored data is an end system responsibility.

Figure 5 shows that the security service allocations to the end systems, to Legion as it forms the transfer mechanism for the applications, and to the meta-data catalogs and associated directories. Allocations are based on the DGSA element view of the architecture.

In the flow of Figure 5, the initial authentication and access control is provided by the originating end system through the use of a Kerberos authentication server. Once the user is authenticated, the end system calls the meta-data catalog to locate the directory containing the user's access rights. This directory can be anywhere within the DOCT architecture. For example, the access rights of the personnel at SDSC are maintained by the SDSC security administrator. An end system at NCSA will need to query the SDSC directory to determine the access rights. This is the general case. However, in most instances it is expected that the access control directory will be at the site of the end system that initiates the application.

Legion, through its encryption function, provides confidentiality and integrity for data transmission through the DOCT infrastructure. The user's ticket is passed as a Legion object property. At the receiving site, the end system calls the meta-data catalog to determine where the appropriate access control directory resides. It then retrieves the user's access rights. This is expected to be part of the Legion security MayI() function which is run by each application before execution is allowed..

The basic elements of the Specific Security Architecture include Kerberos, directory based access control and object level encryption.

3.6 Mechanism Analysis and Selection

A complete discussion of the mechanism analysis and selection for all of DOCT is beyond the scope of this paper. It will be published in December 1997 as part of the DOCT research. However, it is useful to show an example of the results of this process. The example shown is for legal document transfer and processing. It provides an example of mechanism selection to provide secure transfer of data from outside the DOCT infrastructure to systems residing on the inside.

3.6.1 Mechanisms for the Legal Document Processing Domain. Security mechanisms for the Legal Document Processing Domain must provide security services to protect data flow into the domain from external systems. This domain has many similar characteristics to the Electronic Commerce Domain. However, it has more stringent security requirements across a wide variety of specific applications. For example, in the legal document processing workflow there are multiple tasks that an examination process must execute. The security mechanisms that best protect the process can be different for each task. This is probably the most complex of the domains.

A rather specific scenario for electronic filing of legal documents has been defined and demonstrated as part of DOCT. It is outlined below.

Mechanisms for Electronic Filing. The first step in electronic filing is applicant registration with the receiving organization. As presently configured in an early demonstration model, this is accomplished over the Internet as shown in Figure 6.

After registration, the electronic filling applicant can download the organization's public key from the Web site. Also available is a filing program providing the ability to securely transfer legal documents to an FTP server at the organizations "electronic mail room." The encryption mechanism selected for the initial demonstrations was PGP. This main selection criteria for PGP was its wide availability and zero cost (see Figure 7).

The applicant's public key is then submitted using the downloaded program. It is then automatically entered in the organization's key ring.

The applicant can now use the filing program to send a legal document to the organizations electronic mailroom. Within the DOCT research the document will consist of an SGML file and multiple associated entity files (MPG, GIF, JPG, VRML, etc.) as shown in Figure 8.

Figure 9 shows an overview of the document transfer process and the security mechanisms used for the electronic filing demonstration. The multi-file document is compressed, signed using the user's private key, and then encrypted using the organizations public key. Since the document is transferred from outside of the DOCT infrastructure, Legion can not be employed.

Once the document is in the electronic mail room it undergoes preliminary processing. It is decrypted, the senders signature is verified and the document is transferred to a processing server that provides strong authentication and access control. It is important that no unencrypted information reside on any server that is available to the public.

All processing within the electronic mail room is accomplished through the use of Java software agents. No human intervention is required, even to process error paths.

Once the document has been moved to the internal secure server, it is processed (again with a Java agent) to determine if there is any content that could make the document subject to a secrecy act. If so, it is automatically encrypted and sent to another server for further processing. Once transferred, it is outside the scope of the DOCT project. All internal transfer of the document is done using Legion confidentiality and integrity mechanisms. This brings us back into the realm of the basic DOCT Specific Security Architecture.

The security architecture of Figure 6 uses Kerberos, Legion and MDAS to provide the basic security services. However, additional mechanisms are required to support external transfer into DOCT. It is unrealistic to expect the public to implement these mechanisms. However, it is reasonable to expect the public to implement simple public/private key encryption, especially if the programs to do so are provided by the receiving organizations.

4.0 Financial Institution Projects

The DGSA also proved highly successful for developing security architectures for commercial organizations. The DGSA model was used as part of the development of a security program for a large foreign financial institution. The DGSA concepts were used to assess the security protection of individual projects within an overall information security architecture. This example demonstrates the flexibility of the DGSA model and how its structured approach can be applied to areas beyond just architecture development.

The basic approach adopted for this task was to define the institutions overall information systems architecture in terms of the DGSA, and then separate out the specific projects and develop the Logical and Specific Security Architectures for each project. The Specific Security Architecture was then the subject of a Security Risk Analysis and a Security Test and Evaluation. Based on the results of these last two tasks, a recommendation for project certification could be made.

The example project used for this paper an Internet Banking Project undertaken by the institution to provide banking services over the Internet.

4.1 Overall Information System Architecture

The complete view of the information system architecture for the institution is shown in Figure 10. The shaded area indicates the physical plant LSE. This is a protected environment consisting of multiple buildings in a fenced, guarded area. All personnel entering the LSE must possess a badge issued by the institution. Visitors are logged at the front gate and, unless given special authorization, are escorted at all times while they are within the LSE. This strict physical control greatly simplified the non-technical areas of the security architecture development since we did not need to consider any areas as "open to the public."

4.2 Internet Banking Domain

The financial institution implemented a Web based approach to its Internet banking functions. The actual applications still run on the mainframe complex using transaction based processes. To integrate the Internet Banking with the mainframe required the use of an IP/SNA gateway to translate the HTML forms requests to SNA based CICS transactions.

The Logical Security Architecture for this domain is shown in Figure 11. Note that confidentiality is allocated to both the Web Server and the Public computer. This is needed because of the limited 40 bit encryption provided in export versions of Netscape. The confidentiality was addressed through the use of a Java applet that provides a second level of encryption at the application layer.

The other allocations are rather obvious, except that it was necessary to develop the means for passing user authentication and access control information from the HTML forms to the mainframe with each transaction request. This led to individual code being developed for the Web Server and the IP/SNA Gateway to support the mainframe transaction environment.

Development of the security mechanisms required a detailed data flow analysis. The flow analysis is shown in Figure 12.

Once the steps in the information flow were identified, an analysis was performed to determine what mechanisms were needed at each step. As an example, it was determined that standard SSL did not provide the necessary confidentiality to protect the information flow between the user and the Web server. Therefore, additional mechanisms were required. These were implemented through the use of a Java applet. An overview of the confidentiality mechanism is shown in Figure 13.

The DGSA model provided a structured way to address these security projects. Once the mechanisms were allocated to the architecture, a Security Test and Evaluation Plan was developed to examine how well the security service requirements were actually met by the technical implementation. The DGSA model allowed the security team to attack the real security problems, and not spend needless time defining an approach.

5.0 Conclusion

One problem with information system architecture development has always been an agreement on the definition of the architecture model. Use of the DGSA has solved this problem. The DGSA provides a model that is flexible, can be applied across multiple program types, and can be used for a wide variety of security tasks. The DGSA has been made an integral part of our total security tool set.

Bibliography

1. DOCT - http://www.sdsc.edu/DOCT
2. Andrew S. Grimshaw, William A. Wulf, James C. French, Alfred C. Weaver and Paul Reynolds, "Legion: The Next Logical Step Toward a Nationwide Virtual Computer", 1994, CS-94-21 Legion, http://www.cs.virginia.edu/~mentat
3. Moore, Regan W., Massive Data Analysis System, URL http://www.sdsc.edu/MDAS
4. Moore, RW., Klobuchar, R., et. al., "Concept of Operations for the Distributed Object Computation Testbed," SDSC report GA-C22533, November 1996.
5. Legion Project - URL http://legion.virginia.edu

Biographies

Douglas Mosier is an Assistant Vice President and Chief Scientist for the Information System Solutions Group, Information Technology Solutions Sector of Science Applications International, Corp. He received his BS from the United States Military Academy in 1963 and his MSEE from the University of Michigan in 1970. He has been involved with information systems development for over 20 years.

Tom Lowman is a Senior Engineer for the Information System Solutions Group, Information Technology Solutions Sector of Science Applications International, Corp. He received his BSEE from Montana State University in 1968 and his MSEE from the Florida Institute of Technology in 1975. He has actively worked with communications systems, information technology and related areas for over 20 years.