1 / 11

IEEE- P2600 PP Guidelines Suggested Format and Content

IEEE- P2600 PP Guidelines Suggested Format and Content. Members: Alan Sukert Ron Nevo, Brian Smithson , Nancy Chen, Farrell Lee, Sameer Yami, Tom Haapanen, Peter Cybuck December 2007. ST authors and CCTLs/consultants who write STs for vendors

oedith
Download Presentation

IEEE- P2600 PP Guidelines Suggested Format and Content

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IEEE- P2600PP Guidelines Suggested Format and Content Members: Alan Sukert Ron Nevo, Brian Smithson , Nancy Chen, Farrell Lee, Sameer Yami, Tom Haapanen, Peter Cybuck December 2007

  2. ST authors and CCTLs/consultants who write STs for vendors • Understand how to write an ST against one of the Operational Environment PPs • Customers & individuals involved in HCD procurements • Understand how to apply these PPs and what they mean • Understand what compliance means against each of the Operational Environment PPs and individual TOE PPs • Vendors and their product developers • ST evaluators • Guidance on how to evaluate a TOE based on the PPs • Validators (both present and future) PP GuidelinesPossible Audience and Goals

  3. PP Guidelines Possible Guidelines Content • How to interpret what products belong in which Operational Environment – distinctions among 4 environments • Actual examples on how to construct an ST for a product using the structure (e.g., what applies to a typical type of HCD, etc.) • Include sample text for each ST section based on one of the PPs • Show multiple ways to meet requirements • How the PPs allow vendors to be compliant without indicating a specific implementation (i.e., allow for flexibility) Comment on scheme-specific policies and interpretations • Certification issues in specific countries (e.g.., unique Scheme policies)

  4. PP Guidelines Possible Guidelines Content (cont) • Explaining how the PPs were formulated (e.g., additional explanation of App Notes) • Where (and to whom ) to send questions on PP text (e.g., applicable URL pointers) • Explain why certain decisions were made, why certain threats did or did not end up in PPs, etc. • Confidential vs. protected data – definitions, examples, how to choose what data should be specified in an ST, etc. • What SFRs/threats/objectives apply to each environment • How to deal with updates of CC and the relation to existing PPs and current / new STs

  5. PP Guidelines Possible Guidelines Content (cont) • General introduction about guidance and what is expected of ST authors. • Would take a “high level” approach to what the guidelines is trying to accomplish (e.g., allow innovation in STs that are created from the PPs). • Put everything in perspective • Include mailing list • Would help generate FAQs • Show important “To dos’ and ‘Not to dos’ • Clarification of what PPs from the Family of PPs should be selected for a given TOE

  6. PP GuidelinesPossible Guidelines Format • Combined format – general wording on the PPs and FAQs • Be completely web-based, especially FAQs. • Would allow the guidelines to be “evergreen”. • Be a published document. • Be both published and web-based • Include mailing list? Would help generate FAQs • Use applicable IEEE style guide for this type of document • “Web Publications” vs. “Guide” format template

  7. PP GuidelinesContent Recommendation • Include an Introduction and Purpose • Separate sections for guidance to vendors, ST authors, ST evaluators, PP validators. Each section should include: • How to interpret what products belong in which Operational Environment – distinctions among 4 environments • Examples showing multiple ways to meet requirements • Show important “To dos’ and ‘Not to dos’ • Clarification of what PPs from the Family of PPs should be selected for a given TOE • Table that shows what PPs from the Family of PPs should be incorporated into ST for a given Operational Environment and TOE

  8. PP GuidelinesFormat Recommendation • Be a published document • Consider web-based FAQs • Follow the IEEE Standard for a ‘Guide’

  9. PP GuidelinesDevelopment Plan • Must finish document before first ST would be written against the validated P2600 PPs • Availability of selected Scheme to validate the P2600 PPs will determine when this should be • Approach • Provide only high-level guidance in initial version • Include more detailed guidance in later versions • Initial Plan (assumes worst case) • Dec 07 P2600 Meeting – Create task group and complete initial document scoping • Feb 08 Meeting – Review draft of Introduction, initial content and initial FAQs • Mar 08 meeting – Review full content of initial version

  10. PP GuidelinesDevelopment Issues • Scope PP Guidelines appropriately so they aren’t so “huge” • What is the appropriate scope? • Choice of what Audience the document will support is critical • Do we have the knowledge and expertise to provide guidance to ST authors? Evaluators? Validators? • Make the FAQs dynamic so they grow over time • Web pages vs. hardcopy document

  11. PP GuidelinesOther Issues • Will IEEE charge for this document • Will guidelines be separate from P2600 standard or be included with the standard • Who will maintain/update these guidelines • How do the guidelines get updated as CC gets updated • Will IEEE membership/password access be required (i.e., open just to IEEE members)

More Related