Possibility of Fedora SCAP content to be served by SCAP security guide repository (either as subdirectory or via separated branch)?

Moessbauer, David david.moessbauer at progeny.net
Tue Sep 3 18:22:05 UTC 2013


Is there a matrix that can be referenced that will map the DISA STIG-ID (or Group ID) to the CCE Audit IDs?  ...or any other mapping that can be deduced

In Example:
Group ID (Vulid):  V-38487
Group Title:  SRG-OS-000103
Rule ID:  SV-50288r1_rule
Rule Version (STIG-ID):  RHEL-06-000015


v/r
 
David Moessbauer
(410) 627-5633 (M)
 
The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.


-----Original Message-----
From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of Jan Lieskovsky
Sent: Tuesday, September 03, 2013 1:04 PM
To: Shawn Wells
Cc: Dhirendra Kholia; scap-security-guide at lists.fedorahosted.org
Subject: (nwl) Re: Possibility of Fedora SCAP content to be served by SCAP security guide repository (either as subdirectory or via separated branch)?

Hi Shawn,

  thank you for your reply.

> 
> On 9/3/13 9:26 AM, Jan Lieskovsky wrote:
> > Hello Jeff, Shawn, SCAP security guide people,
> >
> >    [Sorry if this is not the appropriate place to discuss the topic 
> > below. If so, kindly direct me to proper contact people. Thank you.]
> The public mailing list is *absolutely* the desired location! Thanks 
> for moving this discussion to on-list!

Ok, good (wasn't sure not to leak something prematurely). But transparency is definitely welcomed.

> 
> 
> 
> >    {Sorry for such a long post, but got much information to share.}
> >
> > We have internally discussed possibility to start creating SCAP 
> > content for Fedora distribution. Snippet of previous conversation(s) below:
> >
> > Subj = 	Fedora SCAP content adoption [was: Re: Challenges in SCAP
> > adoption]:
> > ====================================================================
> > ========
> > Hello guys,
> >
> >    please find below draft we have agreed upon so far how Fedora 
> > SCAP content next steps should look like (from discussion at 
> > #openscap):
> >
> > #1 Create Fedora subdirectory (preferably with Fedora version 
> > subdirectory
> > yet)
> >     in the upstream SSG git repository,
> > #2 Create new Fedora package (to be posted for review and maintained by
> >     me) to be generated based on the content of that directory,
> > #3 Content provided by this package should be the primary source of
> >     content, when doing oscap scans on Fedora hosts in the future.
> >
> > For the content of that Fedora directory itself:
> > - Red Hat Security Technologies Team point of view:
> >    * to have 3-rd party standardized content, which would be subset
> >    of content we currently have for RHEL-6 to be possible to scan Fedora
> >    hosts
> >    too,
> > - Red Hat Product Security Team point of view:
> >    * to have content / policy / rules to check issues interesting from
> >    security point of view (like the recent Amazon rootpw kickstart issue
> >    was)
> >
> > The standardized Fedora content would be generated and maintained by me.
> > For the security issues content the maintainer needs to be agreed 
> > upon yet (probably Dhiru will take this responsibility?)
> >
> > Questions / comments welcome.
> >
> > Thank you && Regards, Jan.
> > --
> > Jan iankko Lieskovsky / Red Hat Security Technologies Team
> >
> > Shawn Wells has replied to this with the following (selected only 
> > relevant bits from the reply):
> > ====================================================================
> > ============
> >> For the content of that Fedora directory itself:
> >> - Red Hat Security Technologies Team point of view:
> >>     * to have 3-rd party standardized content, which would be subset
> >>     of content we currently have for RHEL-6 to be possible to scan Fedora
> >>     hosts
> >>     too,
> > As a starting point, the "common" profile from RHEL6 may be of interest.
> > It reflects rules we've found to be consistent across all baselines 
> > (STIG, USGCB, FISMA) however has generic refine values for things 
> > like password length. Code:
> >    
> > https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6
> > /input/profiles/common.xml
> >
> > Below is my proposal regarding initial Fedora directory content, as 
> > sent to Shawn in private message:
> > ====================================================================
> > ================
> > * Part #1 regarding repository content:
> >
> > I have had brief look at the common profile (thank you for that 
> > direction Shawn):
> > [1]
> > https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6
> > /input/profiles/common.xml
> >
> > but prior proposing any actual content changes in the SSG 
> > repository, wanted to check "how things works / are expected to 
> > work" (mainly in the sense of relation with scap-security-guide 
> > mailing list people) with you.
> >
> > I can create Fedora package spec / src.rpm proposal - when creating 
> > this one i think Fedora subdirectory should follow the common 
> > directory structure, i.e.:
> > * distro/
> >      * input
> >      * output
> >      * references
> >      * transforms
> >      * utils
> >
> > subdirectories, the Makefile and README files.
> >
> > For the beginning i would say the 'input' subdir should have at 
> > least 'intro'
> > subdir, and guide.xml && guide.xslt files (of course 'profiles', 'checks'
> > etc.
> > to come later).
> >
> > These are all technical things, i should be able to handle (submit 
> > that Fedora package for review, when it's time comes etc.).
> 
> Directory structure makes sense, and would provide consistency for 
> existing content authors.

To be consistent was the intention (not to put another blocks wrt to existing understanding / quick start up).

> 
> Currently there is a single RPM which deploys content for both JBoss 
> and RHEL6. Is it preferred to have a unique Fedora content RPM, or 
> should the existing RPM be modified to include Fedora content? Given the 'EPEL'
> nature of the existing RPM, I'm OK with combining things though I 
> don't know the subtleties of the Fedora packaging regulations.

Separate RPM would be preferred afaics (RHEL and Fedora have different release cycles. Right now not definitely sure this might be a problem in the future, but better to start as separate content for any case).

> 
> 
> > But what i mainly wanted to check with you being how i am expected 
> > to communicate these changes on scap-security-guide mailing list. 
> > Should we first communicate this / schedule a meeting with Jeffrey 
> > Blank regarding this? Will you communicate this with Jeffrey? Or 
> > should these intentions be communicated on SSG mailing list first? 
> > Shawn, your guidance here would be appreciated.
> Jeff & I are certainly stakeholders, but we're part of a much larger 
> and active community. Personally, I'd much prefer to have transparent 
> conversations in the open wherever possible.

Sure, understandable (was just afraid not to leak something - still new to this list).

> 
> > I think once this skeleton of Fedora directory is agreed upon, we 
> > can follow up with discussion wrt to upcoming content (assuming to 
> > be based on subset of 'common.xml'
> > profile checks).
> >
> > To summary:
> > ===========
> > * after internal mailing communication we agreed on it's time to 
> > start creating
> >    Fedora SCAP content,
> >
> > * the current proposal is this content to live in SCAP security 
> > guide repository
> >    under dedicated Fedora subdirectory (or under dedicated git 
> > branch),
> We thought about creating branches for the various content platforms 
> (e.g. RHEL6, RHEVM, JBossEAP) though the added complexity didn't seem 
> worth it. Right now we have a single git branch, vs a "dev," "stable"
> etc setup. This shouldn't be thought of set in stone... best practice 
> ideas from your dev perspective would be most welcome!

We have talked (within our team) about this a bit yesterday. While subdirectory approach might seem easier, git branch way could simplify cloning the future
RHEL-6 content (would merge instead of copy manually). Again, right now not completely sure a moment in the future will come the subdirectory approach to show as bottleneck. More trying to think what can go wrong if we use subdirectory approach, than truly stand on it needs to be a git branch based way.

> 
> 
> > * we can / will handle the technical issues (provide content for the 
> > subdirectory
> >    [which after common SSG patch approval process would be committed into
> >    SSG repo],
> >    create directory structure, create package for Fedora distribution,
> >    handle it's
> >    review process etc. when it's time comes etc.,
> >
> > * but prior actual sending of initial patch (realizing the above 
> > proposals),
> >    wanted to communicate these intentions with you to see if you / SSG
> >    members
> >    would have some objections against this to be realized. If so, please
> >    let us
> >    know (also in case there is different procedure expected to be pursued,
> >    when proposing such changes, let us know which one that is).
> With the RHEL6 content there are several people trusted with ack'ing 
> patchsets. How is Fedora patch sign-off envisioned?

To be honest this is not clear yet. Maybe it would help if you could clarify why they are trusted for RHEL-6 - like they are approved by 3-rd party or they have proven to understand the underlying RHEL-6 environment in a way, they can be considered authorities?

Once this is clear, we can sketch how to manage the same for Fedora content.

> 
> Meaning, do you envision "community signoff" -- e.g. standard 3rd 
> party review process, but anyone in the community can ack -- or should 
> ack's be received through yourself/Josh/Dhirendrea before a push?

I am not that far in understanding SCAP / OVAL / XCCDF content yet, I would propose myself to do the review. Of course, something else is validity / correctness of OVAL definitions taking into account the nuances of a Fedora system (IOW how to get some test to work correctly for Fedora system) - I could offer my help here.

But for what is worthy regarding general XCCDF validity, (I think) we would definitely welcome SCAP security guide community help here.

> 

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team _______________________________________________
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