The Architecture of Secure Systems

Jim Alves-FossLaboratory for Applied Logic

Department of Computer Science

University of Idaho

By,Nagaashwini Katta.

TOPICS TO DISCUSS Introduction System model Formalism Exemplary System Conclusion References

INTRODUCTIONThe paper presents a generic approach to secure system development which can be applied for a wide range of secure systems.

Based on separability, this approach simplifies the overall design, verification and validation effort.

The approach is based on Rushby’s separability model providing a standard methodology used by the designers and verifiers while implementing in wide range.

SYSTEM MODEL

John Rushby presented the separability concept. The basic idea behind this concept is to model the behavior of the secure system as if it were a physically distributed system.

This kernel provides mechanisms for the existence of several virtual machines on one hardware platform, which helps for inter-machine communication.

A system designed using this approach will be provably secure.

1. Secure distributed system design2. Secure distributed system verification an

validation.

Secure distributed system Design

A distributed system consists of a collection of separate components connected in a well-defined medium, so as to share information and resources. This is not secure. So an isolated system is always secure.

For a single component to handle multiple security regions, it has to provide a separation kernel. The regions have separate security regions with a strict information flow-control policy. Shared network can be a LAN,WAN, internal communication buffer or any combination.

Secure Distributed system Verification and Validation

The verification and validation of system security involves several issues which are still under research, so these are partially discussed in this paper.

1. Policy2. Formal Security model3. Verification and Validation.

Policy : To build a secure system , a system security policy is to be present, where the presentation does not matter-either formal or informal way. The policy must specify the permissible and forbidden actions of the system. According to the paper, we limit this access for communication or information-flow between regions.

1. Do we mandate specific information flow between regions?

2. How do we map specific users into security regions?

Formal Security Model: A formal security model is essential to satisfy the policy defined, which can be used in the verification and validation in the implementation. The polices discussed in this paper are separability and restrictiveness which focus on information flow.

Verification and Validation : Starting with a policy and formal security model, now we need to verify if the system satisfies the model. This is done by showing that the system specification and design satisfy the policy along with showing that the implementation satisfies the design.

FORMALISMFormalism presents an approach to the formal specification, verification and validation of secure systems based on the approach discussed. To satisfy this we use top-down divide and conquer approach.

Decompose components of

the system until we reach

a clear security

boundary.

Each execution environment is considered as either a single-level process or as a multi-level process.

Allow the implementation of

multi-level execution

environments as a collection of

single-level virtual machines permitting

flexibility in the model

A component is designed in such a way that a multi-level process handles information flow and access control restrictions.

Distributed system is

created using instances of

these processing elements.

Assurance is given that security is maintained between these elements.

Add communication

facility to enable these

independent elements to share

information.

Communication facility has to ensure the security and integrity of the information passing between the processing elements.

Specification of components : In general, collection of process specifications are parameterized by gates and values. Communication and synchronization between processes occurs through events at gates. An event occurs at a gate when all processes using that gate are ready to proceed, and denoted by the name of the gate.Notation Description

g ! v Data value v is to occur at gate g g ? x : Type Type is to occur at g and stored in x, local

variable [ ] Denotes alternation ; Sequential ordering p1 | [g1,g2] | p2 Processes p1 and p2 can proceed in parallel

at gates g1 and g2. p1 || p2 Completely synchronized with events at all

gates. p1 ||| p2 Un-synchronized and independent

[guard expression] -> action

Guarding of the actions

phase1 >> phase2

Phases of execution may be sequentially composed.

System Components : This specifies the specification of secure processes and the secure network that combines them. Generalizing this composition, we specify the network input and output events over synchronization gates. A network that has input and output on the same port invoke this device with the same gate name.Process may perform either of these two events :

a. The event of sending a message.b. The event of receiving a message.

1. Secure Single-level Process – The process is connected to 2 external gates defining the network, parameterized by a unique process identifier.

2. Secure Network – The network is defined as a simple queue which does not allow modification of messages forming a collection of un-trusted network interfaces. These interfaces are responsible for checking the validity of messages and assuring that all messages are passed on to the processes.

3. Secure Multi Level Process – These processes are needed to model devices that must handle information from multiple security compartments, where there is no clear cut separations between the compartments.

Secure Single-level Process Interface Specification.

Secure Multi-level Process Interface Specifications.

Steps to Specify and Build in Secure SystemsThe initial step is to determine a top-level interface for system and the security policy that is maintained further.

1. Isolate the processes of the system.2. For each process, Specify the security level associated

with that process.3. For each process, Assign an appropriate interface.4. Define the network that interconnect these processes in

terms of communication paths.5. Define a composite system by connecting all processes to

their appropriate networks.

EXAMPLE SYSTEM

The system is simple and used to demonstrate how to specify the secure system. We consider a system that consists of multiple processes running on a single stand alone system with inter-process communication, one login process and two shared resources.The security policy we use here is restrictiveness which requires that processes with security labels that are not permitted to communicate under the security policy.We consider

Example System SpecificationSecure single level component and secure multi level

database.

Example System Specification

A Secure single level component : Important feature is that how it processes sending and receiving of messages. To trust such a component, it has to label outgoing messages and filter incoming messages.So we can specify secure single-level process as one trusted interface unit (ensures that all communication between component and network are labeled and filtered)and one un trusted operational unit.

Secure Multi-Level Database :Here we define a true multi level system. Say a device with a simple database that receives publish(adds to its records) and acquire (searches for a matching publish with same identifier)requests from the connectednetwork.

Trusted Interface Unit Specification

Un-trusted Process Interface Specification.

CONCLUSION The paper discussed about the separability concept and its use in design and implementation. It is applicable on modern systems and object-oriented systems.

The approach also discussed the specification of security of a system and also in the applications like databases, network services, secure networked or distributed systems.

This reduces the verification and validation effort seen by many system developers who are often unsure about the portions of the system and how much must be validated for security.

References1. J. Alves-Foss. Mechanical Verification of Secure Distributed

System Specifications. PhD thesis, Department of Computer Science, University of California, Davis, 1991.

2. D. McCullough. Specifications for multi-level security and a hook-up property. In Proc. IEEE Symposium on Security and Privacy, pages 161{166, 1987.

3. J. McLean. A general theory of composition for trace sets closed under selective interleaving functions. In Proc. IEEE Symposium on Research in Security and Privacy, pages 79{93, 1994.

4. Information processing systems Open Systems Inter-connection. LOTOS - A formal description technique based on the temporal ordering of observational behavior. International Organization for Standardization, International Standard 8807-02-15 edition, 1989.

5. J.M Rushby. Design and verification of secure systems. In Proc. ACM Symposium on Operating Sys-tem Principles, volume 15, pages 12{21, 1981.