Have you considered the CPE Applicability Language (NISTIR 7698)? It facilitates this without overloading CPE IDs.

Thanks, Leland

-----Original Message----- From: Martin Preisler [mailto:mpreisle@redhat.com] Sent: Thursday, October 20, 2016 2:31 PM To: SCAP Security Guide Subject: [Non-DoD Source] VMs, containers vs. bare-metal machines in SSG

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.

-- Martin Preisler Identity Management and Platform Security | Red Hat, Inc. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org

----- Original Message -----

From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, October 20, 2016 2:45:39 PM Subject: Re: VMs, containers vs. bare-metal machines in SSG

[snip]

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?

I'd like for SSG to be agnostic of the tech so I would go for CPE ID for container-image and that will be applicable when scanning docker images, rkt images, plain LXC images, etc... Same with vm-image, applicable on all offline virtual machine scanning, regardless of what is powering the VM or how it's stored.

-----Original Message----- Yeah, we'd use CPE applicability - a CPE name and its CPE OVAL definition. That will get us the best compatibility with various SCAP scanners out there.

What I meant by "fake" is that docker or vm-storage are not architectures, they are not even OSes, they don't fit well in the CPE ID schemes.

With the CPE 2.3 Applicability check-fact-ref element, you don't have to create "fake" CPE IDs, just use OVAL to determine whether a particular check is applicable, after using CPE ID to get close. Just a thought...

Thanks, Leland

As opposed to writing one XCCDF, why not write one XCCDF per point of interest (inside the container of interest, inside the OS but outside the container of interest, ...) - until upstream standards address Origin, Point (in SpaceTime), Frame of Reference, ... for a cyber-physical assembly?

-----Original Message----- From: Martin Preisler [mailto:mpreisle@redhat.com] Sent: Thursday, October 20, 2016 3:57 PM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Re: VMs, containers vs. bare-metal machines in SSG

----- Original Message -----

From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, October 20, 2016 2:45:39 PM Subject: Re: VMs, containers vs. bare-metal machines in SSG

[snip]

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?

I'd like for SSG to be agnostic of the tech so I would go for CPE ID for container-image and that will be applicable when scanning docker images, rkt images, plain LXC images, etc... Same with vm-image, applicable on all offline virtual machine scanning, regardless of what is powering the VM or how it's stored.

-- Martin Preisler Identity Management and Platform Security | Red Hat, Inc. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

On 19/01/17 18:40, Watson Yuuma Sato wrote:

On 20/10/16 20:30, 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.

Hi folks,

Following idea 3, here is a WIP PR to tackle this matter. https://github.com/OpenSCAP/scap-security-guide/pull/1645

The PR is in a state good for review.

Changes are not intended to be extensive and complete, the aim is to get the ball rolling and check whether we are in the same page regarding how to mark the rules.

Thank you.

Please, share your concerns...

-- Watson Sato Security Technologies | Red Hat, Inc

Rules for a subsystem should only apply if the subsystem to which they apply actually exist on the system.

1) The *Docker* methodology for containers would have us not use SSH in containers, but the LXC/LXD methodology (the OG of containers) would. 2) There is no reason that you need to have SSH on a bare metal machine if it is set up properly and there is an out of band methodology for accessing the system in an emergency (the same goes for containers really)

Presently, the system is upside down. We're looking at the OS as a single entity when, in reality, it is a collection of subsystems that work independently, or in concert, to create a whole.

If the SSG were decomposed into sections that applied to each individual subsystem, then only those parts that required application could be applied appropriately across any set of given processes. This would fit both the Docker and traditional-style systems equally.

Trevor

On Tue, Aug 15, 2017 at 6:19 AM, Watson Yuuma Sato wsato@redhat.com wrote:

On 19/01/17 18:40, Watson Yuuma Sato wrote:

...

On 20/10/16 20:30, 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.

Hi folks,

Following idea 3, here is a WIP PR to tackle this matter. https://github.com/OpenSCAP/scap-security-guide/pull/1645

Please, share your concerns...

Hello again,

Following idea 3, most of obvious (e.g. partition, grub, kernel) rules got marked as machine using CPE "cpe:/a:machine". Now there are some Rules witch are harder to decide whether they make sense or not for containers.

Take for example, Rules related to sshd. Technically, ssh can run fine in a container, but it is not recommended, there are other ways to access a running container. An exception to running ssh in, is that this container's purpose is to be an ssh server.

If mark these as machine only they will never apply to containers and we will need new Rules to evaluate ssh inside containers. If they are left as is, they will continue to be evaluated for containers, installing ssh, increasing attack surface and possibly causing false positives.

We would like SSG to have sane defaults for these Rules, but still allow for tailoring for exception scenarios.

In https://github.com/OpenSCAP/scap-security-guide/pull/2235 I started a prototype for Idea 1, to have separate datastreams for containers. But that showed to not be a good idea. So I changed it to idea 2, with separate Profiles for containers. Main idea is to generate these Profiles automatically from existing Profiles and use information already present in Rules to filter out the ones not recommended for containers.

Also, there is new idea of adding "container-base" Profile with basic configuration for containers, I see it like a "standard" Profile for containers.

So, container Profiles would have Rules which are not recommended for containers dropped, and inherit Rules from "container-base".

Looking forward for your thoughts.

-- Watson Sato Security Technologies | Red Hat, Inc _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedo rahosted.org To unsubscribe send an email to scap-security-guide-leave@list s.fedorahosted.org