Beyond the CC certificate. How to continue to assess the security assurance in operational systems?

Transcription

1 Beyond the CC certificate How to continue to assess the security assurance in operational systems? 1

2 Christophe BLAD / OPPIDA : Certifier then Technical manager of the French scheme 2005 now: Director of OPPIDA s ITSEF OPPIDA s ITSEF ~15 CC evaluators ~50 evaluations since 2002 EAL1 to EAL5 Digital signature applications File encryption solutions Virtualization solutions Firewalls VPNs Systems 2

3 Observed situation CC-certified products, in operational systems, do not offer the expected security features Reasons: CC currently focus on design and implementation phases of the product life-cycle Deployment and usage are system-specific and cannot be evaluated by the ITSEF for a product on-the-shelf 3

4 Inherent risks Risk Assessment Identified risks Design & Implementation Deployment Security Objectives / Requirements Security Implementation Deployed security architecture Deployment drift Accepted identified risks Implementation drift Operational system Running Security Operational drift 4 OK OK NOK NOK Null if certified Security Assurance in the operational system

5 Solutions to evaluate the deployment and operational drift To define checkpoints to be implemented in the operational system 1. Define measurement requirements 2. Collect base measures 3. Interpret base measures using references 4. Evaluate assurance on measures 5. Correlate and aggregate measures 6. Display results Source: BUGYO project, operational security assurance monitoring, European EUREKA/CELTIC funded research project 5

6 The benefit of a taxonomy to specify measurement requirements Classification of requirements and results Evaluation of the completeness of the requirements Interpretation of results: If execution of the security function is OK but its configuration NOK -> current situation OK but NOK after reboot Aggregation and presentation of results by categories 6

7 Definition of a taxonomy to specify measurement requirements Are the [Properties] of the [Security requirement realization] as [expected]? [Security requirement realization]: The concerned security requirement: SFRs, security objectives for the operational environment The supporting element: the TOE / subsystems of the TOE / elements of TOE operational environment (operating system, database, administrators, premises, ) The type of element: physical / social / cyber [Properties]: The temporal property: Configuration / Execution The specificity: Generic (TOE guidance) / Specific (deployment specific) [expected]: The reference permitting to interpret the collected data 7

8 Who and where to specify the measurement requirements? The intended audience is the community of future integrators and operators of the certified product/system - > the document must be public/available The security target A specific operational guide The CC certification report The developer in collaboration with the evaluator can edit it 8

9 9 Example: volume encryption application

10 The deployment drift Security requirement realization Properties Expectation Requirement Certification scope Supporting element Type Temporal Specificity TOE Version Workstation Cyber Configuration Generic Version = Tested platform Workstation Cyber Configuration Generic OS = Windows XP SP3 10

11 Security objectives for the operational environment (1/2) Security requirement realization Properties Expectation Requirement Supporting element Objectives for the operational environment Physical aspects Physical access to workstations Physical access to workstations Personnel aspects Type Temporal Specificity Offices Physical Configuration specific Intrusion tests performed once a month Offices Physical Execution specific Intrusion test results OK Trusted admin System admins Social Configuration specific A security clearance process is defined Trusted admin System admins Social Execution specific The system administrator has a security clearance Password protection users Social Configuration specific A password protection policy is defined Password users Social Execution specific Users apply the password protection Regular audit of logs 11 protection policy Security officer Social Execution specific The security officier performs audit of logs once a week

12 Security objectives for the operational environment (2/2) Security requirement realization Properties Expectation Requirement Supporting element Objectives for the operational environment Connectivity aspects Trusted host (update, antivirus, ) Trusted PKCS#11 library, smartcard driver Type Temporal Specificity workstation 1 Cyber Execution specific Workstation conforms to the workstation security policy workstation 1 Cyber Configuration specific Installed PKCS#11 library = Gemalto xxx Trusted smartcard users smartcards Cyber Configuration Generic CC EAL4 certified smartcard Trusted PKI internal PKI Cyber Configuration Generic CC certified PKI 12

13 For each SFR Security requirement realization Properties Expectation Requirement Supporting element Type Temporal Specificity SFRs FCS_COP.1 (file encryption) FCS_COP.1 Workstations Cyber Configuration Generic Encryption configuration FCS_COP.1 Workstations Cyber Execution Generic Pictogram on encrypted folders FCS_COP.1 Workstations Cyber Execution Specific Encrypted container content 13

14 Deployment of probes to collect base measures The selection of the necessary probe is helped by the precise specification of the measurement requirements Manual probes: human checking Automated probes: scripts, tools The frequency of the checking and the quality of the probe (trust in the collected data) permits to evaluate an assurance level for the result Assurance scale depends on your needs Regular / frequent / continuous Unproved / proved probe 14

15 Interpretation of the collected data Collected data (base measures) can be: Complete or parts of Configuration files Network traffic Output of system shell commands Minutes of interviews Collected data needs to be compared with a reference to decide if the expectation is reached or not Normalization of results allows correlation and aggregation 15

16 16

17 Correlation / aggregation / presentation Define you own rules depending of the specificity of your operational system Easy rule: percentage of conformity Is execution more important than configuration? In case of duplication of equipments (eg. Load balancing), the non conformity of one of the equipment does not lead to non conformity of the complete system 17

18 Security Measurement Infrastructure Security Problem Definition Security Objectives Security Requirements Measurement Requirements (Are [Properties] of [SecReq realization] as [expected]?) Abstract Infrastructure Objects Operational Security measures (value {0,1}, assurance) Derived Measures (interpreted BMs) Base Measures (raw data) System real elements Operational system

19 Threats/OSP/compliance Security metrics Security Problem Definition Measurement Infrastructure Security Objectives Security Objectives metrics Security Requirements Security Requirements metrics Measurement Requirements (Are [Properties] of [SecReq realization] as [expected]?) Architectural metrics Abstract Infrastructure Objects Operational Security Assurance measures (value {0,1}, assurance) Derived Measures (interpreted BMs) Element metrics System real elements Operational system Base Measures (raw data)

20 Future work Specification of Assurance Profiles (AP) PP/ST+ specification of measurement requirements Allow communities of experts to define both security requirements and how to assure that the security requirements are running in the operational system Ground for the definition of Security SLAs Standardization of the AP structure on-going at ETSI (European Telecom Standards Institute) 20

21 21