Chapter 18: Evaluating SystemsOverviewGoalsEvaluation MethodologyWhy Evaluate?Bit of HistoryTCSEC: 1983–1999Functional RequirementsSlide 9Slide 10Slide 11Assurance RequirementsSlide 13Slide 14Evaluation Classes A and BEvaluation Classes C and DEvaluation ProcessEvaluation PhaseRAMPImpactScope LimitationsProcess LimitationsContributionsFIPS 140: 1994–PresentRequirementsSecurity Level 1Security Level 2Security Level 3Security Level 4Slide 30Common Criteria: 1998–PresentSlide 32CC TermsProtection ProfilesForm of PPForm of PP (con’t)Slide 37Security TargetHow It WorksForm of STForm of ST (con’t)Slide 42Slide 43CC RequirementsSecurity Functional RequirementsSSE-CMM: 1997–PresentSSE-CMM ModelProcess AreasExample: Assess ThreatCapability Maturity LevelsUsing the SSE-CMMKey PointsNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-1Chapter 18: Evaluating Systems•Goals•Trusted Computer System Evaluation Criteria•FIPS 140•Common Criteria•SSE-CMMNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-2Overview•Goals–Why evaluate?•Evaluation criteria–TCSEC (aka Orange Book)–FIPS 140–Common Criteria–SSE-CMMNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-3Goals•Show that a system meets specific security requirements under specific conditions–Called a trusted system–Based on specific assurance evidence•Formal evaluation methodology–Technique used to provide measurements of trust based on specific security requirements and evidence of assuranceNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-4Evaluation Methodology•Provides set of requirements defining security functionality for system•Provides set of assurance requirements delineating steps for establishing that system meets its functional requirements•Provides methodology for determining that system meets functional requirements based on analysis of assurance evidence•Provides measure of result indicating how trustworthy system is with respect to security functional requirements–Called level of trustNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-5Why Evaluate?•Provides an independent assessment, and measure of assurance, by experts–Includes assessment of requirements to see if they are consistent, complete, technically sound, sufficient to counter threats–Includes assessment of administrative, user, installation, other documentation that provides information on proper configuration, administration, use of system•Independence critical–Experts bring fresh perspectives, eyes to assessmentNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-6Bit of History•Government, military drove early evaluation processes–Their desire to use commercial products led to businesses developing methodologies for evaluating security, trustworthiness of systems•Methodologies provide combination of–Functional requirements–Assurance requirements–Levels of trustNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-7TCSEC: 1983–1999•Trusted Computer System Evaluation Criteria–Also known as the Orange Book–Series that expanded on Orange Book in specific areas was called Rainbow Series–Developed by National Computer Security Center, US Dept. of Defense•Heavily influenced by Bell-LaPadula model and reference monitor concept•Emphasizes confidentiality–Integrity addressed by *-propertyNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-8Functional Requirements•Discretionary access control requirements–Control sharing of named objects–Address propagation of access rights, ACLs, granularity of controls•Object reuse requirements–Hinder attacker gathering information from disk or memory that has been deleted–Address overwriting data, revoking access rights, and assignment of resources when data in resource from previous use is presentNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-9Functional Requirements•Mandatory access control requirements (B1 up)–Simple security condition, *-property–Description of hierarchy of labels•Label requirements (B1 up)–Used to enforce MAC–Address representation of classifications, clearances, exporting labeled information, human-readable output•Identification, authentication requirements–Address granularity of authentication data, protecting that data, associating identity with auditable actionsNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-10Functional Requirements•Audit requirements–Define what audit records contain, events to be recorded; set increases as other requirements increase•Trusted path requirements (B2 up)–Communications path guaranteed between user, TCB•System architecture requirements–Tamperproof reference validation mechanism–Process isolation–Enforcement of principle of least privilege–Well-defined user interfacesNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-11Functional Requirements•Trusted facility management (B2 up)–Separation of operator, administrator roles•Trusted recovery (A1)–Securely recover after failure or discontinuity•System integrity requirement–Hardware diagnostics to validate on-site hardware, firmware of TCBNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-12Assurance Requirements•Configuration management requirements (B2 up)–Identify configuration items, consistent mappings among documentation and code, tools for generating TCB•System architecture requirements–Modularity, minimize complexity, etc.–TCB full reference validation mechanism at B3•Trusted distribution requirement (A1)–Address integrity of mapping between masters and on-site versions–Address acceptance proceduresNovember 1, 2004 Introduction to Computer Security©2004 Matt BishopSlide #18-13Assurance Requirements•Design specification, verification requirements–B1: informal security policy model shown to be consistent with its axioms–B2: formal security policy model proven to be consistent with its axioms, descriptive top-level specification (DTLS)–B3: DTLS shown to be consistent with security policy model–A1: formal top-level specification (FTLS) shown consistent with security policy model using approved formal methods; mapping between FTLS, source