TM8104 IT Security EvaluationAutumn 20091 Evaluation - the Main Road to IT Security Assurance CC Part 3.

Slides:



Advertisements
Similar presentations
© Crown Copyright (2000) Module 2.6 Vulnerability Analysis.
Advertisements

Module N° 4 – ICAO SSP framework
© Crown Copyright (2000) Module 2.3 Functional Testing.
Security Requirements
Module 1 Evaluation Overview © Crown Copyright (2000)
Software Quality Assurance Plan
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Common Criteria Evaluation and Validation Scheme Syed Naqvi XtreemOS Training Day.
More CMM Part Two : Details.
Effective Design of Trusted Information Systems Luděk Novák,
IT Security Evaluation By Sandeep Joshi
1 norshahnizakamalbashah CEM v3.1: Chapter 10 Security Target Evaluation.
The Open Source Security Myth — And How to Make it A Reality Michael Davis Dynamic Security Concepts, Incorporated Track 3, 1300 Sunday, 1 August 2004.
Trusted Hardware: Can it be Trustworthy? Design Automation Conference 5 June 2007 Karl Levitt National Science Foundation Cynthia E. Irvine Naval Postgraduate.
1 Evaluating Systems CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute May 6, 2004.
Configuration management. Reasons for software configuration management  it facilitates the ability to communicate  status of documents, coding, changes.
1 SYSTEM and MODULE DESIGN Elements and Definitions.
1 Building with Assurance CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute May 10, 2004.
Software Requirements
Fundamentals of Information Systems, Second Edition
Overview of Software Requirements
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
Software Engineering CSE470: Systems Engineering 35 Computer System Engineering Computer System Engineering is a problem-solving activity. Itemize desired.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Software Configuration Management
Security Assessments FITSP-M Module 5. Security control assessments are not about checklists, simple pass-fail results, or generating paperwork to pass.
Enterprise Architecture
Codex Guidelines for the Application of HACCP
1 A Common-Criteria Based Approach for COTS Component Selection Wes J. Lloyd Colorado State University Young Researchers Workshop (YRW) 2004.
Effective Methods for Software and Systems Integration
SEC835 Database and Web application security Information Security Architecture.
Practical IS security design in accordance with Common Criteria Security and Protection of Information 2005 František VOSEJPKA S.ICZ a.s. June 5, 2005.
Introduction to Software Quality Assurance (SQA)
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Information Systems Security Computer System Life Cycle Security.
Evaluating Systems Information Assurance Fall 2010.
Security Assessments FITSP-A Module 5
Cybersecurity: Engineering a Secure Information Technology Organization, 1st Edition Chapter 7 Software Supporting Processes and Software Reuse.
Software Configuration Management
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Background. History TCSEC Issues non-standard inflexible not scalable.
SOFTWARE DESIGN.
1 Common Criteria Ravi Sandhu Edited by Duminda Wijesekera.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Lecture 7: Requirements Engineering
1 FRENCH PROPOSAL FOR ESARR6 1 - BACKGROUND - 15/02/00 : Kick-off meeting, Presentation of the CAA/SRG input (SW01), Request from the chairman to comment.
ANKITHA CHOWDARY GARAPATI
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
1 Common Evaluation Methodology for IT Security Part 2: Evaluation Methodology chapter 5-8 Marie Elisabeth Gaup Moe 06/12/04.
Purpose: The purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development,
Chapter 19: Building Systems with Assurance Dr. Wayne Summers Department of Computer Science Columbus State University
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
Next level solutions 1 Security: It’s Just Good Systems Engineering Ronda R. Henning Harris Corporation
Chapter 21: Evaluating Systems Dr. Wayne Summers Department of Computer Science Columbus State University
Cmpe 589 Spring Fundamental Process and Process Management Concepts Process –the people, methods, and tools used to produce software products. –Improving.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
DESIGN PROCESS AND CONCEPTS. Design process s/w design is an iterative process through which requirements are translated into a “blueprint” for constructing.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
 System Requirement Specification and System Planning.
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Chapter 1 Computer Technology: Your Need to Know
ITIL: Service Transition
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Ch.18 Evaluating Systems - Part 2 -
Software and Systems Integration
Lecture 9- Design Concepts and Principles
Software Requirements
CMMI – Staged Representation
Chapter 19: Building Systems with Assurance
Lecture 9- Design Concepts and Principles
Presentation transcript:

TM8104 IT Security EvaluationAutumn Evaluation - the Main Road to IT Security Assurance CC Part 3

TM8104 IT Security EvaluationAutumn Assurance definition Asssurance that the claimed security measures of the TOE are effective and implemented correctly is derived from knowledge about the - definition - construction - operation of the TOE

TM8104 IT Security EvaluationAutumn Measuring Assurance by: Active investigation of the: TOE by: Expert evaluators with increasing emphasis on: scope depth rigour

TM8104 IT Security EvaluationAutumn Assurance Structure Statements of Requirements Technical specification High-Level design Detailed design Implementation TOE Each Assurance Component Consists of: Developer Actions (.D) Activities to be performed by the developer - shall use, shall provide Content and Presentation of Evidence (.C) Evidence required for evaluation, what the evidence must demonstrate, and what information the evidence must convey - include, identify, describe, show, demonstrate Evaluator Actions (.E) Analysis implied by the evidence provided, and by the targeted level of assurance - confirm, determine Lower Levels of Abstraction

TM8104 IT Security EvaluationAutumn Organising the requirements Class Family Component Element - share a common intent different coverage of security objectives - share security objectives different in emphasis or rigour - describes a set of security requirements - describes indivisible security requirements

TM8104 IT Security EvaluationAutumn Class hierarchy Assurance class i 1< i < 7 Assurance family 1 Assurance family 2 Assurance family n Assurance component 1 Assurance component 2 Assurance component j Element 1 Element 2 Element k Element 1 Element 2 Element k 2 < n < 6 1 < j < 6 1 < k < 21

TM8104 IT Security EvaluationAutumn Assurance classes and families

TM8104 IT Security EvaluationAutumn Assurance class ACM Configuration Management CM Automation CM Capabilities CM Scope CC Part 3 – page 71/86

TM8104 IT Security EvaluationAutumn Configuration management - integrity of the TOE ACM_AUT (2) CM automation establishes the level of automation used to control the configuration items ACM_CAP (4) CM capabilities define the characteristics of the CM system ACM_SCP (3) CM scope indicates the TOE items that need to be controlled by the CM system

TM8104 IT Security EvaluationAutumn ACM_AUT.1 Partial Configuration Management Automation Objectives - the automated tools must be able to support the numerous changes that occur during development, and ensure that the changes are authorised Dependencies - ACM_CAP.3 Authorization Controls Developer action elements: ACM_AUT.1.1D, ACM_AUT.1.2D Content and pres. of evidence:1.1C/1.4C Evaluator action elements: 1.1E

TM8104 IT Security EvaluationAutumn Assurance class ADO Delivery and Operation Delivery Installation, Generation and Start-Up CC Part 3 – page 87/92

TM8104 IT Security EvaluationAutumn Delivery and operation - secure delivery, installation and operation of the TOE ADO_DEL (3) Delivery covers the procedures to maintain appropriate security during transfer of the TOE to the user ADO_IGS (2) Covers secure installation, generation and start-up procedures

TM8104 IT Security EvaluationAutumn Assurance class ADV Development Funct. Specification TSF Internals High-Level Design Impl. Representation Low-Level Design Repr. Correspondence CC Part 3 – page 93/128

TM8104 IT Security EvaluationAutumn Development descriptions of the representation of the TSF at various levels of abstraction, and correspondence mappings ADV_FSP (6) Correspondence and consistency between the TSP, TSP model and functional specification ADV_HLD (5) Provides a description of the TSF in terms of major structural units ADV_IMP (3) Description of implementation in terms of source code, firmware construction documentation, hardware drawings, etc.

TM8104 IT Security EvaluationAutumn Development - 2 ADV_INT (3) Describes the internal structure of the TSF ADV_LLD (3) A description of the internal workings of the TSF in terms of modules, their interrelationships and dependencies ADV_RCR (3) Describes the correspondence between the various development representations

TM8104 IT Security EvaluationAutumn Assurance class AGD Guidance Documents Administrator Guidance User Guidance 1 1 CC Part 3 – page 129/133

TM8104 IT Security EvaluationAutumn Guidance documents - requirements for user and administrator guidance AGD_ADM (1) How to configure, maintain and administer the TOE in a correct manner for maximum security AGD_USR (1) Documentation for the non-administrative user of the TOE

TM8104 IT Security EvaluationAutumn Assurance class ALC Life Cycle Support Development Security Tools and Techniques Flaw Remediation Life Cycle Definition CC Part 3 – page 135/147

TM8104 IT Security EvaluationAutumn Life Cycle Support - the establishment of discipline and control in the process of refinement of the TOE during development and maintenance. ALC_DVS (2) Concerned with physical, procedural, personell and other security measures used in the development environment to protect the TOE ALC_FLR (4) Discovered flaws should be tracked and corrected by the developer ALC_LCD (3) Establishment of a model for developm. and maint. of the TOE ALC_TAT (3) Selection of tools for development, analysis and impl. of the TOE

TM8104 IT Security EvaluationAutumn Assurance class ATE Tests Coverage Independent Testing Depth Functional Tests 3 CC Part 3 – page 149/165

TM8104 IT Security EvaluationAutumn Tests - testing establishes whether the TSF exhibits the properties necessary to satisfy the functional requirements of the PP/ST ATE_COV (3) Deals with completeness of testing ATE_DPT (4) Decides the level of detail to which the TOE is tested ATE_FUN (1) Establishes that the TSF exhibits the properties necessary to satisfy the functional requirements of its PP/ST ATE_IND (3) Demonstrates that the security functions perform as specified

TM8104 IT Security EvaluationAutumn Assurance class AVA Vulnerability Assessment Covert Ch. Analysis Vulnerability Analysis Misuse Strength of TOE funct. 3 4 CC Part 3 – page 167/185

TM8104 IT Security EvaluationAutumn Vulnerability assessment addresses the possible existence of exploitable covert channels, misuse, incorrect configuration of the TOE, and the ability for all security critical mechanisms to withstand direct attacks AVA_CCA (3) Is carried out to determine the existence and potential capacity of unintended signalling channels AVA_MSU (2) Investigates whether the TOE can be configured or used in a manner which is insecure

TM8104 IT Security EvaluationAutumn Vulnerability assessment - 2 AVA_SOF (1) Assessment of the strength of the security mechanisms AVA_VLA (4) Assessment to determine whether vulnerabilities identified could allow malicious users to violate the TSP

TM8104 IT Security EvaluationAutumn Assurance Family ADV_INT TSF Internals Objectives - Component Levelling - Application Notes - - deals with the internal structure of the TSF modular construction, layering of software, minimization of circular dependencies, minimization of non-TSP enforcing software based on the amount of structure and minimization required “portions of the TSF”, interfaces, sub-systems, modules implementation units

TM8104 IT Security EvaluationAutumn Assurance Family ADV_INT TSF Internals ADV_INT.1 Modularity Dependencies: ADV_IMP.1 Subset of the implementation of the TSF ADV_LLD.1 Descriptive low-level design Developer Action Elements: 1.1.D The developer shall the design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design 1.2.D The developer shall provide an architectural description

TM8104 IT Security EvaluationAutumn Assurance Family ADV_INT TSF Internals ADV_INT.1 Modularity Content and presentation of evidence: 1.1.C The architectural description shall identify the modules of the TSF 1.2.C The architectural description shall describe the purpose, interface, parameters and effects of each module of the TSF 1.3.C The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions

TM8104 IT Security EvaluationAutumn Assurance Family ADV_INT ADV_INT.1 Modularity Evaluator actions: 1.1.E The evaluator shall confirm that the presentation provided meets all requirements for contents and presentation of evidence 1.2.E The evaluator shall determine the both the low-level design and the implementation representation are in compliance with the architectural description TSF Internals 1 2 3

TM8104 IT Security EvaluationAutumn Assurance Family ADV_INT TSF Internals ADV_INT.2 Reduction of complexity ADV_INT.3 Minimisation of complexity

TM8104 IT Security EvaluationAutumn Assurance levels

TM8104 IT Security EvaluationAutumn Assurance Levels EAL1 - Functionally tested EAL2 - Structurally tested EAL3 - Methodically tested and checked EAL4 - Methodically designed, tested, and reviewed EAL5 - Semiformally designed and tested EAL6 - Semiformally verified design and tested EAL7 - Formally verified design and tested

TM8104 IT Security EvaluationAutumn Example: EAL3 Objectives: - to gain maximum assurance from positive security engineering at the design stage - to obtain a moderate level of independently assured security

TM8104 IT Security EvaluationAutumn Developers have to use: (1 of 17) ACM_CAP.3 Authorization controls Dependencies: ACM_SCP.1 TOE CM coverage ALC_DVS.1 Identification of security measures Developers action elements: Provide a reference for the TOE Use a CM system Provide CM documentation

TM8104 IT Security EvaluationAutumn Developers have to use: (2 of 17) ACM_SCP.1 TOE CM Coverage Dependencies: ACM_CAP.3 Authorisation controls Developers action elements: Provide CM documentation

TM8104 IT Security EvaluationAutumn Developers have to use: (3 of 17) ADO_DEL.1 Delivery procedures Dependencies: None Developers action elements: document procedures for delivery of the TOE or parts of it to the user Use the delivery procedures

TM8104 IT Security EvaluationAutumn Developers have to use: (4 of 17) ADO_IGS.1 Installation, generation and start-up procedures Dependencies: AGD_ADM.1 Administrator guidance Developers action elements: Provide document procedures necessary for secure installation, generation and start-up of the TOE

TM8104 IT Security EvaluationAutumn Developers have to use: (5 of 17) ADV_FSP.1 Informal functional specification Dependencies: ADV_RCR.1 Informal correspondence specification Developers action elements: Provide a functional specification Use a CM system Provide CM documentation

TM8104 IT Security EvaluationAutumn Developers have to use: ( 6 of 17) ADV_HLD.2 Security enforcing high-level design Dependencies: ADV_FSP.1 Informal functional specification Developers action elements: Provide high-level design of the TSF

TM8104 IT Security EvaluationAutumn Developers have to use: ( 7 of 17) ADV_RCR.1 Informal correspondence demonstration Dependencies: None Developers action elements: Provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided

TM8104 IT Security EvaluationAutumn Developers have to use: ( 8 of 17) AGD_ADM.1 Administrator guidance Dependencies: ADV_FSP.1 Informal functional specification Developers action elements: Provide administrator guidance addressed to system administrative personnel

TM8104 IT Security EvaluationAutumn Developers have to use: ( 9 of 17) AGD_USR.1 User guidance Dependencies: ADV_FSP.1 Informal functional specification Developers action elements: Provide user guidance

TM8104 IT Security EvaluationAutumn Developers have to use: ( 10 of 17) ALC_DVS.1 Identification of security measures Dependencies: None Developers action elements: Produce development security documentation

TM8104 IT Security EvaluationAutumn Developers have to use: ( 11 of 17) ATE_COV.2 Analysis of coverage Dependencies: ADV_FSP.1 Informal functional specification ATE_FUN.1 Functional testing Developers action elements: Provide an analysis of the test coverage

TM8104 IT Security EvaluationAutumn Developers have to use: ( 12 of 17) ATE_DPT.1 Testing: high-level design Dependencies: ADV_HLD.1 Descriptive high-level design ATE_FUN.1 Functional testing Developers action elements: Provide the analysis of the depth of testing

TM8104 IT Security EvaluationAutumn Developers have to use: ( 13 of 17) ATE_FUN.1 Functional testing Dependencies: None Developers action elements: Test the TSF and document the results Provide test documentation

TM8104 IT Security EvaluationAutumn Developers have to use: ( 14 of 17) ATE_IND.2 Independent testing - sample Dependencies: ADV_FSP.1 Informal functional specification AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance ATE_FUN.1 Functional testing Developers action elements: Provide the TOE for testing

TM8104 IT Security EvaluationAutumn Developers have to use: ( 15 of 17) AVA_MSU.1 Examination of guidance Dependencies: ADO_IGS.1 Inst., gen., and start-up procedures ADV_FSP.1 Informal functional specification AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance Developers action elements: Provide guidance documentation

TM8104 IT Security EvaluationAutumn Developers have to use: ( 16 of 17) AVA_SOF.1 Strength of the TOE Security Function evaluation Dependencies: ADV_FSP.1 Informal functional specification ADV_HLD.1 Descriptive high-level design Developers action elements: Provide a strength of TSF analysis for each mechanism identified in the ST as having a strength of TOE security claim

TM8104 IT Security EvaluationAutumn Developers have to use: ( 17 of 17) AVA_VLA.1 Developer vulnerability analysis Dependencies: ADV_FSP.1 Informal functional specification ADV_HLD.1 Descriptive high-level design AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance Developers action elements: Perform and document an analysis of the TOE deliverables searching for obvious ways in which a user can violate the TSP Document the disposition of obvious vulnerabilities