Standards In The Evaluation Of IT Security Steve Randall & Scott Cadzow TC-MTS# October 2004 Sophia Antipolis 39TD025

12-Oct-04TC-MTS 39TD0252 Common Criteria  Products offering security features always carefully evaluated (particularly by government bodies)  Mid-90s, evaluation bodies got together to define a single set of evaluation requirements, the “Common Criteria (CC)” in ISO/IEC  Part 1: Introduction and general model  Part 2: Security functional requirements  Part 3: Security assurance requirements  Rapidly growing interest in security and evaluation within commercial world  Key aspects of CC:  Formal evaluation process  Using trained evaluators  International recognition of results

12-Oct-04TC-MTS 39TD0253 CC Terminology  Protection Profile (PP)  Abstract specification of required security functionality  Security Target (ST)  Concrete specification of a product providing required security functionality  Target Of Evaluation (TOE)  Actual product providing required security functionality

12-Oct-04TC-MTS 39TD0254 Standards and CC [1]  CC generally used to evaluate product  Communications products often incorporate implementations of standards  Standards are rarely evaluated under CC  The question for TISPAN:  Can standards be written in a way that simplifies the evaluation of products implementing them?

12-Oct-04TC-MTS 39TD0255 Standards and CC [2]  Protocol standards are spiritually close to PPs  Specify implementation independent requirements  Use formalized text to specify requirements (shall, may, should…)  Use specification languages for design, validation and testing (SDL, UML, MSC, ASN.1, TTCN)  Have traceability:  Title  Version numbering  Change control

12-Oct-04TC-MTS 39TD0256 What is TISPAN Doing ? - Long Term -  Providing guidance to standards developers on standards preparation  To allow evaluation  To achieve higher quality standards  Introducing CC vocabulary  Requirements stated in terms of ISO/IEC Part 2  Evaluation stated as a goal of standardisation

12-Oct-04TC-MTS 39TD0257 What is TISPAN Doing ? - Short Term –  A guide to CC as it applies to standards  Evaluation Assurance Levels (EALs)  Functional requirements classes  Evaluation classes  Proforma for PP  Guidance on preparing a standard for CC evaluation:  Format  Content  Development process  Proforma for ST  Format and overview of developers’ responsibilities in preparing a product for evaluation

12-Oct-04TC-MTS 39TD0258 Evaluation Assurance Levels (EAL)  EAL 1:Functionally tested  EAL 2:Structurally tested  EAL 3:Methodically tested and checked  EAL 4:Methodically designed, tested and reviewed  EAL 5:Semiformally designed and tested  EAL 6:Semiformally verified design and tested  EAL 7: Formally verified design and tested

12-Oct-04TC-MTS 39TD0259 CC Specification Structure  Functional requirements and evaluation requirements categorized as Classes, Families and Components. Class Family Component

12-Oct-04TC-MTS 39TD02510 Functional Requirements Classes  FAU:Security Audit  FCO:Communication  FCS:Cryptographic Support  FDP:User Data Protection  FIA:Identification and Authentication  FMT:Security Management  FPR:Privacy  FPT:Protection of TOE Security Functions  FRU:Resource Utilization  FTA:TOE Access  FTP:Trusted Paths and Channels

12-Oct-04TC-MTS 39TD02511 Example Families (FIA)  FIA_AFL:Authentication Failures  FIA_ATD:User Attributes Definition  FIA_SOS:Specification Of Secrets  FIA_USU:User Authentication  FIA_UID:User Identification  FIA_USB:User-Subject Binding

12-Oct-04TC-MTS 39TD02512 Assurance Classes  APE:Protection Profile Evaluation  ASE:Security Target Evaluation  ACM:Configuration Management  ADO:Delivery and Operation  ADV:Development  AGD:Guidance Documents  ALC:Life Cycle Support  ATE:Tests  AVA:Vulnerability Analysis

12-Oct-04TC-MTS 39TD02513 Example Families (ADV)  ADV_FSP:Functional Specification  ADV_HLD:High-Level Design  ADV_IMP:Implementation representation  ADV_INT:TOE Security Function Internals  ADV_LLD:Low-Level Design  ADV_RCR:Representation Correspondence  ADV_SPM:Security Policy Modelling

12-Oct-04TC-MTS 39TD02514 Protection Profile  Although content similar, PP is written in a different way to a standard. It is, therefore:  unlikely (and undesirable) that ETSI will change the style of its standards;  unreasonable to expect ISO and the security community to change the way a PP is written;  unrealistic to expect an evaluator to find all PP information in an ETSI standard (or multiple standards);  inefficient to write out information twice (once in a standard and again in the PP).  “PICS” approach adopted where information is summarized in a table which includes references to text rather than the text itself.

12-Oct-04TC-MTS 39TD02515 PP Header ETSI Protection Profile Introduction Doc No.VersionDate Full Title OverviewCopy the Scope clause here Description This should come directly from the first clause in the main body of the standard (clause 4?) which is likely to be a general introduction.

12-Oct-04TC-MTS 39TD02516 PP Security Environment aSecurity Environment (This section should summarize the Vulnerability Analysis) a.1Assumptions a.1.1Users are assumed to be suitably authorizedB.4.2 a.2Assets a.2.5Authentication keys7.5, B.8.1 a.3Threat agents a.3.2Unauthorized software applicationsB.9.1 a.4Threats a.4.8Unauthorized modification or destruction of an authentication keyB.9.5 a.5Security policies (OPTIONAL) a.5.3Common Criteria for Information Technology Security EvaluationISO/IEC 15408

12-Oct-04TC-MTS 39TD02517 PP Security Objectives bSecurity Objectives (Information likely to come from a different doc, e.g., Stage 1 or Stage 2) b.1Security objectives for the TOE b.1.1Users must be identified and authenticated on registrationEG §5.4 b.2Security objectives for the environment b.2.1 The database of user registration information must be up ‑ to ‑ date EG §5.6

12-Oct-04TC-MTS 39TD02518 PP Security Requirements cSecurity Requirements (Information should come directly from the security standard) c.1TOE security requirements c.1.1TOE security functional requirements c.1.1.7It shall be possible for a suitably authorized user to establish and modify the access rights of other users FDP_ACF c.1.3TOE security assurance requirements c.1.3.1A TOE implementing this PP shall be evaluated at CC EAL4 ISO/IEC ‑ 3 c.2Environment security requirements (OPTIONAL) c.2.4User authentication data shall be protected during transmission through the network FDP_ETC.27.3

12-Oct-04TC-MTS 39TD02519 PP Additional Information dAdditional Information (OPTIONAL) eRationale Reference to a document or annex explaining how the selected security objectives and requirements counter the threats identified in the Vulnerability Analysis. It is probably a good idea to include the rationale in the Vulnerability Analysis.

Standards In The Evaluation Of IT Security 39TD025