On 10/20/16 2:30 PM, Martin Preisler wrote: > We have had increasing requests to scan containers and VM storage images > for compliance. In those use-cases a lot of our rules don't make sense. > For example separate partition for /tmp isn't really applicable to containers. > > I thought about how we can deal with this in SSG. We have several options: > > 1) Separate benchmark and datastreams for containers and VM storage images: > ssg-rhel7-ds.xml and ssg-rhel7-container-ds.xml > > 2) Separate profile for containers and VM storage images: > pci-dss and pci-dss-container > > 3) Use applicability and CPE platforms to distinguish between what is being > scanned. That allows us to use the same pci-dss profile for bare-metal, VM, > VM storage image and container image. > > Right now I am leaning towards 3) because it "unlocks" the feature > transparently to our users. There is nothing extra they have to study to > start scanning containers. The downside is that we will have to add "fake" > CPE IDs for platforms like "vm-storage" and "container". Rules that apply > to everything will have no <platform> element in them. Rules that apply > to just containers will have something like: > > <platform idref="cpe:/a:*:container-image"/> > > or > > <platform idref="cpe:/a:*:vm-storage"/> > > Official NIST CPE ID dictionary has these related CPE IDs > cpe:/a:redhat:docker:1.5.0-27 > cpe:/a:linuxcontainers:lxc:0.5.0 > cpe:/a:redhat:libvirt:1.2.7 > > Not sure we want to go with any of those though. I would like to keep it > container and VM tech agnostic. > > Before I start hacking this I would like to hear your thoughts.
Really like the idea of CPEs. We can always work with NIST to get extra CPEs added.... but wouldn't that mean creation of redhat:docker, redhat:openshift, Docker:docker, pivotal:cloudfoundry, etc? _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
