Post on 27-Dec-2015
IS 2620: Developing Secure Systems
Assurance and EvaluationAssurance and Evaluation
Lecture 8March 15, 2012
Reference
Matt Bishop Book Chapters 18, 19, 21
3
Trust
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 SDLC, Formal methods, design analysis, testing etc.
4
Relationships
Policy
Mechanisms
Assurance
Statement of requirements that explicitly definesthe security expectations of the mechanism(s)
Provides justification that the mechanism meets policythrough assurance evidence and approvals based onevidence
Executable entities that are designed and implementedto meet the requirements of the policy
Evaluation standardsTrusted Computer System Evaluation Criteria
Information Technology Security Evaluation Criteria Common Criteria
5
Problem Sources (Neumann)
1. Requirements definitions, omissions, and mistakes
2. System design flaws
3. Hardware implementation flaws, such as wiring and chip flaws
4. Software implementation errors, program bugs, and compiler bugs
5. System use and operation errors and inadvertent mistakes
6. Willful system misuse
7. Hardware, communication, or other equipment malfunction
8. Environmental problems, natural causes, and acts of God
9. Evolution, maintenance, faulty upgrades, and decommissions
6
Types of Assurance 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
7
Waterfall Life Cycle Model
Requirementsdefinition andanalysis
System andsoftwaredesign
Implementationand unittesting Integration
and systemtesting
Operationandmaintenance
8
Other Models of Software Development
Exploratory programming Develop working system quickly No requirements or design specification, so low
assurance Prototyping (Similar to Exploratory)
Objective is to establish system requirements Future iterations (after first) allow assurance
techniques Formal transformation
Create formal specification Very conducive to assurance methods
9
Models System assembly from reusable components
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
Rapid prototyping and “best practices” Project driven by business decisions Requirements open until project complete Components tested, integrated several times
10
Architectural considerations for assurance
Determine the focus of control of security enforcement mechanism Operating system: focus is on data Applications: more on operations/transactions
Centralized or Distributed Distribute them among systems/components Tradeoffs? Generally easier to “assure” centralized system
Security mechanism may exist in any layer
11
Architectural considerationsExample: Four layer architecture
Application layer Transaction control
Services/middleware layer Support services for applications Eg., DBMS, Object reference brokers
Operating system layer Memory management, scheduling and process control
Hardware Includes firmware
12
Trusted Computing Base(Security an integral part)
Reference monitor (total mediation!) Mediates all accesses to objects by subjects
Reference validation mechanism must be– 1. Tamperproof
2. Never be bypassed
3. Small enough to be subject to analysis and testing – the completeness can be assured
Security kernel Hardware + software implementing a RM
13
Trusted Computing Base TCB consists of all protection mechanisms
within a computer system that are responsible for enforcing a security policy
TCB monitors four basic interactions Process activation Execution domain switching Memory protection I/O operation
A unified TCB may be too large Create a security kernel
14
Techniques for Design Assurance Modularity & Layering
Well defined independent modules Simplifies and makes system more understandable Data hiding Easy to understand and analyze
Different layers to capture different levels of abstraction 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
15
Design meets requirements?
Techniques needed To prevent requirements and functionality from being
discarded, forgotten, or ignored at lower levels of design
Requirements tracing Process of identifying specific security requirements that
are met by parts of a description
Informal Correspondence Process of showing that a specification is consistent with
an adjacent level of specification
16
Requirement mapping and informal correspondence
Security Functional Requirements
External Functional Specification
Internal Design Specification
Implementation CodeRequirement
Tracing
InformalCorrespondence
17
Design meets requirements? Informal arguments
Protection profiles Define threats to systems and security objectives Provide rationale (an argument)
Security targets Identifies mechanisms and provide justification
Formal methods: proof techniques Formal proof mechanisms are usually based on logic
(predicate calculus) Review
When informal assurance technique is used Reviews of guidelines Conflict resolution methods Completion procedures
18
Implementation considerations for assurance
Modularity with minimal interfaces Language choice
C vs. Java Java
Configuration management tools Control of the refinement and modification of
configuration items such as source code, documentation etc.
19
Implementation meets Design? Security testing
Functional testing (FT) (black box testing) Testing of an entity to determine how well it meets its specification
Structural testing (ST) (white box testing) Testing based on an analysis of the code to develop test cases
Testing occurs at different times Unit testing (usually ST): testing a code module before
integration System testing (FT): on integrated modules Security testing: product security
Security functional testing (against security issues) Security structural testing (security implementation) Security requirements testing
20
Code development and testing
Code
Unit test
Integrate
Build system
Execute systemTest on current Build
Code
Test the testOn current build
Integrate testedtest into automated
Test suite
Build test suite
Codebugs
21
Operation and maintenance assurance
Bugs in operational phase need fixing Hot fix
Immediate fix Bugs are serous and critical
Regular fix Less serious bugs Long term solution after a hot fix
Courtesy of Professors Chris Clifton & Matt Bishop
22
Evaluation
What is Formal Evaluation?
Method to achieve Trust Not a guarantee of security
Evaluation methodology includes: Security requirements Assurance requirements showing how to establish
security requirements met Procedures to demonstrate system meets
requirements Metrics for results (level of trust)
Examples: TCSEC (Orange Book), ITSEC, CC
Formal Evaluation: Why?
Organizations require assurance Defense Telephone / Utilities “Mission Critical” systems
Formal verification of entire systems not feasible Instead, organizations develop formal evaluation
methodologies Products passing evaluation are trusted 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:
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
1983-85
US-NIST
MSFR
1990
FederalCriteria
1992
Europe
ITSEC
1991
Canada
TCPEC
1993
CommonCriteria1993-98
ISO 15408CommonCriteria
1999
European National/Regional
Initiatives
1989-93
Canadian Initiatives
1989-93
Common Criteria: Origin
TCSEC
Known as Orange Book, DoD 5200.28-STD Four trust rating divisions (classes)
D: Minimal protection C (C1,C2): Discretionary protection B (B1, B2, B3): Mandatory protection A (A1): Highly-secure
TCSEC: The Original Trusted Computer System Evaluation Criteria
U.S. Government security evaluation criteria Used for evaluating commercial products
Policy model based on Bell-LaPadula Enforcement: Reference Validation Mechanism
Every reference checked by compact, analyzable body of code
Emphasis on Confidentiality Metric: Seven trust levels:
D, C1, C2, B1, B2, B3, A1 D is “tried but failed”
TCSEC Class Assurances C1: Discretionary Protection
Identification Authentication Discretionary access control
C2: Controlled Access Protection Object reuse and auditing
B1: Labeled security protection Mandatory access control on limited set of objects Informal model of the security policy
TCSEC Class Assurances(continued)
B2: Structured Protections Trusted path for login Principle of Least Privilege Formal model of Security Policy Covert channel analysis Configuration management
B3: Security Domains Full reference validation mechanism Constraints on code development process Documentation, testing requirements
A1: Verified Protection Formal methods for analysis, verification Trusted distribution
How is Evaluation Done?
Government-sponsored independent evaluators Application: Determine if government cares Preliminary Technical Review
Discussion of process, schedules Development Process Technical Content, Requirements
Evaluation Phase
TCSEC: Evaluation Phase
Three phases Design analysis
Review of design based on documentation Test analysis Final Review
Trained independent evaluation Results presented to Technical Review Board Must approve before next phase starts
Ratings Maintenance Program Determines when updates trigger new evaluation
TCSEC: Problems
Based heavily on confidentiality Did not address integrity, availability
Tied security and functionality Base TCSEC geared to operating systems
TNI: Trusted Network Interpretation TDI: Trusted Database management System
Interpretation
Later Standards
CTCPEC – Canada ITSEC – European Standard
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
E1: Security target defined, tested Must have informal architecture description
E2: Informal description of design Configuration control, distribution control
E3: Correspondence between code and security target E4: Formal model of security policy
Structured approach to design Design level vulnerability analysis
E5: Correspondence between design and code Source code vulnerability analysis
E6: Formal methods for architecture Formal mapping of design to security policy Mapping of executable to source code
ITSEC Problems:
No validation that security requirements made sense Product meets goals But does this meet user expectations?
Inconsistency in evaluations Not as formally defined as TCSEC
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
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
IT Security Requirements
Documentation
Part 1: Introduction and General Model Part 2: Security Functional Requirements Part 3: Security Assurance Requirements CEM
Latest version: 3.1 (variations exist) http://www.commoncriteriaportal.org/public/expert/index.php?menu=2
Class Decomposition
Class
Family
Components
ElementsNote: Applicable to both functional and assurance documents
CC Evaluation 1: Protection Profile
Implementation independent, domain-specific set of security requirementsNarrative OverviewProduct/System descriptionSecurity Environment (threats, overall policies)Security Objectives: System, EnvironmentIT Security Requirements
Functional requirements drawn from CC set
Assurance levelRationale for objectives and requirements
CC Evaluation 2: Security Target
Specific requirements used to evaluate systemNarrative introductionEnvironmentSecurity Objectives
How metSecurity Requirements
Environment and system Drawn from CC set
Mapping of Function to RequirementsClaims of Conformance to Protection Profile
Common Criteria:Functional Requirements
314 page document 11 Classes
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
Non-repudiation of origin1. Selective Proof. Capability to request verification
of origin
2. Enforced Proof. All communication includes verifiable origin
Class Example: Privacy
1. Pseudonymity– 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]
2. Reversible Pseudonimity• …
3. Alias Pseudonimity1. …
Common Criteria:Assurance Requirements
231 page document 10 Classes
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. Functionally tested2. Structurally tested3. Methodically tested and checked4. Methodically designed, tested, and reviewed5. Semi-formally designed and tested6. Semi-formally verified design and tested7. Formally verified design and tested
Common Criteria:Evaluation Process
National Authority authorizes evaluators U.S.: NIST accredits commercial organizations Fee charged for evaluation
Team of four to six evaluators Develop work plan and clear with NIST Evaluate Protection Profile first If successful, can evaluate Security Target
Defining Requirements
ISO/IEC Standard 15408
A flexible, robust catalogue of standardized IT security
requirements(features and assurances)
Protection Profiles
Consumer-driven security requirements in specific
information technology areas
Operating Systems Database Systems Firewalls Smart Cards Applications Biometrics Routers VPNs
Access ControlIdentification
AuthenticationAudit
Cryptography
Industry Responds
Protection Profile
Consumer statement of IT security requirements to industry in a
specific information technology area
Security Targets
Vendor statements of security claims for their IT
products
CISCO Firewall Lucent Firewall Checkpoint Firewall Network Assoc. FW Security
Features and
Assurances
Firewall Security Requirements
Demonstrating Conformance
IT Products
Vendors bring IT products to independent, impartial testing
facilities for security evaluation
Security Features
and Assurances
Private sector, accredited security testing laboratories
conduct evaluations
Common Criteria
Testing Labs
Test results submitted to the National Information Assurance Partnership
(NIAP) for post-evaluation validation
Test Reports
Validating Test Results
Laboratory submits test report to Validation
Body
Test Report
Validation Body validates laboratory’s test results
Common Criteria
Validation Body
NIAP issues Validation Report and Common
Criteria Certificate
Validation Report
National Information Assurance Partnership
Common Criteria Certificate
TM
Common Criteria:Status
About 80 registered products (2005) Only one at level 5
(Java Smart Card) Several OS at 4 Likely many more not registered
223 Validated products (Oct, 2007) Tenix Interactive Link Data Diode Device Version
2.1 at EAL 7+