IS 2620: Developing Secure Systems

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

2. 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 Evaluation standards Trusted Computer System Evaluation Criteria Information Technology Security Evaluation Criteria Common Criteria

5. Problem Sources (Neumann) • 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

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 • Operationalassurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation

7. Waterfall Life Cycle Model

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– • Tamperproof • Never be bypassed • 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 Informal Correspondence Internal Design Specification Requirement Tracing Implementation Code

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 Code Test the test On current build Unit test Code bugs Integrate Integrate tested test into automated Test suite Build system Build test suite Execute system Test on current Build

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

22. Evaluation

23. 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

24. 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

25. 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

26. 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

27. Common Criteria: Origin

28. 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

29. 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”

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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.

39. PP/ST Framework

40. IT Security Requirements The Common Criteria defines two types of IT security requirements: Assurance Requirements - for establishing confidence in security functions: • correctness of implementation • effectiveness in satisfying security objectives Functional Requirements - for defining security behavior of the IT product or system: • implemented requirements become security functions Examples: • Development • Configuration Management • Life Cycle Support • Testing • Vulnerability Analysis Examples: • Identification & Authentication • Audit • User Data Protection • Cryptographic Support

42. 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

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

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

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

46. 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

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

48. Class Example: Privacy • 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] • Reversible Pseudonimity • … • Alias Pseudonimity • …

49. 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

50. Common Criteria:Evaluation Assurance Levels 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