High Level ORML Requirements Ideas
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256 Hi, Theres been some talk on the mailing list about putting together some ORML requirements as a stepping stone to building out a language. Weve tried to incorporate the comments from this list along with analysis of the various remediation tools on the market into the draft list of requirements below. How should these requirements be prioritized what are the core things you need to be able to express in order to automate remediation/modification? Also, is there any data you would need in order to remediate vulnerabilities that isnt in this list? User Actionable Information 1.1. Unique Identification - The standard shall provide for the simple identification of a unique modification 1.2. Description - The standard shall provide for a human readable description of the modification 1.3. Dependencies - The standard shall provide for a human readable description of all dependencies for application of the modification 1.4. Behavioral Parameters - The standard shall provide for a human readable enumeration of all behavioral parameters, such as reboot requirement or device locks, associated with a modification 1.5. Applicability - The standard shall provide for an enumeration of the CPEs the modification applies to 1.6. Basis - The standard shall provide for the enumeration SCAP compatible identifiers (CVE, CCE, OVAL ID, etc) which represent findings that would server as the basis for applying a given modification 1.7. Error/Status Messages - The standard shall provide for the description of error and status messages which may be returned as a result of the attempted application of a modification 1.8. Switches/Controls - The standard shall provide for the listing and description of all interactive parameters which may be provided to the modification, including such metadata as data types, filters and default values. 1.9. User Interactions - The standard shall provide for the description of required/allowed user interactivity to occur during the application of the modification. 1.10.Integrity Controls - The standard shall provide for some mechanism, such as a digital signature, to provide assurance as to the integrity of the modification. 1.11.Executables and Scripts - The standard shall provide for the encapsulation of encoded binary payloads using such mechanisms as base64 encoding. 1.12.Supersedence - The standard shall provide for a user readable enumeration of all ORML content superseded by a given modification. 1.13.Deprecation - The standard shall provide for the specification of a Boolean value designating whether a given modification has been deprecated. 1.14.Undo - The standard shall provide for the specification of the metadata required to undo a modification. This includes a flag specifying if the undo capability is supported and the reference to a modification capable of performing the undo if appropriate. 1.15.Alternatives - The standard shall provide for the specification of many modifications associated with a given applicability/basis combination. 1.16.Side Effects - The standard shall provide for the human readable specification of any secondary effects resulting from the application of a given modification. 2. System Actionable Information 2.1. Binary Payload and Execution - The standard shall provide for the encapsulation and execution of arbitrary binary content. 2.2. Parameterization - The standard shall provide for the specification and usage of runtime evaluation of parameters. 2.3. External Data - The standard shall provide for the reference to external content, such as scripts and executables. 2.4. Compatibility with OVAL System Characteristics - The standard shall provide for the specification of OVAL System Characteristics as a desired state. For example, the ability to create, delete, modify, and overwrite files using OVAL System Characteristics style data. 2.5. Administrator Provided Switches and Controls - The standard shall provide for the ability to accept switches/controls passed from a system administrator prior to deployment and execution. 2.6. Status Updates and Error Messages - The standard shall provide for the ability to sent status updates/error messages based on the success of a modification. 2.7. Multiple Action Modifications - The standard shall provide for the specification of multiple discrete actions and the sequence in which those actions shall run within the scope of a single modification. 2.8. Action Chains - The standard shall provide for the specification of the capability for an action which may otherwise require a reboot upon completion to be chained together with other actions. 2.9. Pre-requisites - The standard shall provide for the system actionable specification of SCAP compatible identifiers are pre-requisites for the application of a modification or execution of an action. 3. OVAL Addendums 3.1. Relating Findings to Modifications - OVAL shall provide for the specification of modifications related to OVAL definitions and criterion. 3.2. Modification Metadata - OVAL shall provide for the specification of metadata about modifications capable of remediating a finding. 3.3. Modification Encapsulation - OVAL shall provide for the encapsulation of a modification. 3.4. Modification Success - OVAL shall provide for the assessment of the success of the attempted application of a modification. -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSIDO6Z3xz8BLNKAgAQi7eQf/TugHX7Et9AckEGKKOSZpeqxepTFMc9fC koxqTMKGhgYV5oQSQBmY8CLWfMzkbuLnd+Vbo/DpmvzXhvIWtGcfpjo+GoIV491F mOJriD4efZsHWpzdC96mX+DDUKsZw6er7Ql7c32xOPE7fFVDthvQumZlq9V7P3AF LRC8JHnbaWRMFUC7e4wW++/a0djFbXKY8WMvE0A/WvLWujF1lqczy7//03kKP+ZP AdNi11OJRtkcuXzBEQ8AmmHmdyvHSbJ1W8Tk4VPPNWPJX5xb2b1mbi/VYYun1LeW FKZ0GJgtIBuBezkjv8J3S+0pI4H96xhidYGsN4ymFjvSA6tnKA/NkQ== =KahQ -----END PGP SIGNATURE----- |
||||||||
PGPexch.htm.pgp (6K) | Free Forum Powered by Nabble | Forum Help |