Re: I-0451: When To Use IFF/IFC And ACF/ACC

[Gary Stoneburner <gary.stoneburner@nist.gov>]

DJ,

I see the interpretation as providing guidance on how to make decisions
on ACC/ACF verses IFC/IFF.  This is in contrast to an interpretation
giving the requirements on how to use these.

You have proposed a good example of thinking through the ramifications of
choosing one over the other.  Still, the goal is to meet the needs
and the CC requirements are means and tools, not the end itself. 
So, if you can meet the need with ACC/ACF great.  If you need
IFC/IFF wonderful.  Whatever works is just fine.  The NIB
received questions and saw what appeared to us to be force fits of needs
into one or the other of these sets of requirements.  We tried to
back up and give guidance that would be helpful in getting the best use
from these CC components.

You seem correct in that the issue you raise, it is not access to a
container, but the protection of certain data wherever it is
contained.  The access rights to the container are derived from this
data (and apparently this derivation is time sensitive) .  It may be
possible to fix the access rights (ACC/ACF perhaps).  Yet this would
still remain a solution to access based upon data in the container, and
not fundamentally access based upon the container.  The latter
would, in that case, only be a means of accomplishing the former and as
it is not really what is wanted, might have some undesirable (and perhaps
unacceptable) consequences.

Cheers,
Gary

PS:  Does that help? :-)

At 01:32 PM 3/8/2004, Dr.Ir. D.J. Out wrote:


> As this interp addresses a problem
> I have been wrestling with while doing some very fundamental CCIMB work,
> I have a quick reaction. I would welcome discussion on this.
>
> Suppose I have a TOE with the following requirements:
>
> - FDP_ACC/ACF specifying that users are only allowed to read their own
> personnel records and no-one elses
> - AVA_VLA.4
>
> during my vulnerability analysis, I find that whenever a user prints a
> file, sometimes parts of the contents of this file end up in some
> world-readable file in /var/spool
>
> Do I now:
> A) fail the evaluation as I can sometimes read parts of personnel records
> of users
> B) pass the evaluation as "parts of the contents of the personnel
> records in /var/spool" do not constitute a personnel record, and I
> should have used FDP_IFF/IFC.
>
> The interpretation below seems to imply that B is the answer. Can anyone
> confirm that this is correct?
>
> If B is true, does this imply that:
> specifying any form of confidentiality for user data in the TOE, should
> ALWAYS be done by FDP_IFC/IFF, since for confidentiality you don't care
> about "the container" but you do care about "the
> contents"?
>
> Dirk-Jan Out
>
>
> NIAP Interpretations Board wrote:
> >   The following is a proposal
> > for a NIAP Interpretation of, or formal
> >   guidance about, a Common Criteria document that has been approved
> > by the
> >   NIB and is being submitted to the CCIMB for concurrence. It is
> > being
> >   posted for informational purposes.
> >
> >
> >                      
> > CCITSE/CEM  GUIDANCE (PROPOSED)
> >     
> > _________________________________________________________________
> >                    
> > I-0451: When To Use IFF/IFC And ACF/ACC
> >     
> > _________________________________________________________________
> > TYPE:                
> > Guidance
> > NUMBER:              
> > I-0451
> > STATUS:              
> > Ready to Send to Management/CCIMB
> > TITLE:               
> > When To Use IFF/IFC And ACF/ACC
> > PREVIOUS POSTING:      [cc-cmt 00357]
> >
> > SOURCE REFERENCE:     CC v2.1 Part 2 Subclause 6.1
> > FDP_ACC
> >                      
> > CC v2.1 Part 2 Subclause 6.2 FDP_ACF
> >                      
> > CC v2.1 Part 2 Subclause 6.5 FDP_IFC
> >                      
> > CC v2.1 Part 2 Subclause 6.6 FDP_IFF
> > RELATED TO:          
> > <None>
> > ISSUE:
> >    When is it appropriate to use IFF/IFC or ACF/ACC?
> > STATEMENT
> >    ACF/ACC should be used when the intent is to control access
> > to an
> >    object; IFF/IFC should be used when the intent is to control
> > the flow
> >    of information.
> >    Access to an object means that there is a set of rules that
> > define
> >    whether some entity (a "subject") may have a
> > particular form of access
> >    to a data container (an "object") for some
> > particular type of
> >    operation. There are no controls based on the information
> > itself; that
> >    is: if the subject is permitted to write the object, it may
> > write any
> >    data into the object; similarly, if a subject is permitted
> > to read an
> >    object, it can do whatever it wishes with the data it has
> > read.
> >    Information flow control is based on some fundamental
> > characteristic
> >    associated with the information (not the container), and may
> > not
> >    involve an active subject. Information flow policies dictate
> > whether
> >    information with a particular characteristic can move from
> > one
> >    controlled entity to another.
> > SUPPORT:
> >    When the Common Criteria was first written, the goal on the
> > functional
> >    side was to capture the policies that were present in the
> > previous
> >    criteria that served as inspiration. In the case of the
> > Trusted
> >    Computer System Evaluation Criteria, this was Discretionary
> > Access
> >    Control (DAC) and Mandatory Access Control (MAC). However,
> > at this
> >    time, there was an effort not to use terms that brought with
> > them
> >    specific connotations--hence, many TCSEC terms were not used
> > in the
> >    CC.
> >    While the TCSEC separated controls based upon who was
> > allowed to make
> >    changes (discretionary verses mandatory), the CC has
> > separated
> >    controls based upon the type of control. Since IFF/IFC type
> > controls
> >    were often non-discretionary and ACF/ACC were often
> > discretionary the
> >    confusion arose that this was always the case.
> >    Access controls (ACF/ACC) may be used to model what in
> > the
> >    TCSEC-paradigm was called Discretionary Access Control, but
> > this is
> >    not their sole use. They could also be used to implement
> > Role-Based
> >    Access Controls, as well as a variety of other controls. The
> > key
> >    characteristic is that the controls are based on the object
> > containing
> >    the information: they address the fundamental question of
> > whether a
> >    particular subject can access a particular object. Note that
> > this is
> >    independent of the actual implementation: it could be an
> > access
> >    control list on an object, but it could also be a permitted
> > access
> >    list on a subject, or some fixed rule set stored
> > completely
> >    independently of either subject or object. Access control
> > policies
> >    typically have an element of active decision making.
> >    Information flow controls (IFF/IFC) may be used to model
> > what in the
> >    TCSEC-paradigm was called Mandatory Access Control (more
> > properly,
> >    non-Discetionary Access Control, although even that is a
> > misnomer),
> >    but that is not their sole use. The key characteristic is
> > that the
> >    controls are based on a characteristic associated with
> > the
> >    information, such as a sensitivity label, the quality of the
> > data, or
> >    the source of the data. More importantly, the characteristic
> > stays
> >    associated with the data as it moves through the TSF, and
> > serves to
> >    provide the basis for the controls (although this
> > characteristic may
> >    be discarded, or the association destroyed, after the
> > decision has
> >    been made). Note that the characteristic need not be
> > embedded in the
> >    information; for example, consider unlabelled information
> > entering a
> >    multi-level system through a labelled port.
> >    In Information Flow, subjects need not be involved, as might
> > happen in
> >    a network device that connects two ports. In fact, there
> > might not be
> >    a decision made during run-time at all; the decision may
> > have been
> >    made ahead of time by the TOE design and captured in the TOE
> > design
> >    (for example, an information diode).
> >    In determining which policy to use in writing a security
> > target or
> >    profile, it is extremely important not to let the actual or
> > planned
> >    implementation affect the choice of policy. The type of
> > policy should
> >    be chosen based on the fundamental type of control: is it
> > subject
> >    access to an object, or is it based on characteristics of
> > the
> >    information.
>
>
>
> -- 
> TNO ITSEF BV
> P.O. Box 96864          tel
> +31 70 374 0304
> 2509 JG The Hague       fax +31 70 374
> 0651
> The Netherlands        
> www.commoncriteria.nl

**************************************************************************
* Opinions expressed are not intended to reflect an official position
**************************************************************************
* Gary Stoneburner
* Computer Security Division, National Institute of Standards & Technology
* 100 Bureau Drive, Stop 8930, Gaithersburg, MD 20899-8930         
* Phone: 301-975-5394, FAX: 301-948-0279, Email: Stoneburner@nist.gov
* http://csrc.nist.gov/staff/stoneburner/gshome.html
**************************************************************************