IT Security Evaluation Why do we need security evaluation To - PDF document

IT Security Evaluation Why do we need security evaluation � To provide a basis for specifying security expectations � To verify that a computer product/system fulfills the requirements imposed on it � To establish a metric for the degree of trust that can be placed on a security product/system � To guide developers which security is expected 1

Some Security Standards Aiming for evaluation Evaluation process Evaluation Framework Source: Common Evaluation Methodology for Information Technology Security 2

Evaluation principles � Appropriate � The evaluation activities should be appropriate to the intended level of assurance � Impartial � All evaluations shall be free from bias � Objective � Minimum subjective judgment that is possible � Repeatable � Given the same process and TOE the same evidence should yield the same result � Sound � The result should be complete and technical correct Key Parties in evaluation � Evaluator � Conducts the evaluation according to the methodology � Developer � Seeks for evaluation and choose the evaluation criteria � Consumer � Consumes the evaluation report CEM for CC as example Source: Common Evaluation Methodology for Information Technology Security 3

Roles in Evaluation CEM for CC as example Source: Common Evaluation Methodology for Information Technology Security Product/System Evaluation 4

History – Product/System Evaluation Trusted computer evaluation criteria (TCSEC) DoD 1985 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 1993 TCSEC � Scope � Protection of confidentiality of classified information processed by DoD � Oriented towards isolated computer systems (mainframe) � Historic but well known and the base for most other product evaluation standards � Also known as “Orange Book” 5

TCSEC Requirements Security policy What security (access to resoruces) is required in the Functionality system/product What does the system to be secure Accountability How the system links individuals to actions and audit orderly behavior Assurance How certain can we be that the functionality is correct Quality Is the defined security enforced in Documentation the expected way How well is the functionality and the development documented TCSEC Hierachy � Class D – Minimal Protection (unrated) � Class C – Discretionary Protection � C1 Discretionary security protection � C2 Controlled Access protection � Class B – Mandatory Protection � B1 Labeled Security Protection � B2 Structured Protection � B3 Security Domains � Class A – Verified Protection � A1 Verified Design 6

Common Criteria � Harmonized criteria for the international community for evaluation and recognition � ISO IS 15408 � Currently Version 2.1 from August 1999 � Available at: http://csrc.nist.gov/cc/index.html � The scope of the common criteria covers Systems and Products Target of evaluation � Target Of Evaluation (TOE) � An IT product or system and its associated administrator and user guidance documentation that is the subject of an evaluation. 7

TOE Evaluation Process Requirements construction and organization Source: Common criteria 8

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 rigour � Component � The smallest selectable set of elements that may be included in a PP, an ST, or a package Requirement use � 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 � A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE � Protection Profile � An implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs 9

Functional Security Requirements � Class FAU: Security audit � Class FCO: Communication � Class FCS: Cryptographic support � Class FDP: User data protection � Class FIA: Identification and authentication � Class FMT: Security management � Class FPR: Privacy � Class FPT: Protection of the TSF � Class FRU: Resource utilisation � Class FTA: TOE access � Class FTP: Trusted path/channels Example: FCO Communication � FCO Non-repudiation of origin ensures that the originator of information cannot successfully deny having sent the information. � FCO_NRO.1 Selective proof of origin requires the TSF to provide subjects with the capability to request evidence of the origin of information. � FCO_NRO.2 Enforced proof of origin requires that the TSF always generate evidence of origin for transmitted information. 10

Assurance Requirements � Class ACM: Configuration management � Class ADO: Delivery and operation � Class ADV: Development � Class AGD: Guidance documents � Class ALC: Life cycle support � Class ATE: Tests � Class AVA: Vulnerability assessment Combination of assurance requriements – Evaluation Assurance Level (EAL) � 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 tested � EAL7 - formally verified design and tested 11

Combination of assurance requriements – Evaluation Assurance Levels Source: Common criteria Protection Profile Source: Common criteria 12

Protection Profile � Protection profiles focus on an area specified by the sponsor � No single repository – e.g. US Government PP or German BSI PP � Example areas: � RBAC Profiles � Firewall Profiles � IDS Profiles � Biometric Profiles � PKI Profiles � OS Profiles Protection Profile Title: Role-Based Access Control Protection Profile http://www.cesg.gov.uk/site/iacs/i tsec/media/protection- profiles/RBAC_987.pdf 13

Functional Requirements Functional Requirements 14

Evaluation Preperation � Initiation � The sponsors starts the process � Feasibility study � The evaluator checks if the evaluation can be performed � A list of evaluation deliverables is included where all involved parties agree to Source: Common Evaluation Methodology for Information Technology Security 15

Evaluation Conduct � Evaluation � Review the evaluation deliverables and perform evaluator actions required by the assurance criteria � Observation reports can be generated during the evaluation � Evaluation Technical Report is produce � It contains the verdict and the justification Source: Common Evaluation Methodology 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 16

Process Evaluation Systems Security Engineering Capability Maturity Model � SSE-CMM is a process reference model � SSE-CMM concern the system security engineering activities for a secure product or a trusted system addressing the complete lifecycle � ISO Standard 21827 � Available at: http://www.sse-cmm.org/index.html 17

Process areas - Security Best Practices � PA01 – Administer Security Controls � PA02 – Assess Impact � PA03 – Assess Security Risk � PA04 – Assess ThreatPA05 – Assess Vulnerability � PA06 – Build Assurance Argument � PA07 – Coordinate Security � PA08 – Monitor Security Posture � PA09 – Provide Security Input � PA10 – Specify Security Needs � PA11 – Verify and Validate Security Process areas – Project and Organizational Best Practices � PA12 – Ensure Quality � PA13 – Manage Configurations � PA14 – Manage Project Risk � PA15 – Monitor and Control Technical Effort � PA16 – Plan Technical Effort � PA17 – Define Organization's Systems Engineering Process � PA18 – Improve Organization's Systems Engineering Processes � PA19 – Manage Product Line Evolution � PA20 – Manage Systems Engineering Support Environment � PA21 – Provide Ongoing Skills and Knowledge � PA22 – Coordinate with Suppliers 18

Capability Levels SSE Appraisal Method Source: SSE-CMM 19