operating system evaluations what security functionality is expected l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Operating System Evaluations – What security functionality is expected PowerPoint Presentation
Download Presentation
Operating System Evaluations – What security functionality is expected

Loading in 2 Seconds...

play fullscreen
1 / 22

Operating System Evaluations – What security functionality is expected - PowerPoint PPT Presentation


  • 378 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
operating system evaluations what security functionality is expected

Operating System Evaluations – What security functionality is expected

Helmut Kurth, atsec information systems

Walt Farrell, IBM

© IBM corp, atsec information security 2007

structure
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

os as seen in the orange book
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

pre orange book os
(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

orange book os security policy
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

legacy protection profiles
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

what do we have today
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

operating systems today
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

operating systems today9
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

security functions
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

example of user authentication
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

example user authentication
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

example user authentication13
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

comparison of popular operating systems
Comparison of Popular Operating Systems

© IBM corp, atsec information security 2007

 : Integrated (as part of the product)

 : supported (as part of the environment)

new os protection profiles
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

some problems in those pps
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

pp os sl mr
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

suggestions for a new os pp
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

suggestions for a new os pp19
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

suggestions for a new os pp20
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

conclusion
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

questions
Questions

© IBM corp, atsec information security 2007