TRUSTED OS DESIGN

1
TRUSTED OS DESIGN

• Introduction
• Trusted Design Elements
• Security Features
• Ordinary Operating Systems
• Trusted Operating Systems
• Kernelized Design
• Separation / Isolation
• Virtualization
• Layered Design

2
Introduction

• OS handles many duties - interruptions, context
  switches, user computation with minimizing
  overhead, security enforcements
• Needs of security is becoming more pervasive
• Trusted System Design Elements
• Security must be considered in every aspect of
  the design of OSs
• Security must be part of the initial design of a
  trusted OS and carried throughout the design and
  implementation

3
Design Principles of Security Mechanisms (Saltzer
and Schroeder 75)

• Economy of mechanism
• keep the design as simple and small as possible
• Fail-safe defaults
• default is no-access
• Complete mediation
• every access must be checked
• Open design
• security does not depend on the secrecy of
  mechanism

4
Design Principles of Security Mechanisms (Saltzer
and Schroeder 75)

• Separation of privilege
• a system that requires two keys is more robust
  than one that requires one
• Least privilege
• every program and every user should operate using
  the least privilege necessary to complete the job
• Least common mechanism
• minimize the amount of mechanism common to more
  than one user and depended on by all users
• Psychological acceptability
• human interface should be designed for ease of
  use
• the users mental image of his protection goals
  should match the mechanism

5
Security Features of Ordinary O S

• Authentication of users
• Protection of memory
• File and I/O device access control
• Allocation and access control to general objects
• Enforcement of sharing
• Guarantee of fair service
• Interprocess communication and synchronization
• Protection of operating system protection
  structure

6
Security Features of Ordinary O S

• FIGURE 5-10 Overview of an Operating Systems
  Function

7
What makes a Secure OS? Or Trusted OS

• Extra security features (compared to ordinary OS)
• Stronger authentication mechanisms
• Example require token password
• More security policy options
• Example only let users read file f for purpose p
• Logging and other features
• More secure implementation
• Apply secure design and coding principles
• Assurance and certification
• Code audit or formal verification
• Maintenance procedures
• Apply patches, etc.

8
Security Features of Trusted O S(contd)

• FIGURE 5-11 Security Functions of a Trusted
  Operating System

9
Secure Operating Systems

• Will discuss
• Mechanisms associated with secure OS
• Standards for certification
• Mostly used by government, some commercial
  interest

10
Security Features of Trusted OS

• Identification and Authentication
• Mandatory and Discretionary Access Control
• MAC access control policy decisions are made
  beyond the control of the individual owner of an
  object (military security)
• DAC access control policy allows a certain
  amount of access control to the discretion of the
  objects owner or anyone who is authorized to
  control the objects access (commercial security)
• both can be applied to the same object
• MAC has precedence over DAC

11
Security Features of Trusted OS(contd)

• Object Reuse Protection
• object reuse attack an attacker claims a large
  amount of disk space and then scavenges for
  sensitive data
• OS clears all space (memory,registers,storages,
  magnetic media) to be reassigned to protect
  object reuse attack
• Complete Mediation
• Check all access and prevent any access that
  circumvents monitor

12
Security Features of Trusted OS(contd)

• Trusted path
• for critical operation (password setting,
  changing access permissions), user want an
  unmistakable communication, called a trusted path
• Accountability and Audit
• accountability entails maintaining a log of
  security-relevant events
• The log contains each event and the person
  responsible for operations

13
Security Features of Trusted O S(contd)

• Intrusion Detection
• detect intrusion (ideally) while they occur
• Anomaly detection
• Learn normal activity, Report abnormal actions
• Attack detection
• Recognize patterns associated with known attacks
• Audit Log
• The central problem with audit are volume and
  analysis
• Audit reduction is required, but the analysis
  capability should be maintained

14
Audit Log

• Log security-related events
• Protect audit log
• Write to write-once non-volatile medium
• Audit logs can become huge
• Manage size by following appropriate policy
• Storage becomes more feasible
• Analysis more feasible since entries more
  meaningful
• Example policies
• Audit only first, last access by process to a
  file
• Do not record routine, expected events
• E.g., starting one process always loads

15
Trusted Path

• Mechanism that provides confidence that the user
  is communicating with what the user intended to
  communicate with (typically TCB)
• attackers can't intercept or modify whatever
  information is being communicated.
• defends attacks such as fake login programs
• Spoofing
• Fool user/process into thinking they are
  communicating with secure part of system
• Intercept communication

16
Trusted path

• Mechanisms to prevent spoofing
• Special key sequence for passwd command
  intercepted by trusted kernel (e.g,
  ctrl-alt-delete)
• Allow security-relevant changes only at boot
  time, before user processes loaded

17
Security Kernel

• Kernel part of an OS that performs lowest-level
  functions
• Security kernel
• is responsible for enforcing the security
  mechanism of the OS
• provides the security interface among the H/W,
  OS, other parts
• Why security functions may be isolated in a
  security kernel ?
• Coverage ?? ??? security kernel? ??
• Separation OS ??? ?? ? ??? ??? ?? - ???? ??
• Unity ?? ?? ??? ??? ?? ???? ??
• Modifiability ??, ??? ??
• Compactness ?? ??? security function? ?? - ???
  ??
• Verifiability ?? ?? ??

18
Reference Monitor

• The most important part of a security kernel
  which controls all accesses to objects
• It must be
• small
• tamperproof
• always invoked for every access
• In addition to the reference monitor, the
  security kernel includes other parts of security
  suites
• audit, identification and authentication, setting
  enforcement parameters (access rights),
• These parts interact with the reference monitor

19
Kernelized Design

• Trusted Computing Base
• Hardware and software for enforcing security
  rules
• Reference monitor
• Part of TCB
• All system calls go through reference monitor for
  security checking
• Most OS not designed this way

User space
User process
Kernel space
OS kernel
TCB
Reference monitor
20
Trusted Computing Base

• The set of all hardware, software and procedural
  components that enforce the security policy.
• in order to break security, an attacker must
  subvert one or more of them.
• What consists of the conceptual Trusted Computing
  Based in a Unix/Linux system?
• hardware, kernel, system binaries, system
  configuration files, etc.

21
Trusted Computing

• Trusted Computing Group
• an alliance of Microsoft, Intel, IBM, HP and AMD
  which promotes a standard for a more secure' PC.
  
• formerly TCPA
• Next-Generation Secure Computing Base (NGSCB) by
  Microsoft
• formerly Palladium
• claims to intend to provide strong process
  isolation, sealed storage, secure path to and
  from the user, and attestation

22
Trusted Computing

• Ensure that users can't tamper with the
  application software, and these applications can
  communicate securely with their authors and with
  each other
• driven by Digital Right Management needs

23
TCB (contd)

• TCB must maintain the secrecy and integrity of
  each domain, monitors four basic interactions
• Process activation
• Execution domain switching
• Memory protection
• I/O operation
• TCB Design
• Because all security-relevant code is located in
  one part, it is convenient to divide the
  operating system into TCB and non-TCB aspect.
• To ensure that the security enforcement cannot be
  affected by non-TCB code, TCB code must run in
  some protected state

24
TCB (contd)
User applications Utilities User request
interpreter User process coordination,
synchronization User environment objects,
names(e.g. , files) User I/O Procedures, user
processes Creation and deletion of user
objects Directories Extended types Segmentation,
paging, memory management
User applications
Non-TCB
Primitive I/O Basic operations Clock
timing Interrupt handling Hardware registers,
memory Capabilities
TCB
25
TCB (contd)

• TCB Implementation Combined Security
  Kernel/Operating System
• Security-relevant activities tend to be performed
  in different places
• In modular OS, separate activities can be handled
  in independent modules
• Collecting all security functions into the TCB
  may destroy the modularity of an existing OS
• Security functions are separated and placed in
  different places of the OS (Fig 5-14)

26
TCB (contd)
27
TCB (contd)

• TCB Implementation Separate Security Kernel
• Design the security kernel first and then design
  the OS around it
• The security kernel forms an interface layer
• monitors all operating system hardware accesses
• performs all protection functions
• The OS itself handles most functions not related
  to security
• The security kernel can be small and efficient

28
TCB (contd)
29
Separation / Isolation

• 4 ways of separation
• Physical separation 2 different processes use
  two different H/W
• Temporal separation different processes are run
  at different times
• Cryptographic separation encrypt data so that
  different processes can not access sensitive data
• Logical separation
• Also called Isolation
• a process such as reference monitor separates one
  users objects from those of another user

30
Virtualization

• a powerful tool for trusted system designers
  because it allows users to access complex objects
  in a carefully controlled manner
• virtualization The OS emulates or simulates a
  collection of a computer systems resources
• Virtual machine a collection of real or
  simulated hardware facilities
• The OS provides the virtual resource to the user,
  while the security kernel precisely controls user
  accesses

31
Types of VMs
32
Multiple Virtual Memory Spaces

• IBM MVS/ESA
• paging system
• each users logical address space is separated
  from that of other users
• includes the OS in each users logical address
  space

33
Virtual Machines

• Conventional OS controls hardware facilities
  directly

34
Virtual Machines (contd)

• IBM Processor Resources/System Manager (PR/SM)
• provides an entire virtual machine to each user
• Each user has logical memory, I/O devices, file,
  other resources
• gives the user a full set of hardware features

35
Layered Design

• the most sensitive operations in the innermost
  layers
• the more trusted processes are closer to the
  center
• depict the trusted OS in layers as a stack with
  the security functions closest to the hardware

36
Layered Design (contd)

• A single logical function implemented in several
  modules in different layers
• The modules of each layer perform operations of a
  certain degree of sensitivity

37
Layered Design (contd)

• Layered structure used for the Provably Secure OS
  (PSOS) Neu86

38
SELinux

• Security-enhanced Linux system (NSA)
• Enforce separation of information based on
  confidentiality and integrity requirements
• Mandatory access control incorporated into the
  major subsystems of the kernel
• Limit tampering and bypassing of application
  security mechanisms
• Confine damage caused by malicious applications

http//www.nsa.gov/selinux/
39
What is SE Linux? (Wikipedia)

• SE Linux is a research prototype of the Linux
  kernel and a number of utilities with enhanced
  security functionality
• Designed to demonstrate the value of mandatory
  access controls and how such controls could be
  added to Linux.
• The SELinux kernel contains new architectural
  components originally developed to improve the
  security of the Flask operating system.
• These architectural components provide general
  support for the enforcement of many kinds of
  mandatory access control policies, including
  those based on the concepts of Type Enforcement,
  Role-based Access Control, and Multi-level
  Security.

40
What functions does SE Linux provides?

• The SE Linux kernel enforces MAC policies that
  confine user programs and system servers to the
  minimum amount of privilege they require to do
  their jobs.
• When confined in this way, the ability of these
  user programs and system daemons to cause harm
  when compromised (via buffer overflows or
  misconfigurations, for example) is reduced or
  eliminated.
• This confinement mechanism operates
  independently of the traditional Linux access
  control mechanisms.
• It has no concept of a "root" super-user, and
  does not share the well-known shortcomings of the
  traditional Linux security mechanisms (such as a
  dependence on setuid/setgid binaries).

41
What functions does SE Linux provides?

• The security of an unmodified Linux system
  depends on the correctness of the kernel, all the
  privileged applications, and each of their
  configurations.
• A problem in any one of these areas may allow the
  compromise of the entire system.
• In contrast, the security of the SE Linux kernel
  depends primarily on the correctness of the
  kernel and its security policy configuration.
• A problem or compromise of individual user
  programs and system daemons do not pose a threat
  to the security of other user programs and system
  daemons or to the security of the system as a
  whole.

42
What is the SE Linux good for?

• The SE Linux's new features are designed to
  enforce the separation of information based on
  confidentiality and integrity requirements.
• They are designed for preventing processes from
• reading data and programs,
• tampering with data and programs,
• bypassing application security mechanisms,
• executing untrustworthy programs, or
• interfering with other processes in violation of
  the system security policy.
• They also help to confine the potential damage
  that can be caused by malicious or flawed
  programs.

43
Why Linux?

• Open source
• Already subject to public review
• This by itself does not guarantee security
• NSA can review source, modify and extend
• Hope to encourage additional operating system
  security research
• Released under the same terms and conditions as
  the original sources.
• includes documentation and source code

44
5.5 Assurance in Trusted O S

• Introduction
• Typical Operating System Flaws
• I/O processing
• Ambiguity in access policy
• Incomplete mediation
• Generality
• Assurance Methods
• Testing
• Formal Verification
• Validation

• Evaluation
• U.S Orange Book
• German Green Book
• British Criteria
• Other Activities
• ITSEC
• U.S combined federal criteria
• Common criteria

45
Introduction

• How can we have confidence in the security
  features of an OS?
• Ways of determining whether a particular OS is
  appropriate for a certain set of security needs
• Ways of demonstrating the security of an OS
• testing,
• formal verification, and
• information validation

46
Typical Operating System Flaws

• I/O Processing The largest single source of
  flaws
• I/O is performed by independent HW subsystems
  which often fall outside the security kernel or
  security restrictions implemented by an OS
• I/O code is often much more complex and much more
  dependent on the specific device HW
• I/O activity sometimes bypasses the OS functions
  for fast data transfer, thus bypassing the
  protection features
• I/O operations are often character-oriented, and
  also for fast data transfer, some security
  functions may be limited

47
Typical Operating System Flaws

• Ambiguity in access policy (between isolation
  sharing)
• Separate users vs. share resources.
• Creates ambiguity at implementation
• Incomplete mediation (for efficiency reason)
• Access checks only conducted once per operation.
• No constant monitoring.
• designers adopt the most efficient enforcement.
• Generality (especially among commercial OS for
  large system)
• let the users customize operating system
  installation themselves.
• 3rd party products allowed to run with same
  privileges as OS .

48
Assurance methods

• Testing
• Can demonstrate existence of flaw, not absence
• Formal verification
• Time-consuming, painstaking process
• Validation
• Requirements checking
• Design and code reviews
• Sit around table, drink lots of coffee,
• System testing

49
Assurance Methods

• Testing
• Only demonstrates the existence of a problem
  (passing tests does not mean the absence of
  problem)
• hard to achieve adequate test coverage due to
  combinatorial explosion of inputs
• testing based only on observable effects
• Various testing methods but not complete

50
Assurance Methods

• Penetration testing
• a testing strategy
• also called tiger team analysis or ethical
  hacking
• experts try to crack the system being tested

51
Assurance Methods

• Formal verification
• The correctness of OS is proven formally (like a
  program verification)
• Theorem Provers (rules of logic)
• Two principal difficulties
• Time may take several people months or even
  years to formally verify a system.
• Complexity - for some large systems it is
  hopeless to attempt

52
Assurance Methods
Example of program verification
53
Assurance Methods

• Validation - Counterpart to verification
  assuring that the system developers have
  implemented all requirements.
• Requirements checking
• Cross-check each operating system requirement
  with the systems source code and execution-time
  behavior.
• Design and code review
• Scrutinize the design or code to assure
  traceability from each requirement to design and
  code components
• System testing
• The programmers or an independent test team
  select data to check the system

54
Open Source

• A debate has opened in the software development
  community over so-called open source operating
  systems
• Linux operating system
• 27 of high-end servers run Linux.
• Open source vs. closed source
• Benefits of open source
• Cost
• Quality
• Support
• Extensibility

55
Assurance Criteria

• Criteria are specified to enable evaluation
• Originally motivated by military applications,
  but now is much wider
• Examples
• Orange Book
• Common Criteria

56
Evaluation

• Most consumers (users, system purchasers) are not
  security experts, and thus they are incapable of
  verifying, checking, and determining the
  accuracy, validity, correctness, etc of the
  system
• An independent third-party experts evaluation is
  very desirable
• Several evaluation schemes exist
• U.S. Orange book (TCSEC Trusted Computer System
  Evaluation Criteria)
• European ITSEC (Information Technology Security
  Evaluation Criteria)
• ITSEC
• U.S. Combined Federal Criteria
• Common Criteria

57
Rainbow Series

• DoD Trusted Computer Sys Evaluation Criteria
  (Orange Book)
• Audit in Trusted Systems
  (Tan Book)
• Configuration Management in Trusted Systems
  (Amber Book)
• Trusted Distribution in Trusted Systems (Dark
  Lavender Book)
• Security Modeling in Trusted Systems
  (Aqua Book)
• Formal Verification Systems
  (Purple Book)
• Covert Channel Analysis of Trusted Systems (Light
  Pink Book)
• many more

http//www.radium.ncsc.mil/tpep/library/rainbow/in
dex.html
58
TCSEC 19831999

• Trusted Computer System Evaluation Criteria
• Also known as the Orange Book
• Series that expanded on Orange Book in specific
  areas was called Rainbow Series
• Developed by National Computer Security Center,
  US Dept. of Defense in late 1970s
• A set of standards for computing systems having
  different levels of security requirements

59
TCSEC 19831999

• 7 classes (levels, ratings) of NCSC certification
• D, C1, C2, B1, B2, B3, A1
• Heavily influenced by Bell-LaPadula model and
  reference monitor concept
• Emphasizes confidentiality

60
TCSEC Requirements

• Security Policy
• Accountability
• Assurance
• Documentation
• Next few slides details not important
• Main point Higher levels require more work ,
  documentation and configuration management are
  part of the criteria

61
TCSEC Requirements

• The security requirements for each of the seven
  evaluated classes

62
TCSEC Criteria
63
TCSEC Criteria(continued)

• Class D Minimal Protection
• No security requirements
• Class C For environments with cooperating users
• Class C1 Discretionary Security Protection
• Discretionary control A user is allowed to
  decide when the controls apply, when they do not,
  and which named individuals or groups are allowed
  access
• protected mode OS, authenticated login, DAC,
  security testing and documentation (Unix)
• Class C2 Controlled Access Protection
• Still discretionary control but the granularity
  of control is finer. Audit log capability.
• DAC to level of individual user, object
  initialization, auditing
  (Windows NT 4.0)

64
TCSEC Criteria(continued)

• Class B, A
• All users and objects must be assigned a security
  label (classified, unclassified, etc.)
• System must enforce Bell-La Padula model
• Class B1 Labeled Security Protection
• classification and Bell-La Padula
• Now include mandatory access control.
• Each controlled subject and object must be
  assigned a security level (label), and these
  labels must be used as the basis for access
  control decisions.
• Must implement mandatory access control policy
  (Bell La Padula model)

65
TCSEC Criteria(continued)

• Class B2 Structured Protection
• Design requirement is enhanced. Security must be
  included in the design of the OS
• system designed in top-down modular way, must be
  possible to verify, covert channels must be
  analyzed
• Class B3 Security Domains
• Design of a system must begin with construction
  and proof of a formal model of security
• ACLs with users and groups, formal TCB must be
  presented, adequate security auditing, secure
  crash recovery

66
TCSEC Criteria(continued)

• Class A1 Verified Design
• Formally verified system design
• Formal proof of protection system, formal proof
  that model is correct, demonstration that
  implementation conforms to model, formal covert
  channel analysis

67
Limitations

• Written for operating systems
• NCSC introduced interpretations for other
  things such as networks (Trusted Network
  Interpretation, the Red Book), databases (Trusted
  Database Interpretation, the Purple or Lavender
  Book)
• Focuses on BLP
• Most commercial firms do not need MAC
• Does not address integrity or availability
• Critical to commercial firms
• Combine functionality and assurance in a single
  linear scale

68
Contributions

• Heightened awareness in commercial sector to
  computer security needs
• Commercial firms could not use it for their
  products
• Did not cover networks, applications
• Led to wave of new approaches to evaluation
• Some commercial firms began offering
  certifications
• Basis for several other schemes, such as Federal
  Criteria, Common Criteria

69
European ITSEC Evaluation

• Information Technology Security Evaluation
  Criteria
• Origins of the ITSEC
• England, Germany, France independently began work
  on evaluation criteria.
• England and Germany published their first drafts
  in 1989
• France had its criteria in limited review when
  these three nations, joined by the Netherlands,
  decided to work together to develop a common
  criteria document.

70
ITSEC

• A harmonized version for use by all European
  Union member nations
• ITSEC preserved the German functionality classes
  F1F10, while at the same time allowing the
  flexibility of the British claims language.
• There is similarly an effectiveness component to
  the evaluation, corresponding to the U.S. notion
  of assurance and to the German E0-E7
  effectiveness levels.

71
ITSEC

• A vendor has to define a target of evaluation
  (TOE), the item that is the evaluations focus.
• The vendor states the following information
• System security policy or rationale
• Specification of security-enforcing functions
• Definition of the mechanisms of the product by
  which security is enforced
• A claim about the strength of the mechanisms
• The target evaluation level in terms of
  functionality and effectiveness

72
ITSEC

• The evaluation proceeds to determine the
  following aspects
• Suitability of functionality
• Binding of functionality
• Vulnerabilities
• Ease of use
• Strength of mechanism

73
ITSEC vs. Orange Book
74
U.S Combined Federal Criteria

• Combined federal criteria was produced jointly by
  the National Institute for Standards and
  Technology(NIST) and the National Security
  Agency(NSA)
• Introduce the notions of protection profile and
  security target
• Protection profile
• A user would generate a protection profile to
  detail the protection needs, both functional and
  assurance, for a specific situation or a generic
  scenario.
• Security target
• A vendor would then map the requirements of the
  protection profile in the context of specific
  product onto a statement called security target

75
U.S Combined Federal Criteria

• Assurance
• Profile Specific Assurance
• Profile Independent Assurance
• Dependencies
• Internal Dependencies
• External Dependencies

• Protection Profile
• Rationale
• Protection Policy and regulations
• Information Protection Philosophy
• Expected Threats
• Environmental Assumption
• Intended Use
• Functionality
• Security Features
• Security Services
• Available Security Mechanisms

76
U.S Combined Federal Criteria

• Security target
• Rationale
• Implementation fundamentals
• Information Protection Philosophy
• Countered threats
• Environmental Assumptions
• Intended Use
• Functionality
• Security Features
• Security Services
• Security Mechanisms selected

• Assurance
• Target-specific assurances
• Target-Independent Assurance
• Dependencies
• Internal Dependencies
• External Dependencies

77
The Common Criteria (CC) ParadigmStuart Katzke,
Ph.D.Senior Research ScientistNational
Institute of Standards Technology100 Bureau
Drive Stop 8930Gaithersburg, MD 20899(301)
975-4768skatzke_at_nist.govfax [phone]
78
An Evolutionary Process

• Two decades of research and development

Common Criteria 1993-98
Federal Criteria 1992
US-NIST MSFR 1990
US-DOD TCSEC 1983-85
ISO 15408 Common Criteria 1999
Canada TCPEC 1993
Europe ITSEC 1991
European National/Regional Initiatives 1989-93
Canadian Initiatives 1989-93
79
The Common Criteria(International
Standard-ISO/IEC 15408)

• What the standard is
• Common structure and language for expressing
  product/system IT security requirements (Part 1)
• Catalog of standardized IT security requirement
  components and packages (Parts 2 and 3)
• How the standard is used The CC Paradigm
• Develop protection profiles and security targets
  -- specific IT security requirements and
  specifications for products and systems
• Evaluate products and systems against known and
  understood IT security requirements

80
IT Security Requirements
The Common Criteria defines two types of IT
security requirements--

• Functional Requirements
• - for defining security behavior
• of the IT product or system
• implemented requirements
• become security functions

• Assurance Requirements
• - for establishing confidence in security
  functions
• correctness of implementation
• effectiveness in satisfying security
  objectives

• Examples
• Identification Authentication
• Audit
• User Data Protection
• Cryptographic Support

• Examples
• Development
• Configuration Management
• Life Cycle Support
• Testing
• Vulnerability Analysis

81
Evaluation Assurance Levels
Common Criteria defines seven hierarchical
assurance levels--
EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7
EAL Designation
Functionally Tested Structurally
Tested Methodically Tested Checked Methodically
Designed, Tested Reviewed Semiformally Designed
Tested Semiformally Verified Design
Tested Formally Verified Design Tested
82
Protection Profiles (generic) Security Targets
(specific)

• Protection Profile contents
• Introduction
• TOE Description
• Security Environment
• Assumptions
• Threats
• Organizational security policies
• Security Objectives
• Security Requirements
• Functional requirements
• Assurance requirements
• Rationale

• Security Target contents
• Introduction
• TOE Description
• Security Environment
• Assumptions
• Threats
• Organizational security policies
• Security Objectives
• Security Requirements
• Functional requirements
• Assurance requirements
• TOE Summary Specification
• PP Claims
• Rationale

83
Protection Profiles

• A CC protection profile (PP) is an
  implementation-independent set of security
  requirements for a category of products or
  systems that meet specific consumer needs
• a document, typically created by a user or user
  community,
• A PP effectively defines a class of security
  devices (for example, smart cards or network
  firewalls).
• Subject to review and certified
• Requirements
• Functional
• Assurance
• EAL

84
Protection Profiles

• Product vendors can choose to implement products
  that comply with one or more PPs, and have their
  products evaluated against those PPs.
• In such a case, a PP may serve as a template for
  the product's ST (Security Target), or the
  authors of the ST will at least ensure that all
  requirements in relevant PPs also appear in the
  target's ST document.
• Customers looking for particular types of
  products can focus on those certified against the
  PP that meets their requirements.

85
Security Targets (ST)

• A security target (ST) is a document that
  identifies set of security requirements and
  specifications to be used for evaluation of an
  identified product or system
• Describes specific security functions and
  mechanisms
• Each target is evaluated against the SFRs
  established in its ST, no more and no less.
• This allows vendors to tailor the evaluation to
  accurately match the intended capabilities of
  their product.

86
Security Targets (ST)

• This means that a network firewall does not have
  to meet the same functional requirements as a
  database management system, and that different
  firewalls may in fact be evaluated against
  completely different lists of requirements.
• The ST is usually published so that potential
  customers may determine the specific security
  features that have been certified by the
  evaluation.

87
Profiles and Targets (Some Examples)

• Protection Profiles (Product Independent)
• Operating Systems (C2, CS2, RBAC)
• Firewalls (Packet Filter and Application)
• Smart cards (Stored value and other)
• Security Targets (Product Specific)
• Oracle Database Management System
• Lucent, Cisco, Checkpoint Firewalls

88
Beneficiaries of the Standard

• Consumer Consortia (Users Groups)
• Use ISO/IEC 15408 to build protection profiles
  expressing their needs
• Work with developers to build matching IT
  products and systems
• Individual IT Consumers
• Look for protection profiles matching their
  security requirements -- use in procurement
  specifications
• In acquisitions, give preference to products that
  have been evaluated
• Product and System Developers
• Build products to meet targeted/selected
  protection profiles
• Use ISO/IEC 15408 to specify IT product and
  system security capabilities via security targets
• Product Evaluators and Certifiers
• Use ISO-compliant protection profiles and
  security targets to measure IT product and system
  compliance

89
Defining Requirements
90
Industry Responds
91
Demonstrating Conformance
92
Validating Test Results
Validation Body validates laboratorys test
results
Validation Report
Common Criteria Validation Body
Laboratory submits test report to Validation Body
NIAP issues Validation Report and Common Criteria
Certificate
93
Mutual Recognition Arrangement

• National Information Assurance partnership
  (NIAP), in conjunction with the U.S. State
  Department, negotiated a Recognition Arrangement
  that
• Provides recognition of Common Criteria
  certificates by 19 nations
• Canada, United Kingdom, France, Germany,
  Australia, New Zealand, Greece, Norway, Finland,
  Italy, Israel, Spain, The Netherlands, Japan,
  Hungary, Austria, Sweden, Turkey, US
• Eliminates need for costly security evaluations
  in more than one country
• Offers excellent global market opportunities for
  U.S. IT industry

94
Industry Use of the CC

• Industry can use the CC paradigm in several
  important ways
• For IT security requirements definition (by
  technology area and sector)
• PPs
• STs
• By encouraging vendors/developers to undergo IT
  security evaluations and assessments
• By giving acquisition preference/consideration to
  evaluated products (all things being equal)
• Meets requirements
• Meets cost-benefit ( other) requirements

95
Developing Security Requirements(Technology Area
and Industry Sector)
Generalized, Consumer Driven Security Requirements
Technology Area Protection Profiles
Technology Area Protection Profiles
Technology Area Protection Profiles
Technology Area Protection Profiles
Database Systems
Operating Systems
Firewalls
Applications

• Defense
• Banking
• Process
• Control
• Insurance

• Healthcare
• Finance
• Transportation
• Manufacturing

Operating System PP
DBMS PP
Firewall PP
Application PP
IT System Security Requirements
Enterprise Information Systems within Sectors
96
NIST Forums(Technology Area and Industry Sector)

• Focus on security requirements definition
• Achieve results in community driven, cooperative
  environment
• Reach critical mass and rapid convergence on IT
  security requirements
• Raise security bar across the board increase
  later
• May require compromise on less than optimal
  solutions
• Contribute requirements to standards groups

97
Forum Expectations

• Community ownership of security requirements
• Leadership
• Funding/resources
• Technical expertise
• Community adoption and enforcement through
  acquisition
• Increased demand for evaluated IT products and
  systems

98
Recent Forum Successes

• Smart Card Security Users Group
• (Technology Area)
• Healthcare Security Forum
• (Industry Sector)
• Process Control Security Forum
• (Industry Sector)
• Telecommunications Security Forum
• (Industry Sector)

99
Potential Forums

• Technology Areas
• Operating Systems
• Database Systems
• Firewalls
• Biometrics
• Industry Sectors
• Insurance
• Audit and Controls
• Banking and Finance
• Manufacturing

100
Future

• Identify areas of common interest for NIST and
  IEEE
• Identify potential vehicles for cooperation and
  collaboration, e.g., standard activity,
  workshops, conferences, forums
• Follow-on meetings to discuss implementation
  details

101
Common Criteria

• Three parts
• CC Documents
• Protection profiles requirements for category
  of systems
• Functional requirements
• Assurance requirements
• CC Evaluation Methodology
• National Schemes (local ways of doing evaluation)

http//www.commoncriteria.org/
102
(No Transcript)
103
CC Functional Requirements

• Security Functional Requirements (SFRs) - specify
  individual security functions which may be
  provided by a product.
• The Common Criteria presents a standard catalogue
  of such functions. For example, an SFR may state
  how a user acting a particular role might be
  authenticated.
• The list of SFRs can vary from one evaluation to
  the next, even if two targets are the same type
  of product.
• Although Common Criteria does not prescribe any
  SFRs to be included in an ST, it identifies
  dependencies where the correct operation of one
  function (such as the ability to limit access
  according to roles) is dependent on another (such
  as the ability to identify individual roles).

104
(No Transcript)
105
CC Functional Requirements

• Contains 11 classes of functional requirements
• Each contain one or more families
• Elaborate naming and numbering scheme
• Classes
• 1.Security Audit, 2. Communication, 3.
  Cryptographic Support,
• 4. User Data Protection, 5. Identification
  and Authentication,
• 6. Security Management, 7. Privacy, 8.
  Protection of Security Functions,
• 9. Resource Utilization, 10. TOE Access,
  11. Trusted Path
• Families of Identification and Authentication
• 1. Authentication Failures, 2. User Attribute
  Definition,
• 3. Specification of Secrets, 4. User
  Authentication,
• 5. User Identification, 6. User/Subject
  Binding

106
(No Transcript)
107
CC Assurance Requirements

• Security Assurance Requirements - descriptions of
  the measures taken during development and
  evaluation of the product to assure compliance
  with the claimed security functionality.
• For example, an evaluation may require that all
  source code is kept in a change management
  system, or that full functional testing is
  performed.
• The Common Criteria provides a catalogue of
  these, and the requirements may vary from one
  evaluation to the next.
• The requirements for particular targets or types
  of products are documented in the ST and PP,
  respectively.

108
CC Assurance Requirements

• Ten security assurance classes
• Classes
• Protection Profile Evaluation
• Security Target Evaluation
• Configuration Management
• Delivery and Operation
• Development
• Guidance Documentation
• Life Cycle
• Tests
• Vulnerabilities Assessment
• Maintenance of Assurance

109
(No Transcript)
110
Protection Profiles

• Example Controlled Access PP (CAPP_V1.d)
• Security functional requirements
• Authentication, User Data Protection, Prevent
  Audit Loss
• Security assurance requirements
• Security testing, Admin guidance, Life-cycle
  support,
• Assumes non-hostile and well-managed users
• Does not consider malicious system developers

111
Common Criteria

• Figure 5-24 Classes, Families, and Components in
  Common Criteria

class
Example Identification and Authentication
family
Example User Authentication
component
Example Challenge-Response Authentication
Mechanism
112
Common Criteria

• Figure 5-25 Functionality or Assurance packages

Example ITSEC F-C2 (DAC)
113
Common Criteria

• Figure 5-26 Protection profile and security
  targets

Example ITSEC F-C2
114
Evaluation Assurance Level

• the numerical rating assigned to the target to
  reflect the assurance requirements fulfilled
  during the evaluation.
• Each EAL corresponds to a package of assurance
  requirements which covers the complete
  development of a product, with a given level of
  strictness.
• Common Criteria lists seven levels
• EAL1 being the most basic and EAL7 being the most
  stringent.
• Normally, an ST or PP author will choose one of
  these packages, possibly 'augmenting'
  requirements in a few areas with requirements
  from a higher level.
• Higher EAL levels do not necessarily imply
  "better security", they only mean that the
  claimed security assurance of the TOE has been
  more extensively validated.

115
Evaluation Assurance Levels 1 4

• EAL 1 Functionally Tested
• Review of functional and interface specifications
• Some independent testing
• EAL 2 Structurally Tested
• Analysis of security functions, incl high-level
  design
• Independent testing, review of developer testing
• EAL 3 Methodically Tested and Checked
• Development environment controls config mgmt
• EAL 4 Methodically Designed, Tested, Reviewed
• Informal spec of security policy, Independent
  testing

116
Evaluation Assurance Levels 5 7

• EAL 5 Semiformally Designed and Tested
• Formal model, modular design
• Vulnerability search, covert channel analysis
• EAL 6 Semiformally Verified Design and Tested
• Structured development process
• EAL 7 Formally Verified Design and Tested
• Formal presentation of functional specification
• Product or system design must be simple
• Independent confirmation of developer tests

117
Example Windows 2000, EAL 4

• Evaluation performed by SAIC
• Used Controlled Access Protection Profile
• Level EAL 4 Flaw Remediation
• EAL 4 Methodically Designed, Tested, Reviewed
  
• Flaw Remediation
• Evaluation based on specific configurations
• Produced configuration guide that may be useful

118
(No Transcript)
119
Example Windows 2000, EAL 4

• So, if a product is Common Criteria certified,
  does that mean it is very secure? Let's look at
  an example.
• Microsoft Windows 2000 is certified product at
  EAL4, but regular security patches for security
  vulnerabilities are still published by Microsoft
  for Windows 2000.
• This is possible because the process of getting
  an Common Criteria certification allows a vendor
  to make certain assumptions about the operating
  environment and the strength of threats, if any,
  faced by the product in that environment.
• Based on these assumptions, the claimed security
  functions of the product are evaluated.
• Since Microsoft Windows 2000 has been EAL4
  certified, it should only be considered secure in
  the assumed, specified circumstances, also known
  as the evaluated configuration, specified by
  Microsoft.

120
Example Windows 2000, EAL 4

• Whether you run Microsoft Windows 2000 in the
  precise evaluated configuration or not, you
  should apply Microsoft's security patches for the
  vulnerabilities in Windows 2000 as they continue
  to appear.
• If any of these security vulnerabilities are
  exploitable in the product's evaluated
  configuration, the product's Common Criteria
  certification should be voluntarily withdrawn by
  the vendor.
• Alternatively, the vendor should re-evaluate the
  product to include application of the patches to
  fix the security vulnerabilities within the
  evaluated configuration.
• Failure by the vendor to take either of these
  steps would result in involuntary withdrawal of
  the product's certification by the certification
  body of the country in which the product was
  evaluated.
• Microsoft Windows 2000 remains at EAL4 without
  including the application of any Microsoft
  security vulnerability patches in its evaluated
  configuration. This shows both the limitation and
  strength of an evaluated configuration.

121
Common Criteria

• So far, most PPs and most evaluated STs/certified
  products have been for IT components (e.g.,
  firewalls, operating systems, smart cards).
• Common Criteria certification is sometimes
  specified for IT procurement.
• Other standards containing, e.g, interoperation,
  system management, user training, supplement CC
  and other product standards.
• Examples include the ISO 17799 (Or more properly
  BS 7799-2, which is now ISO/IEC 27001) or the
  German IT-Grundschutzhandbuch.

122
Is Windows Secure?

• Good things
• Design goals include security goals
• Independent review, configuration guidelines
• But
• Secure is a complex concept
• What properties protected against what attacks?
• Typical installation includes more than just OS
• Many problems arise from applications, device
  drivers
• Windows driver certification program

123
Limitations of Secure OS

• Noninterference
• Actions by high-level users (secret, top secret)
  should not be observable by low-level users
  (unclassified, )
• Difficult to achieve and prove, not impossible
• Covert Channels
• Can user of system deliberately communicate
  secret information to external collaborator?

124
Noninterference
High
High
Process
inputs
outputs
Low
Low
inputs
outputs
125
Example Smart Card
Signing
Tamper-proof hardware
key
Challenge
Response
input
output
126
Covert Channels

• Butler Lampson
• Difficulty achieving confinement
• Communicate by using CPU, locking/unlocking file,
  sending/delaying msg,
• Gustavus Simmons
• Cryptographic techniques make it impossible to
  detect presence of a covert channel