Constructing Trusted Code Base XIV Certification Aleksy Schubert & Jacek Chrząszcz
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 Other tools 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 basis for many later standards
ITSEC Other tools 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 Other tools 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 Discretionary Security Policy subject based
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 Test Documentation and Design Documentation
TCSEC classes Other tools 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 Other tools 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 Other tools 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 Other tools 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 Other tools 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 typical for securing legacy systems
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 some additional security-specific engineering costs possible
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 the value of the protected assets justifies the additional costs
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
Other tools ESC/Java2 http: //kindsoftware.com/products/opensource/escjava2/ OpenJML http://openjml.org/ KeY http://www.key-project.org/ Verifast http: //people.cs.kuleuven.be/~bart.jacobs/verifast/ Microsoft VCC http://research.microsoft.com/en-us/projects/vcc/ Dafny http: //research.microsoft.com/en-us/projects/dafny/ Eiffel https://www.eiffel.com/