lecture 19 trusted computing and multilevel security
DESCRIPTION
Lecture 19 Trusted Computing and Multilevel Security. modified from slides of Lawrie Brown and Hesham El- Rewini. Computer Security Models. two fundamental computer security facts: all complex software systems have eventually revealed flaws or bugs that need to be fixed - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/1.jpg)
Lecture 19Trusted Computing and Multilevel Security
modified from slides of Lawrie Brown and Hesham El-Rewini
![Page 2: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/2.jpg)
Computer Security Models• two fundamental computer security facts:
• all complex software systems have eventually revealed flaws or bugs that need to be fixed
• it is extraordinarily difficult to build computer hardware/software not vulnerable to security attacks
• problems involved both design and implementation– led to development of formal security models
2
![Page 3: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/3.jpg)
Trusted OS Functions
3
![Page 4: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/4.jpg)
Bell-LaPadula (BLP) Model• formal model for access control
– developed in 1970s• subjects and objects are assigned a security class
– a subject has a security clearance– an object has a security classification– form a hierarchy and are referred to as security
levels• top secret > secret > confidential > restricted >unclassified
– security classes control the manner by which a subject may access an object
4
![Page 5: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/5.jpg)
BLP Model Access Modes• READ
– the subject is allowed only read access to the object• APPEND
– the subject is allowed only write access to the object• WRITE
– the subject is allowed both read and write access to the object
• EXECUTE– the subject is allowed neither read nor write access
to the object but may invoke the object for execution5
![Page 6: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/6.jpg)
Multilevel Security (MLS)• RFC 2828 defines multilevel security as follows:“A class of system that has system resources (particularly stored information) at more than one security level (i.e., has different types of sensitive resources) and that permits concurrent access by users who differ in security clearance and need-to-know, but is able to prevent each user from accessing resources for which the user lacks authorization.”
6
![Page 7: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/7.jpg)
Multi-Level Security• 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
7
? AC
![Page 8: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/8.jpg)
Multi-Level Security
8
![Page 9: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/9.jpg)
Multi-Level Security• ds-property : An individual (or role) may
grant to another individual (or role) access to a document – based on the owner’s discretion,
• constrained by the MAC rules
• site policy overrides any discretionary access controls
9
? AC
![Page 10: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/10.jpg)
BLP Formal Description• based on current state of system (b, M, f, H):
– current access set b: triples of (s, o, a)• subject s has current access to object o in access mode a
– access matrix M: matrix of Mij
• access modes of subject Si to access object Oj
– level function f: security level of subjects and objects• fo ( Oj ) is the classification level of object Oj
• fs ( Si ) is the security clearance of subject Si
• fc ( Si ) is the current security level of subject Si
– hierarchy H: a directed rooted tree of objects10
![Page 11: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/11.jpg)
BLP Formal Description• 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: current (Si, Oj, Ax) implies Ax M[Si Oj]
• BLP gives formal theorems– theoretically possible to prove system is secure– in practice usually not possible
11
![Page 12: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/12.jpg)
Illustration
o1
s1 o2
o3
s2 o4
o5
Low
High
o5
s2
Object
Subject
12
Write
Write
Read
Read
Read
Read
![Page 13: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/13.jpg)
BLP Rules1
• get access
2• release access
3• change object level
4• change current level
5• give access permission
6• rescind access permission
7• create an object
8• delete a group of objects
13
![Page 14: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/14.jpg)
BLP Example
*-property
![Page 15: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/15.jpg)
BLP Example
ss-property and *-property
![Page 16: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/16.jpg)
16
BLP Example
“downgrade” in a controlled and monitored manner
“classification creep”: information from a range of sources and levels
“covert channels”: (untrusted) low classified executable dataallowed to be executed by a high clearance (trusted) subject
Confidentiality or Integrity
![Page 17: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/17.jpg)
17
Biba Integrity Model• strict integrity policy:
– Modify: To write or update information in an object– Observe: To read information in an object– Execute: To execute an object– Invoke: Communication from one subject to another– simple integrity: I(S) ≥ I(O)– integrity confinement: I(S) ≤ I(O)– invocation property: I(S1) ≥ I(S2)
![Page 18: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/18.jpg)
18
Clark-Wilson Integrity Model• closely models commercial operations
– Well-formed transactions• A user should not manipulate data arbitrarily
– Separation of duty among users• A person who create or certify a well-formed
transaction may not execute it
![Page 19: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/19.jpg)
19
Clark-Wilson Integrity Model• Principal components of the model
– Constrained data items (CDIs)• Subject to strict integrity controls
– Unconstrained data items (UDIs)• Unchecked data items
– Integrity verification procedures (IVPs): • Intended to assure that all CDIs conform to some
application-specific model of integrity and consistency– Transformation procedures (TPs):
• System transactions that change the set of CDIs from one consistent state to another
![Page 20: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/20.jpg)
20
Clark-Wilson Integrity Model
![Page 21: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/21.jpg)
21
Chinese Wall Model• integrity and confidentiality• use both discretionary and mandatory access
– Subjects: Active entities that may wish to access protected objects
– Information: Information organized into a hierarchy • Objects: Individual items of information, each concerning a
single corporation• Dataset (DS): All objects that concern the same corporation• Conflict of interest (CI) class: All datasets whose
corporations are in competition– Access rules: Rules for read and write access
![Page 22: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/22.jpg)
22
Chinese Wall Model
Simple security rule: A S can read O only if• O is in the same DS as an object already accessed by S, OR• O belongs to a CI from which S has not yet accessed any information
*-property rule: A S can write an O only if• S can read O according to the simple security rule, AND• All objects that S can read are in the same DS as O. sanitized data
![Page 23: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/23.jpg)
23
Terminology Related to Trust• Trust: The extent to which someone who relies on a system can have confidence that
the system meets its specifications – i.e., that the system does what it claims to do and does not perform unwanted functions
• Trusted system: A system believed to enforce a given set of attributes to a stated degree of assurance.
• Trustworthiness: Assurance that a system deserves to be trusted, such that the trust can be guaranteed in some convincing way, – such as through formal analysis or code review.
• Trusted computer system: A system that employs sufficient hardware and software assurance measures to allow its use for simultaneous processing of a range of sensitive or classified information.
• Trusted computing base (TCB): A portion of a system that enforces a particular policy– The TCB must be resistant to tampering and circumvention. – The TCB should be small enough to be analyzed systematically.
• Assurance: A process that ensures a system is developed and operated as intended by the system's security policy.
• Evaluation: Assessing whether the product has the security properties claimed for it.• Functionality: The security features provided by a product.
![Page 24: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/24.jpg)
24
Reference Monitors
Properties• Complete mediation• Isolation• Verifiability
o Trustworthy system
![Page 25: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/25.jpg)
25
Trojan Horse Defense
![Page 26: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/26.jpg)
Trusted Platform Module (TPM)
• concept from Trusted Computing Group • hardware module at heart of hardware/
software approach to trusted computing (TC)• uses a TPM chip
– motherboard, smart card, processor– working with approved hardware/software– generating and using crypto keys
• has three basic services: • authenticated boot, certification, encryption
26
![Page 27: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/27.jpg)
27
TPM Functions
![Page 28: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/28.jpg)
Authenticated Boot Service• responsible for booting entire OS in stages and ensuring
each is valid and approved for use– at each stage digital signature associated with code is verified– TPM keeps a tamper-evident log of the loading process
• log records versions of all code running– can then expand trust boundary to include additional
hardware and application and utility software– confirms component is on the approved list, is digitally
signed, and that serial number hasn’t been revoked• result is a configuration that is well-defined with
approved components
28
![Page 29: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/29.jpg)
Certification Service• once a configuration is achieved and logged the TPM
can certify configuration to others– can produce a digital certificate– confidence that configuration is unaltered because:
• TPM is considered trustworthy• only the TPM possesses this TPM’s private key
• include challenge value in certificate to also ensure it is timely
• provides a hierarchical certification approach– hardware/OS configuration– OS certifies application programs– user has confidence is application configuration
29
![Page 30: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/30.jpg)
Encryption Service• encrypts data so that it can only be decrypted by a
machine with a certain configuration• TPM maintains a master secret key unique to machine
– used to generate secret encryption key for every possible configuration of that machine
• can extend scheme upward– provide encryption key to application so that decryption can
only be done by desired version of application running on desired version of the desired OS
– encrypted data can be stored locally or transmitted to a peer application on a remote machine
30
![Page 31: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/31.jpg)
31
Protected Storage Function
![Page 32: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/32.jpg)
Security Assurance• “…degree of confidence 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.”
32
![Page 33: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/33.jpg)
Assurance and Evaluation• 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
• assurance– deals with security features of
IT products– applies to:
• requirements• security policy• product design• product implementation• system operation
target audiences:
• consumers – select security features and
functions – determine the required levels of
security assurance
• developers– respond to security
requirements– interpret statements of
assurance requirements– determine assurance
approaches and level of effort
![Page 34: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/34.jpg)
34
Scope of Assurance• system architecture
– addresses both the system development phase and the system operations phase
• system integrity– addresses the correct operation of the system hardware and firmware
• system testing– ensures security features have been tested thoroughly
• design specification and verification– addresses the correctness of the system design and implementation
with respect to the system security policy• covert channel analysis
– attempts to identify any potential means for bypassing security policy
![Page 35: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/35.jpg)
35
Scope of Assurance• trusted facility management
– deals with system administration• trusted recovery
– provides for correct operation of security features after a system recovers from failures, crashes, or security incidents
• trusted distribution– ensures that protected hardware, firmware, and software do not go
through unauthorized modification during transit from the vendor to the customer
• configuration management– requirements are included for configuration control, audit,
management, and accounting
![Page 36: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/36.jpg)
Assurance• Testing
– based on the actual product being evaluated, • not on abstraction
• Verification– each of the system’s functions works correctly
• Validation– developer is building the right product
• according to the specification36
![Page 37: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/37.jpg)
Testing• Observable effects versus internal structure• Can demonstrate existence of a problem,
– but passing tests does not imply absence of any• Hard to achieve adequate test coverage within
reasonable time– inputs & internal states
• hard to keep track of all states
• Penetrating Testing– tiger team analysis, ethical hacking
• Team of experts in design of OS tries to crack system37
![Page 38: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/38.jpg)
Formal verification• The most rigorous method• Rules of mathematical logic to demonstrate
that a system has certain security property
• Proving a Theorem– Time consuming– Complex process
38
![Page 39: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/39.jpg)
Entry
min A[1]i 1
i i + 1
i > n
min < A[i]
min A[i]
Exityes
noyes
no
Example: find minimum
39
![Page 40: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/40.jpg)
Finding the minimum valueAssertions
P: n > 0 Q: n > 0 and1 i n and
min A[1]
R: n > 0 and S: n > 0 and1 i n and i = n + 1 and
for all j 1 j i -1 for all j 1 j i -1
min A[j] min A[j] 40
![Page 41: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/41.jpg)
Validation• Requirements checking
– system does things it should do• also, system does not do things it is not supposed to do
• Design and code reviews– traceability from each requirement to design and
code components• System testing
– data expected from reading the requirement document can be confirmed in the actual running of the system
41
![Page 42: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/42.jpg)
42
CC Assurance LevelsEAL 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
![Page 43: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/43.jpg)
Evaluation• ensures security features work correctly and effectively
and show no exploitable vulnerabilities• performed in parallel with or after the development of TOE• higher levels entail: greater rigor, more time, more cost• principle input: security target, evidence, actual TOE• result: confirm security target is satisfied for TOE• process relates security target to high-level design, low-
level design, functional specification, source code implementation, and object code and hardware realization of the TOE
• degree of rigor and depth of analysis are determined by assurance level desired
43
![Page 44: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/44.jpg)
44
Evaluation Parties and Phases• evaluation parties:
– sponsor - customer or vendor– developer - provides evidence for evaluation– evaluator - confirms requirements are satisfied– certifier - agency monitoring evaluation process
• monitored and regulated by a government agency in each country
• Common Criteria Evaluation and Validation Scheme (CCEVS)– operated by NIST and the NSA
![Page 45: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/45.jpg)
45
Evaluation Parties and Phases• 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
![Page 46: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/46.jpg)
Evaluation• Review: requirements, design, implementation,
assurance• US “Orange Book” Evaluation
– Trusted Computer System Evaluation Criteria (TCSEC)• European ITSEC Evaluation
– Information Technology Security Evaluation Criteria• US Combined Federal Criteria
– 1992 jointly buy NIST and NSA
46
![Page 47: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/47.jpg)
Summary
• computer security models– Bell-Lapadula– Biba Integrity Model– Clark-Wilson Integrity Model– Chinese Wall Model
• trusted systems– reference monitors– Trojan Horse Defense
• application of multilevel security– role-based access control– database security
• common criteria for information technology security evaluation– requirements– profiles and targets
• trusted computing and the trusted platform module– authenticated boot service– certification service – encryption service– TPM functions– protected storage
• assurance and evaluation– target audience– scope of assurance– common criteria evaluation
assurance levels– evaluation process
![Page 48: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/48.jpg)
Role-Based Access Control
![Page 49: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/49.jpg)
49
RBAC Elements
![Page 50: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/50.jpg)
50
RoleHierarchy
UserAssignments
![Page 51: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/51.jpg)
51
Database Classification
Table
Column
![Page 52: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/52.jpg)
52
Database Classification
Row
Element
![Page 53: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/53.jpg)
Database Security: Read Access• DBMS enforces simple security rule (no read up)• easy if granularity is entire database or at table
level• inference problems if have column granularity
– if can query on restricted data can infer its existence• SELECT Ename FROM Employee WHERE Salary > 50K
– solution is to check access to all query data• also have problems if have row granularity
– null response indicates restricted/empty result• no extra concerns if have element granularity
53
![Page 54: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/54.jpg)
Database Security: Write Access• enforce *-security rule (no write down)• have problem if a low clearance user wants to
insert a row with a primary key that already exists in a higher level row:– can reject, but user knows row exists– can replace, compromises data integrity– polyinstantiation and insert multiple rows with
same key, creates conflicting entries• same alternatives occur on update• avoid problem if use database/table granularity
54
![Page 55: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/55.jpg)
Example of Polyinstantiation
55
![Page 56: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/56.jpg)
Common Criteria (CC)• Common Criteria for Information Technology and
Security Evaluation– ISO standards for security requirements and defining
evaluation criteria• aim is to provide greater confidence in IT product security
– development using secure requirements– evaluation confirming meets requirements– operation in accordance with requirements
• following successful evaluation a product may be listed as CC certified– NIST/NSA publishes lists of evaluated products
56
![Page 57: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/57.jpg)
57
CC Requirements
• functional requirements– define desired security
behavior• assurance requirements
– basis for gaining confidence that the claimed security measures are effective and implemented correctly
• component – describes a specific set of
security requirements– smallest selectable set
common set of potential security requirements for use in evaluation
• target of evaluation (TOE) – refers to the part of product or
system subject to evaluation• class
– collection of requirements that share a common focus or intent
![Page 58: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/58.jpg)
58
CC Security Functional Requirements
![Page 59: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/59.jpg)
59
CC Security Assurance Requirements
![Page 60: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/60.jpg)
Construction of CC Requirements
60
![Page 61: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/61.jpg)
61
CC Security Paradigm
![Page 62: Lecture 19 Trusted Computing and Multilevel Security](https://reader035.vdocuments.us/reader035/viewer/2022081520/568168ba550346895ddfa667/html5/thumbnails/62.jpg)
Protection Profile (PP)• smart card provides simple PP example• describes IT security requirements for smart
card use by sensitive applications
• physical probing• invalid input• linkage of multiple operations
threats that must be addressed:
• reflect the stated intent to counter identified threats and comply with identified organizational security policies
security objectives
• provided to thwart specific threats and to support specific policies under specific assumptions
security requirements
62