Open Stack

On 01/13/16 15:10, Major Hayden wrote:
> After presenting openstack-ansible-security at the Security Project Mid-Cycle meeting yesterday, the question came up around how to handle situations where automation might cause problems.
>
> For example, the STIG requires[1] that all system accounts other than root are locked.  This could be dangerous on a running production system as Ubuntu has non-root accounts that are not locked.  At the moment, the playbook does a hard stop (using the fail module) when this check fails[2].  Although that can be skipped with --skip-tag, it can be a little annoying if you have automation that depends on the playbook running without stopping.
>
> Is there a good alternative for this?  I've found a few options:
>
>    1) Leave it as-is and do a hard stop on these tasks
>    2) Print a warning to the console but let the playbook continue
>    3) Use an Ansible callback plugin to catch these and print them at the end of the playbook run

The STIG is just DISA's interpretation and based on my experience with 
helping get the Solaris 10 and Solaris 11 STIG correct it is often 
overly strict and sometimes poor advice for the general case.

In the case of Solaris, Ubuntu, Fedora requiring some of these system 
accounts to be locked would actually weaken system security because 
certain required functionality would break.

So I would strongly caution against taking the DISA STIG as an 
authoratative stance for OS security configuration.  A lot of it is very 
good and overlaps with CIS and vendor recommendations.  For Red Hat, 
Fedora and Solaris I would recommend instead to look at the vendor 
delivered XCCDF profiles.

I think it would be much more valuable for us to focus on getting 
XCCDF/OVAL developed for OpenStack specific rules and leave the OS 
configuration/recommendations to the OS vendors.

-- 
Darren J Moffat