[2600] Summary of today's WebEx/Teleconference follow-up session on new versus old asset/threat model
Attendees:
Tom Benkart
Lee Farrell
Ron Nevo
Brian Smithson (host)
Alan Sukert
Jerry Thrasher
Bill Wagner
Documents reviewed:
http://grouper.ieee.org/groups/2600/presentations/WashingtonDC2007/IEEE_P2
600_v26b-new_model_impact.doc
http://grouper.ieee.org/groups/2600/presentations/WashingtonDC2007/P2600.1
-27b.pdf
Some discussion items:
[in the P2600 impact document]
1. Should threat vector details include information about applicable
functions (e.g. print, scan, fax...)?
No, the P2600 Std is decoupled from the FPPs, and the functional division
(especially things like nonvolatile storage) are FPP-specific.
2. Should threat vector details include information about data object
states?
No, the state is included in the threat name (e.g. T.DOC.COMMS.DIS implies
the "data in transit" state).
3. What should be done with cross reference tables, like threats listed by
asset or threats listed by access?
Although they are not as definitive (because now the threat vectors are
more like examples than definitions), it is still useful information to
keep in P2600. If it seems like that part of the document is getting too
"table-crazy", perhaps they could be moved to an annex.
[in the new FPP draft]
4. For TSF Data assets, should they be more specific to the function of
the TOE?
For example, if the PRT TOE says that it protects TSF Configuration data,
what data is that? Some of it would be common with other TOEs (like user
identification data) and some of it would be specific to the PRT TOE (like
maybe output finisher defaults). One way to clarify it would be to append
each asset (and threat, objective, etc.) name with the TOE name, e.g.
T.CONF.STORED.DIS.PRT. Although this would be a name change only, it would
add a lot of clutter, and so we'll ask some schemes for their opinions
before going ahead with that. But in any case, some examples of data
should be provided for each asset, most likely in PP app notes. If this is
carried through to the SFRs, then an app note in the SFR would make it
easier for an ST author to either combine data items from multiple TOEs
into a single SFR statement, or iterate the SFR with each data item.
5. Specifying "ignored threats" could be a problem (example:
T.DOC.OUTPUT.DIS, which is considered in PRT and FAX but ignored in CPY).
One way to handle this would be to append the TOE name to the asset and
threat, as discussed above. Another way would be to eliminate the threat
from discussion in TOEs where it is to be ignored. It is probably safer to
append the TOE name because otherwise you could end up with an ST that
considers the threat because it conforms to one PP and ignores it because
it conforms to another PP.
6. Should the compliance clause include objectives that are out of scope
of the FPP?
This isn't really an issue of new versus old model, so we will make sure
it's on the agenda for the P2600 meeting.
Conclusion:
The attendees agreed to make a recommendation that we go ahead with the
new asset/threat/etc model. However, the final decision is up to the
larger group and should be decided at the next P2600 meeting.
Next actions:
Smithson will continue updating the FPP (to 27c), finishing off the
objective and SFR rationales and, time permitting, complete the full SFR
statements for one or more TOEs. The draft should be posted to the mailing
list and also sent to NIAP, BSI, IPA, and JBMIA, for comments.
Thank you to everyone who attended this online meeting.
Regards,
--
Brian Smithson
Project Manager
PMP, SSCP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435