Operating System Evaluations – What security functionality is expected

1. Operating System Evaluations – What security functionality is expected Helmut Kurth, atsec information systems Walt Farrell, IBM © IBM corp, atsec information security 2007

2. Structure • Operating Systems in the time of the Orange Book • CAPP / LSPP • Operating Systems today • US Medium Robustness Operating System PPs • Problems identified • Suggestion for new Operating System Protection Profiles © IBM corp, atsec information security 2007

3. OS as seen in the Orange Book • Development started about 1978 based on work performed in the late 60ies and early 70ies: • Grace Nibaldi: Proposed Technical Evaluation Criteria for Trusted Computer Systems, 25 October 1979, The Mitre Corporation • James P. Anderson: Computer Security Technology Planning Study, October 1972 • Paul A. Karger, Roger R. Schell: Multics Security Evaluation: Vulnerability Analysis, June 1974 • David E. Bell, Leonard J. LaPadula: Secure Computer System: Unified Exposition and Multics Interpretation © IBM corp, atsec information security 2007

4. (Pre-) Orange Book OS • Monolithic system with users accessing the system via (dumb) terminals or use of batch jobs • Physically secured areas • No network connection • Closed user community • Centrally operated and managed • Devices directly connected to system • No sharing with other systems • No support for cryptography © IBM corp, atsec information security 2007

5. Orange Book OS Security Policy • Required Policy • Access control  Discretionary Access Control to files • Flow control  Mandatory Access Control (when processing classified information) • Authentication  (human) user authentication (mainly userid/password based) • Confinement of subjects and objects (Separation) • Detection of security violation  (minimal) audit and surveillance • Limited recovery mechanisms (entering a secure state) • Mostly manual administration © IBM corp, atsec information security 2007

6. Legacy Protection Profiles • Controlled Access Protection Profile (CAPP) • Designed to reflect the Orange Book C2 requirements in CC terminology • Does not have additional functional requirements • Still used in many evaluations (although most Security Targets have a significant amount of additional security functional requirements) • Labeled Security Protection Profile (LSPP) • Designed to reflect Orange Book B1 requirements • Basically adding mandatory access control to CAPP • No longer accepted in evaluations © IBM corp, atsec information security 2007

7. What do we have Today? • The world has changed ! • Server system versus client systems • Interconnected with trusted and untrusted systems / networks • More dedicated systems for specific services • Centralized management of large number of systems • Sharing of infrastructure (disks, backup) • Dynamic with respect to hardware and software configuration • Use of services provided by other systems © IBM corp, atsec information security 2007

8. Operating Systems Today • Example (Server) • Server systems are often part of a large datacenter with several thousands of servers • Interconnected with a network infrastructure • Partly protected by dedicated firewall systems • Use of central management facilities • Use of central backup facilities • Use central services (directory, certificate server, etc.) • Cryptographic services for network authentication and protection of network links • Centralized monitoring • Little to no direct (human) "user" access (access is via services provided to network clients) © IBM corp, atsec information security 2007

9. Operating Systems Today • Example (Client) • Part of a network • Especially in the case of mobile computers, constantly changing network environment • Support for a large number of network protocols • Cryptographic services for network authentication and protection of network links • Devices get dynamically connected and disconnected • User authentication to client, client authenticates to server • Use of devices shared with other systems and accessible via the network only (disks, printers, scanners) • Sharing of local devices with other systems © IBM corp, atsec information security 2007

10. Security Functions • The challenge: • Security functions get more complicated • Security requirements are enforced by a cooperation of several IT systems • Cryptographic functions often used to support other security functions • Management gets more and more decentralized • The "old" view of a single operating system instance fully enforcing all SFRs does no longer reflect reality • Example: User authentication © IBM corp, atsec information security 2007

11. Example of User Authentication • User authenticates using a smartcard • Smart card is a separate IT system • Smart card carries the user's certificate and private key • Smart initialization/personalization becomes important • User certificates are managed by a PKI system • User attributes/privileges may be managed by a Directory Server © IBM corp, atsec information security 2007

12. Example: User Authentication • OS requires user to enter his PIN and sends this to the smart card for verification • OS retrieves user certificate from the smart card • OS validates certificate using the PKI (checking if certificate has been revoked) • OS validates that the smart card contains the user's private key using a challenge-response protocol • OS retrieves user security attributes from the directory server © IBM corp, atsec information security 2007

13. Example: User Authentication • In this example: • The OS does not store or manage a list of authorized users • The OS does not manage or store the user's authentication credentials • The OS does not manage or store the user's security attributes • Still the OS "coordinates" the authentication process • The OS may also support other authentication methods for human users • The OS may support different authentication methods for remote systems © IBM corp, atsec information security 2007

14. Comparison of Popular Operating Systems © IBM corp, atsec information security 2007  : Integrated (as part of the product)  : supported (as part of the environment)

15. New OS Protection Profiles • PP_OS_SL_MR • U.S. Government Protection Profile for Single-level Operating Systems in Environments Requiring Medium Robustness, Version 1.91 • Similar to CAPP but with detailed requirements for cryptographic functions, some minor additions in other areas and significantly higher assurance requirements • PP_OS_ML_MR • U.S. Government Protection Profile for Multi-level Operating Systems in Environments Requiring Medium Robustness, Version 1.91 • Similar to LSPP but with detailed requirements for cryptographic functions, addition of mandatory integrity control and some minor additions in other areas and significantly higher assurance requirements • None of them is well suited for a modern operating system operating in a distributed environment © IBM corp, atsec information security 2007

16. Some Problems in those PPs • Missing requirements in both PPs: • Ability for centralized user management and authentication support • Ability for centralized system management • Ability for secure communication with other trusted systems • Problematic requirements in PP_OS_SL_MR and PP_OS_ML_MR (Examples): • Discretionary access control model is very simple and inflexible • User/group based, not easily adaptable to role-based or privilege/capability based access control models • Large number of required cryptographic algorithms, but very few requirements to use them for specific purposes • Exception: protection of security attributes during import/export, protection of TSF data on Intra-TSF communication • PP_OS_ML_MR: Mandatory integrity control model not reflecting practical needs © IBM corp, atsec information security 2007

17. PP_OS_SL_MR • PP_OS_SL_MR and modern operating systems: • Requirements are fairly generic (in our opinion too generic) • Not hard to be compliant with most of the functional requirements, except: • Some requirements for crypto • Group access rights (incompatible with some existing policies) • Owner control (incompatible with some existing policies) • Limitation on scope of selectable attributes • Functional requirements not adapted to modern environments (especially server systems in commercial environments). Important requirements are missing • Hard to meet some assurance requirements (ADV_IMP_EXP.2, ADV_INT_EXP.1, AVA_CCA_EXP.2, AVA_VLA_EXP.3) © IBM corp, atsec information security 2007

18. Suggestions for a new OS PP • A new OS Protection Profile should • Clearly describe the intended operational environment • Different for server and client systems • Define the minimum requirements for a type of products • As precise as useful, without missing important requirements • Allow for sufficient flexibility to add details in a Security Target (not just by refinement, but by mandatory instantiations of additional details) • Guide the ST author how to express additional requirements • Potentially define optional requirements addressing specific objectives and/or operational environments • Include SFRs not (yet) common in existing operating systems but demanded by large groups of customers © IBM corp, atsec information security 2007

19. Suggestions for a new OS PP • Should reflect modern operating environments and requirements • Integrated into a network, some centralized management and monitoring • Should allow for "optional components" (i. e. component may be part of the OS or may be provided by the IT environment) like: • PKI services • Directory services • Key distribution center • Should require more secure authentication methods • Should require the possibility for authentication of communication partners and cryptographic protection of communication links © IBM corp, atsec information security 2007

20. Suggestions for a new OS PP • Should allow controlled secure sharing of resources with other trusted entities (including centralized backup) • Should include requirements for failure handling • Should include filtering functions for network services • Should include confidentiality and integrity protection of locally stored user data using cryptographic functions • Should allow for role- and privilege based access control • Should allow for fine-grained administrative role model using delegation of authorities • Should require an integrity policy that provides some protection against malicious software © IBM corp, atsec information security 2007

21. Conclusion • Modern operating systems provide significantly more security functions than requested by today's OS Protection Profiles • New US Medium Robustness PPs do not adequately address modern OS capabilities and the requirements for modern operating environments • Expressing those using part 2 of the CC is possible • Security Targets for modern operating systems show this • Some requirements should be included as optional requirements • Not required for all application areas, but used widely • Vendors should be involved in the definition of such new Protection Profiles © IBM corp, atsec information security 2007

22. Questions © IBM corp, atsec information security 2007