first post

JENNINGS, JARED L CTR USAF AFMC 96 SK/CCI jared.jennings.ctr at us.af.mil
Wed Jul 23 23:07:45 UTC 2014


Greg Elin says:
> Do you have plans to make any or all of
> it available outside of forge.mil?

Yes.

> developing a toolkit to make OpenSCAP and FISMA easier for civic innovators

Indeed. I notice you used vagrant for your demo commands. One of the coolest things I've done with our CMITS policy was when we wanted some software from an outside firm, and they wanted a machine configured just like our workstations. I just wrote a node definition that said "eh, mostly like one of our standalone boxes," and a Vagrantfile that told Vagrant to use its Puppet provisioner to apply our manifest, and with one (half-an-hour long) "vagrant up" command, our partner could set up a virtual AFSEO workstation. It sounds not unlike what you are doing.

> Can you share with the list portions of the README that describe the extent to which you lock things down?

The CMITS release is sort of a kit; the final piece that pulls all the rest together is for you to write.
 
Most of the reason for CMITS was to have flexibility about how locked-down we are, and how we do it: on some systems we couldn't fulfill such-and-such requirement, and so we don't, but we need to explain that. Or - oh, here's a good one. Some of our systems are standalone; they implement the NFS requirements trivially by disabling NFS. Others are on a network; they implement the NFS requirements in a more fleshed-out way. So the CMITS release contains an nfs module, with an nfs::no class and an nfs::stig class.

Then if you only have standalone boxes, you write something like 

class stig_compliance {
    include nfs::no
}

node mybox {
    include stig_compliance
}

If you have more complicated needs, you write more classes.


More information about the scap-security-guide mailing list