IS 2620 Developing Secure Systems Assurance and Evaluation

IS 2620: Developing Secure Systems Assurance and Evaluation Lecture 8 March 15, 2012

Reference l Matt Bishop Book l Chapters 18, 19, 21

Trust l l l Trustworthy entity has sufficient credible evidence leading one to believe that the system will meet a set of requirements Trust is a measure of trustworthiness relying on the evidence Assurance is confidence that an entity meets its security requirements based on evidence provided by the application of assurance techniques l SDLC, Formal methods, design analysis, testing etc. 3

Relationships Evaluation standards Trusted Computer System Evaluation Criteria Information Technology Security Evaluation Criteria Common Criteria 4

Problem Sources (Neumann) 1. 2. 3. 4. 5. 6. 7. 8. 9. Requirements definitions, omissions, and mistakes System design flaws Hardware implementation flaws, such as wiring and chip flaws Software implementation errors, program bugs, and compiler bugs System use and operation errors and inadvertent mistakes Willful system misuse Hardware, communication, or other equipment malfunction Environmental problems, natural causes, and acts of God Evolution, maintenance, faulty upgrades, and decommissions 5

Types of Assurance l l Policy assurance is evidence establishing security requirements in policy is complete, consistent, technically sound Design assurance is evidence establishing design sufficient to meet requirements of security policy Implementation assurance is evidence establishing implementation consistent with security requirements of security policy Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation 6

Waterfall Life Cycle Model 7

Other Models of Software Development l Exploratory programming l l l Prototyping (Similar to Exploratory) l l l Develop working system quickly No requirements or design specification, so low assurance Objective is to establish system requirements Future iterations (after first) allow assurance techniques Formal transformation l l Create formal specification Very conducive to assurance methods 8

Models l System assembly from reusable components l l l Depends on whether components are trusted Must assure connections, composition as well Very complex, difficult to assure This is common approach to building secure and trusted systems Extreme programming l l Rapid prototyping and “best practices” Project driven by business decisions Requirements open until project complete Components tested, integrated several times 9

Architectural considerations for assurance l Determine the focus of control of security enforcement mechanism l l l Centralized or Distributed l l Operating system: focus is on data Applications: more on operations/transactions Distribute them among systems/components Tradeoffs? Generally easier to “assure” centralized system Security mechanism may exist in any layer 10

Architectural considerations Example: Four layer architecture l Application layer l l Services/middleware layer l l l Support services for applications Eg. , DBMS, Object reference brokers Operating system layer l l Transaction control Memory management, scheduling and process control Hardware l Includes firmware 11

Trusted Computing Base (Security an integral part) l Reference monitor (total mediation!) l l Reference validation mechanism must be– 1. 2. 3. l Mediates all accesses to objects by subjects Tamperproof Never be bypassed Small enough to be subject to analysis and testing – the completeness can be assured Security kernel l Hardware + software implementing a RM 12

Trusted Computing Base l l TCB consists of all protection mechanisms within a computer system that are responsible for enforcing a security policy TCB monitors four basic interactions l l l Process activation Execution domain switching Memory protection I/O operation A unified TCB may be too large l Create a security kernel 13

Techniques for Design Assurance l Modularity & Layering l l l Different layers to capture different levels of abstraction l l Well defined independent modules Simplifies and makes system more understandable Data hiding Easy to understand analyze Subsystem (memory management, I/O subsystem, credit-card processing function) Subcomponent (I/O management, I/O drivers) Module: set of related functions and data structure Use principles of secure design 14

Design meets requirements? l Techniques needed l l Requirements tracing l l To prevent requirements and functionality from being discarded, forgotten, or ignored at lower levels of design Process of identifying specific security requirements that are met by parts of a description Informal Correspondence l Process of showing that a specification is consistent with an adjacent level of specification 15

Requirement mapping and informal correspondence Security Functional Requirements External Functional Specification Internal Design Specification Requirement Tracing Implementation Code 16 Informal Correspondence

Design meets requirements? l Informal arguments l Protection profiles l l l Security targets l l Identifies mechanisms and provide justification Formal methods: proof techniques l l Define threats to systems and security objectives Provide rationale (an argument) Formal proof mechanisms are usually based on logic (predicate calculus) Review l When informal assurance technique is used l l l Reviews of guidelines Conflict resolution methods Completion procedures 17

Implementation considerations for assurance l l Modularity with minimal interfaces Language choice l l l C vs. Java Configuration management tools l Control of the refinement and modification of configuration items such as source code, documentation etc. 18

Implementation meets Design? l Security testing l Functional testing (FT) (black box testing) l l Structural testing (ST) (white box testing) l l Testing of an entity to determine how well it meets its specification Testing based on an analysis of the code to develop test cases Testing occurs at different times l l l Unit testing (usually ST): testing a code module before integration System testing (FT): on integrated modules Security testing: product security l l l Security functional testing (against security issues) Security structural testing (security implementation) Security requirements testing 19

Code development and testing Code Unit test Code Test the test On current build Code bugs Integrate tested test into automated Test suite Integrate Build system Build test suite Execute system Test on current Build 20

Operation and maintenance assurance l l Bugs in operational phase need fixing Hot fix l l l Immediate fix Bugs are serous and critical Regular fix l l Less serious bugs Long term solution after a hot fix 21

Evaluation Courtesy of Professors Chris Clifton & Matt Bishop 22

What is Formal Evaluation? l l l Method to achieve Trust l Not a guarantee of security Evaluation methodology includes: l Security requirements l Assurance requirements showing how to establish security requirements met l Procedures to demonstrate system meets requirements l Metrics for results (level of trust) Examples: TCSEC (Orange Book), ITSEC, CC

Formal Evaluation: Why? l l l Organizations require assurance l Defense l Telephone / Utilities l “Mission Critical” systems Formal verification of entire systems not feasible Instead, organizations develop formal evaluation methodologies l Products passing evaluation are trusted l Required to do business with the organization

Mutual Recognition Arrangement National Information Assurance partnership (NIAP), in conjunction with the U. S. State Department, negotiated a Recognition Arrangement that: l l l Provides recognition of Common Criteria certificates by 24 nations (was 19 in 2005) Eliminates need for costly security evaluations in more than one country Offers excellent global market opportunities for U. S. IT industry

An Evolutionary Process Two decades of research and development… US-DOD TCSEC US-NIST MSFR Federal Criteria Common Criteria 1990 1992 1993 -98 1983 -85 European National/Regional Initiatives 1989 -93 Canada Europe Canadian Initiatives TCPEC 1991 1989 -93 1993 ITSEC ISO 15408 Common Criteria 1999

Common Criteria: Origin

TCSEC l l Known as Orange Book, Do. D 5200. 28 -STD Four trust rating divisions (classes) l l D: Minimal protection C (C 1, C 2): Discretionary protection B (B 1, B 2, B 3): Mandatory protection A (A 1): Highly-secure

TCSEC: The Original l Trusted Computer System Evaluation Criteria l l Policy model based on Bell-La. Padula Enforcement: Reference Validation Mechanism l l l U. S. Government security evaluation criteria Used for evaluating commercial products Every reference checked by compact, analyzable body of code Emphasis on Confidentiality Metric: Seven trust levels: l l D, C 1, C 2, B 1, B 2, B 3, A 1 D is “tried but failed”

TCSEC Class Assurances l C 1: Discretionary Protection l l C 2: Controlled Access Protection l l Identification Authentication Discretionary access control Object reuse and auditing B 1: Labeled security protection l l Mandatory access control on limited set of objects Informal model of the security policy

TCSEC Class Assurances (continued) l B 2: Structured Protections l l l B 3: Security Domains l l Trusted path for login Principle of Least Privilege Formal model of Security Policy Covert channel analysis Configuration management Full reference validation mechanism Constraints on code development process Documentation, testing requirements A 1: Verified Protection l l Formal methods for analysis, verification Trusted distribution

How is Evaluation Done? l Government-sponsored independent evaluators l l Application: Determine if government cares Preliminary Technical Review l l Discussion of process, schedules Development Process Technical Content, Requirements Evaluation Phase

TCSEC: Evaluation Phase l Three phases l Design analysis l l Test analysis Final Review Trained independent evaluation l l l Review of design based on documentation Results presented to Technical Review Board Must approve before next phase starts Ratings Maintenance Program l Determines when updates trigger new evaluation

TCSEC: Problems l Based heavily on confidentiality l l l Did not address integrity, availability Tied security and functionality Base TCSEC geared to operating systems l l TNI: Trusted Network Interpretation TDI: Trusted Database management System Interpretation

Later Standards l l CTCPEC – Canada ITSEC – European Standard l l l l l Did not define criteria Levels correspond to strength of evaluation Includes code evaluation, development methodology requirements Known vulnerability analysis CISR: Commercial outgrowth of TCSEC FC: Modernization of TCSEC FIPS 140: Cryptographic module validation Common Criteria: International Standard SSE-CMM: Evaluates developer, not product

ITSEC: Levels l E 1: Security target defined, tested l l E 2: Informal description of design l l Structured approach to design Design level vulnerability analysis E 5: Correspondence between design and code l l Configuration control, distribution control E 3: Correspondence between code and security target E 4: Formal model of security policy l l Must have informal architecture description Source code vulnerability analysis E 6: Formal methods for architecture l l Formal mapping of design to security policy Mapping of executable to source code

ITSEC Problems: l No validation that security requirements made sense l l l Product meets goals But does this meet user expectations? Inconsistency in evaluations l Not as formally defined as TCSEC

l l Replaced TCSEC, ITSEC 7 Evaluation Levels (functionally tested to formally designed and tested) Functional requirements, assurance requirements and evaluation methodology Functional and assurance requirements are organized hierarchically into: class, family, component, and, element. The components may have dependencies.

PP/ST Framework

IT Security Requirements The Common Criteria defines two types of IT security requirements: Functional Requirements Assurance Requirements - for defining security behavior of the IT product or system: • implemented requirements become security functions - 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

Documentation l Part 1: Introduction and General Model Part 2: Security Functional Requirements Part 3: Security Assurance Requirements CEM l Latest version: 3. 1 (variations exist) l http: //www. commoncriteriaportal. org/public/expert/index. php? menu=2 l l l

Class Decomposition Class Family Components Note: Elements Applicable to both functional and assurance documents

CC Evaluation 1: Protection Profile Implementation independent, domain-specific set of security requirements l l l Narrative Overview Product/System description Security Environment (threats, overall policies) Security Objectives: System, Environment IT Security Requirements l l l Functional requirements drawn from CC set Assurance level Rationale for objectives and requirements

CC Evaluation 2: Security Target Specific requirements used to evaluate system l l l Narrative introduction Environment Security Objectives l l Security Requirements l l How met Environment and system Drawn from CC set Mapping of Function to Requirements Claims of Conformance to Protection Profile

Common Criteria: Functional Requirements l l 314 page document 11 Classes l l l Security Audit, Communication, Cryptography, User data protection, ID/authentication, Security Management, Privacy, Protection of Security Functions, Resource Utilization, Access, Trusted paths Several families per class Lattice of components in a family

Class Example: Communication l Non-repudiation of origin 1. 2. Selective Proof. Capability to request verification of origin Enforced Proof. All communication includes verifiable origin

Class Example: Privacy 1. Pseudonymity – – – 2. Reversible Pseudonimity • 3. The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user name bound to [assignment: list of subjects and/or operations and/or objects] The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to [assignment: list of subjects] The TSF shall [selection: determine an alias for a user, accept the alias from the user] and verify that it conforms to the [assignment: alias metric] … Alias Pseudonimity 1. …

Common Criteria: Assurance Requirements l l 231 page document 10 Classes l l l Protection Profile Evaluation, Security Target Evaluation, Configuration management, Delivery and operation, Development, Guidance, Life cycle, Tests, Vulnerability assessment, Maintenance Several families per class Lattice of components in family

Common Criteria: Evaluation Assurance Levels 1. 2. 3. 4. 5. 6. 7. Functionally tested Structurally tested Methodically tested and checked Methodically designed, tested, and reviewed Semi-formally designed and tested Semi-formally verified design and tested Formally verified design and tested

Common Criteria: Evaluation Process l National Authority authorizes evaluators l l l U. S. : NIST accredits commercial organizations Fee charged for evaluation Team of four to six evaluators l l l Develop work plan and clear with NIST Evaluate Protection Profile first If successful, can evaluate Security Target

Defining Requirements ISO/IEC Standard 15408 Protection Profiles Operating Access Control Identification Authentication Audit Cryptography A flexible, robust catalogue of standardized IT security requirements (features and assurances) Systems Database Systems Firewalls Smart Cards Applications Biometrics Routers VPNs Consumer-driven security requirements in specific information technology areas

Industry Responds Protection Profile Security Targets CISCO Firewall Security Requirements Consumer statement of IT security requirements to industry in a specific information technology area Security Features and Assurances Lucent Firewall Checkpoint Firewall Network Assoc. FW Vendor statements of security claims for their IT products

Demonstrating Conformance Private sector, accredited security testing laboratories conduct evaluations IT Products Security Features and Assurances Vendors bring IT products to independent, impartial testing facilities for security evaluation Common Criteria Testing Labs Test Reports Test results submitted to the National Information Assurance Partnership (NIAP) for post-evaluation validation

Validating Test Results Validation Body validates laboratory’s test results Test Report Common Criteria Validation Body Validation Report TM National Information Assurance Partnership Common Criteria Certificate Laboratory submits test report to Validation Body NIAP issues Validation Report and Common Criteria Certificate

Common Criteria: Status l About 80 registered products (2005) l l Only one at level 5 (Java Smart Card) Several OS at 4 Likely many more not registered 223 Validated products (Oct, 2007) l Tenix Interactive Link Data Diode Device Version 2. 1 at EAL 7+