Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
IEEE P2600:Breaking new ground in protection profile structure
Brian SmithsonRicoh Americas Corporation
Cupertino, California, US
This updated version available from http://grouper.ieee.org/group/2600/presentations/8iccc/
8ICCC – B. Smithson – 2
Agenda
About the IEEE P2600 Standard Working GroupAbout the IEEE 2600 Standard
Challenges, solutions, and examples
Questions, comments, additional information
8ICCC – B. Smithson – 3
About the IEEE P2600 Standard Working Group
IEEE 2600 : a standard for Hardcopy Device and System SecurityNo security standard exists for Hardcopy Devices (HCDs)WG formed in 2004 under the IEEE Computer Society Information Assurance Standards CommitteeMeets every ~6 weeks in the US, Canada, (sometimes EU, Japan)Standards approval and PP validation expected in 1st half of 2008
To date: 90 attendees from 33 organizationsCore group of ~20 participants from leading manufacturers
“P2600” during drafting/approval process, “2600” after standards approval
8ICCC – B. Smithson – 4
About the IEEE 2600 Standard
Overall scope:For manufacturers: what security capabilities to provideFor customers: how to select, install, configure, and use
It is a broad IEEE Standard, but with no independent verificationWe also define a Protection Profile so that manufacturer compliance can be independently validated and certified
Benefit to customers:A comprehensive standard establishes a common baseline of security expectations for HCD productsNo longer need to wade through individual security feature claims
Benefit to manufacturers:A standard that is referenced by customers sets a common baseline of procurement requirementsNo longer need to wade through individual security requirements
8ICCC – B. Smithson – 5
Challenge:Security for which customer environment?
Hardcopy devices (HCDs) are used in many environmentsHome / small offices, small-to-medium sized enterprisesLarge enterprises, government, educational institutionsSelf-service copy shops, hotel business centers, public librariesProduction printing companies, corporate copy/print centers
Different assets and different asset valuesDocumentsUser/administrator credentials and other personal informationJob data, job logs, audit logsUse (or denial of use) of the HCDDevice, network, and security configuration dataOther devices on the same network
Different environmental assumptionsUser trustPhysical security, visibility, and access
8ICCC – B. Smithson – 6
Solution:Defined four (4) representative environments
A. For highly proprietary or legally regulated documents
B. General enterprise useC. Public-facing useD. Small office / home office use
It was necessary to createfour Protection Profiles,one for each environment
As a goal, the requirements ofA would be a superset of B,B would be a superset of C,C would be a superset of D
High UserAccountability
Environment A
Environment B
Environment C
Environment D
Low UserAccountability
All user I&A, strong document security, complete audit logs
All user I&A, some document security, exception logging
All user I&A, little document security,
usage logging
Administrator I&A,no logging,
basic device security
Market segments based on collective experience
8ICCC – B. Smithson – 7
Challenge:Which assets and threats apply generally to HCDs?
Our initial approach was anecdotal:Brainstorm a list of known threatsCull, categorize by asset, and assign to operating environmentsWe had difficulty making a consistent assignment of threats to environments and protection profiles, and choices were not basedon a documented rationale or systematic method
Second approach was more analytical:Expand threat descriptions into fully-formed threat vectorsUsed a modified STRIDE/DREAD methodology to derive a risk rating for each threat in each environmentWe still had consistency problems, because even when confined toa representative customer environment, we could not define some kinds of assets and asset values on behalf of customers.
Adapted from: Swiderski and Snyder, Threat Modeling, 2004 Microsoft Press. Details of our approach are outlined here: http://grouper.ieee.org/groups/2600/presentations/Cupertino/ThreatAnalysis.ppt
8ICCC – B. Smithson – 8
Solution:Only define data as assets …
Generalized data assets and asset statesDifferent threats apply to different states
DocumentsJob instructions/statusConfiguration dataJob/audit logs
In transitAt rest…
Asset
User Data TSF Data
User Document Data User Function Data TSF Protected Data TSF Confidential Data
TRANSIT
RETREIVE
DELETED
OUTPUT
TRANSIT RESTTRANSIT TRANSITRESTREST REST
JOB
8ICCC – B. Smithson – 9
Solution:… and use OSPs to address other objectives
We used Organizational Security Policies (OSPs) to address security objectives where we cannot easily define the corresponding assets and threats:
User authorizationProtection of customer networksAudit loggingPower-on self-test
8ICCC – B. Smithson – 10
Example:Why use an OSP for User Authorization?
Asset and threat definitions are based on what is important to the customer, for example:
Controlling access to informationAsset: documents and other information available to HCD usersThreat: inappropriate access to informationObjective: require IA&A for information access control purposes
Ensuring accountability for accessAsset: compliance with policies / laws / regulationsThreat: unaccountable access to informationObjective: require IA&A for usage tracking and audit purposes
Ensuring payment for useAsset: cost of equipment and operationThreat: users do not pay their share of the costObjective: require IA&A for usage access control, accounting, billing…
identification, authentication, and authorization
8ICCC – B. Smithson – 11
Example:How we use an OSP for User Authorization
Assets and threats vary, but there is a root objective:
“require identification, authentication, and authorization”
We base our OSP on the root objective:
P.USER.AUTHORIZATION: Users will be authorized according to security policies before being permitted to use the TOE
P.ADMIN.AUTHORIZATION: Administrators will be authorized according to security policies before being permitted to manage the TOE
By using an OSP, we do not need to define specific assets that are protected or threats that are mitigated by the objective.
8ICCC – B. Smithson – 12
Example:Why use an OSP for protecting customer networks?
HCD customers are concerned that their networks may be exposed to threats originating from or through the HCD
Bridging a fax/data modem connection to the customer networkUsing HCD network services as a source or proxy for attacks
Some objectives may imply functional requirements:“Do not bridge fax to network” implies fax and network interfaces“Do not bridge any interface to network” implies multiple interfaces
Fulfillment of the objectives can take different forms:Technical controls
Flow control SFPs; access control SFPs; administrator control
Architectural controlsNo data path; modem chipset does not support data connections
We do not want to require technical controls when an architectural control would suffice
8ICCC – B. Smithson – 13
Example:How we use an OSP for protecting customer networks
A sufficiently general OSP provides appropriate coverage, and:Does not imply TOE functionality that may not be presentIs architecturally safe
P.SMI.MEDIATE: Data connections to and from shared-medium interfaces will be mediated according to security policies
This OSP can cover a wide variety of threat scenarios:An attacker uses the HCD as an SMTP relay for spammingAn attacker uses the HCD’s FTP service for a bounce attackAn attacker uses a PPP connection to the fax/data modem to establish a bridge to the customer networkAn attacker uses a USB network interface device to establish a bridge to the customer networkAn attacker uses page description or job control language, or downloadable applet code, to attack the customer network
8ICCC – B. Smithson – 14
Challenge:How can one PP apply to many possible HCD configurations?
There are many kinds of HCDs:Single function: print | scan | copy | faxMultifunction: print + scan + copy,print + scan + copy + faxAdditional features: network, hard disk,document storage and retrieval
CC does not allow conditional requirementsIf the PP provides security coverage for all features, then all features must be present in the conforming ST
8ICCC – B. Smithson – 15
Solution:Structure the PP as a “Family of Protection Profiles”
A Family of PPs is single document containing multiple PPs and aset of rules for their use
Structure:Family PP references and Family overview (APE_INT)Family conformance claims (APE_CCL)
Individual PPs for hardcopy functions and security-relevant features:TOE overview (APE_INT)Problem definition (APE_SPD)Objectives (APE_OBJ)Functional requirements (APE_REQ)
Family assurance requirements (APE_REQ)
The latest draft can be viewed here: http://grouper.ieee.org/groups/2600/techdocs.html
8ICCC – B. Smithson – 16
Solution:Individual PPs and family conformance rules
Individual PPs:Hardcopy functions:
Print (PRT), Scan (SCN), Copy (CPY), Fax (FAX)Security-relevant features:
Document storage and retrieval (DSR)Nonvolatile storage (NVS)Shared-medium interface (SMI)
Family conformance rules:The Hardcopy Rule: A conforming ST must claim conformance with one or more of: PRT, SCN, CPY, FAX.
So we know that we’re dealing with a hardcopy device!
The Complete TOE Rule: A conforming ST must claim conformance with all PPs in the family whose TOEs represent functions that are provided in the target product of the ST.
So we know that the ST provides comprehensive security coverage for its target product
8ICCC – B. Smithson – 17
Examples:How to construct an IEEE 2600 Security Target
Simple printer:Conforms to the PRT protection profile
Printer with network interface:Conforms to PRT+SMI
Fax machine that can also make copies:FAX+CPY
Copier with hard disk:CPY+NVS
“All-in-one” with network:PRT+SCN+CPY+FAX+SMI
Multifunction with network and hard disk, no fax:PRT+SCN+CPY+NVS+SMI
Multifunction with everything:PRT+SCN+CPY+FAX+DSR+NVS+SMI
8ICCC – B. Smithson – 18
Challenge:How to associate a PP with an IEEE Standard?
Considerations:The 2600 Standard provides information and guidance outside of the scope that is appropriate/permissible in a PP.We want to include some security objectives in the Standard thatwe cannot include in the PP.Manufacturers can claim that their product complies with the 2600 Standard without independent testing and verification.We want to permit manufacturers to claim compliance with the 2600 Standard, and optionally, obtain CC certification for theirproducts.
Goals:Make the objectives of the Standard compatible with the verifiedobjectives of the PP so that CC certification provides verification of 2600 complianceMake it simple for customers to understand manufacturers’ claims of compliance and certification
8ICCC – B. Smithson – 19
Solution:Separate IEEE Standards for each PP
The broad standard is IEEE 2600
PPs will be published as separate standards in the 2600 series2600.1 for environment A2600.2 for environment B2600.3 for environment C2600.4 for environment D…
PPs will also be registered and published as standalone PPsWill have different (non-IEEE) cover pages and front matter
8ICCC – B. Smithson – 20
Solution:Base the 2600 objectives on PP objectives
In the normative clause of IEEE 2600 that identifies compliance requirements:
Use objectives that are identical to the PP security objectives,except that we replace CC-specific terms (like “TOE”)IEEE 2600 compliance requirements that are outside of the scope of the PP are expressed with “should” instead of “shall”
This ensures compatibility between compliance with IEEE 2600 and CC certification based on IEEE 2600.n
8ICCC – B. Smithson – 21
Solution:Simple, understandable claims
If a product complies with IEEE 2600 but is not CC certified, the manufacturer would make this claim*:
“This product complies with the IEEE 2600 Standard for Operational Environment X”
If a product has been CC certified, the manufacturer would make this claim*:
“This product is Common Criteria Certified, conforming to IEEE 2600.n”
The environment is identified by the PP standard “2600.n”Compliance with P2600 is implicit
Final wording of these compliance statements has not yet been defined or approved.
8ICCC – B. Smithson – 22
Questions, comments, and additional information
Questions? Comments?
For additional information about the IEEE P2600 serieshttp://grouper.ieee.org/groups/2600
To contact the presenter:About IEEE P2600: [email protected] Ricoh: [email protected]
http://www.ricoh-usa.com
Thank you – Grazie molto – どうもありがとう
This updated version available from http://grouper.ieee.org/group/2600/presentations/8iccc/