[2600] Threats divided up by MFP function
In dividing up threats/objectives/requirements according to individual
functions, I have taken our complete threats list (including those that
are not included in any PP) and made a table of which ones I think would
fit in which functional categories. You can download the file here:
http://grouper.ieee.org/groups/2600/presentations/Maui2007/threats-by-func
tion-25a.xls
I am looking for comments and discussion, but also some collaboration on
this. Here is what I have done so far and some issues that I've found:
Functions:
Common functions (COM) - this would include any functions (and
accompanying threats/objectives/requirements) that are common to all HCDs.
Note that these would be REQUIRED of all HCDs, so we need to be careful
what and how we specify in this category. I am thinking that this will
include TSF-oriented functions, like device and security settings, some
logging/audit functions such as for job logs and event logs, and maybe
some access controls. I don't know, I haven't worked through the details
yet. Having a "common functions" category was suggested by NIAP, and I
think it's a good idea. The alternative would be to have duplicate t/o/r's
applied to the other functions, and that will add bulk and complexity to
the PPs and could also lead to other problems if we have similar but not
identical t/o/r's applied to multiple functions.
Print functions (PRT) - this would include any functions (and t/o/r's)
associated with printing. It would therefore include threats associated
with consumables (although not necessarily covered in the PPs). It would
also include threats associated with having a document output tray.
Scan functions (SCN) - this would include any functions (and t/o/r's)
associated with scanning. It would cover threats associated with having a
document input tray (although not covered in PPs). However, it would not
cover features like scan-to-email, because that would only be present in
conjunction with network functions.
Copy functions (CPY) - this would include any functions (and t/o/r's)
associated with copying. I am not certain that this is necessary at all,
but see issue #3 below. It was suggested by one of the JBMIA WG reps.
Fax functions (FAX) - this would include any functions (and t/o/r's)
associated with faxing. It would not cover input (scanning) or output
(printing), but it would cover fax modem issues.
Document server functions (SVR) - this would include any functions (and
t/o/r's) associated with any kind of document server. You'll see that this
column is empty in my table. I don't think that is because there are no
threats that are unique to document servers, I think it is because we have
not properly accounted for them. See issue #4.
Network functions (NET) - this would include any functions (and t/o/r's)
associated with having a network interface. This should include threats
associated with network services and also threats associated with network
communications.
Nonvolatile storage functions (NVS) - this would include any functions
(and t/o/r's) associated with nonvolatile storage. At first, I restricted
this to nonvolatile *document* storage, but on second thought, I removed
that restriction because TSF data might be stored on a hard disk. The
challenge here will be to scope it appropriately so that it includes NV
devices that could reasonably be removed for salvage (like hard disks or
flash cards) but does not include NV devices that are not so easily
removed (like SMT-mounted flash).
Issues so far:
1. The approach I have taken is to try to assign each threat to only one
function category. However, T.TSF.CONF.AB could apply to either FAX or SCN
because either one could have an address book. But it is also possible
that, at least for SCN, some devices may not have an address book feature.
This leads me to wonder, should T.TSF.CONF.AB be re-specified in some
other way as a more innocuous common function?
2. We have a problem with T.UD.IMP.PRINT and T.UD.IMP.SCAN. These threats
require two functions to be present (PRT+NET and SCN+NET, respectively).
We are trying to define our PP functions so that any combination (plus
common functions) can comprise a TOE, and requiring any specific
combinations like PRT+NET or SCN+NET would make it very messy. We could
solve this by re-specifying these two threats as a single threat
T.UD.IMP.NET (to distinguish it from T.UD.IMP.FAX), and then it would only
apply to the NET function.
3. I mentioned that CPY is an empty column. I could not think of any
threats that are in SCN and PRT that would not apply to a simple copier,
except for T.TSF.CONF.AB. So, if T.TSF.CONF.AB remains, then it might be
reasonable to put all of the SCN and PRT threats except for T.TSF.CONF.AB
into the CPY column. Or, if T.TSF.CONF.AB is removed and turned into a
more general common function, then I think CPY would be entirely
redundant.
4. I mentioned that SVR is also empty. I think that we need to consider
this function again, because it does have some features that are not
present in HCDs that do not have a document server. For example, the
ability for users to set access controls and for administrators to manage
stored documents. We should also consider how to scope this function
appropriately. If an HCD has a "re-print last job" feature, would that be
considered a document server?
5. NVS needs careful definition, because otherwise we could end up
specifying security functions that are not needed or appropriate for some
kinds of nonvolatile storage that might be present in an HCD.
More work needed:
In addition to resolving those issues, I would like to find a concise way
to define the TOE boundaries for each of these functions. I think we need
both words and a graphical representation to describe each TOE boundary.
Would anyone like to help me with that? I'm less of an HCD guy and more of
an infosec guy, so I'm probably not the right person to do this in a way
that would be most meaningful and useful to the HCD engineers who will
need to use our PPs to write STs.
For extra credit:
Alas, this whole thing makes me wonder if our threat definitions have a
fundamental problem (please don't kill the messenger!) because they
originated from a brainstorming effort and not a more formal threat
modeling and analysis approach. I keep running into problems, in this
current effort but also when working with objectives and SFRs, in which
our conceptual model of an HCD doesn't map very well to coherent security
objectives. This makes it difficult to write the PP, but it will also make
it difficult to implement the necessary security functions. Therefore, as
an experiment, I have been working with a very interesting free tool from
Microsoft and am trying to use it to model HCDs. I would like to see how
results from this tool compare with the threats that we have defined.
Perhaps it could guide us to some changes that would make all of this much
easier to specify (and implement!). If anyone is interested in working
with me on that, please let me know. Here is a link to the tool:
http://www.microsoft.com/downloads/details.aspx?FamilyID=59888078-9DAF-4E9
6-B7D1-944703479451&displaylang=en
Regards,
--
Brian Smithson
Project Manager
PMP, SSCP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Corporation
(408)346-4435