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

[David Booz <booz@us.ibm.com>]

I like this use case and I think it raises a good question.

The current policy spec says, last paragraph of section 4.12.1:
"If the combination of implementationType / bindingType / collection of policySets does not satisfy all of the intents which apply to the element, the configuration is not valid. However, an SCA Runtime can allow a deployer to force deployment even in the presence of such errors as long as a warning is issued or some other indication is provided that deployment has been forced. Details of the behavior of the deployer in such situations are not specified in this specification."

Would a FIPS compliant runtime allow the deployer to "force deployment even in the presence of such errors...". I would think not. It is not an SCA runtime compliance point that a deployer be able to override the results of the policySet selection algorithm in section 4.12.

Should an SCA runtime be FIPS compliant in all circumstances? That is, should SCA compliance imply FIPS compliance. I would think not.

The SCA Policy spec is simply acknowledging that vendors need some room WRT how tightly (or loosely) they police satisfaction of intents.


Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

"Moberg Dale" ---11/09/2009 01:47:06 PM---Suppose that intents were used for toplevel composites that had to be certified with respect to some

From:	"Moberg Dale" <dmoberg@axway.com>
To:	<sca-policy@lists.oasis-open.org>
Date:	11/09/2009 01:47 PM
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?]