<div dir="ltr"><div>Goal: Enable use of manually created waivers for non-passing rule explanations/resolutions.</div><div><br></div><div>This was inspired by Martin Preisler's blog post "Waivers in Openscap HTML Report" <<a href="http://martin.preisler.me/2014/11/waivers-in-openscap-html-report/">http://martin.preisler.me/2014/11/waivers-in-openscap-html-report/</a>>.</div><div><br></div><div>When a scan is completed, there may be some errors or fails due to specific differences in the target architecture. In order to create clean scans, some have taken to the practice of "tailoring" the input rules, essentially removing rules that cause fails. This has several drawbacks, not the least of which being that it applies ad-hoc modifications to what may be certified SCAP or STIG content defining a required set of tests, yielding untrustworthy results.</div><div><br></div><div>A better mechanism would be to preserve all the tests, but enable explanatory text to be placed inline with failed rules on the target machine. These explanations should be accompanied by the authoring user and date, and should only appear when the rules scan result differs from the waiver file's result. A single waiver file could be applied across a collection of results files from a large installation of machines, with slight differences in the machines potentially resulting in different sets of waivers being applied.</div><div><br></div><div>The "waiver file" is created using YAML, Markdown or some other human-managable format that can be easily converted to XML and processed along with the results.xml file produced by OpenSCAP. I'm not an expert at YAML, but an example waiver file might look something like:</div><div><br></div><div>    authority: John Doe</div><div>      datetime: 2015-04-06</div><div><span class="" style="white-space:pre">     </span>- rule_id: CCE-12345-1</div><div><span class="" style="white-space:pre">     </span>  new_result: pass</div><div><span class="" style="white-space:pre">        </span>  remark: ></div><div><span class="" style="white-space:pre">    </span>    Indented, multiple line remark</div><div><span class="" style="white-space:pre">       </span>    in which newlines become spaces.</div><div><br></div><div><span class="" style="white-space:pre">    </span>      code = 1; // Add extra indent to preserve newlines.</div><div><span class="" style="white-space:pre">       </span>      return;   // This could appear as a code block.</div><div><br></div><div><span class="" style="white-space:pre"> </span>    And the explanation can continue here.</div><div><br></div><div><span class="" style="white-space:pre">      </span>- rule_id: CCE-23456-3</div><div><span class="" style="white-space:pre">     </span>  new_result: not applicable</div><div><span class="" style="white-space:pre">      </span>  remark: Feature non-existent in this architecture.</div><div><br></div><div>    authority: Jane Doe</div><div>      datetime: ...</div><div><br></div><div>The combined report is created with a command like:</div><div><br></div><div>    oscap xccdf generate report --waiver-yaml waiver.yml $INPUT</div><div><br></div><div>The report would indicate rules with waivers via a tag or color coding. Ideally (not needed in an intial release) other sorts/filters could exist, such as:</div><div> * only report non-waived rules (similar to the "tailoring" mechanism)</div><div> * only report waivers</div><div> * group high, medium and low severity rules together in the summary display</div><div> * separate waivers at the end of the summary display</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Fen Labalme, CivicActions.com</div><div>Engineering | Quality | Systems</div><div><br></div></div></div>
</div>