Presentation on theme: "National Information Assurance Partnership Paul Mansfield January 2013"— Presentation transcript:
1 National Information Assurance Partnership Paul Mansfield January 2013 An Evolution
2 Common Criteria Recognition Arrangement (CCRA) CertificateConsumersFinlandGreeceIsraelAustriaTurkeyHungaryCzechRepublicSingaporeIndiaDenmarkPakistanMalaysiaUSCanadaUKGermanyFranceAustraliaJapanNetherlandsNorwaySouth KoreaNew ZealandSpainSwedenItalyCertificateProducers
3 2012 International Common Criteria Conference Common Criteria Recognition Arrangement (CCRA) Management Committee (CCMC) AgreementVision StatementDevelop Collaborative Protection Profiles (cPP)International Technical Communities (iTC)CC SchemesLabsStakeholdersVendorsCCMC Chair Directed CC Executive Secretariat and CC Directors BoardUpdate CCRATerms of Reference & CCRA DocumentsTransition Plan
4 2012 ICCC Vision Statement Key Points Raise General Security LevelStandardizationCCRA Mutual Recognition – cPPiTCs Define cPPscPPs Instead of Individual STsSTs w/o cPP – Limited to EAL22 Nations DisagreementEvaluations above cPPNational Requirements & Special ArrangementsCCRA cPP OnlycPPs Will Address Vulnerability AnalysisTransparent and Repeatablehttps://www.commoncriteriaportal.org/
5 Develop, promulgate and manage foundational security requirements NIAP Functions:Prioritize PP DevelopmentAuthor and promulgate PPsConduct risk analysisDevelop profiles with a risk-based mindsetInfluence international standards (e.g., ISO)NIAP leads technical communities to develop, promulgate and manage foundational security requirements that enable the acquisition of validated products to continually improve network defense for America and its Allies.
6 GOTS vs. COTS Government Devices (GOTS) Commercial Devices (COTS) Traditionally, the US government has used government designed and certified devices to protect its most sensitive data.Government Devices (GOTS)Purpose-built for securityStrict design and implementation criteriaLong, exhaustive security evaluationCommercial Devices (COTS)Provide a balance of security and featuresQuick to market, flexible
7 Committee on National Security Systems Policy (CNSSP) 11 COTS comply with NIAP processLayered COTS preferred over GOTSGOTS evaluated by NSAEvolutionMove away from Evaluation Assurance Level (EAL)Comply with Protection Profile (PP)PPs developed by Technical CommunitiesCCRA Collaborative PPs (cPP)
8 Benefits of New Evaluation Process One Evaluation LevelAchievable, Repeatable, TestableOne PP per TechnologyInternationally acceptedObjective Assurance RequirementsExtended Package (EP) if requiredTechnical CommunitiesIndustry/Government Partners, shared expertise, contribute to PP development
9 What’s Not Working?“Cookie cutter approach” to technology type being evaluatedSubjective, inconsistent standards across vendors or countriesHigher EAL doesn’t equal higher securityProcess is too lengthyNot repeatable across labs, schemes/nationsNo enforcement of security requirement testingEALs are not related to the technology type being evaluated, such that a USB and Firewall are evaluated against the same criteria. Evaluations at higher levels of assurance provide a false sense of confidence. Common Evaluation Methodology (CEM) does not recognize technologies as different – rather, the current model utilizes a cookie cutter approach.Since the EALs are broad, vendors can choose the standards they want the products to be evaluated against an EAL. Each nation creates their own testing regimens. There has not been sufficient cooperation among all stakeholders to reach agreement in requirements. In many nations conforming to CC evaluations is optional.A higher EAL level meant that the product adhered to a more stringent set of quality assurance requirements during evaluation, but the security features were not tested.A higher EAL level does not mean that one product is more secure than another, so that in reality, an EAL6 product may be no better than an EAL2 product.b. The CC became an opportunity to force vendors to disclose sensitive information.Evaluations for an EAL can take years to complete, which can mean that products may be out-of-date by the time an evaluation is completed.EAL evaluations are not repeatable across the labs, schemes or nations.EALs look at documentation of a security requirement being implemented but does not test the security requirement.
10 What is a Protection Profile? Tailored set of baseline security functional and security assurance requirementsFocuses on tailored requirements and assurance activities by technologyTailored set of use cases, threats, and objectivesAllows for the expansion of baseline requirements through extended packages for specialized technologiesi.e. Network Device PP and Firewall EPPPs are a set of security functional requirements that have international recognition.A PP is tailored to products of a specific technology type, such as a Network Devise or IPSec for VPN Clients. It focuses on functional requirements and assurance activities by technology.PPs can have extended packages so that specific functions of a product can also be evaluated.An example of an extended package would be for a firewall. The firewall would be evaluated against a Network Devise PP and then also to a Firewall Extended Package.The requirements of PPs will be a set of technology-specific threats and core function requirements necessary to mitigate those threats to create a basic level of security for a particular technology and product.
11 Why Are PP’s Good (Achievable) Reduced time and costs of evaluation (Repeatable) Produce comparable and meaningful results across labs/schemes(Testable) Assurance Activities – tailored CEMAssurance of product complianceAddress specific threatsCreated and maintained by Technical Communities (TCs)PPs are achievable, repeatable, and testablePPs should be completed within a 4-6 month time frame instead of years, which drastically cuts down time and costs.PPs include a set of tailored technology-specific threats derived from operational knowledge and technical expertise along with a set of core functional requirements necessary to mitigate those threats.There is only one evaluation level, PP compliant, so that all products that have been evaluated are to the same standards. Comparable and meaningful results are produced.They establish a basic level of security for a particular technology and include assurance activities so that the evaluations become repeatable across labs, require less documentation, and become more time effective.Requires vendors to disclose only information pertinent to evaluation and safeguards their proprietary information.PPs are have less subjective requirements/test criteria. Vendors and labs can no longer choose only a few requirements to be evaluated against; they must adhere to all assurance activities (e.g., testing requirements), so that a product will be truly PP compliant. Tailored CEM (Common Evaluation Methodology)PPs are created and maintained by Technical Communities (TCs) so that all requirements can be met by all vendor types, thereby giving a larger role to industry and providing greater incentive to participate.
12 Collaborative environment to create requirements and standards for PPs What Exactly Are TCs?Any participating vendor, country, critical infrastructure, evaluator or labCollaborative environment to create requirements and standards for PPsUltimate creator of PPs with NIAP guidanceTCs consist of any vendor, country, critical infrastructure, evaluator, or lab that wishes to participate.TCs are a collaborative environment where all involved help in creating the requirements and standards set forth by a PP.NIAP will continue to be the forefront of the PP, helping to guide and write the PPs, but it will ultimately be the TC that will set the requirements, thus allowing an equal opportunity for all to meet these requirements.
13 ST vs. PP Example (click) 1.) You have some device that you wish to have evaluated. (click)*SFR – Security Functional Requirement**SAR – Security Assurance Requirement***TAA – Tailored Assurance Activity
14 ST vs. PP Example Protection Profile Security Target *SFR 1 *SFR 1 Functional PackageFunctional Package**SAR 01SAR 02SAR 03SAR ....SAR 24**SAR 01SAR 02TAA 03TAA ....TAA 10(click)2.) The device will either go against an EAL a Security Target (ST) or a Protection Profile (PP).A vendor ST can claim any valid “Functional Package”, i.e. any valid combination of security functional requirements.A vendor ST can claim any valid “Assurance Package”, i.e. any valid combination of security assurance requirement.Assurance PackageAssurancePackage*SFR – Security Functional Requirement**SAR – Security Assurance Requirement***TAA – Tailored Assurance Activity
15 ST vs. PP Example Protection Profile Security Target *SFR 1 *SFR 1 Functional PackageFunctional Package**SAR 01SAR 02SAR 03SAR ....SAR 24**SAR 01SAR 02TAA 03TAA ....TAA 10(click)However, some product vendors only claim minimal security functionality in their ST and continue to claim an assurance package of EAL4 (Evaluation Assurance Level 4).This approach can be deceiving to the consumer who assume or equate a higher assurance package level as being more secure.In fact, it is the security functionality present in a product that provides the security AND the assurance package provides an indication of the confidence that has been gained through evaluation that the security functionality works as intended.4.) As a result, the product can obtain the “assurance package” EAL4 stamp but only test against a subset of “security functional” requirements. (click)Assurance PackageAssurancePackage*SFR – Security Functional Requirement**SAR – Security Assurance Requirement***TAA – Tailored Assurance Activity
16 ST vs. PP Example Protection Profile Security Target *SFR 1 *SFR 1 Functional PackageFunctional Package**SAR 01SAR 02SAR 03SAR ....SAR 24**SAR 01SAR 02TAA 03TAA ....TAA 10(click)3.) However, not all of the security functional requirements may be relevant to a product technology type also not all the assurance requirements in an assurance package, e.g. EAL 4, may be relevant to the product technology type, and therefore not apply. (click)5.) A product technology type PP can be constructed with an agreed:- specification of security functional requirements, i.e. “Functional Package”- specification of security assurance requirements, i.e. “Assurance Package”andA product must pass ALL of the PP functional and assurance requirements (click)6.) So, although a product technology type PP may have fewer security assurance requirements and therefore perhaps assumed to equate to a lower EAL. However, the PP is more considered in the choice of the security assurance requirements appropriate for a product technology type. Together with the added specificity of the security assurance requirements through a process of refinement or “Tailoring” there can be greater confidence that the assurance activities are adequate and appropriate for that product technology type.“Secure” is a combination of the security functional requirements which provide the security features in a product technology type, and the assurance security requirements are appropriate for a product technology type and that their correct application provide the appropriate confidence that the security functions operate as intended.Therefore, an agreed product technology type PP claim is less open to security functional or assurance requirements misinterpretation, than an ST for a product that may have only minimal security functional requirements and an inappropriate EAL claim.Assurance PackageAssurancePackage*SFR – Security Functional Requirement**SAR – Security Assurance Requirement***TAA – Tailored Assurance Activity
17 Technical Community Key to PP Development and Maintenance Any participating CCRA nation, vendor, critical infrastructure industry, academia, evaluator, or labCollaborative environment to create requirements and testing standards for PPsTCs consist of any vendor, country, critical infrastructure, evaluator, or lab that wishes to participate.TCs are a collaborative environment where all involved help in creating the requirements and standards set forth by a PP.NIAP will continue to be the forefront of the PP, helping to guide and write the PPs, but it will ultimately be the TC that will set the requirements, thus allowing an equal opportunity for all to meet these requirements.
18 Published Protection Profiles Full Disk EncryptionUSB Flash DriveHardcopy Device (MFP)Stateful FirewallNetwork Devices 1.1ESM Policy ManagementESM Access ControlESM Identity & Credential Mgt.Mobility Endpoint OSMobility Endpoint VoIP AppSIP ServerWireless LAN Access SystemWireless LAN ClientVPN ClientPeripheral Sharing SwitchLocated at
19 Protection Profiles Under Development NDPP V2VPN Gateway Extended PackageBIOSMFP v2USB v2Hardware Security ModuleVirtualizationStorage Area NetworkFile EncryptionMobile Device Management
22 NIAP Evolution Progress IA Products Must be CC Evaluated & Validated – U.S. National Policy (NSTISSP-11)Not the case in most other CC-nationsNo longer accepting traditional (EAL4) evaluationsEvaluations must go against NIAP Approved PPCreated Technical CommunitiesNetwork, Firewall, ESMPublished 12 Standard PP (December 2012)Continuing Outreach to Gov’t & International Partners, Industry, Labs, Academia