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.