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.
--
SCAP Security Guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/
