[prev in list] [next in list] [prev in thread] [next in thread]
List: scap-security-guide
Subject: Re: VMs, containers vs. bare-metal machines in SSG
From: Trevor Vaughan <tvaughan () onyxpoint ! com>
Date: 2016-10-28 13:35:15
Message-ID: CANs+FoVQ=nRAREsCgdAbMVnhU+wUjw_cjGA1VJXRzPoh8soarw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
[Attachment #5 (text/html)]
<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1) Direct replacement of OVAL checks (because \
I do it my way, per the written documentation)</div><div>2) Addition to the \
checks...if RHEL, or CentOS, or Fedora, or Whatever.... -> OVAL</div><div>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</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Source: Keep trying to do it my way without forking \
the entire SSG project and keep \
failing.</div><div><br></div><div>Thanks,</div><div><br></div><div>Trevor \
</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 21, \
2016 at 1:15 PM, Radzykewycz, T (Radzy) <span dir="ltr"><<a \
href="mailto:radzy@windriver.com" target="_blank">radzy@windriver.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">> From: Brent Kimberley \
<Brent.Kimberley@Durham.ca><br> <span class="">> As opposed to writing one \
XCCDF, why not write one XCCDF per<br> > point of interest (inside the container \
of interest, inside the<br> > OS but outside the container of interest, ...) - \
until upstream<br> > standards address Origin, Point (in SpaceTime), Frame of \
Reference,<br> > ... for a cyber-physical assembly?<br>
<br>
</span>When I start working on our container environment, I expect I<br>
need to write custom XCCDF and custom OVAL for some of the checks.<br>
Some of the management may be done in the container, but I expect<br>
most to be done in the underlying host. So paths may be different,<br>
which would lead to either more complex OVAL with parameterization,<br>
or duplication of the OVAL content.<br>
<br>
And as implied elsewhere, the XCCDF needs to be modified to<br>
indicate the correct information for the environment.<br>
<br>
Enjoy!<br>
<span class="HOEnZb"><font color="#888888"><br>
-- radzy<br>
</font></span><div class="HOEnZb"><div \
class="h5">______________________________<wbr>_________________<br> \
scap-security-guide mailing list -- <a \
href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.<wbr>fedorahosted.org</a><br>
To unsubscribe send an email to <a \
href="mailto:scap-security-guide-leave@lists.fedorahosted.org">scap-security-guide-leave@<wbr>lists.fedorahosted.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div \
dir="ltr"><div>Trevor Vaughan<br>Vice President, Onyx Point, Inc<br></div><div>(410) \
541-6699 x788<br></div><div><br>-- This account not approved for unencrypted \
proprietary information --</div></div></div></div></div> </div>
[Attachment #6 (text/plain)]
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic