________________________________________ > From: Brent Kimberley <[email protected]> Mon, 7 Nov 2016 17:45:42 > +0000 > > Hi Radzy. > > Are you trying to bundle everything into one XCCDF? If so, > you may be making the problem harder than it needs to be.
Hi Brent No, I'm not trying anything yet. I'm just looking ahead to what I expect my next task will be, and trying to make sure I understand enough background information to be able to proceed when I get to it. I'll interpret your comment as a recommendation that I plan on using multiple XCCDFs. And probably multiple OVALs as well. I do want to minimize the amount of cut-n-paste duplication. So it would be nice if some of the minor differences can be handled by a single file with selectable options. If that won't work, or if it's too difficult, then I'll go ahead with the cut-n-paste. But I think it's worth spending some time to avoid it. Enjoy! -- radzy > -----Original Message----- > From: Radzykewycz, T (Radzy) [mailto:[email protected]] > Sent: Friday, November 4, 2016 4:52 PM > To: [email protected] > Subject: RE: VMs, containers vs. bare-metal machines in SSG > > > ________________________________________ > > -----Original Message----- > > From: Radzykewycz, T (Radzy) [mailto:[email protected]] Friday, > > October 21, 2016 1:16 PM > > > From: Brent Kimberley <[email protected]> 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? > > > > When I start working on our container environment, I expect I need to > > write custom XCCDF and custom OVAL for some of the checks. > > Some of the management may be done in the container, but I expect most > > to be done in the underlying host. So paths may be different, which > > would lead to either more complex OVAL with parameterization, or > > duplication of the OVAL content. > > > > And as implied elsewhere, the XCCDF needs to be modified to indicate > > the correct information for the environment. > > > > From: Brent Kimberley <[email protected]> Wed, 2 Nov 2016 > > 19:52:29 +0000 (edited) Hi Radzy. > > Assuming a strawman consisting of: one OS(i.e. apps, libraries, > > OSxContainer-Interface, etc.); and one container(i.e. app, libraries, > > ContainerxOS-Interface, etc.). > > > > There is > > one XCCDF for the OS (baseline) > > one XCCDF for the container (delta) > > one XCCDF for OS + container (net) > > one XCCDF for OS union net (max) > > one XCCDF for max - (OS intersection net ) (min) > > > > The last XCCDF is: > > one XCCDF for OS intersection net (min) > > > > Whereas functionality at risk of eclipse is > > max - (OS intersection net ) > > Hi Brent > > Right. Thanks for the enumeration. > > I still need to look into two questions: > > - Can I use docker to support what I need to do ? Since OpenSCAP > does have some kind of docker support built-in, and I haven't > looked at it, this might be less work. But I need to look > into it. > > - Can I use some kind of a prefix variable to minimize the amount > of duplication. Then I could have a profile for the OS and one > for each container, and specify a procedure where both profiles > are run with independent oscap commands. Then some XCCDF for > the other cases not covered by those two, possibly in a third > oscap invocation.. > > And of course, there's always the possibility that some aspects of both will > be useful. And the likelyhood that I'll need to do something custom. > > Enjoy! > > -- radzy _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
