[PATCH 00/15] Adding new profile, C2S

Jeffrey Blank blank at eclipse.ncsc.mil
Tue Apr 15 01:35:02 UTC 2014


Okay, I'll play, and I appreciate the elaboration of the larger
picture.  Can you lend any insight into the process by which these
requirements were created?  Were they discussed with the vendor?
1-year ago suggests that some things may have evolved since then.
Maybe the customer would like to evolve this Profile, too.

Please do not presume to understand my personal perspective.  The
customer here wasn't entirely clear to me until you said so, and in
fact it's quite exciting.  One of the goals of scap-security-guide
(though rarely stated) was to bring clarity to what constitutes
security-relevant compliance checks.  Having hundreds of Rules dilutes
the ones that are important.  Like patching.  The last week in
particular shows that that particular Rule may be more important than
the whole other lot.  This is the basis for my sensitivity to adding
Rules.

Let's chat a little later to sort out when I land.  I had meant to
indicate flexibility with my earlier post, and I'm sure we can add
some of these things at least provisionally and then plan for a
conversation with the Profile owner to get completely on the same
page.

We want a community that's as big as possible and as open as possible,
delivering the best possible security automation content.  Please
schedule some time on my calendar for next week.  I believe that Red
Hat's own perspective on the matter should be discussed with the
customer as well.  Most people are pretty reasonable in a dialogue --
this just showed up in quite a hurry, but we'll play along.






On Mon, Apr 14, 2014 at 2:47 PM, Shawn Wells <shawn at redhat.com> wrote:
> On 4/14/14, 2:26 PM, Shawn Wells wrote:
>
> On 4/14/14, 2:23 PM, Jeffrey Blank wrote:
>
> NACK to all (except typos), but let's discuss in person tomorrow
> morning at Summit.
>
> Many of these were removed or are not in RHEL 6 to begin with.  Or are
> handled in other ways.  I'd like to have a discussion with the driver
> for this Profile, since I believe its intentions are already achieved
> through existing Rules.
>
>
> Please elaborate on this.
>
> You seem to be nack'ing on your personal perspective that CIA's Linux
> baseline doesn't match your view on what a baseline should be.
>
>
>
> SSG represents a body of controls through which interested parties can form
> their own profiles. A significant part of SSG's value is that profile owners
> need not agree on security controls: by definition the DoD baseline (e.g.
> the STIG) can be different from Ft Meade's baseline (e.g. CS2), which is
> further different than CIA's (via C2S). The C2S patches do not alter any
> existing baselines, so the basis of your objection is unclear.
>
> There's certainly value to working with profile owners to evolve their
> underlying requirements, however that reflects future initiatives. The
> submitted C2S profile reflects requirements as they are today. I agree many
> of their requirements are... interesting... as reflected in the <rationale>
> tag here:
> https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/005233.html
>
> With that said, the C2S baseline is the current U.S. Government mandated
> security control list for all Linux instances within the Commercial Cloud.
> CIA established the C2s baseline requirements long ago (1yr+?) through a
> formal RFP which was awarded earlier this year. These are C2S's
> requirements, period. Lack of the C2S profile will alienate tenants of C2S,
> which is most of the U.S. Intelligence Community, and make SSG irrelevant to
> them.
>
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>


More information about the scap-security-guide mailing list