1 / 22

Operating System Evaluations – What security functionality is expected

Operating System Evaluations – What security functionality is expected. Helmut Kurth, atsec information systems Walt Farrell, IBM. Structure. Operating Systems in the time of the Orange Book CAPP / LSPP Operating Systems today US Medium Robustness Operating System PPs Problems identified

ghada
Download Presentation

Operating System Evaluations – What security functionality is expected

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related