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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

Operating System Evaluations –

What security functionality is expected

Helmut Kurth, atsec information systems

Walt Farrell, IBM

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

(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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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)

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

Comparison of Popular Operating SystemsOS AIX Linux Solaris z/OS Windows Vista

Directory support

PKI

Crypto functions

Crypto HW ?

Kerberos

IPsec

SSL Tunnel

Management framework () ()

Smartcard support

Virtualization/Partitioning ()

Firewall functions

IDS support

Controlled remote access

: Integrated (as part of the product) : supported (as part of the environment)

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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)

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

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

© IB

M c

orp,

ats

ec in

form

atio

n se

curit

y 20

07

Questions