IEEE P2600: Breaking new ground in protection profile structure

1. IEEE P2600:Breaking new ground in protection profile structure Brian Smithson Ricoh Americas Corporation Cupertino, California, US brian.smithson@ricoh-usa.com This updated version available from http://grouper.ieee.org/group/2600/presentations/8iccc/

2. Agenda • About the IEEE P2600 Standard Working Group • About the IEEE 2600 Standard • Challenges, solutions, and examples • Questions, comments, additional information

3. About the IEEE P2600 Standard Working Group • IEEE 2600: a standard for Hardcopy Device and System Security • No security standard exists for Hardcopy Devices (HCDs) • WG formed in 2004 under the IEEE Computer Society Information Assurance Standards Committee • Meets 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 organizations • Core group of ~20 participants from leading manufacturers • “P2600” during drafting/approval process, “2600” after standards approval

4. About the IEEE 2600 Standard • Overall scope: • For manufacturers: what security capabilities to provide • For customers: how to select, install, configure, and use • It is a broad IEEE Standard, but with no independent verification • We 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 products • No 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 requirements • No longer need to wade through individual security requirements

5. Challenge:Security for which customer environment? • Hardcopy devices (HCDs) are used in many environments • Home / small offices, small-to-medium sized enterprises • Large enterprises, government, educational institutions • Self-service copy shops, hotel business centers, public libraries • Production printing companies, corporate copy/print centers • Different assets and different asset values • Documents • User/administrator credentials and other personal information • Job data, job logs, audit logs • Use (or denial of use) of the HCD • Device, network, and security configuration data • Other devices on the same network • Different environmental assumptions • User trust • Physical security, visibility, and access

6. All user I&A, strong document security, complete audit logs High UserAccountability Environment A Environment B Environment C Environment D All user I&A, some document security, exception logging All user I&A, little document security, usage logging Low UserAccountability Administrator I&A,no logging,basic device security Solution:Defined four (4) representative environments • Market segments based on collective experience • For highly proprietary or legally regulated documents • General enterprise use • Public-facing use • 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

7. Challenge:Which assets and threats apply generally to HCDs? • Our initial approach was anecdotal: • Brainstorm a list of known threats • Cull, categorize by asset, and assign to operating environments • We had difficulty making a consistent assignment of threats to environments and protection profiles, and choices were not based on a documented rationale or systematic method • Second approach was more analytical: • Expand threat descriptions into fully-formed threat vectors • Used a modified STRIDE/DREAD methodology to derive a risk rating for each threat in each environment • We still had consistency problems, because even when confined to a 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

8. Solution:Only define data as assets … • Generalized data assets and asset states • Different threats apply to different states • Documents • Job instructions/status • Configuration data • Job/audit logs • In transit • At rest • …

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 authorization • Protection of customer networks • Audit logging • Power-on self-test

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 information • Asset: documents and other information available to HCD users • Threat: inappropriate access to information • Objective: require IA&A for information access control purposes • Ensuring accountability for access • Asset: compliance with policies / laws / regulations • Threat: unaccountable access to information • Objective: require IA&A for usage tracking and audit purposes • Ensuring payment for use • Asset: cost of equipment and operation • Threat: users do not pay their share of the cost • Objective: require IA&A for usage access control, accounting, billing… • identification, authentication, and authorization

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.

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 network • Using 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 controls • No data path; modem chipset does not support data connections • We do not want to require technical controls when an architectural control would suffice

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 present • Is 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 spamming • An attacker uses the HCD’s FTP service for a bounce attack • An attacker uses a PPP connection to the fax/data modem to establish a bridge to the customer network • An attacker uses a USB network interface device to establish a bridge to the customer network • An attacker uses page description or job control language, or downloadable applet code, to attack the customer network

14. Challenge:How can one PP apply to many possible HCD configurations? • There are many kinds of HCDs: • Single function: print | scan | copy | fax • Multifunction: print + scan + copy,print + scan + copy + fax • Additional features: network, hard disk,document storage and retrieval • CC does not allow conditional requirements • If the PP provides security coverage for all features, then all features must be present in the conforming ST

15. Solution:Structure the PP as a “Family of Protection Profiles” • A Family of PPs is single document containing multiple PPs and a set 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

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

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

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 that we 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 their products. • Goals: • Make the objectives of the Standard compatible with the verified objectives of the PP so that CC certification provides verification of 2600 compliance • Make it simple for customers to understand manufacturers’ claims of compliance and certification

19. Solution:Separate IEEE Standards for each PP • The broad standard is IEEE 2600 • PPs will be published as separate standards in the 2600 series • 2600.1 for environment A • 2600.2 for environment B • 2600.3 for environment C • 2600.4 for environment D • … • PPs will also be registered and published as standalone PPs • Will have different (non-IEEE) cover pages and front matter

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

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.

22. Questions, comments, and additional information • Questions? Comments?  • For additional information about the IEEE P2600 series • http://grouper.ieee.org/groups/2600 • To contact the presenter: • About IEEE P2600: brian.smithson@ieee.org • About Ricoh: brian.smithson@ricoh-usa.com http://www.ricoh-usa.com Thank you – Grazie molto – どうもありがとう This updated version available from http://grouper.ieee.org/group/2600/presentations/8iccc/