<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 September 2015 at 19:21, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Major Hayden's message of 2015-09-10 09:33:27 -0700:<br>
<span class="">> Hash: SHA256<br>
><br>
> On 09/10/2015 11:22 AM, Matthew Thode wrote:<br>
> > Sane defaults can't be used?  The two bugs you listed look fine to me as<br>
> > default things to do.<br>
><br>
> Thanks, Matthew.  I tend to agree.<br>
><br>
> I'm wondering if it would be best to make a "punch list" of CIS benchmarks and try to tag them with one of the following:<br>
><br>
>   * Do this in OSAD<br>
>   * Tell deployers how to do this (in docs)<br>
<br>
</span>Just a thought from somebody outside of this. If OSAD can provide the<br>
automation, turned off by default as a convenience, and run a bank of<br>
tests with all of these turned on to make sure they do actually work with<br>
the stock configuration, you'll get more traction this way. Docs should<br>
be the focus of this effort, but the effort should be on explaining how<br>
it fits into the system so operators who are customizing know when they<br>
will have to choose a less secure path. One should be able to have code<br>
do the "turn it on" "turn it off" mechanics.<br></blockquote><div><br></div><div>I agree with Clint that this is a good approach.</div><div><br></div><div>If there is an automated way that we can verify the security of an installation at a reasonable/standardised level then I think we should add a gate check for it too.</div></div>
</div></div>