Standardized Vulnerability Remediation and System Modification
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256 G2, HP, and ThreatGuard submit the following proposal which calls for the establishment of an addendum to OVAL which specifies language allowing for vulnerability remediation and system modification for community review and comment The OVAL suite of standards currently consists of three standards: * OVAL Definitions * OVAL System Characteristics * OVAL Results We propose the addition of an OVAL Modifications standard to the OVAL standards suite. This standard defines a structure for vulnerability remediation and system modification integrating with many of the design paradigms established by other OVAL standards. The basic addendum consists of the addition of a modifications element as a child to the oval_definitions element. This modifications element contains a list of modification elements which each specify: * A unique modification identifier * Typical metadata regarding the modification (author, timestamp, description, etc) * References to other scap identifiers (OVAL tests/criteria, CXE, etc) relating the goal of the modification. * References may also optionally exist from within OVAL Definition elements to OVAL modifications. * Operation specific data (if its a registry modification a reference to the key/value to be modified and the desired value) This specification builds on top of current community proposals and discussion to fulfill the requirements defined below. o The standard shall allow for specification of action to be performed (Which state am I transitioning to?) o The standard shall allow for a machine actionable statement of the distinct actions to be performed (What steps do I need to run?) o The standard shall allow for specification of asset precondition (Which state do I need to be in to execute?) o The standard shall allow for specification of asset postcondition (Which state will I be in after successful execution?) o The standard shall allow for specification of multiple remediations/modifications tied to a single action specification (What are my options to mitigate a vulnerability?) There are benefits and risks associated with coupling remediation within the OVAL standard as follows o Benefits § Ability to perform very granular remediation, based on individual OVAL criteria which may have no CXE equivalent § One file has all content related to detection and remediation (one file to maintain) § Marketing Merit significant manpower has been put into public awareness of the OVAL brand § Community Size OVAL has a sizable community, some of which has gone through arduous authorization processes to participate. o Risks § One file has all content related to detection and remediation (large, monolithic file) · We are assuming this will be mitigated as the availability and quality of the OVAL repositories and related APIs continues to improve § OVAL, as a standard, is already very large and complex before the addition of relatively simplistic remediation content. · We are assuming this will be mitigated as the OVAL content creation tools continue to mature We are making some assumptions moving forward relating to the continuing maturity of the OVAL specification, but believe this is the way to proceed which provides the highest amount of benefit while mitigating as much impact on content authors, consumers and tool vendors as possible. Thanks, Alex Quilter, Kevin Sitto, Pai Peng, Rob Hollis, Shane Shaffer, Todd Dolinsky, Yuzheng Zhou -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSG0RBp3xz8BLNKAgAQiesQf/d9xYQ+74OrmHUe4OlwM+Le2I26pwqv2d t4gKLVXAbHXynUHJ+SlHuaTZJaMvcLhT7U0eQgVjiEVRSCzVBoaYIYXsBvfh8zPK cQy9xJvOESQWZI9ytyclXBcWdUTfWW5lpylxt51H6WJifNUH0H8bzyxEMNz6gfgU yedR67CeM4/jVp05vMPSljWA+AUsrPe0SoFwGcJ6AsPe6SGFafmAzPh0V23dZnBJ G6E4qgiHD9UXGOzwY6b7qkiMUuUnAKbSHfcBFV/CQhre+H0d0a3QWGQ9pgG9z9HT DWP/y9MyWmL0q128QKFuSMRj4ugi9TkInRMtvcr7+tDSeu27eiD00g== =ytlJ -----END PGP SIGNATURE----- |
||||||||
PGPexch.htm.pgp (7K)
|
|
||||||||
|
|
||||||||
|
|
||||||||
|
|
|
||||||||
|
|
||||||||
|
|
|
||||||||
|
Hello all,
Looking for a compromise, I see that we are not that far from each other. Where will the remediation content live? As I see it, it is part of the SCAP data stream. Another file(set) that can be referenced in the XCCDF makes the most sense. This content already is much more than one file. Remediation should start at the Rule. It sort of does now, but seriously, it should start there more legitimately. For those that want one file, they can probably inline the OVAL and ORML right into the XCCDF. I am guessing no one will actually do that. Should ORML reuse OVAL? It will need to reuse a checking system for sure. Since OVAL is the SCAP preferred checking system, it will reuse it (by convention). OVAL should not be so closely coupled as to disallow other checking systems though. It should have the same flexibility as XCCDF. Decoupling allows the languages to mature independently. So a precondition check and post condition check that would look like XCCDF checks could use OVAL but would not be restricted to that checking system. How can they be separate? Why can't we add the ability to reference OVAL ids that live in other files the way XCCDF does? This would also be useful with integrating CPE with OVAL. Once the ability exists, we can by convention (or officially) keep the remediation content separate and still reuse OVAL definitions, tests, etc. Is referring to an OVAL test OK? We said no at developer days, but we also said it was a convention and nothing can stop someone outside OVAL from doing so. I am of the opinion that duplicating the data (e.g. test) in the ORML and OVAL is worse than keeping OVAL's interface only definitions. The fireworks are exciting. Though I look forward to a quick solution. Best regards, Vladimir Giszpenc DSCI Contractor Supporting US Army CERDEC S&TCD IAD Tactical Network Protection Branch (732) 532-8959 |
||||||||
|
|
||||||||
|
| ||||||||