Constructing Trusted Code Base XIV
Certification
Today’s news (on tvn24bis.pl)
(June 6th on BBC)
security vulnerability CVE-2014-0224 was discovered by
Masashi Kikuchi
OpenSSL accepts ChangeCipherSpec (CCS) inappropriately
during a handshake
the bug hasn’t been found for over 16 years
Masashi Kikuchi did a code review before attempting to write
TLS/SSL in Coq
Certification of security
the need of security
the need to check security
the standards of security
the community of security
Certification of security – currently
Common Criteria (CC): The Common Criteria for Information
Technology Security Evaluation
ISO/IEC 15408 (ver. 3.1 rev. 4)
process of CC:
computer system users can specify their security functional and assurance requirements
producents can then implement and/or make claims about the security attributes of their products
testing laboratories can evaluate the products to determine if they actually meet the claims
three stages: specification, implementation and evaluation
the source of need: government agencies, big companies
Predecesors of CC
ITSEC
European standard
developed in the early 1990
involved: France, Germany, the Netherlands and the UK adopted by some other countries, e.g. Australia.
CTCPEC
Canadian standard
first published in May 1993 involved: Canada
used jointly by evaluators from both USA and Canada
TCSEC
USA
developed in late 80s and early 90s involved: USA
ITSEC
detailed examination of security features
comprehensive and informed functional and penetration testing
levels of confidence: E0 through E6
the higher the stronger
no requirement of specific technical features in order to
achieve a particular assurance level
possibility: authentication + integrity (without confidentiality
+ availability)
Security Target document
only security features identified in the Security Target are
evaluated
Z notation used to prove security properties about the Mondex
smart card electronic cash system (E6)
TCSEC
USA DoD standard: DoDD 5200.28-STD (DoDD 8500.1 since
October 24, 2002, CC since 2005)
used to evaluate, classify and select computer systems for their
security features
operations: processing, storage and retrieval of sensitive or
classified information
main publication: Orange Book from 1983 (85) – National
Computer Security Center (NCSC), National Security Agency
Requirements of TCSEC – Policy
security policy
explicit well-defined
enforced by the computer system
basic security policies
Mandatory Security Policy – based on subject’s clearance, authorization for the information and the confidentiality level of the information
Marking - access control labels
Requirements of TCSEC – Accountability
accountability of individuals
someone can evaluate others’ operations (within a reasonable
amount of time and without undue difficulty)
Requirements
Identification – users should be recognisable
Authentication – access rights of individuals to information should be verified
Auditing – actions affecting security should be traceable to the authenticated individual
Requirements of TCSEC – Assurance
guarantee that the trusted portion of the system works only as
intended
two types of assurance:
Assurance Mechanisms
Operational Assurance: System Architecture, System Integrity, Covert Channel Analysis, Trusted Facility Management and Trusted Recovery
Life-cycle Assurance: Security Testing, Design Specification and Verification, Configuration Management and Trusted System Distribution
Continuous Protection Assurance – continuous protection against tampering and/or unauthorized changes
Requirements of TCSEC – Documentation
development, deployment and management of the system
Security Features User’s Guide Trusted Facility Manual
TCSEC – classes
D – Minimal protection
evaluation level for systems where higher levels are not possible
C – Discretionary protection
C1 – Discretionary Security Protection
identification and authentication separation of users and data
discretionary access control capable of enforcing access limitations on an individual basis
required system documentation and user manuals
C2 – Controlled Access Protection
finer grained discretionary access control
individual accountability through login procedures audit trails
object reuse resource isolation
TCSEC – classes
B – Mandatory protection
B1 – Labeled Security Protection
informal statement of the security policy model data sensitivity labels
mandatory access control over selected subjects and objects label exportation capabilities
all discovered flaws must be removed or otherwise mitigated design specifications and verification
TCSEC – classes
B – Mandatory protection
B2 – Structured Protection
security policy model clearly defined and formally documented DAC and MAC enforcement extended to all subjects and objects
covert storage channels are analyzed for occurrence and bandwidth
carefully structured into protection-critical and non-protection-critical elements
design and implementation enable more comprehensive testing and review
authentication mechanisms are strengthened
trusted facility management is provided with administrator and operator segregation
strict configuration management controls are imposed operator and administrator roles are separated
TCSEC – classes
B – Mandatory protection
B3 – Security Domains
satisfies reference monitor requirements
structured to exclude code not essential to security policy enforcement
significant system engineering directed toward minimizing complexity
security administrator role defined audit security-relevant events
automated imminent intrusion detection, notification, and response
trusted system recovery procedures
covert timing channels are analyzed for occurrence and bandwidth
TCSEC – classes
A – Verified protection
A1 – Verified Design
functionally identical to B3
formal design and verification techniques including a formal top-level specification
formal management and distribution procedures
Beyond A1
system architecture demonstrates that the requirements of self-protection and completeness for reference monitors have been implemented in the Trusted Computing Base (TCB) security testing automatically generates test-case from the formal top-level specification or formal lower-level
specifications
formal specification and verification is where the TCB is verified down to the source code level, using formal verification methods where feasible
trusted design environment is where the TCB is designed in a trusted facility with only trusted (cleared) personnel
Common Criteria – key notions
Target Of Evaluation (TOE) – the product or system that is
the subject of the evaluation
Protection Profile (PP) – a document, typically created by a
user or user community, which identifies security requirements
for a class of security devices
Security Target (ST) – the document that identifies the
security properties of the target of evaluation
Security Functional Requirements (SFRs) – specify individual
security functions which may be provided by a product
Security Assurance Requirements (SARs) – descriptions of the
measures taken during development and evaluation of the
product to assure compliance with the claimed security
functionality
Evaluation Assurance Level (EAL) – the numerical rating
describing the depth and rigor of an evaluation.
Evaluation Assurance Levels
EAL1: Functionally Tested
some confidence in correct operation is required the threats to security are not viewed as serious independent testing against a specification
examination of the guidance documentation provided no assistance from the developer required
minimal cost
item works in a manner consistent with its documentation item provides useful protection against identified threats
Evaluation Assurance Levels
EAL2: Structurally Tested
developer should deliver design information and test results no more effort on the part of the developer than as in good commercial practice
low to moderate level of independently assured security no need for the complete development record
Evaluation Assurance Levels
EAL3: Methodically Tested and Checked
assumes positive security engineering at the design
no substantial change of existing sound development practices moderate level of independently assured security
thorough investigation of the TOE and its development no substantial re-engineering
Evaluation Assurance Levels
EAL4: Methodically Designed, Tested and Reviewed
maximum assurance from positive security engineering based on good commercial development practices
no substantial specialist knowledge, skills, and other resources highest level at which it is likely to be economically feasible to retrofit to an existing product line
moderate to high level of independently assured security in conventional commodity TOEs
Evaluation Assurance Levels
EAL5: Semiformally Designed and Tested
maximum assurance from security engineering based upon rigorous commercial development practices
moderate application of specialist security engineering techniques
probably is designed and developed with the intent of achieving EAL5 assurance
additional costs attributable to the EAL5 requirements, relative to rigorous development without the application of specialized techniques, should not be large
high level of independently assured security in a planned development
rigorous development approach without incurring unreasonable costs attributable to specialist security engineering techniques
Evaluation Assurance Levels
EAL6: Semiformally Verified Design and Tested
high assurance from application of security engineering techniques
rigorous development environment
protecting high value assets against significant risks. development of security TOEs
application in high risk situations
Evaluation Assurance Levels
EAL7: Formally Verified Design and Tested
development of security TOEs
extremely high risk situations and/or where the high value of the assets justifies the higher costs
tightly focused security functionality extensive formal analysis
