Overview

1. Overview • Overview of Challenges • The Common Criteria • Security Functional Requirements • Security Assurance Levels • Reading Techniques • Test Organization Techniques

2. The Challenges • Understanding and expressing requirements • Intermediating steps between requirements and implementation • Coding the application correctly • Adequate validation, verification and testing • Deployment and operational maintenance • Evolution

3. Requirements • Diverse stakeholders proliferate features • Note complexity of standards • Hard to know requirements precisely • Iterative approach often needed • Operational assumptions often hard to express • Costs, schedules and available platforms must constrain wish list • Example: Passport logout feature

4. Design • Proceeding from stakeholder requirements to implementation is difficult • Task often broken into steps • User requirements specification • Software requirements specification (e.g. state machines to describe protocol steps) • Detailed design (e.g. UML diagrams, interfaces) • Example: IETF specifications for IPSec • Architecture (Security Architecture for the Internet Protocol) • Specifications: ESP and IKE

5. Implementation • Rubber hits the road • Correspondence to specifications is challenging • Common challenges in interfaces to existing code • Security problems abound in existing Internet environment • Example: experience with implementations of IPSec and SSL

6. V V & T • Validation: conformance to user requirements • Verification: conformance to software specifications • Reading assessments (walk through) • Formal modeling and proof • Adage • Verification: building the product right • Validation: building the right product • Testing (simulation, emulation, or field test) (unit, integration, or system) (random, regression, or red team) • Discussion point: special challenges in VV&T for security • Later: vulnerability assessment

7. Deployment and Operations • Often difficult to move entrenched architecture toward secure foundation • Often difficult to deploy a good solution incrementally • “Flag day” challenges • Network effects • Patches are a challenge • Increasing service perspective on deployed software

8. Evolution • Products increasingly go through an evolution of many steps • Each step adapts to new operational contexts and/or adds new features • Product groups are increasingly common • Add functionality in a modular way

9. Common Criteria • Evolved from TCSEC (US Orange Book 1983-1999) and ITSEC (European standard 1991-2001) • ISO/IEC Standard 15408 • NIST endorsement: establishes a common language for specifying security requirements in IT products and systems as well as a rigorous approach for evaluating security features. • NIST CC/EVS • Version 2.2 (January 2004) posted on course web site under Chapter 19

10. Common Criteria Eval Context sets the standards, monitors the quality of the evaluations and administers the regulations to which the evaluation facilities and evaluators must conform

11. Common Criteria Parts • Part 1, Introduction and General Model • Part 2, Security Functional Requirements • Part 3, Security Assurance Requirements

12. Functional Requirements • The functional requirements are levied on those functions of the TOE that are specifically in support of IT security, and define the desired security behavior. • Examples: requirements for • identification, • authentication, • security audit, • non-repudiation of origin.

13. Assurance Requirements • Assurance that the security objectives are achieved by the selected security functions is derived from the following two factors: • confidence in the correctness of the implementation of the security functions, i.e., the assessment whether they are correctly implemented; and • confidence in the effectiveness of the security functions, i.e., the assessment whether they actually satisfy the stated security objectives.

14. Concepts and Relationships

15. TOE Development Model Target of Evaluation (TOE)

16. Specification Styles • Three types of specification style are mandated by this class: • Informal • Semiformal • Formal • The functional specification, high-level design, level design and TSP models will be written using one or more of these specification styles. • Ambiguity in these specifications is reduced by using an increased level of formality.

17. Informal • An informal specification is written as prose in natural language. • Natural language is used here as meaning communication in any commonly spoken tongue (e.g. Dutch, English, French, German). • An informal specification is not subject to any notational or special restrictions other than those required as ordinary conventions for that language (e.g. grammar and syntax). • While no notational restrictions apply, the informal specification is also required to provide defined meanings for terms that are used in a context other than that accepted by normal usage.

18. Semiformal Specification • A semiformal specification is written in a restricted syntax language and is typically accompanied by supporting explanatory (informal) prose. • The restricted syntax language may be a natural language with restricted sentence structure and keywords with special meanings, or it may be diagrammatic (e.g. data-flow diagrams, state transition diagrams, entity-relationship diagrams, data structure diagrams, and process or program structure diagrams). • Whether based on diagrams or natural language, a set of conventions must be supplied to define the restrictions placed on the syntax.

19. Formal Specification • A formal specification is written in a notation based upon well-established mathematical concepts, and is typically accompanied by supporting explanatory (informal) prose. • These mathematical concepts are used to define the syntax and semantics of the notation and the proof rules that support logical reasoning. • The syntactic and semantic rules supporting a formal notation should define how to recognize constructs unambiguously and determine their meaning. • There needs to be evidence that it is impossible to derive contradictions, and all rules supporting the notation need to be defined or referenced.

20. Functional Requirements Paradigm

21. Security Functions in Dist TOE

22. User Data vs. TSF Data

23. Functional Classes

24. Example: Security Audit

25. Security Audit Analysis • Class Behavior (Security Audit): Security auditing involves recognising, recording, storing, and analysing information related to security relevant activities (i.e. activities controlled by the TSP). The resulting audit records can be examined to determine which security relevant activities took place and whom (which user) is responsible for them. • Family Behavior (Security Audit Analysis): This family defines requirements for automated means that analyse system activity and audit data looking for possible or real security violations. This analysis may work in support of intrusion detection, or automatic response to an imminent security violation.

26. FAU_SAA.1 • Potential violation analysis: basic threshold detection on the basis of a fixed rule set is required. • Running case study: credit card fraud detection. • Card events reach fraud detection TOE security function which must meet FAU_SAA.1 functional requirement.

27. FAU_SAA.2 • Profile based anomaly detection: the TSF maintains individual profiles of system usage, where a profile represents the historical patterns of usage performed by members of the profile target group. • Use of the credit card during daytime hours after a long pattern of use only on weekends and evenings. • Use of the credit card for unusual purposes such as new types of purchases.

28. FAU_SAA.3 • Simple attack heuristics, the TSF shall be able to detect the occurrence of signature events that represent a significant threat to TSP enforcement. • Attempt to use credit card to withdraw cash without successful PIN entry.

29. FAU_SAA.4 • Complex attack heuristics: the TSF shall be able to represent and detect multi-step intrusion scenarios. The TSF is able to compare system events (possibly performed by multiple individuals) against event sequences known to represent entire intrusion scenarios. • Credit card used to make phone calls to multiple locations at the same time. • Card used to buy gasoline followed by failed cash withdrawal attempt.

30. Stylized Requirements • 1.2: Accumulation or combination of [assignment: subset of defined auditable events] known to indicate a potential security violation • My 1.2: Accumulation or combination of purchase events known to indicate a potential security violation

31. Stylized Requirements • 2.1 The TSF shall be able to maintain profiles of system usage, where an individual profile represents the historical patterns of usage performed by the member(s) of [assignment: the profile target group]. • 2.2 The TSF shall be able to maintain a suspicion rating associated with each user whose activity is recorded in a profile, where the suspicion rating represents the degree to which the user’s current activity is found inconsistent with the established patterns of usage represented in the profile. • 2.3 The TSF shall be able to indicate an imminent violation of the TSP when a user’s suspicion rating exceeds the following threshold conditions [assignment:conditions under which anomalous activity is reported by the TSF].

32. Stylized Requirements • My 2.1 The TSF shall be able to maintain profiles of system usage, where an individual profile represents the historical patterns of usage performed by the member(s) of credit card users. • My 2.3 The TSF shall be able to indicate an imminent violation of the TSP when a user’s suspicion rating exceeds the following threshold conditions: (1) purchases made on weekdays after one year of non-use on weekdays and (2) purchases outside purchase categories established in first year of use.

33. Exercise • Complete a similar functional requirements specification for FAU_SAA.3 • Complete a similar functional requirements specification for FAU_SAA.4 • See Page 21 of CC Part 2 or the notes for these slides.

34. Example: Privacy

35. Anonymity • This family ensures that a user may use a resource or service without disclosing the user’s identity. The requirements for anonymity provide protection of the user identity. Anonymity is not intended to protect the subject identity. • 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 provide [assignment: list of services] to [assignment: list of subjects] without soliciting any reference to the real user name.

36. Pseudonymity • This family ensures that a user may use a resource or service without disclosing its user identity, but can still be accountable for that use. • Pseudonymity: The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to [assignment: list of subjects]. • Reversible pseudonymity: The TSF shall provide [selection: an authorised user, [assignment: list of trusted subjects]] a capability to determine the user identity based on the provided alias only under the following [assignment: list of conditions]. • Alias pseudonymity: The TSF shall provide an alias to the real user name which shall be identical to an alias provided previously under the following [assignment: list of conditions] otherwise the alias provided shall be unrelated to previously provided aliases.

37. Illustration of Pseudonymity • Pseudonymity: Each user is given a pseudonym by the system, but only the system uses this information (e.g. to determine access rules). • Reversible Pseudonymity: Each user is given a pseudonym by the system, but a manager can reverse the pseudonym to determine the user. • Alias Pseudonymity: Users reuse the same pseudonym on multiple accesses to the database, otherwise pseudonyms are distinct.

38. Unlinkability • This family ensures that a user may make multiple uses of resources or services without others being able to link these uses together. • The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine whether [assignment: list of operations] [selection: were caused by the same user, are related as follows [assignment: list of relations]].

39. Unobservability • This family ensures that a user may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used. • The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the operation [assignment: list of operations] on [assignment: list ofobjects] by [assignment: list of protected users and/or subjects].

40. Security Assurance Requirements • Assurance classes I • Protection Profile (PP) • Security Target (ST) • Assurance classes II • Configuration management • Delivery and operation • Development • Guidance documents • Life cycle support • Tests • Vulnerability assessment • Assurance levels

41. Assurance Through Evaluation • Analysis and checking of process(es) and procedure(s); • Checking that process(es) and procedure(s) are being applied; • Analysis of the correspondence between TOE design representations; • Analysis of the TOE design representation against the requirements; • Verification of proofs; • Analysis of guidance documents; • Analysis of functional tests developed and the results provided; • Independent functional testing; • Analysis for vulnerabilities (including flaw hypothesis); • Penetration testing.

42. Assurance Requirements

43. Protection Profiles • A PP defines an implementation-independent set of IT security requirements for a category of TOEs. • Such TOEs are intended to meet common consumer needs for IT security. • Consumers can therefore construct or cite a PP to express their IT security needs without reference to any specific TOE.

44. Security Targets • An ST contains the IT security requirements of an identified TOE and specifies the functional and assurance security measures offered by that TOE to meet stated requirements. • The ST for a TOE is a basis for agreement between the developers, evaluators and, where appropriate, consumers on the security properties of the TOE and the scope of the evaluation.

45. Configuration Management • Configuration management (CM) helps to ensure that the integrity of the TOE is preserved, by requiring discipline and control in the processes of refinement and modification of the TOE and other related information.

46. Delivery and Operation • Delivery and operation defines requirements for the measures, procedures, and standards concerned with secure delivery, installation, and operational use of the TOE, ensuring that the security protection offered by the TOE is not compromised during transfer, installation, start-up, and operation.

47. Development • Development defines requirements for the stepwise refinement of the TSF from the TOE summary specification in the ST down to the actual implementation.

48. Guidance Documents • Guidance documents define requirements directed at the understandability, coverage and completeness of the operational documentation provided by the developer. • For users • For administrators

49. Life Cycle Support • Life cycle support defines requirements for assurance through the adoption of a well defined life-cycle model for all the steps of the TOE development, including flaw remediation procedures and policies, correct use of tools and techniques and the security measures used to protect the development environment.

50. Tests • Tests state testing requirements that demonstrate that the TSF satisfies the TOE security functional requirements.