Re: [sca-policy] Troubles with overrides on errors stemming fromunsatisfied intents...

[Mike Edwards <mike_edwards@uk.ibm.com>]

Dale,

I think you lay out a good use case
here.

I can see the need for runtimes that
provide guarantees - and such runtimes would in all probability prevent

the overriding of stated policy requirements.

There is a question worth asking however,
whether there is equally the need to have runtimes that are by
design flexible and which can in principle
allow the deliberate bending of policy requirements. This is
perhaps not far away from the idea that
a binding implementation and/or the policySets which apply to 
that binding could claim to honour a
particular intent when in fact they do not - eg claim to provide
"confidentiality" when they
do not encrypt the messages.  Such behaviour would be perfectly legal
by
the SCA specifications.  Of course,
it would not help with the FIPS requirements you describe below.

The problem with enforcement of policy
is that it requires control right down to the bits on the wire,
something that the SCA specifications
don't attempt to do.  I suppose you might envisage a marker
like "FIPS compliant" being
added to bindings, policySets and to the applications built to run on
such a system - with each component
of the system being certified to behave in a compliant way.
Some systems need to be built that way.
 But it might not be such a good idea to place such heavy
requirements on all runtimes.

SCA aims to support a range of systems
- something that can be uncomfortable at times - the current
specifications hopefully do this in
a way that is useful.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	"Moberg Dale" <dmoberg@axway.com>
To:	<sca-policy@lists.oasis-open.org>
Date:	09/11/2009 18:49
Subject:	[sca-policy] Troubles with overrides on errors stemming from unsatisfied intents...

---

Suppose that intents were used for toplevel
composites that had to be certified with respect to some detailed profile
of security features.
 
For concreteness, consider the FIPS 200 levels
discussed in SP 800-53 Rev.
3Aug
2009Recommended Security Controls for Federal Information Systems and Organizations
(*Errata as of 09-14-2009*) sp800-53-rev3-final-errata.pdf
that describes several stronger and weaker grades of security “policy
sets”
 
FIPS 200, Minimum Security Requirements
for Federal Information and Information Systems, is a
mandatory federal standard developed
by NIST in response to FISMA. To comply with the federal
standard, organizations must first
determine the security category of their information system in
accordance with FIPS 199, Standards
for Security Categorization of Federal Information and
Information Systems, derive
the information system impact level from the security category in
accordance with FIPS 200, and then
apply the appropriately tailored set of baseline security
controls in NIST Special Publication
800-53, Security Controls for Federal Information Systems
and Organizations. Organizations
have flexibility in applying the baseline security controls in
accordance with the guidance provided
in Special Publication 800-53. This allows organizations to
tailor the relevant security control
baseline so that it more closely aligns with their mission and
business requirements and environments
of operation.
 
FIPS 200 and NIST Special Publication
800-53, in combination, help ensure that appropriate
security requirements and security
controls are applied to all federal information and information
systems. An organizational assessment
of risk validates the initial security control selection and
determines if any additional controls
are needed to protect organizational operations (including
mission, functions, image, or reputation),
organizational assets, individuals, other organizations, or
the Nation. The resulting set of
security controls establishes a level of security due diligence for the
organization.
 
Here would be a natural use case for intents
that rapidly summarize a quite diverse set of standards, not all of which
might be directly relevant to a toplevel composite, but some would be.
 
My version of Ashok’s question is: if someone
really specified some intent like
 
security:low-impact-fips200:fip800-53:external-environments
 
and read that
 
Assurance is the grounds for confidence
that the security controls implemented within an
information system are effective
in their application. Assurance can be obtained in a variety of
ways including:
• Actions
taken by developers, implementers, and operators in the specification,
design,
development, implementation, operation,
and maintenance of security controls;43
and
• Actions
taken by security control assessors to determine the extent to which the
controls are
implemented correctly, operating
as intended, and producing the desired outcome with
respect to meeting the security
requirements for the system       
 
would allowing operator override
of the above “imagined” intent basically invalidate the ability of a
sca toplevel composite to satisfy provisions for assurance in the security?
 
[There are already 100s of similar
illustrations that could be raised about how the SCA system of intents
and policies could be realisitically used to satisfy already specified
security standards of governments and verticals and whatnot. Is it unreasonable
to expect SCA to accommodate actual market requirements in this area?]

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU