Re: Where can we use Information flow control policy (FDP_IFC/IFF)?

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

Thanks Andrew,

Basically, I agree with you.
Yes, input data validation in applications might not be a scope of security
functions in the view of CC.
But, in a broader sense, what is security function in applications and what
is not is very grey.

Take a look at ISO/IEC17799 (Information technology - Code of practice for
information security management).
It specifies the following requirements at the section 10.2 (Security in
application systems).

--------------------------------------
10.2 Security in application systems
10.2.1 Input data validation
Data input to application systems should be validated to ensure that it is
correct and appropriate.
--------------------------------------

Also, I find the following phrases in CC part2 annexes F.5 (FDP_IFC)

--------------------------------------
However, they go beyond just the traditional MAC mechanism and can be used
to identify and describe non-interference policies and state-transition.
Those components are quite flexible.They allow the domain of flow control to
be specified and there is no requirement that the mechanism be based upon
labels.
--------------------------------------

For me, it is not clear how far FDP_IFC go beyond the traditional MAC
mechanism, and how it went flexible.

Perhaps, it might not went as far as to include the input data validation
mechanism for it's use, is it?

But, once the ST author has decided to use it as a security requirement for
input data validation in the application, does the ST evaluation fail in
terms of CC/CEM ?  I'm not sure about this.

----- Original Message ----- 
From: "Andrew Teklemariam" <andrewt@neoscale.com>
To: "Multiple recipients of list" <cc-cmt@nist.gov>
Sent: Tuesday, June 24, 2003 2:14 AM
Subject: RE: Where can we use Information flow control policy (FDP_IFC/IFF)?


>
>
> YOKOTA HIROFUMI wrote:
> > -----Original Message-----
> > From: YOKOTA HIROFUMI [mailto:yokota-hirofumi@jqa.jp]
> > Sent: Monday, June 23, 2003 1:57 AM
> > To: Multiple recipients of list
> > Subject: Re: Where can we use Information flow control policy
>
> >...
> > However, when to think about general application products and to write
> > those
> > STs, we need to identify the security functions in the code aside from
> the
> > application codes. Could the input data validation be a security
> function,
> > not an application function?
>
> My understanding is that it can be included only if it is a security
> attribute.  A couple of things here: 1. we don't have to include
> FDP_IFC/IFF or anything for that matter.  We do so only if the product
> provides a security function that we want to advertise.  2.  What is
> being evaluated is a set of security functions provided by the product.
> For example, data-integrity, authentication, authorization, access
> control so on and so forth.  If the application is checking for valid
> user-IDs before it allows login for example, we claim there is an
> authentication/identification security function provided by the product.
> But if an application checks input fields to make sure all options are
> appropriate and consistent, that may not be a security function and
> hence is not of interest as far as the ST is concerned.  Also note:
> security functions that get included are purely for sales purposes (in
> my view).  For example, a customer will be able to compare two products
> based on the ST and see which one provides security functions that are
> important.
>
> >Is it appropriate to express the requirement
> > using FDP_IFC/IFF?
> >
> > Now, think about the extreme case. That is: all input message fields
> are
> > validated by the correct range of values for each field. Then, if we
> use
> > FDP_IFC/IFF, does this mean that all the input fields are to be
> specified
> > as
> > security attributes? Does this mean that all the input data is
> considered
> > as
> > TSF data, not considered as user data?  Isn't this funny?
> >
>
> Again, what security functionality is being provided when "input message
> fields are validated by the correct range of values for each field"??
> Checking port numbers or valid IP addresses may be attributed as input
> filtering, authorizing or denying access to a resource.  But checking
> the TCP options field for fragments/offsets will not be a security
> function although it is a necessary thing for the correct operation of
> the product.  i.e., it does not provide a security value/function to the
> customer?
> -andrew
>
>
> > Regards,
> >    Yokota
> >
> > ----- Original Message -----
> > From: "Andrew Teklemariam" <andrewt@neoscale.com>
> > To: "Multiple recipients of list" <cc-cmt@nist.gov>
> > Sent: Friday, June 20, 2003 1:37 AM
> > Subject: RE: Where can we use Information flow control policy
> > (FDP_IFC/IFF)?
> >
> >
> > >
> > >
> > >
> > > ..stuff deleted
> > >
> > > >Additionally, my concerns around this is:
> > > >when FDP_IFC/IFF are used for filtering input messages by cheking
> > > values on
> > > >the particular input-field, could this be an appropriate use of
> > > FDP_IFC/IFF
> > > >as security function requirements?
> > > >I'm wondering if this use is nothing more than just an input data
> > > >validation
> > > >check and it might be an application function, not a security
> function.
> > > >Although, I'm thinking, this could be an accepted use of
> FDP_IFC/IFF.
> > > >What do you think about this?
> > > >
> > > >Thanks a lot for your time and assistance.
> > > >  Yokota
> > >
> > > An example of FDP_IFC, FDP_IFF use is what a firewall does.  See
> > > NetScreen's ST. Hopefully, that will give you a good idea.
> > > -andrew
> > >
> > >
> >
>
>