Computer security principles and practice 3rd by williams stallings and brown ch13

Chapter 13 Trusted Computing and Multilevel Security Computer Security Models • • Problems involved both design and implementation Led to development of formal security models o All complex software systems have eventually All complex software systems have eventually Two fundamental computer revealed flaws or bugs that need to be fixed security facts: It is extraordinarily difficult to build computer hardware/software not vulnerable to security attacks • Initially funded by US Department of Defense Bell-LaPadula (BLP) model very influential Bell-LaPadula (BLP) Model • • • • • • Developed in 1970s Formal model for access control Subjects and objects are assigned a security class o o Top secret > secret > confidential > restricted > unclassified Form a hierarchy and are referred to as security levels A subject has a security clearance An object has a security classification Security classes control the manner by which a subject may access an object Bell-LaPadula (BLP) Model Access Modes The subject is READ READ allowed only APPEND APPEND read access to the object is allowed only write access to the object The subject is The subject The subject allowed neither is allowed WRITE WRITE both read EXECUTE EXECUTE read nor write and write access to the access to the object but may object invoke the object for • execution Multilevel security o o No read up • • Subject can only read an object of less or equal security level Referred to as the simple security property (ss-property) No write down • • A subject can only write into an object of greater or equal security level Referred to as the *-property high-level object-1 flow of information malicious subject with high-level security clearance low-level object-1 Figure13.1 Information Flow ShowingtheNeed for the*-property BLP Formal Description • • Based on current state of system (b, M, f, H): (current access set b, access matrix M, level function f, hierarchy H) Three BLP properties: ss-property: (Si, Oj, read) has fc(Si) ≥ fo(Oj) *-property: (Si, Oj, append) has fc(Si) ≤ fo(Oj) and (Si, Oj, write) has fc(Si) = fo(Oj) • ds-property: (Si, Oj, Ax) implies Ax ∈ M[Si BLP give formal theorems o Theoretically possible to prove system is secure o In practice usually not possible Release access • Change object level • Change current level • Give access permission • Rescind access permission • Create an object • Delete a group of objects • BLP Rules Carla level roles c1-s operation roles c1-s— read c1-t c1-s— write c1-t — write f2 c1-t — read f1 (a) Two newfiles arecreated: f1: c1-t; f2: c1-s Carla level roles operation roles c1-s— read f3 (comments to f2) Dirk c1-s c1-t c1-s— write c1-t — write f2 c1-t — read f1 (b) A third fileisadded: f3: c1-s Figure13.2 Exampleof Useof BLP Concepts (page of 3) Carla level roles Dirk c1-s operation roles c1-s— read c1-t c1-s — write f3 (comments to f2) f2 c1-t — write f4 exam c1-t — read exam template f1 (c) An exam is created based on an existingtemplate: f4: c1-t Carla level roles operation roles c1-s— read f3 (comments to f2) Dirk c1-s c1-t c1-s — write f2 c1-t — write f4 exam f1 c1-t — read exam template (d) Carla, as student, ispermitted acess to theexam: f4: c1-s Figure13.2 Exampleof Useof BLP Concepts (page of 3) Decrypted file File released User application (performs decryption) Symmetric key Key released Current platform software environment TPM Verification Encrypted file Protected symmetric key Storage Loading of encrypted key Figure13.13 Decryptinga FileUsinga Protected Key Figure 13.12 Common Criteria for Information Technology Security Evaluation • • • Common Criteria (CC) for Information Technology and Security Evaluation o ISO standards for security requirements and defining evaluation criteria Aim is to provide greater confidence in IT product security o o o Development using secure requirements Evaluation confirming meets requirements Operation in accordance with requirements Following successful evaluation a product may be listed as CC certified o NIST/NSA publishes lists of evaluated products CC Requirements Common set of potential security requirements for Assurance requirements use in evaluation • Basis Basis for for gaining gaining confidence confidence that that the the claimed claimed security security measures measures are are effective effective Functional requirements and and implemented implemented correctly correctly • Define Define desired desired security security behavior behavior Target of evaluation (TOE) • Refers to the part of product or system subject to evaluation Component Class • Collection Collection of of requirements requirements that that share a common focus or intent • Describes Describes a a specific specific set set of of security security requirements requirements • Smallest Smallest selectable selectable set set Table 13.3 CC Security Functional Requirements Table 13.4 CC Security Assurance Requirements CLASSb Familyj Component Component • • • PACKAGES Reusableset of functional or assurancerequirements Optional input to PP or ST Component CLASSa Familyj Familyk Component Component • • • Component PROTECTION PROFILE possibleinput sources for PP Component Component • • • SECURITY TARGET possibleinput sources for ST Component Optional extended (non-CC) security requirements Figureure 13.13 13.14 Organization and Construction of Common Criteria Requir ements Fig Target of evaluation (TOE) Human user/ remoteIT product Security attributes Subject TOE security functions (TSF) EnforcesTOE Security Policy (TSP) Object/ Information Subject Security attributes User TOE security functions interface(TSFI) Security attributes Subject Subject Security attributes Security attributes Resource Process TSF scopeof control (TSC) Figure 13.15 curity Functional Requirements Paradigm Figure 13.14 Se Protection Profile (PP) • • Smart card provides simple PP example Describes IT security requirements for smart card use by sensitive applications Threats Threats that that must must be be addressed: addressed: • Physical probing • Invalid input • Linkage of multiple operations Security Security objectives objectives • Reflect the stated intent to counter identified threats and comply with identified organizational security policies Security Security requirements requirements • Provided to thwart specific threats and to support specific policies under specific assumptions Security Assurance “Degree of confidence one has that the security controls operate correctly and protect the system as intended Assurance is not, however, an absolute guarantee that the measures work as intended.” • Evaluators Use the assurance requirements as criteria when evaluating security features and controls • May be in the same organization as consumers or a third-party evaluation team Developers • • • Respond to security requirements Interpret statements of assurance requirements Determine assurance approaches and level of effort • Consumers • • Select security features and functions Determine the required levels of security assurance Target audiences • • • • • • • System operation Product implementation Product design Security policy Requirements Applies to: IT products Deals with security features of Assurance Assurance and Evaluation Scope of Assurance System architecture System integrity System testing • • • Addresses Addresses both both the the system system development development phase phase and and the the system system operations operations phase phase Addresses Addresses the the correct correct operation operation of of the the system system hardware hardware and and firmware firmware Ensures Ensures security security features features have have been been tested tested thoroughly thoroughly Covert channel analysis Trusted facility management Configuration management • • • Attempts Attempts to to identify identify any any potential potential means means for for Deals Deals with with system system administration administration bypassing bypassing security security policy policy Requirements Requirements are are included included for for configuration configuration control, control, audit, audit, management, management, and and accounting accounting Design specification and verification Trusted recovery Trusted distribution • • • Addresses Addresses the the correctness correctness of of the the system system Provides Provides for for correct correct operation operation of of security security Ensures Ensures that that protected protected hardware, hardware, firmware, firmware, design design and and implementation implementation with with respect respect to to features features after after a a system system recovers recovers from from and and software software do not not go go through through the the system system security security policy policy failures, failures, crashes, crashes, or or security security incidents incidents unauthorized unauthorized modification modification during during transit transit from from the the vendor vendor to to the the customer customer Common Criteria Evaluation Assurance Levels EAL 1: Functionally tested EAL 2: Structurally tested EAL 3: Methodically tested and checked EAL 4: Methodically designed, tested, and reviewed EAL 5: Semi-formally designed and tested EAL 6: Semi-formally verified design and tested EAL 7: Formally verified design and tested Evaluation Ensures Ensures security security features features work work correctly correctly and and effectively effectively and and show show no no exploitable exploitable vulnerabilities vulnerabilities Performed Performed in in parallel parallel with with or or after after the the development development of of the the TOE TOE Higher Higher levels levels entail: entail: greater greater rigor, rigor, more more time, time, more more cost cost Principle Principle input: input: security security target, target, evidence, evidence, actual actual TOE TOE Result: Result: confirm confirm security security target target is is satisfied satisfied for for TOE TOE Process Process relates relates security security target target to to high-level high-level design, design, low-level low-level design, design, functional functional specification, specification, source source code code implementation, implementation, and and object object code code and and hardware hardware realization realization of of the the TOE TOE Degree Degree of of rigor rigor and and depth depth of of analysis analysis are are determined determined by by assurance assurance level level desired desired Evaluation Parties and Phases • • • Evaluation parties: o o Sponsor - customer or vendor o Evaluator - confirms requirements are satisfied o Certifier - agency monitoring evaluation process Developer - provides evidence for evaluation Monitored and regulated by a government agency in each country Common Criteria Evaluation and Validation Scheme (CCEVS) o Operated by NIST and the NSA Preparation Initial contact between sponsor and developer Conduct of evaluation Confirms satisfaction of security target Conclusion Final report is given to the certifiers for acceptance Phases Summary • • • The Bell-LaPadula model for computer security o o o o o o o Computer security models • General description Formal description of model Implementation example-multics Limitations to the BLP model • Other formal models for computer security o o o Biba integrity model Clark-Wilson integrity model Chinese wall model The concept of trusted systems o o Reference monitors Trojan horse defense o o Abstract operations Example of BLP use Application of multilevel security • • Multilevel security for role-based access control Database security and multilevel security Trusted computing and the trusted platform module o o o o o Authenticated boot service Certification service Encryption service TPM functions Protected storage Common criteria for information technology security evaluation o o o Requirements Profiles and targets Example of a protection profile Assurance and evaluation o o o o Target audience Scope of assurance Common criteria evaluation assurance levels Evaluation ...Chapter 13 Trusted Computing and Multilevel Security Computer Security Models • • Problems involved both design and implementation Led to development of formal security models o All complex... a security class o o Top secret > secret > confidential > restricted > unclassified Form a hierarchy and are referred to as security levels A subject has a security clearance An object has a security. .. to be handled concurrently within the same system when some users having access to the system have neither a security clearance nor need-to-know for some of the data handled by the system and (b)