The Architecture of Secure Systems

1. The Architecture of Secure Systems Jim Alves-Foss Laboratory for Applied Logic Department of Computer Science University of Idaho By, NagaashwiniKatta.

2. TOPICS TO DISCUSS • Introduction • System model • Formalism • Exemplary System • Conclusion • References

3. INTRODUCTION The 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.

4. 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 design 2. Secure distributed system verification an validation.

5. 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.

6. 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. Policy 2. Formal Security model 3. 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?

7. 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 : Startingwith 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.

8. FORMALISM Formalism 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.

9. 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.

10. 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.

11. 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. Secure Single-level Process – The process is connected to 2 external gates defining the network, parameterized by a unique process identifier. 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.

12. Secure Single-level Process Interface Specification.

13. Secure Multi-level Process Interface Specifications.

14. Steps to Specify and Build in Secure Systems The initial step is to determine a top-level interface for system and the security policy that is maintained further. Isolate the processes of the system. For each process, Specify the security level associated with that process. For each process, Assign an appropriate interface. Define the network that interconnect these processes in terms of communication paths. Define a composite system by connecting all processes to their appropriate networks.

15. 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 Specification Secure single level component and secure multi level database.

16. Example System Specification

17. 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.

18. Trusted Interface Unit Specification

19. Un-trusted Process Interface Specification.

20. 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.

21. References • J. Alves-Foss. Mechanical Verification of Secure Distributed System Specifications. PhD thesis, Department of Computer Science, University of California, Davis, 1991. • D. McCullough. Specifications for multi-level security and a hook-up property. In Proc. IEEE Symposium on Security and Privacy, pages 161{166, 1987. • 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. • 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. • J.M Rushby. Design and verification of secure systems. In Proc. ACM Symposium on Operating Sys-tem Principles, volume 15, pages 12{21, 1981.