OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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?]

 

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]