110 likes | 114 Views
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
E N D
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
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
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)
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
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
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
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
PP GuidelinesFormat Recommendation • Be a published document • Consider web-based FAQs • Follow the IEEE Standard for a ‘Guide’
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
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
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)