1. © 2001 Objective Interface Systems, Inc. Common Expressions/Languages for Protection Profiles Bill Beckwith bill.beckwith@ois.com Objective Interface Systems, Inc. 13873 Park Center Road, Suite 360 Herndon, VA 20171-3247 703/295-6500 (voice) 703/295-6501 (fax) http://www.ois.com/ info@ois.com

2. © 2003 Objective Interface Systems, Inc. 2 Agenda  Objectives  Background on Common Criteria  Objectives  Arena for Common Expression  MILS Example

3. © 2003 Objective Interface Systems, Inc. 3 Background on Common Criteria  Common Criteria  Used as the basis for evaluation of security properties of IT  Permit comparability between independent security evaluations  By providing a common set of requirements for the security functions  And for assurance measures applied to them during a security evaluation  Evaluation process establishes a level of confidence  Target audience: consumers, developers, evaluators, et al  Protection Profile  An implementation-independent set of security requirements  For a category of TOEs  That meet specific consumer needs  A warning to standards authors: PPs have no APIs, no wire formats, …

4. © 2003 Objective Interface Systems, Inc. 4 EAL: Evaluated Assurance Level  EAL 1 = functionally tested  EAL 2 = structurally tested  EAL 3 = methodically tested and checked  EAL 4 = methodically designed, tested, and reviewed  analysis of security functions  informal model of security policy & independent testing  vulnerability analysis for low attack potential attackers  EAL 5 = semiformally designed and tested  semiformal functional spec & HL design + semiformal correspondence  covert channel analysis  vulnerability analysis for moderate attack potential attackers  EAL 6 = semiformally verified design and tested  structured development process & more structured architecture  vulnerability analysis for high attack potential attackers  structured presentation + semiformal LL design  systematic covert channel analysis  more comprehensive vulnerability analysis  improved CM and development environment controls  EAL 7 = formally verified design and tested  formal functional spec and HL design + formal correspondence  comprehensive testing

5. © 2003 Objective Interface Systems, Inc. 5 Objectives  Reduce time-to-understand new PPs  Develop and leverage common knowledge  Improve consistency of PPs  Common definitions  Common approach  Common creation and vetting process  Ease creation of high quality PPs  Template  Reference example  Assure composition of components  Facilitate layering of PPs  Facilitate specification of layered security architectures  Facilitate evaluation of layered security architecture implementations

6. © 2003 Objective Interface Systems, Inc. 6 Arena for Common Expression

7. © 2001 Objective Interface Systems, Inc. MILS Security: Example Architecture

8. © 2003 Objective Interface Systems, Inc. 8 Security Evolution Fail-first Patch-later (cont.)  Questions:  How many PC anti-virus programs can detect or repair handle malicious device drivers?  None!  What can an Active-X web download do to your PC?  Anything!

9. © 2003 Objective Interface Systems, Inc. 9 Privilege Mode Processing Network Data Wild Creatures of the Net, Worms, Virus,... Foundational Threats Buffer Overflow ?

10. © 2003 Objective Interface Systems, Inc. 10 Privilege Mode Processing Network Data Under MILS Network Data and Privilege Mode Processing is Separated Paradigm Shift Foundational Threats (That MILS Protects Against)

11. © 2001 Objective Interface Systems, Inc. MILS Multiple Independent Levels of Security

12. © 2003 Objective Interface Systems, Inc. 12 The Whole Point of MILS Really simple:  Dramatically reduce the amount of security critical code  Dramatically increase the scrutiny of security critical code

13. © 2003 Objective Interface Systems, Inc. 13 MILS Objective  Enable the Application Layer Entities to  Enforce, Manage, and Control  Application Level  Security Policies  where the Application Level Security Policies are  Non-Bypassable,  Evaluatable,  Always-Invoked, and  Tamper-proof.  An architecture that allows the Security Kernel to share the RESPONSIBILITY of Security with the Application.

14. © 2003 Objective Interface Systems, Inc. 14 Required Characteristics of MILS Reference Monitors Partitioning Kernel & trusted Middleware must be: Non-bypassable  Security functions cannot be circumvented Evaluatable  Security functions are small enough and simple enough for mathematically verification Always Invoked  Security functions are invoked each and every time Tamperproof  Subversive code cannot alter the security functions  By exhausting resources, over-running buffers, or other ways of making the security software fail

15. © 2003 Objective Interface Systems, Inc. 15 MILS Architecture  Three distinct layers (John Rushby, PhD)  Partitioning Kernel must  Separate process spaces (partitions)  Provide secure transfer of control between partitions  MILS Middleware provides  Application component creation  Secure inter-object message flow  e.g., ORB, device driver, file system  Applications provide  Application specific security functions  e.g., firewalls, crypto services

16. © 2003 Objective Interface Systems, Inc. 16 CSCI (Main Program) Monolithic Applications Partitioning Kernel Middleware Orange Book vs. MILS Architecture Kernel Privilege Mode Monolithic Kernel Information Flow Periods Processing Mathematical Verification User Mode Device drivers Auditing File systems MAC DAC Network I/OFault Isolation Data isolation

17. © 2003 Objective Interface Systems, Inc. 17 MILS: Like a JVM for All Applications  The Java Virtual Machine contains  Internet Java  To a confined set of operations  In each JVM  Result:  Potential for damage is limited  The MILS architecture contains  All executable code  To a confined set of operations  In each partition  Result:  Potential for damage is bounded  + Information flow is bounded Application and Data MILS Partition

18. © 2003 Objective Interface Systems, Inc. 18 MILS Network Security Policy Example MILS provides End-to-End: D1 D2 D3 BS RV RPM E1 E2 E3 RS BV BPM Red DataBlack Data Information Flow Data Isolation Periods Processing Damage Limitation CPU & Network Registers Switches, DMA, … Policy Enforcement Independent of Node Boundaries System

19. © 2003 Objective Interface Systems, Inc. 19 Partitioning Kernel: Just a Start …  Partitioning Kernel provides  Secure foundation for secure middleware  Secure Middleware provides  Most of traditional O/S capabilities  File system  Device drivers ( not in the kernel, not special privileges)  Etc.  Secure intersystem communication (PCS)  Secure foundation for building secure applications  Secure Applications can  Be built!  Be trusted to enforce application-level security policies!!!

20. © 2003 Objective Interface Systems, Inc. 20 Layer Responsibilities MILS Partitioning Kernel Functionality  Time and Space Partitioning  Data Isolation  Inter-partition Communication  Periods Processing  Minimum Interrupt Servicing  Semaphores  Timers  Instrumentation MILS Middleware Functionality  RTOS Services  Display Drivers  Keyboard Drivers  File System  Partitioned Communication System  Inter-processor Communication  Traditional Middleware  Real-time CORBA  Data Distribution Services  Web Services And nothing else!