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

[ashok malhotra <ashok.malhotra@oracle.com>]

Hi Dale:
In my view intents merely express high-level desires or wishes. A 
runtime might well say, sorry, I cannot do that
and you then should have a choice to proceed or abort.
For certification and guarantees you should use policySets.
Does that make sense?
All the best, Ashok


Moberg Dale wrote:
>
> 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 
> <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/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?]
>