slides - afcea

Report
National Information Assurance
Partnership
Paul Mansfield
January 2013
1
®
Certificate
Producers
Common Criteria Recognition Arrangement
(CCRA)
US
Australia
Netherlands New Zealand
Certificate
Consumers
Austria
Hungary
Czech
Republic
India
Canada
Norway
France
Spain
Denmark
Israel
Germany
Sweden
Finland
Pakistan
Italy
Japan
South
Korea
Turkey
Greece
Singapore
Malaysia
UK
2012 International Common Criteria Conference
• Common Criteria Recognition Arrangement (CCRA) Management
Committee (CCMC) Agreement
• Vision Statement
– Develop Collaborative Protection Profiles (cPP)
– International Technical Communities (iTC)
• CC Schemes
• Labs
• Stakeholders
• Vendors
• CCMC Chair Directed CC Executive Secretariat and CC Directors Board
– Update CCRA
– Terms of Reference & CCRA Documents
– Transition Plan
3
2012 ICCC Vision Statement Key Points
•
•
•
•
•
•
Raise General Security Level
Standardization
CCRA Mutual Recognition – cPP
iTCs Define cPPs
cPPs Instead of Individual STs
STs w/o cPP – Limited to EAL2
– 2 Nations Disagreement
• Evaluations above cPP
– National Requirements & Special Arrangements
– CCRA MR @ cPP Only
• cPPs Will Address Vulnerability Analysis
– Transparent and Repeatable
• https://www.commoncriteriaportal.org/
4
Develop, promulgate and manage
foundational security requirements
• NIAP Functions:
– Prioritize PP Development
– Author and promulgate PPs
• Conduct risk analysis
• Develop profiles with a risk-based mindset
– Influence 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.
5
GOTS vs. COTS
Traditionally, the US government has used government designed and certified
devices to protect its most sensitive data.
• Government Devices (GOTS)
– Purpose-built for security
– Strict design and implementation criteria
– Long, exhaustive security evaluation
• Commercial Devices (COTS)
– Provide a balance of security and features
– Quick to market, flexible
6
Committee on National Security Systems Policy
(CNSSP) 11
• Policy
– COTS comply with NIAP process
– Layered COTS preferred over GOTS
– GOTS evaluated by NSA
• Evolution
– Move away from Evaluation Assurance Level (EAL)
– Comply with Protection Profile (PP)
– PPs developed by Technical Communities
– CCRA Collaborative PPs (cPP)
7
Benefits of New Evaluation Process
• One Evaluation Level
– Achievable, Repeatable, Testable
• One PP per Technology
– Internationally accepted
– Objective Assurance Requirements
– Extended Package (EP) if required
• Technical Communities
– Industry/Government Partners, shared expertise,
contribute to PP development
8
What’s Not Working?
• “Cookie cutter approach” to technology type being
evaluated
• Subjective, inconsistent standards across vendors or
countries
• Higher EAL doesn’t equal higher security
• Process is too lengthy
• Not repeatable across labs, schemes/nations
• No enforcement of security requirement testing
9
What is a Protection Profile?
• Tailored set of baseline security functional and security
assurance requirements
• Focuses on tailored requirements and assurance
activities by technology
• Tailored set of use cases, threats, and objectives
• Allows for the expansion of baseline requirements
through extended packages for specialized technologies
– i.e. Network Device PP and Firewall EP
10
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 CEM
– Assurance of product compliance
• Address specific threats
• Created and maintained by Technical Communities (TCs)
11
What Exactly Are TCs?
• Any participating vendor, country, critical
infrastructure, evaluator or lab
• Collaborative environment to create
requirements and standards for PPs
• Ultimate creator of PPs with NIAP guidance
12
ST vs. PP Example
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity
13
ST vs. PP Example
Protection Profile
Security Target
*SFR 1
SFR 2
SFR 3
*SFR 1
Functional SFR 2
SFR 3
Package
SFR 4
Functional
Package
**SAR 01
SAR 02
TAA 03 Assurance
TAA .... Package
TAA ....
TAA 10
**SAR 01
SAR 02
SAR 03
Assurance SAR ....
Package SAR ....
SAR 24
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity
14
ST vs. PP Example
Protection Profile
Security Target
*SFR 1
SFR 2
SFR 3
*SFR 1
Functional SFR 2
SFR 3
Package
SFR 4
Functional
Package
**SAR 01
SAR 02
TAA 03 Assurance
TAA .... Package
TAA ....
TAA 10
**SAR 01
SAR 02
SAR 03
Assurance SAR ....
Package SAR ....
SAR 24
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity
15
ST vs. PP Example
Protection Profile
Security Target
*SFR 1
SFR 2
SFR 3
*SFR 1
Functional SFR 2
SFR 3
Package
SFR 4
Functional
Package
**SAR 01
SAR 02
TAA 03 Assurance
TAA .... Package
TAA ....
TAA 10
**SAR 01
SAR 02
SAR 03
Assurance SAR ....
Package SAR ....
SAR 24
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity
16
Technical Community
• Key to PP Development and Maintenance
• Any participating CCRA nation, vendor, critical
infrastructure industry, academia, evaluator,
or lab
• Collaborative environment to create
requirements and testing standards for PPs
17
Published Protection Profiles
• Full Disk Encryption
• USB Flash Drive
• Hardcopy Device (MFP)
• Stateful Firewall
• Network Devices 1.1
• ESM Policy Management
• ESM Access Control
• ESM Identity & Credential
Mgt.
• Mobility Endpoint OS
• Mobility Endpoint VoIP App
• SIP Server
• Wireless LAN Access System
• Wireless LAN Client
• VPN Client
• Peripheral Sharing Switch
Located at www.niap-ccevs.org/pp/
18
Protection Profiles Under Development
• NDPP V2
• VPN Gateway Extended
Package
• BIOS
• MFP v2
• USB v2
•
•
•
•
•
Hardware Security Module
Virtualization
Storage Area Network
File Encryption
Mobile Device Management
19
Contact Information
• NIAP website:
– http://www.niap-ccevs.org/
• Contact info:
– Mark Loepker – [email protected]
– Paul Mansfield – [email protected]
• Email:
– [email protected]
• Telephone:
– 410.854.4458
20
Questions?
21
NIAP Evolution Progress
• IA Products Must be CC Evaluated & Validated – U.S.
National Policy (NSTISSP-11)
– Not the case in most other CC-nations
• No longer accepting traditional (EAL4) evaluations
• Evaluations must go against NIAP Approved PP
• Created Technical Communities
– Network, Firewall, ESM
• Published 12 Standard PP (December 2012)
• Continuing Outreach to Gov’t & International Partners,
Industry, Labs, Academia
22

similar documents