why do we need security evaluation
play

Why do we need security evaluation To provide a basis for - PDF document

Why do we need security evaluation To provide a basis for specifying security expectations IT Security Evaluation To verify that a computer product/system fulfills the requirements imposed on it To establish a metric for the degree


  1. Why do we need security evaluation � To provide a basis for specifying security expectations IT Security Evaluation � To verify that a computer product/system fulfills the requirements imposed on it � To establish a metric for the degree of trust Simone Fischer-Hübner that can be placed on a security product/system (“objective yardstick”) � To guide developers which security is expected � To fulfil legal requirements (§ 14 German Digital Signature Act, § 17 Digital Signature Ordinance) History – Product/System Some Security Standards Evaluation Trusted Computer Presented in The Federal Evaluation Criteria this lecture Criteria (TCSEC) DoD 1985 NIST/NSA 1992 UK system security Common Criteria confidence levels (CC) 1989 Information Technology ISO 1999 German IT-Security Security Evaluation Criteria Criteria (ITSEC) 1989 EU 1991 French „Blue- White-Red“ Book 1989 Canadian Trusted Computer Product Evaluation Criteria Aiming for evaluation 1993 TCSEC TCSEC Requirements � Scope � Protection of confidentiality of classified information processed by DoD � Oriented towards isolated computer systems (mainframes) � Interpretations of TCSEC for other systems: � Trusted Network Interpretation (Red Book), 1987 � Trusted Database Management System Interpretation (Lavender Book), 1991 � Historic but well known and the base for most other product evaluation standards � Also known as “Orange Book” 1

  2. TCSEC Hierarchy Common Criteria � Harmonized criteria for the international community � Class D – Minimal Protection (unrated) functionality & quality Increasing requirements for for evaluation and recognition � Class C – Discretionary Protection � ISO IS 15408 � C1 Discretionary security protection � Current Version 3.1 from 2006/2007 � C2 Controlled Access protection � Available at: http://www.commoncriteriaportal.org/ � Class B – Mandatory Protection � The scope of the common criteria covers � B1 Labeled Security Protection � Systems (specific IT installation with a particular purpose and known � B2 Structured Protection operational environment) � B3 Security Domains and Products (hardware/software package that can be incorporated � Class A – Verified Protection � into a variety of systems ) � A1 Verified Design Common Criteria Structure Target of evaluation � Part 1: Introduction and General Model � Target Of Evaluation (TOE) � An IT product or system possibly � Part 2: Security Functional Requirements accompanied by guidance documentation � Part 3: Security Assurance Requirements that is the subject of an evaluation Requirements construction and organization Requirement expression Source: Common criteria � Class � A grouping of families that share a common focus � Family � A grouping of components that share security objectives but may differ in emphasis or rigor � Component � The smallest selectable set of elements that may be included in a PP, a ST, or a package Source: Common criteria 2

  3. Requirement use Protection Profile � Package � A reusable set of either functional or assurance components (e.g. An EAL), combined together to satisfy a set of identified security objectives � Security Target (ST) � A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE � Protection Profile (PP) � An implementation-independent, re-usable set of security requirements for a category of TOEs that meet specific consumer needs Source: Common criteria Functional Security Protection Profile Requirements � Protection profiles focus on an area specified � Class FAU: Security audit by the sponsor � Class FCO: Communication � No single repository – e.g. US Government PP � Class FCS: Cryptographic support or German BSI PP � Class FDP: User data protection � Example areas: � Class FIA: Identification and authentication � RBAC Profile � Class FMT: Security management � Firewall Profiles � Class FPR: Privacy � IDS Profiles � Class FPT: Protection of the TSF � Biometric Profiles � PKI Profiles � Class FRU: Resource utilisation � OS Profiles � Class FTA: TOE access � Class FTP: Trusted path/channels Example: FCO Communication Assurance Requirements � FCO Non-repudiation � Class ACM: Configuration management of origin ensures that � Class ADO: Delivery and operation the originator of information cannot � Class ADV: Development successfully deny � Class AGD: Guidance documents having sent the information. � FCO_NRO.1 Selective proof of origin requires the TSF � Class ALC: Life cycle support (TOE Sec. Funct.) to provide subjects with the capability � Class ATE: Tests to request evidence of the origin of information. � FCO_NRO.2 Enforced proof of origin requires that the � Class AVA: Vulnerability assessment TSF always generate evidence of origin for transmitted information. 3

  4. Combination of assurance requriements – Combination of assurance requriements – Evaluation Assurance Level (EAL) Evaluation Assurance Levels � EAL1 - functionally tested Evaluation is not a primary goal during design � EAL2 - structurally tested � EAL3 - methodically tested and checked � EAL4 - methodically designed, tested and reviewed � EAL5 - semiformally designed and tested TOE is designed with evaluation in mind � EAL6 - semiformally verified design and Source: Common criteria tested � EAL7 - formally verified design and tested Evaluation Preperation Evaluation Conduct � Evaluation � Initiation � Review the evaluation � The sponsors starts deliverables and perform the process evaluator actions � Feasibility study required by the assurance criteria � The evaluator checks � Observation reports can if the evaluation can be generated during the be performed evaluation � A list of evaluation � Evaluation Technical deliverables is Report is produce included where all � It contains the verdict involved parties and the justification agree to Source: Common Evaluation Methodology Source: Common Evaluation Methodology for Information Technology Security for Information Technology Security Evaluation Conclusion � Conformance to CC assessed � The overseer reviews the ETR for conformance with the CC � Evaluation Summary report is generated � It bases on the ETR and includes the result of the overseer review Source: Common Evaluation Methodology for Information Technology Security 4

Recommend


More recommend