<div dir="ltr">I have a lot of calls now, but could consider another, esp. if it were a once or twice a month sort of thing. But a collaboration tool like Trello or a wiki or - what do people use these days? - might be useful.<div><br></div><div>WRT waivers, additional fields may be:</div><div>* timeframe (start, end dates of applicability)</div><div>* risk score/evaluation (high/med/low or more fine-grained?)</div><div>* environment/asset (different machines, OS versions, etc. may have different waiver sets)</div><div>* alternative test (a value may be in /etc/syslog.conf on one machine but in /etc/default/syslog on another)</div><div><br></div><div>I just added the last. I agree the output of applying waivers yo a results.xml file should create a new results_with_waivers.xml file as well as the report.html output for auditor use, but I like the idea of the original waiver file being external and human editable. Perhaps a cryptographic fingerprint of the waiver text file should be included in the results files, encouraging the authors to use a version control system like git so that previous source versions could be easily retrieved.</div><div><br></div><div>=Fen</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 12:04 PM, Greg Elin <span dir="ltr"><<a href="mailto:gregelin@gitmachines.com" target="_blank">gregelin@gitmachines.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In addition to OpenSCAP of hitting the limits of using stateless tools, I think we may also be approaching the limits of using stateless collaboration.<br>
<br>
Maybe we should start considering regularly scheduled group calls to do group demos and discuss ideas?<br>
<span><br>
Greg Elin<br>
P: <a href="tel:917-304-3488" value="+19173043488" target="_blank">917-304-3488</a><br>
E:  <a href="mailto:gregelin@gitmachines.com" target="_blank">gregelin@gitmachines.com</a><br>
<br>
Sent from my iPhone<br>
<br>
> On Apr 8, 2015, at 9:36 AM, Šimon Lukašík <<a href="mailto:slukasik@redhat.com" target="_blank">slukasik@redhat.com</a>> wrote:<br>
><br>
</span><div><div>>> On 04/07/2015 05:57 AM, Fen Labalme wrote:<br>
>> Goal: Enable use of manually created waivers for non-passing rule<br>
>> explanations/resolutions.<br>
>><br>
>> This was inspired by Martin Preisler's blog post "Waivers in Openscap<br>
>> HTML Report"<br>
>> <<a href="http://martin.preisler.me/2014/11/waivers-in-openscap-html-report/" target="_blank">http://martin.preisler.me/2014/11/waivers-in-openscap-html-report/</a>>.<br>
>><br>
>> When a scan is completed, there may be some errors or fails due to<br>
>> specific differences in the target architecture. In order to create<br>
>> clean scans, some have taken to the practice of "tailoring" the input<br>
>> rules, essentially removing rules that cause fails. This has several<br>
>> drawbacks, not the least of which being that it applies ad-hoc<br>
>> modifications to what may be certified SCAP or STIG content defining a<br>
>> required set of tests, yielding untrustworthy results.<br>
>><br>
>> A better mechanism would be to preserve all the tests, but enable<br>
>> explanatory text to be placed inline with failed rules on the target<br>
>> machine. These explanations should be accompanied by the authoring user<br>
>> and date, and should only appear when the rules scan result differs from<br>
>> the waiver file's result. A single waiver file could be applied across a<br>
>> collection of results files from a large installation of machines, with<br>
>> slight differences in the machines potentially resulting in different<br>
>> sets of waivers being applied.<br>
>><br>
>> The "waiver file" is created using YAML, Markdown or some other<br>
>> human-managable format that can be easily converted to XML and processed<br>
>> along with the results.xml file produced by OpenSCAP. I'm not an expert<br>
>> at YAML, but an example waiver file might look something like:<br>
>><br>
>>     authority: John Doe<br>
>>       datetime: 2015-04-06<br>
>> - rule_id: CCE-12345-1<br>
>>  new_result: pass<br>
>>  remark: ><br>
>>    Indented, multiple line remark<br>
>>    in which newlines become spaces.<br>
>><br>
>>      code = 1; // Add extra indent to preserve newlines.<br>
>>      return;   // This could appear as a code block.<br>
>><br>
>>    And the explanation can continue here.<br>
>><br>
>> - rule_id: CCE-23456-3<br>
>>  new_result: not applicable<br>
>>  remark: Feature non-existent in this architecture.<br>
>><br>
>>     authority: Jane Doe<br>
>>       datetime: ...<br>
>><br>
>> The combined report is created with a command like:<br>
>><br>
>>     oscap xccdf generate report --waiver-yaml waiver.yml $INPUT<br>
>><br>
>> The report would indicate rules with waivers via a tag or color coding.<br>
>> Ideally (not needed in an intial release) other sorts/filters could<br>
>> exist, such as:<br>
>>  * only report non-waived rules (similar to the "tailoring" mechanism)<br>
>>  * only report waivers<br>
>>  * group high, medium and low severity rules together in the summary<br>
>> display<br>
>>  * separate waivers at the end of the summary display<br>
>><br>
>> --<br>
>> Fen Labalme, CivicActions.com<br>
>> Engineering | Quality | Systems<br>
><br>
> Hello Fen,<br>
><br>
> A lot of good ideas here.<br>
><br>
><br>
> I was thinking more about waivers and the processing of waivers and I have figured out some more points.<br>
><br>
> * waivers may re-occur<br>
>   -> hence they are always not bound to a scan, sometimes they are bound to asset<br>
> * waivers may have limited life time<br>
>   -> i.e. security folks give operational folks a 3 weeks window to amend deployment<br>
> * each waiver represents a risk evaluated and risk undertaken<br>
>   -> there is a value in processing waiver list/data<br>
><br>
> So I conclude, that it would be beneficial to have waivers stored in the database together with the scan results.<br>
><br>
> This idea is not new. We have already hit the limits of state-less tools (oscap, libopenscap, scap-workbench) on other fronts. Hence we have decided to introduce project SCAPtimony.<br>
><br>
> Think about SCAPtimony as a microservice that stores auditing results as well as it allows you to model compliance policies. More read about SCAPtimony:<br>
><br>
> * <a href="https://github.com/OpenSCAP/scaptimony" target="_blank">https://github.com/OpenSCAP/scaptimony</a><br>
> * <a href="http://isimluk.livejournal.com/#post-isimluk-4908" target="_blank">http://isimluk.livejournal.com/#post-isimluk-4908</a><br>
> * <a href="https://isimluk.fedorapeople.org/slides/2015devconf-compliance_center.pdf" target="_blank">https://isimluk.fedorapeople.org/slides/2015devconf-compliance_center.pdf</a> ( <a href="https://www.youtube.com/watch?v=WCVBNb6nfR8" target="_blank">https://www.youtube.com/watch?v=WCVBNb6nfR8</a> )<br>
><br>
><br>
> So in my books, waivers should be a database table in SCAPtimony project. SCAPtimony should get API[1]. And your proposed yaml might become an API for adding waivers. We already have some support for waivers in libopenscap and rubygem-openscap, so we should be able to leverage those.<br>
><br>
> ~š.<br>
><br>
> [1] SCAPtimony API is currently implemented in sister's project foreman_openscap and needs to be migrated downto SCAPtimony.<br>
><br>
</div></div><div><div>> _______________________________________________<br>
> Open-scap-list mailing list<br>
> <a href="mailto:Open-scap-list@redhat.com" target="_blank">Open-scap-list@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/open-scap-list" target="_blank">https://www.redhat.com/mailman/listinfo/open-scap-list</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div>Fen Labalme, CivicActions.com</div><div>Engineering | Quality | Systems</div><div>mobile: <a href="tel:412-996-4113" value="+14129964113" target="_blank">412-996-4113</a></div><div>skype/aim/twitter: openprivacy</div></div></div>
</div></div>