A Survey of Commercially Available Secure LAN Products

Greg King Verdix Corporation kingOverdix.com 14130-A Sullyfield Circle Cbantilly, VA 22021 703-378-7600

Abstract The advent of the Trusted Network Interpretation (TNI) and the widespread availability of powerful microcomputers has resulted in the development of secure local area networking (LAN) products. Potentially, these prcducts provide tremendous economic benefit by allowing multi-level secure operation of local area networks. This paper examines eight of the mast popular secure LAN products from a technical perspective. The surveyed products include the Vcrdu Secure LAN, the Boeing Secure LAN, the Sun MLS OS, IBMITIS's Secure Xeniz, DEC'E Ethernet Enhanced Security System, the Harris LANfSX, the Ford Aerospace Multinet Gateway, and the Xeroz Encryption Unit. Following the examination of these products, the paper provides subjective conclusions about the state of LAN security.
1. Organi~ation This paper contains eight sections. Section 2 provides a technical overview of the functionality provided by each of the surveyed products. Section 3 provides a discussion of the differences between network components and single distributed systems. Section 4, 5 , 6, and 7 discuss the surveyed products in terms of their mandatory access control, discretionary access control, identification and authentication, and auditing services, Section 8 provides subjective observations and conclusions.

higher-level protocols. The VSLAN is capable of enforcing security on a LAN c o m p e d of heterogeneous hardware and heterogeneous operating system. The VSLAN is being evaluated as a TNI network component. 2.2. Boeing Secure Local Area Network The Boeing Secure Local Area Network is a high performance network component that also consists of trusted interface units. The secure network sewem provide communications protocol processing, mandatory access control, and identification and authentication sewices for the attached devices. The secure network server attaches labels to datagrams and provides mandatory access control decisions based on the value of the labels. The Boeing Secure Local Area Network provides security services a t or above the Transport Layer of the OSI-RM. The secure network servers implement the DoD protocols P ) . Consequently, the product is (e.g. FTP, TCP, UDP, I not independent of a specific higher level protoeol. However, the product is independent of specific operating systems. The Boeing Secure Local Area Network is also being evaluated as a TNI network component.
2.9. Sun Multi-Level Secure (MLS) OS

2. Product Overviews This section provides an overview an overview of the functionality provided by each of the surveyed products.
2.1. V e r d i i Secure Local Area Network

The Verdix Secure Local Area Network (VSLAN) is a network component that consists of IEEE 802.3 trusted interface units and a Network Security Center. The trusted interface units, known as Network Security Devices (NSDs), provides network access for the attached device according to a mandatory and discretionary access control policy defined at the Network Security Center. Identification and Authentication Services are provided througb the use of a EEPROM based token provided to network users. The trusted interface units, in cooperation with the Network Security Sewices also providing auditing and encryption functions for the LAN. The VSLAN operates and provides security sewices at the Data Link Layer of the OS1 reference model (OSIRM). Consequently, the VSLAN is independent of

Sun MLS OS is an extension of SunOS for secure multilevel secure environments. Sun MLS OS is designed to satisfy the requirements for a B1 operating system as defined in the Trusted Computer System Evaluation Criteria (TCSEC). The product is an extension of SunOS. As such, extension have been added to provide mandatory access control (MAC), secure booting, and auditing. While not evaluated according to TNI requirements, Sun MLS OS does provide a type of secure networking support. The operating system implements the DoD protocols (e.g. FTP, TCP, UDP, IP) and uses Berkley Unix sockets as a basis for its secure networking approach. The product is not independent of higher level protocols and, of course, the security provided by the product is intimately derived from the operating system itself. Unlike the network component approaches (e.g. Boeing Secure LAN, and Verdix Secure LAN), the product requires a specific host operating system. Sun MLS OS is being evaluated as a standalone computer system according to the requirements of the TCSEC.
2.4. IBM/TIS Secure Xenix BMJTrusted Information System's (TIS) Secure Xenix

TH0287-3/90/0000/0239$01 .OO Q 1990 IEEE

239

.~

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

(2) operating system is a secure version of Xenix for the IBM P C AT. Currently, the product as offered by TIS,

2.8. Xerox Encryption Unit

(=U)

does not include the secure networking approaches originally conceived at IBM, nevertheless, the approach i s technically interesting for comparison purposes. With Secure Xenix, IBM originally implemented two approaches for secure networking. The first approach i s based on the addition of a session layer to the DoD p m tocols TCPJIP. The second approach does not utilize the IBM session protocol but allows for mediation based on a security label passed in the Internet Protocol Security Option (IPSO), From a user perspective, both approaches are based on Berkley Unix sockets. The approach is, of course, not independent of higher level protocols and the security is derived from the IBM session protocol as well as from the operating system itself. IBM Secure Xenix was sold to Trusted Information SYStems. TIS Secure Xenix is being evaluated as a standalone computer system according to the requirements of the TCSEC.
2.6. DEC Ethernet Enhanced Security System

The Xerox Encryption Unit is an encryption unit that provides IEEE 802.3 LAN access and encryption services. The XEU is a hardware device that utilizes Type I encryption for the protection of classified information. The product provides a COMSEC approach to network security. As a result, the product does not consider many of the requirements of the TCSEC and TNI. Like other products operating at the Data Link Layer of the OS1 RM, the product is independent of specific higher level protocols and host operating systems. The Xerox Encryption Unit is not being evaluated a sa COMPUSEC product. 2.9. Anticipated Assurance Ratings
As of this writing, the anticipated assurance ratings of the surveyed products is shown in the table below.

The DEC Ethernet Enhanced Security System is a network component that consists of encryption devices and key distribution software for specially designated key distribution nodes. The Key Distribution Software requires the VAX VMS operating system. As described in Perb881, the Ethernet Enhanced Security System is a collection of Digital Ethemet Secure Network Controllers (DESNC) operating at the Data Link Layer. These controllers use the Data Encryption Standard (DES) to p m vide confidentiality, integrity, and an access control policy for the LAN. Resulting from the fact that the product operates at the Data Link Layer, the prcduct is independent of higher level protocols and specific host operating systems. [Gass88] states that a commercial product evaluation as a network component according to TNI requirements has been requested.
2.8. Harria LAN/SX Harris LAN/= is a secure local area network based on H a r r i s CX/SX secure Unix and Verdix Secure Local a r r i s CX/SX secure unix is based Area Network. The H 1 certified Unix operating on AT&T System V/MLS; a E system. The product currently implements the DoD protocols, labels its Unix sockets and utilizes the VSLAN to p r e vide network security. Because Harris LANJSX depends on the VSLAN for its network security, the product allows a heterogeneous collection of secure operating systems and hardware on the same LAN.

3.

Network Components ve. Single Distributed syatema

The TNI provides a metric for a security evaluation of a computer network or a network product. As the TNI admits the possibility that vendors may produce p r e ducts, which in isolation are not complete networks, the TNI offers evaluations as single distributed systems or as network components. In the context of this papw, a network component is a trusted communications device that implements communications protocols and is perhaps trusted to provide access control, auditing, and/or identification and authentication for an attached device. The primary difference between a network component and a single distributed system is the fact that a network component in and of itself does not support all of the requirements of the TCSEC while a single distributed system does. The argument for evaluating network components is an assumption that a collection of network components can he assembled into a single distributed system that does satisfy all of the TCSEC requirements without having to constantly re-evaluate the security features provided by individual components. (1)

2.7. Ford Aerospace Multinet Gateway The Ford Aerospace Multinet Gateway is an internet gateway providing mandatory access control and internet services for host systems. Using the Intemet Protocol Security Option, host systems are able to utilize the services of the gateway. The Ford Aerospace Multinet Gateway is being evaluated as a TNI network component.
2. Xenix is
B

As predicted by the TNI, some vendors offer components while others offer complete networks. An example of a network component is a trusted interface unit that functions as a front end processor providing communications and security services to an attached host computer. Typically such trusted interface units might be interfaced to a variety of different host computers. The combination of host computers and the trusted interface units could form a complete network. An example of such a component is the Verdix Secure Local Area Network (VSLAN).
Other vendors offer complete networks. An example of a complete network is the Sun Secure OS which is a collec-

trademark of Microsoft Corporation.

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

tion of Sun workstations and Sewers running Suns Secure OS.

3 . 1 . The S i l e Ddributed System Approach

As noted, the single distributed system approach to secure local area networking is a generally homogeneous collection of workstations and servers that depend on the services of a secure operating system to meet all of the requirements of the TCSEC. The secure operating SYStem provides basic mandatory and discretionary control, auditing, as well as identification and authentication services, The security services are an integral part of the operating system.
From a practical viewpoint, the resulting homogeneous network is overly restrictive. Requiring the use of a secure oDeratina svstem on nodes that could potentially operate in a single level dedicated mode with an untrusted operating system may prove costly. Such an approach may not make use of existing equipment. As [ N e d ] points out, it is rarely possible to acquire, install, and operate a distributed system that does not make use of existing equipment. In fairness, it is important to note there have been some efforts to ease these restrictions, In one approach, dedicated systems are allowed to communicate with the n e t work of secure systems if they communicate at the system low level. In another case, a gateway has been p m posed to allow foreign hosts to communicate with hosts running the secure operating system. These proposals, however, appear to be in response to user demands for connectivity, and, in at least one case, are not part of an officially evaluated National Computer Security Center (NCSC) commercial product evaluation.

The trusted interface units (TIU) insure the separation and correct labeling of information BS it is read and w r i t ten to the transmission medium. Label attachment and access control are the sole responsibility of the trusted interlace unit. I h e I I U may also provide some form 01 discretionary access control between hosts. The operational parameters of the trusted interface units (e.g. the levels at which the units operate) are centrally administered by a network security officer. In this model security is not a function of a single host operating system. One of the major advantages of this approach is that existing untrusted hosts and unmodified host operating systems may be utilised without requiring operation at the network system high level. For example, in the figure above, because the TlUs insure that the Secret hosts do not have access to Top Secret data, these hosts can be incorporated at a level less than the system high level of the network.

As the model is slightly modified to allow additional resource sharing, a multilevel host may be added. At this point the security of the network becomes dependent on both the security services provided by the trusted interface units as well as the security provided by the multilevel host. The multilevel host must be trusted to insure correct separation and labeling of two or more levels of information.

As the model continues to evolve it may be deairable that a heterogeneous collection of multi-level secure hosts, and single level dedicated workstations are combined. Such an example, illustrated in Figure 2, might be a collection of hosts running different evaluated secure operating systems, as well as numerous single level dedicated workstations with unevaluated, untrusted, operat ing systems.
MultilevelSecure Local Area Networking(LAN/SX)

3 . 2 . The Network Component Approach

In contrast to the single distributed system approach, the network component approach is much less dependent on the security features of a single trusted operating system. Consequently, the resulting LANs may be much more heterogeneous in terms of hardware and secure operating systems. Figure 1 illustrates a model of LAN security where it i s desirable to incorporate untrusted hosts at levels less than system high. To accomplish this, the LAN itself requires some form of access control. This access control is generally incorporated in network components referred to as trusted interface units.

Figure 2. Heterogeneous Collection of Trusted and o s t s . Untrusted H

L l
TODSecret
I
~~

L IL l
Top Secret

Secret

4. Mandatory Access Control The fact that most of todays products are destined for commercial product evaluation a t the NCSC, the fact that protection of classified information has been a traditional focus within the computer security community, and the industry push towards multi-level operation of classified systems, results in an emphasis on mandatory

Figure 1. Trusted Interface Units Provide LAN Access

1. The cbdleogcs to thcse ugumentd and amumptions arc interesting. Sec INcssgl].

24 I

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

access control in today's products, All of the surveyed pmducts include some form of mandatory access control. The NCSC's Trusted Network Interpretation [NCSC87] defines mandatory access control as a means of restrict ing acces to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity. Mandatory access control (MAC) policies are most often discussed and understood best in the context of the Department of Defense's security policy for the pmtection of classified information. With this familiar policy, access control is based on sensitivity labels that include a cl-ification level and a set of compartments.

for privileged servers. According to jAdds881, requiring that two processes be a t the same security label causes difficulty for some of the servers that are part of the TCB. A cited example is the case of the network file system (NFS). NFS needs to be able to respond to clients at any level regardless of its own label. T o accommodate this, the SUN system includes privileged communications. The privileged process is trusted to make the appropriate access control decision.

It is important to note that all servers are not privileged servers. In many cases, it appears that a special server determines the label of the requesting client and invokes the requested server at the same label. In all communications, Sun MLS OS uses the IP label option to p m the labels needed for MAC decisions. To accommodate user connectivity demands (requests to securely connect non Sun hosts running in a dedicated mode), Sun has defined an approach that will utilize a trusted gateway. With the approach, the gateway knows the security label of the destination host and proceeds to strip the label and forward the packet if communication is allowed a t the requested label. Otherwise, the packet is dropped and audited. While this approach allows connectivity, it does not come without cost. Several important assumptions are required. Among these are the fact that untrusted hosts must not communicate with each other if they are at different security level, they must not try and masquerade as a server, they must not read packets not addressed to them, etc.. Ironically, the untrusted hosts are trusted not to perform these actions. This extension to allow connectivity is not part of the NCSC commercial product evaluation.

4.1. Role of Labeb in Mandatory A c c e ~ Control As noted earlier, with vendors scurrying to meet the requirements of the Trusted Network Interpretation and therefore achieve the financial rewards of a formal government endorsement, the implementation of mandatory access control policies has become nearly exclusively label based, as a label based MAC policy becomes a requirement at the B1 level. Nevertheless, it is interest ing to note the alternatives that might have been used had label based mandatory access control not been specified in [NCSC87].
[Abrm85] suggests three separation mechanisms that can be used to isolate security groups on a LAN. In one mechanism, coaxial cable is modulated in frequency channels so that a separate channel is produced for each security group. In another mechanism, as shown in Figure 3, [AbrmBB] suggests encryption as the basis for p m viding logically separate channels for each security group.

4.2.2. IBM/TIS Secure Xenk

- (B2)

Mandatory a c e s control in networked systems of Secure Xenix is performed by establishing a proxy process on the remote system with a user's current security level. The P label option is used to pass the label needed for a MAC decision a t the remote system. When packets are exchanged over the connection, the IP label is compared to verify that only packets with the same label are exchanged. Figure 3. Encryption as A MAC Mechanism. Except for two of the surveyed products, all products assign security labels that contain, as a minimum a hierarchical security level and a non hierarchical set of categories.

As mentioned, because single distributed system approaches rely heavily on the underlying secure operat ing system, it is interesting to note the approach to connecting dedicated systems.
According to (BergerSQ], Secure Xenix allows dedicated systems to be connected to a network of Secure Xenix systems. When a Secure Xenix system requests a connection to an untrusted dedicated system, Secure Xenix is able to determine that the I P label option is not SUP ported and to establish a connection at system low. Attempts to establish a connection at any other level are denied.

4.2. Mandatory Access Control in Single Distributed S y s t e m 4.2.1. Sun MLS OS

- (Bl)

In the Sun MLS OS system, mandatory access control requires sources hosts to label packets and destination hosts to check labels on received packets. At the destination host, if the received packet has a label that is EQUAL to the label of the target process, the packet is delivered; otherwise, it is dropped and audited. This is the case for unprivileged communications.
In the SUN system, however, provisions are also made

4.2.3. Harris LAN/SX -(B1) Harris LAN/SX combines the MAC features of Harris CX/SX Secure Unix with the MAC features of the VSL4N to enforce a mandatory access control policy on the lan. The Harris CX/SX secure m i x associates a label with a socket. On transmission, the label associated with the socket is then provided to the VSLAN's trusted interface unit. On reception the label of each

242

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

datagram is then checked with the label of the destination socket to insure that the socket (and its associated process) are authorized to receive the associated information. One advantage of utilizing the VSLANs trusted interface units is that dedicated, untrusted systems can he connected to the Ian at varying security levels. For dedicated systems, the trusted interface unit correctly labels packets at a single level and category set. Additionally, the MAC approach is enhanced by the label integrity services provided by the trusted interface units. Security labels are passed between systems by the VSLAN using a VSLAN specific label format and protccol.

According to (Herh881, the network assigns an access class range for each node from a secrecy lattice. Two nodes are allowed to communicate if they share a key that was distributed by the Key Distribution Center (KDC). The KDC determines that two nodes are allowed to communicate if they operate at the same access class, or if the nodes overlap in at least one commonaccess class. The DEC system is interesting for several r e w n s . The first of these is the less than traditional implementation of a MAC policy. Of the LANs surveyed, the DEC Ethernet Enhanced Security System and the Xerox Encryp tion Unit are the only products that do not specifically include a label on individual packets. Naturally, this raises interesting questions as to evaluation according to the mandatory access control requirements of the (NCSC871 criteria. [Gass88] states that an evaluation as a class B1 network component has been requested.

4.2.4. Commonality and Differences

The ability to enforce a consistent mandatory access control policy across a diverse hardware and operating system base requires labeling conventions and protocol conventions that can be enforced in many operating s y s tems. In the case of Sun MLS OS, the assumption that a dedicated mode system is well behaved, that it does not masquerade as someone its not, that it doesnt try to act as a server, that it doesnt read packets not addres to it are substantial assumptions that may he difficult to enforce. See [Be11891for a detailed discussion of just how easy it might to perform these actions and violate the assumptions. In the case of Secure Xenix, the IPSO is again used BS a basis for MAC decisions and assumptions are made about systems not supporting IPSO. For secure commnnication between Secure Xenix systems, an IBM specific s e s sion protocol was developed but, obviously, security services can only be provided between systems implementing the proprietary protocol (i.e. a LAN of Secure Xenix systems). In the case of Harris LAN/SX, the common security prctocol and labeling conventions provided by the VSLAN component enable enforcement of a consistent MAC policy without imposing security constraints on dedicated systems or requiring implementation of a specific security protocol. The common security protocol is contained within the trusted units themselves. This allows enforcement of a MAC policy on a LAN that has a diverse hardware and operating system base.

4.3.2. Boeing Secure LAN Component)

(A1 MI Network

The Secure Network Servers (SNS) of the Boeing secure LAN are trusted interface units that attach sensitivity labels to packets. These labels are checked when the packet is sent and received. When a packet is received, the SNS checks that the label of the packet is within the range of the destination and that the destination is active. The host must correctly lahel packets within the range assigned to the host.

4.8.3. Verdix Secure Local Area Network MDIA Network Component)

(B2

The Verdix Secure Local Area Network (VSLAN) is a B2 MDIA network component. The VSLAN uses trusted interface units that assign labels to packets based on the inputs from an attached host and the limits assigned by a network security officer. A network security oficer, at a central management node known as the Network Security Center, defines a transmit and receive security window for each node. These windows define the maximum and minimum levels and category sets a t which a host may transmit and receive.

4.3.4. Ford Aeroapace Multinet Gateway Network Component) 4.3. Mandatory Access Control in Network Components
Unlike their single distributed system counterparts, the surveyed network components are not dependent on a single secure operating system.

- (A1 M

4.3.1. DEC Ethernet Enhanced Security System (TBD Network Component)

The Ford Aerospace Multinet Gateway provides mandatory access control based on a user applied label and an assigned range of labels for each input port and each output port. Labels are assigned when the gateway is configured and can not be changed by an operator. The label of a packet presented to the gateway is compared with a set of defined labels to he accepted for input. F The packet is then routed based on information in the I header. At the output port, the level of the packet is compared with the permissible range of output levels

The DEC Ethernet Enhanced Security System does not assign security labels to information as it exchanged over the network. Instead, the DEC Ethernet Enhanced Security System provides enforcement of a MAC policy through the use of cryptography. The method used is similar to the method illustrated in figure 3.

4.3.6. Xerox Encryption Unit duct)

(COMSEC Pro-

4.3.8. Commonality and Differences

243

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

The DEC product is the only component that does not assign an explicit label to information as it is exchanged over the network. This presents a problem if multilevel nodes are to exchange information as it may not he possible to determine the level at which the information was exchanged. All other systems label packets and provide an a c c e i control check when the packet is sent as well as when it is received.

6. Discretionary Accau, Control

As with mandatory access control, discretionary access control (DAC) in single distributed systems may he an inherent feature of the underlying operating system or the features of the operating system may he combined with the DAC features of a DAC component to form a network DAC service. In network components, DAC may he a matter of restricting access between nodes of the network instead of between individual users or their processes.
6.1. DAC in Single Distributed Systems 5.1.1. Sun MLS OS
According to [Adds87], Sun is working to define DAC standards for incorporation into Sun MLS OS.

rity oKker defines the access control l i s t s at the central management node. These access control lists are then downloaded to individual nodes as required. This limits the communications between hosts but is not intended to limit the communications between individual users of a multi-user hast systems. The fact that this discretionary access control is applied on a per principal basis becomes significant when considering non-concurrent access to a single user workstation. For example, assuming User X and Y share a workstation. User X requires access to Host A but User Y does not, By authorizing an association for user X and denying an association for user Y, the network security officer is able to control which usem have access to the remote system. As a network component independent of higher level prctocols and operating systems, the VSLAN is, naturally, unable to provide discretionary accegq control for the internal objects of a multi-user host system (e.g. files, devices, etc.). When multi-user hast systems are included, a C2, or higher, trusted operating system must be integrated to provide the local DAC. This still p m vides much flexibility as most commercial operating systems have or are capable of achieving a C2 rating.

8. Identi5cation and Authentication

Systems at or above the B2 level require a trusted path between the user and the TCB for initial login and authentication. This trusted path provides assurance that the user is communicating with the TCB and not something masquerading as the TCB. This provides insurance that users will not be tricked into giving away their authentication data to untrusted programs. In addition to the basic requirement for users to identify and authenticate themselves before using the network, TCPjJP and some application protocols do not authenticate connections. TFTP is an example of an application protocol that does not authenticate connections (Berger891. For this reason, if these protocols are to he supported, a system may have to provide some type of authentication before establishing a session between untrusted processes.

5.1.2. Secure Xenix Discretionary access control in the Secure Xenix system is achieved through the use of access control lists and network access profiles. An access control list is a triple that consists of a user, a group, and a set of permissions. These access control lists are used to protect files, devices, and other rmurces of a local machine. To control access to the network, Secure Xenix maintains network access profiles that identify which remote systems, if any, a local user is allowed to access. These network access profiles are accessed by Secure Xenix during session establishment. This allows a security officer to control the hosts a particular user can access.

5.1.3. Harris LAN/SX

Harris LANjSX combines the DAC features of Harris CX/SX with the DAC features of the VSLAN to enforce a network DAC policy. By defining a DAC list for each network node, Harris LAN/SX is able to restrict communications between network users. This enables a n e t work security ofiicer to centrally authorize communication capabilities between nodes of appropriate clearance levels.
5.2. DAC in Network Componenta

As network components may only indirectly support users, it appears that a trusted path between a host computer and the NTCB partition is a consideration. In the case of multi-user host systems, this trusted path may have to be considered in conjunction with the trusted path provided by a host operating system.

8.1. Identi6cation and Authentication i n Single Distributed Systems 8.1.1.

sun MLS os

5.2.1. Verdix Secure Local Area Network

The VSLAN uses access control lists to define associations between nodes. The access control lists are defined on a per principal basis and are specified independently for transmit and receive operations. The network secu-

Sun MLS OS is being designed as a B1 system, ks such, there is no explicit requirement to support a trusted path between users and the TCB for initial login. This implies that it may he passible for untrusted programs to imitate the login sequence tricking users into giving away authentication data. The SUN a p p m h to protocols which do not authenticate connections is unknown at this time.

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

8.1.2. Secure Xenix

Secure Xenix is being designed as a B2 system. As a result, the underlying operating system supports a trusted path between users and the TCB for initial login and authentication. This path takes the form of a Secure Attention Key (SAK) [GligorR'I], that results in the invocation of a trusted process that terminates all untrusted processes to insure authentication data is not intercepted. Secure Xenix also supports a session based mechanism that invokes authentication facilities that establish a session between a local machine and a remote machine. This allows Secure Xenix to fork off requested services on a remote machine after security relevant parameters have been mediated. (BergerBQ]provides an example of how this session mechanism allows the use of application protocols which do not authenticate connections (e.g. TFTP).
8.1.3. Harris LAN/SX Harris LAN/SX combines the I&A services of Harris CX/SX with the I&A services of the VSLAN to provide network identification and authentication. Harris CX/SX identifies and authenticates the individual usem of multiuser host machines through login procedures while the VSLAN authenticates network users through a physical key device.

[Shack871 discusses trusted path noting that, for host interfaces, trusted software within the component scans packet headers to determine whether host packets are delivered to trusted or uutrusted processes. As with other network components, for host interfaces, the trusted path is for an individual host system. To form a single distributed system that satisfied the trusted path, the trusted path of the component would have to he combined with the trusted path of a host operating system. 7. Auditing One of the common problems associated with auditing in a secure LAN is the collection and storage of audit data. If the system is to continue to function after the failure of an audit site, a secure LAN must support multiple audit sites, it must prevent alterations of the audit trail, and it must provide audit reduction tools capable of reassembling scattered audit data.
7.1. Auditing in Single Distributed Systems
7.1.1. Sun MLS OS Auditing in Sun MLS OS is interesting for its flexibility, survivability, and its definition of standard audit message formats for the Unix (3) community.

8.2. Identification and Authentication in Network Components

6.2.1. Verdix Secure Local Area Network The VSLAN, a B2 MDL4 network Component, provides identification and authentication service by requiring the individual responsible for operating a network node (0 present evidence that he has been authorized to use that node. In the VSLAN, authentication is based on something that the user has (e.g. a physical key), instead of on something the user knows (e.g. a password). The VSLAN provides each authorized user with a physical EEPROM device, shaped in the form of key. This key must he inserted into the network security device of the authorized host before access is granted. If the key is inserted into network security devices for which the user is not authorized, the key is rendered invalid, and the actions audited. The identification and authentication mechanisms apply to individual host computers. Multi-user host systenls are expected to identify and authenticate individual users. A trusted path from a host computer to the VSLAN is provided with the Datakey. Turning the Datakey prw vides a secure attention signal to the VSLAN which untrusted host software is unable to imitate.
8.2.2. Boeing

In the Sun system, audit data may be stored at a central audit server within the network, or the audit data may he stored a t multiple locations. Storage at multiple locations allows flexibility for performance and survivability considerations. Each Sun machine contains an audit dameon that is responsible for recording audit messages. Each dameon has a list of audit file system from which it can choose a location for audit files. It consults this list whenever a new audit file must be created. This list may be different for each machine so as to to spread the audit traffic evenly [SihSS]. While this approach seems well suited to insuring that audit data will always find a home, a natural question that arises is how the audit data gets put back together to describe the activity of the system as a whole. Because in the Sun System, all machines share the same file system and file names are unique throughout the system, sorting and merging the data is a straightforward task for a provided utility program.
An additional important

aspect of the Sun audit approach includes the ability of the Sun OS to accept audit data from user applications. 7 . 1 . 2 . Secure Xenix Less information is available about the auditing approach of Secure Xenix. [BergerRS]provides information that describes a more Centralized approach to auditr ing where audit records are generated locally and periodically shipped to an audit site. At the request of the a auditor, the site may be changed from one system t another. This appears to be different than the Sun approach where each machine may be generating audit data to a different audit site.
3 Unlx is a registered trademark of A T I T Bell Laboratories,
1C

MLS LAN

The Boeing MLS'LAN requires all terminal users of the network to identify and authenticate themselves before access is provided. Hosts are required to identify and authenticate individual users.

245

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

7.1.3. Harris LAN/SX

As with MAC, DAC, I&A features of Harris LAN/SX, provides network auditing by combining the network auditing features of the VSLAN with the auditing features of individual host systems.

7.2. Auditing in Network Components

7.2.1. Verdix Secure Local Area Network The VSLAN component provides a more centralized approach to auditing than either of the systems discussed thus far. Network security devices collect audit data that is immediately shipped to the central management node for reporting. As a network component unaware of trusted operating systems, higher level protocols, or user pmeesses, the VSLAN is unable to audit login attempts for multiuser host systems, creation or deletion of files, or certain other host specific events. The VSLAN must be combined with the auditing facilities of a trusted C2 or higher host operating system to provide such auditing.

a.ecordin4 to the TCSEC, other approaches are designed accordins to the TNI, and yet others are COMSEC approaches that consider neither the TNI or TCSEC. Currently, standards efforts are underway as part of the IEEE 802.10 Secure Interoperable LAN Security (SLS) Committee and the Secure Data Network Systems Program to define standard security approaches, services, and protocols. However, until such time as products can be developed according to these standards, the surveyed products may dominate the market. In and of themselves, proprietary approaches are not evil. Proprietary approaches become evil when they restrict the connectivity of a network, when they restrict the ease with which a network c a n migrate to new protocols, and when they compromise security by relying on dangerous assumptions. This survey has identified eight secure LAN products that provide security. Some are network components and othen are single distributed systems. Carefully designed network components seem to have the best chance of providing the appropriate security services without the stated evils.

While the VSLAN approach must be supplemented in the case of multiuser host systems, the approach has particular advantages in the case of untrusted single user workstations. This results from the fact that as a n e t work component, the VSLAN audits events to the granularity of a single host system. For example, the VSLAN is able to audit events to the level of a principal responsible for using a VSLAN trusted interface unit. In the case of a single user workstation, auditing to this granularity is equivalent to auditing to the granularity of a single user.
,7.2.2. Commonality and Differences

Disclaimers
The information contained here has been collected mostly from the sources listed in the References section. The responsibility for any misinterpretation rests with myself. Additionally, the information contained here should not be construed as a product comitment or a guaranteed implementation. The opinions contained in this paper are my own and do not necessarily represent the opinions or position of my employer.

The SUN approach to auditing is an extremely flexible approach that seems to address the performance and storage issues associated with auditing in a large distributed system. By defining standard audit message formats for the Unix community, the approach seems to encourage the development of audit analysis tools by third party vendors. However, the approach is specifically bound to Sun MLS OS. It is not possible to integrate other secure operating systems or foreign hardware into the approach. Although audit sites are selectable, Secure Xenix appears to use a more centralized approach that does not specifically address the use of standard audit message formats. As with the Sun s y s tems, Secure Xeuix systems provide complete auditing to the level of an individual user but perform this as part of the underlying operating system. With the Sun and Secure Xenix approaches, it does not appear possible that an untrusted single user workstation can be integrated such that audit requirements are satis. On the other hand, integration of an untrusted single user workstation does appear possible with the VSLAN n e t work component.

References

[Abrm85]

Abrams M.D., "Observations on Local Area Network Security", Proceedings of the Aerospace Computer Security Conference: Protecting Intellectual Property in Space", 1985. Addison K. et al., "Computer Security at Sun Microsystems, Inc.," Proceedings of the 10th National Computer Security Conference, Baltimore MD, September 1987.

(Adds871

[Adds881 Addison K. and Sancho J., "Secure Networking at Sun Microsystems, Inc ," Proceedings of the 11th National Computer Security Conference, Baltimore MD, October 1988. [Bell891 Bellovin, S.M., "Security Problems in the TCP/IP P r o tocol Suite," AT&T Bell Laboratories, Murray Hill, NJ, 1989.

8. The State of LAN Security

(Berger871 Burger W., "Networking of Secure Xenix Systems", P m ceedings of the 10th National Computer Security Conference, Baltimore MD, September 1987. [Berger89] Burger W., "Networking of Secure Systems", IEEE Journal On Selected Areas in Communications, Vol 7., No. 2, February 1989. [Bopb] Boeing Secure Lan Product Bulletin. National Computer Security Center.

This section provides some observations about the state of LAN security as it relates to the surveyed products. To a large extent each of the surveyed products has a proprietary approach to LAN security. Some approaches involve proprietary security protocols, other approaches are intimately tied ta the security services of a specific host operating system. Some approaches are designed

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.

IEstrinRi! Estrin D., "Controls for Interorganization Networks", E E E Transactions on Software Engineering, Vol SE-13, No.2, February 1987.
IGas88)

Gasser M.. Lipner S., "Secure System Development in Industry. A Perspective From Digital Equipment", Proceedings of the Fourth Aerospace Computer Security Applications Conference, Orlando FL, December 1988

'Gligor87j Gligor 1 ' . et al., "Design and Implementation of Secure Xeniu", IEEE Transactions on Software Engineering, Vol SE-13, No. 2, February 1987. Hrrh88,' Herhison, B.J., "Security on an Ethernet", Proceedings of the 11th National Computer Security Conference, Baltimore MD, October 1988 Ahrams M.D, Schaen S.1, and Schwartz M.W., "Strawman Trusted Network Interpretation Environments Guideline", Proceedings of the 11th National Computer Security Conference, Baltimore MD, October 1988.

IMar881

iMauc881 Maucher J. and Lang R., "Multinet GatewayiCommercia1 COMSEC Endorsement Program", Proceedings of the Fourth Annual Symposium on Physical/ Electronic Security, Philadelphia PA, August 1988.
[NCSC87] National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System

Evaluation Criteria", N C S C T G - 0 5 , Version-1, July 1987.

[Ness871

Nesset, D M., "Factors Affecting Distributed System Security," E E E Transactions on Software Engineering, Vol SE-13, No. 2, February 1987. Schnackenherg D.D., "Development of a Multilevel Secure Local Area Ketnork", Proceedings of the 8th National Computer Security Conference, 1985. Schnaekenherg D D , "Applying the Orange Book To An hlLS LAN," Proceedings of the 10th National Computer Security Conference, Baltimore MD, September 1987. Sibert W . 0 , "Audltmg in a Distrihut,ed System: SunOS MLS Audit Trails", Proceedings of the 11th National Computer Security Conference, Baltimore MD, October 1988.

'Schk85j

;Schk87]

!Sib88!

'Walk85] Walker S T., '"Network Security Overview," Proceedings of the 1985 Symposium on Security and Privacy, 1985
(Yellowj

CSC-STD-003-85, "Guidance For Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments", DoD Computer Security Center, June 1985.

247

Authorized licensed use limited to: UNIVERSITI UTARA MALAYSIA. Downloaded on January 26, 2009 at 21:18 from IEEE Xplore. Restrictions apply.