From: Brent Kimberley Brent.Kimberley@Durham.ca 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.
Enjoy!
-- radzy
I'd like to approach this from a usability point of view and re-request a feature that I feel is crippling adoption of SCAP in orgs that can't have dedicated SCAP-fu experts.
Adding additional layers of complexity is going to further drive away adoption, particularly without good command line and/or graphical tools to understand what I'm looking at.
SA's have very little time to deal with long layers of complexity and not working to enable them to create and modify their own SCAP checks and overrides in a sensible manner is going to continue the battle between the Security and Ops/Dev teams.
What I need, and I know is being worked on in fits, is the ability to not just have profiles, but to be able to directly override various check mechanisms.
In this manner, a very small profile could be noted as compatible with the main profile version X.Y.Z but also have a small data stream that would allow for the following capabilities:
1) Direct replacement of OVAL checks (because I do it my way, per the written documentation) 2) Addition to the checks...if RHEL, or CentOS, or Fedora, or Whatever.... -> OVAL 3) Custom remediation -> I love that you want me to have a broken PAM config for my environment, but I don't want one, thanks
This, in theory, combined with a profile, would allow very small, modular segments to be written that could apply to VMs, Docker Containers, whatever. Basically, anything that is a proper subset, with extensions, of something else.
Something else that would be useful is to push the base structure of the XML databases to 3NF with association tables. While it would be a lot of work, the SCAP content is pretty much directly a database structure and would be *much* easier to manipulate if the relationships were not bound to the original files.
I 100% understand that you can fork the entire standard into another block every time you want to change something but, as history has shown, this way lies upkeep madness and promotes inconsistency across the entire environment.
If you want to be extreme about it, vendors could start setting up SCAP microservices against a standard that would allow for on the fly composition of local Data Streams where all content was twice validated before application.
The SSG, while awesome, is suffering from usability issues that is driving incompatible change at the local organization level pretty much everywhere that I've gone. At some point it's just too much work to keep merging in arbitrary upstream changes to large bases and actually know that you're getting it right. We need more abstract composition ability.
Source: Keep trying to do it my way without forking the entire SSG project and keep failing.
Thanks,
Trevor
On Fri, Oct 21, 2016 at 1:15 PM, Radzykewycz, T (Radzy) <radzy@windriver.com
wrote:
From: Brent Kimberley Brent.Kimberley@Durham.ca 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.
Enjoy!
-- radzy _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
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)
-----Original Message----- From: Radzykewycz, T (Radzy) [mailto:radzy@windriver.com] Sent: Friday, October 21, 2016 1:16 PM To: scap-security-guide@lists.fedorahosted.org Subject: RE: VMs, containers vs. bare-metal machines in SSG
From: Brent Kimberley Brent.Kimberley@Durham.ca 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.
Enjoy!
-- radzy _______________________________________________ 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.
The last XCCDF is: one XCCDF for OS intersection net (min)
Whereas functionality at risk of eclipse is max - (OS intersection net )
-----Original Message----- From: Brent Kimberley Sent: Wednesday, November 2, 2016 3:52 PM To: scap-security-guide@lists.fedorahosted.org Subject: RE: VMs, containers vs. bare-metal machines in SSG
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)
-----Original Message----- From: Radzykewycz, T (Radzy) [mailto:radzy@windriver.com] Sent: Friday, October 21, 2016 1:16 PM To: scap-security-guide@lists.fedorahosted.org Subject: RE: VMs, containers vs. bare-metal machines in SSG
From: Brent Kimberley Brent.Kimberley@Durham.ca 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.
Enjoy!
-- radzy _______________________________________________ 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.
scap-security-guide@lists.fedorahosted.org
-
Brent Kimberley -
Radzykewycz, T (Radzy) -
Trevor Vaughan