Evaluating SystemsReading MaterialOutlineEvaluation GoalsExample: Used CarFormal EvaluationTCSEC: 1983-1999TCSEC Functional RequirementsTCSEC Assurance RequirementsTCSEC ClassesSlide 11Slide 12TCSEC Evaluation processTCSEC Evaluation IssuesInterim Efforts in the ’90sFIPS 140OpenSSL FIPS-140 certificationCommon Criteria – 1998 to todayCC TerminologyProtection Profile (PP)Protection ProfileProduct evaluationCC Functional RequirementsCC Assurance RequirementsEvaluation Assurance LevelsCC Evaluation Process in USEvaluation StatusAlternate PerspectiveCertifying ProcessSSE-CMMCapability Maturity LevelsKey PointsEvaluating SystemsReading Material•Chapter 21 Computer Security: Art and Science•The orange book and the whole rainbow serieshttp://www.radium.ncsc.mil/tpep/library/rainbow/•The common criteriaLists all evaluated protection profiles and productshttp://www.commoncriteriaportal.orgOutline•Motivation for system evaluation•Specific evaluation systemsTCSEC/Orange BookInterim systemsCommon CriteriaEvaluation Goals•Oriented to purchaser/user of system•Assurance that system operates as advertisedExample: Used Car•How do you evaluate a used car?Repair/service records (vendor-supplied documentation)Test drive (self-evaluation)Mechanic (independent verification)•Certified used cars“Get peace of mind with Honda's 150-point inspection”Formal Evaluation•Provide a systematic framework for system evaluationMore consistent evaluationBetter basis for comparing similar product•Trusted third party system for evaluation•Originally driven by needs of government and militaryTCSEC: 1983-1999•Trusted Computer System Evaluation Criteria (TCSEC) also called the Orange BookSpecifies evaluation classes (C1, C2, B1, B2, B3, A1)Specifies functionality and assurance requirements for each class•Functional Model builds onBLP (mandatory labeling)Reference MonitorsTCSEC Functional Requirements•DAC•Object Reuse Sufficient clearing of objects between uses in resource poolE.g. zero pages in memory system•MAC and Labels•Identification and Authentication•Audit requirements increase at higher classes•Trusted PathNon-spoofable means to interact with TCBCtl-Alt-Del in WindowsTCSEC Assurance Requirements•Configuration ManagementFor TCB•Trusted DistributionIntegrity of mapping between master and installations•System ArchitectureSmall and modular•Design Specification – vary between classes•Verification – Vary between classes•Testing•Product DocumentationTCSEC Classes•D – Catch all (aka “you fail”)•C1 – Discretionary ProtectionIdentification and authentication and DACMinimal Assurance•C2 – Control access protectionAdds object reuse and auditingMore testing requirementsWindows NT 3.5 evaluated C2TCSEC Classes•B1 – Labeled Security ProtectionAdds MAC for some objectsStronger testing requirements. Information model of security policy.Trusted Unixes tended to be B1•B2 – Structured protectionMAC for all objects. Additional logging. Trusted Path. Least privilege.Covert channel analysis, configuration management, more documentation, formal model of security policyTCSEC Classes•B3 – Security DomainsImplements full RVM. Requirements on code modularity, layering, simplicity.More stringent testing and documentation.•A1 – Verified protectionSame functional requirements as B3Significant use of formal methods in assuranceHoneywell’s SCOMPTCSEC Evaluation process•Originally controlled by governmentNo fee to vendorMay reject evaluation application if product not of interest to government or doesn’t meet preliminary tests•Later introduced fee-based evaluation labs•Evaluation phasesDesign analysis – no source code accessTest analysisFinal reviewTCSEC Evaluation Issues•Evaluating a specific configurationE.g., Window NT, no applications installed, no networkNew patches, versions require re-certification•RAMP introduced to ease re-certifications•Long time for evaluationSometimes product was obsolete before evaluation finished•Criteria CreepB1 means something more in 1999 than it did in 1989•Narrow scopeOperating systems for military, MLSInterim Efforts in the ’90s•Canadian Trusted Computer Product Evaluation Criteria (CTCPEC)•Information Technology Security Evaluation Criteria (ITSEC) – Western Europe•Commercial International Security Requirements (CISR) – AmEx and EDS•Federal Criteria – NSA and NISTFIPS 140•Framework for evaluating Cryptographic Modules•Still in Use•AddressesFunctionalityAssurancePhysical securityOpenSSL FIPS-140 certification•OpenSSL certified under FIPS-140Certification obtained Feb 2007•Process took five (!) yearsCertified version is 0.9.7, 3 years old•ProblemsProcess slowPublic comments process used by competitors to derail certificationCommon Criteria – 1998 to today•Pulls together international evaluation effortsEvaluations mean something between countriesEconomies of scale•Three top level documentsCommon Criteria Documents•Describe functional and assurance requirements. Defines Evaluation Assurance Levels (EALs)CC Evaluation Methodology (CEM)•More details on the valuation. Complete through EAL5 (at least)Evaluation Scheme•National specific rules for how CC evals are performed in that country•Directed by NIST in USCC Terminology•Target of Evaluation (TOE)The product being evaluated•TOE Security Policy (TSP)Rules that regulate how assets are managed, protected, and distributed in a product•TOE Security Functions (TSF)Implementation of the TSPGeneralization of the TCBProtection Profile (PP)•Profile that describes the security requirements for a class of productsList of evaluated PP’s http://www.commoncriteriaportal.org/public/expert/index.php?menu=6•Replaces the fixed set of classes from TCSEC•ISSO created some initial profiles to match TCSEC classesControlled Access Protection Profile (CAPP) corresponds to C2Labeled Security Protection Profile (LSPP) corresponds to B1Protection Profile•A list of:ThreatsAssumptionsOrganizational policiesObjectivesAssurance requirements•Along with rationale•PP’s are evaluated by CLEFsProduct evaluation•Define a security target (ST)May leverage an evaluated protection profileDefine
View Full Document