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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend