IEEE P2600: Breaking new ground in protection profile structuregrouper.ieee.org/groups/2600/presentations/8iccc/... · 2007-10-08 · Use objectives that are identical to the PP security

IEEE P2600:Breaking new ground in protection profile structure

Brian SmithsonRicoh Americas Corporation

Cupertino, California, US

[email protected]

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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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.


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/

http://grouper.ieee.org/groups/2600

mailto:[email protected]

mailto:[email protected]

http://www.ricoh-usa.com/