RE: Interested in a SCAP Security Guide / STIG hack session? - scap-security-guide - Fedora mailing-lists

25 Feb 2013

      I like the idea about the session.  Be careful in any advertising of using the word "conference".  I know at DISA, with the pending sequestration/furlough, all conference attendance has been halted.
-----Original Message-----
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of scap-security-guide-request@lists.fedorahosted.org
Sent: Monday, February 25, 2013 8:23 AM
To: scap-security-guide@lists.fedorahosted.org
Subject: scap-security-guide Digest, Vol 18, Issue 28
Send scap-security-guide mailing list submissions to
    scap-security-guide@lists.fedorahosted.org
To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
or, via email, send a message with subject or body 'help' to
    scap-security-guide-request@lists.fedorahosted.org
You can reach the person managing the list at
    scap-security-guide-owner@lists.fedorahosted.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of scap-security-guide digest..."
Today's Topics:
1. Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
      XCCDF	1.1.4 schema URI (Shawn Wells)
   2. Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
      XCCDF	1.1.4 schema URI (Gary Gapinski)
   3. Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
      XCCDF	1.1.4 schema URI (Gary Gapinski)
   4. Re: [PATCH] [RFC] Modularized the fix scripts (Jeffrey Blank)
   5. Re: [PATCH] [RFC] Modularized the fix scripts (Jeffrey Blank)
   6. Re: Interested in a SCAP Security Guide / STIG hack session?
      (Jeffrey Blank)
   7. Interested in a SCAP Security Guide / STIG hack session?
      (Saxon, William G CIV SPAWARSYSCEN-ATLANTIC, 58810)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Feb 2013 22:34:56 -0500
From: Shawn Wells shawn@redhat.com
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
    XCCDF	1.1.4 schema URI
Message-ID: 5126E760.6010103@redhat.com
Content-Type: text/plain; charset=UTF-8; format=flowed
On 2/21/13 8:42 PM, Gary Gapinski wrote:
...
-<Benchmark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns:xhtml="http://www.w3.org/1999/xhtml"  xmlns:dc="http://purl.org/dc/elements/1.1/"  id="RHEL-6" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 xccdf-1.1.4.xsd"  resolved="false" xml:lang="en-US" >
+<Benchmark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns:xhtml="http://www.w3.org/1999/xhtml"  xmlns:dc="http://purl.org/dc/elements/1.1/"  id="RHEL-6" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 http://scap.nist.gov/schema/xccdf/1.1/xccdf-1.1.4.xsd"  resolved="false" xml:lang="en-US" >
The new schemaLocation has two URLs in it (but you're right, that needs 
to be http://scap.nist.gov/schema/xccdf/1.1/xccdf-1.1.4.xsd)
------------------------------
Message: 2
Date: Thu, 21 Feb 2013 22:46:26 -0500
From: Gary Gapinski Gapinski@nasa.gov
To: "scap-security-guide@lists.fedorahosted.org"
    scap-security-guide@lists.fedorahosted.org
Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
    XCCDF	1.1.4 schema URI
Message-ID: 5126EA12.8070901@nasa.gov
Content-Type: text/plain; charset="UTF-8"
On 02/21/2013 10:34 PM, Shawn Wells wrote:
...
The new schemaLocation has two URLs in it
Not sure what you mean by this. The first space-separated URI is the
namespace; the second is the associated schema.
------------------------------
Message: 3
Date: Thu, 21 Feb 2013 22:49:21 -0500
From: Gary Gapinski Gapinski@nasa.gov
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
    XCCDF	1.1.4 schema URI
Message-ID: 5126EAC1.3050902@nasa.gov
Content-Type: text/plain; charset="UTF-8"
On 02/21/2013 10:46 PM, Gary Gapinski wrote:
...
On 02/21/2013 10:34 PM, Shawn Wells wrote:
...
The new schemaLocation has two URLs in it
Not sure what you mean by this. The first space-separated URI is the
namespace; the second is the associated schema.
The diff is not showing proper old and new.
The old had xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1
xccdf-1.1.4.xsd".
The new has xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1
http://scap.nist.gov/schema/xccdf/1.1/xccdf-1.1.4.xsd".
------------------------------
Message: 4
Date: Sun, 24 Feb 2013 11:14:51 -0500
From: Jeffrey Blank blank@eclipse.ncsc.mil
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: [PATCH] [RFC] Modularized the fix scripts
Message-ID: 512A3C7B.5060109@eclipse.ncsc.mil
Content-Type: text/plain; charset=UTF-8
...
It may be long-term necessary to consider alternatives.
True in so very many ways.  But I'd be more concerned that XCCDF is
likely to ossify irrevocably, given its current position with standards
bodies.
...
If it is now close to the time when a namespace (or two) for
scap-security-guide fragments, and a schema for those, can be
considered, I'd be willing to put up a trial balloon.
I'd be happy to look at it, but I have serious doubts that it's actually
a good idea.  The ability to do some arbitrary things (which such
formalization is likely to forbid or inhibit) is very valuable, such as
macros for common phrases.  Schemas are requirements levied upon content
developers.
I also want to keep the content language as simple as possible, and as
even Shawn's brief confusion indicated, XML namespaces don't exactly
make things more accessible.
Removing all namespaces from the (undefined) content creation language
was quite intentional.  To the extent possible, I wanted to end up in a
place where the content creation language could be "monkey-see,
monkey-do." (Even though that clearly hasn't worked out, I'd at least
prefer that it not be endlessly verbose to higher primates).
...
This ultimately
becomes an exercise in avoiding arbitrary limitations of XCCDF by
allowing reasonable and useful expression ahead of (SP 800-126 rev 1)
XCCDF generation. As in variables that end up manifest in checks and
fixes. Ideally, the same meaning of value/variable (e.g., password
length) in all venues.
That is sane, and exactly what my little scripts actually are trying to
achieve (well, technically, undo for final output) in their "linking" phase.
...
I don't think XCCDF should be levied on content authors, rather,
something useful that can be competently turned into XCCDF should be
provided. Accompanied by a schema. It can be better than XCCDF; the
shortcomings of such a transformation can be noted so that the
proto-XCCDF/OVAL content can be dumbed-down as and if necessary.
Yes, as usual, yes.  But I'd still prioritize vetting and creation of
(openly-available) content in the deficient (or undefined) languages
we've got now.  It remains shocking to me how little high-quality SCAP
content there is, yet there seem to be thousands of people at these
conferences...
------------------------------
Message: 5
Date: Sun, 24 Feb 2013 12:09:50 -0500
From: Jeffrey Blank blank@eclipse.ncsc.mil
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: [PATCH] [RFC] Modularized the fix scripts
Message-ID: 512A495E.3040607@eclipse.ncsc.mil
Content-Type: text/plain; charset=UTF-8
...
tag is basically just a reference to a <value> somewhere.  I know
I've caught some flack for the JSON usage, but it was a practical way
to get things implemented.  Given that we can't use arbitrary XML to
keep the document all-XML, and that whatever we do within a <fix> tag
ends up being pseudo-standard at best, JSON has proven to be a
lightweight option for use as an intermediate solution.
We can do whatever we want with XML in our authoring language, and we're
not writing in any particular schema (as Gary has pointed out).  As far
as I'm concerned, final output should be valid XCCDF, but you can do
anything you want with XML until then.  (And tooling that prepares the
fixes for execution can take care of preparing the environment to run
the bash script, such as instantiating environment variables.)
And your perception is correct: attempts to introduce JSON (or Perl)
into SSG should expect serious resistance.  Had we started all
development in JSON, then I'd say the same about XML.
...
I know there was a discussion about having a better way to uniquely
identify fixes besides just a path to a script on a system.  Possibly
some UUID which in turn maps to a script somewhere?
I want fixes to identify what they're for (by referencing a Rule id),
not the other way around.  What <fix> to run is not the concern of the
baseline or guidance creator, and remediation is not the raison d'etre
of scap-security-guide.  But we're happy to work closely together and
include simple bash fixes inside the project.
In essence, I would encourage remediation developers to refer to items
in the input/system and input/services (and input/profiles) directories,
and develop tooling that permits combination and integration with the
content generated from there.
...
If there's a
standards-based way to do this it would be great, but with how
immature the <fix> aspect of XCCDF is I'm not sure if that option is
there.  Having some pseudo-standard in place here gives us
flexibility to add fields or metadata as needed without invalidating
the XCCDF document, whereas if there were raw BASH content in the
<fix> tag we would not have that sort of flexibility.
My motivation to look into the "right" way to do remediation will be far
higher when someone can assure me that the OVAL has actually been QA'ed.
 Could you advise on current status of this?  Is this still a dependency
of CLIP?
...
I'll chime in again with an opinion that I think BASH and non-XCCDF
content should live in files external to the XCCDF, and simply be
referenced from the XCCDF.
Absolutely!  Like we do now in SSG, for development.
I'm assuming there will be one XCCDF file from SSG with simple bash
fixes, and one without.  In fact, that reminds me to adjust the Makefile
so that what is perceived as the "main" one does not include fixes.
...
I'll chime in again with an opinion that I think BASH and non-XCCDF
content should live in files external to the XCCDF, and simply be
referenced from the XCCDF.  I know this is a discussion that's been
had a few times, and this may be a battle I've already lost, so kick
me if I shouldn't be bringing this back up.
Definitely -- no development of <fix> tags is occurring inline with the
main content. The fix tags live inside their own directories away from
where the usual XCCDF content is written.
I don't expect issuers of baselines to include <fix> tags, and the act
of adding fixes is intentionally seperable/separated.  It may be
possible to ship one version of the XCCDF file with bash fixes, and some
tooling may be able to process this, but this shouldn't preclude any
other approaches.
------------------------------
Message: 6
Date: Sun, 24 Feb 2013 13:54:39 -0500
From: Jeffrey Blank blank@eclipse.ncsc.mil
To: scap-security-guide@lists.fedorahosted.org
Subject: Re: Interested in a SCAP Security Guide / STIG hack session?
Message-ID: 512A61EF.5040002@eclipse.ncsc.mil
Content-Type: text/plain; charset=UTF-8
Let DISA FSO know if there are problems in what they've shipped in their
official content, using their established process.
Given that the SSG's intention is to be an upstream producer of content
that meets their requirements, it may also make sense to notify us if we
have the same problem (assuming it hasn't already been fixed upstream).
On 02/20/2013 02:24 PM, Robert Sanders wrote:
...
I think this is an *outstanding* idea.  Most of my experience with
the STIGs was tied to the old SRR scripts, and the learning curve on
the new format has been steep.  I'd also suggest to cover topics that
have been addressed here a bit such as : False positives (both
identification of said and how to refer suggestions/fixes back to
SSG/Disa)
-Rob
...
-----Original Message----- From:
scap-security-guide-bounces@lists.fedorahosted.org 
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On
Behalf Of Shawn Wells Sent: Wednesday, February 20, 2013 2:06 PM 
To: scap-security-guide@lists.fedorahosted.org Subject: Interested
in a SCAP Security Guide / STIG hack session?
Over the past few months there has been a good bit of off-list
chatting about hosting a hack session/meetup for the SSG. With the
recent DISA publication of the draft STIG the timing seems right.
So, would anyone be interested in meeting up where we could do
things like: - Share knowledge on the installation of SSG. How do I
 run a scan? How do I customize settings? How do I get a report
that I can show my ISSE/ISSM? How do I generate a Certification
Test Plan, based off my customized rules?

Go a bit deeper, and understand how the code works. What is

XCCDF? OVAL? OCIL? How do I add my own custom rules?

Prep your environment to submit patches back to the SSG. How do I

setup git? How do I create a FedoraHosted account?

Chat about what additional profiles are needed. How should we

handle CNSSI 12-53? What about PCI compliance?
I'd like to specifically go through the RHEL6 STIG content, 
performing scans and generating C&A artifacts. Part of the idea on
this would be attendees could take this setup home and use it to
start providing feedback against the draft STIG.
What do you guys think? Good idea? What topics should be covered?
Jeff and I were chatting, and we'll likely be able to host either
at the Red Hat office in Tysons Corner, VA, or at the IAD Mobility
Lab in Annapolis Junction, MD. And there's nothing saying we
wouldn't do two sessions, one per location.... we can work all that
out once topics/agenda get sorted. 
_______________________________________________ scap-security-guide
mailing list scap-security-guide@lists.fedorahosted.org 
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
...
_______________________________________________
...
scap-security-guide mailing list 
scap-security-guide@lists.fedorahosted.org 
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
------------------------------
Message: 7
Date: Mon, 25 Feb 2013 08:22:42 -0500
From: "Saxon, William G CIV SPAWARSYSCEN-ATLANTIC, 58810"
    bill.saxon@navy.mil
To: scap-security-guide@lists.fedorahosted.org
Subject: Interested in a SCAP Security Guide / STIG hack session?
Message-ID:
    9E3670CE3E72114D8FDF5E0384EC030901966DE9@naeanrfkez38v.nadsusea.nads.navy.mil

Content-Type: text/plain;	charset="US-ASCII"
Yes, I'd be very interested in such a conference.  As I read through
your list of items, I kept thinking..."Yes, I need that".  I'm in
Norfolk, Virginia and would prefer Tysons, Corner.
I would need some lead time to get funding in place as funding is
difficult these days.
If you plan to do this, how will it be advertised...I want to make sure
I hear about it.
Oh yes...the sooner the better.
Thanks,
Bill
William G. (Bill) Saxon
ND-0854-04 SPAWAR Atlantic
NMCI email:   bill.saxon@navy.mil (Preferred)
SPAWAR email: saxon@spawar.navy.mil
Desk:         757.443.0359
Cell:         757.292.3237
Chat:         william.saxon@chat.dco.dod.mil
Message: 4
Date: Wed, 20 Feb 2013 14:06:13 -0500
From: Shawn Wells shawn@redhat.com
To: scap-security-guide@lists.fedorahosted.org
Subject: Interested in a SCAP Security Guide / STIG hack session?
Message-ID: 51251EA5.3010404@redhat.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Over the past few months there has been a good bit of off-list chatting
about hosting a hack session/meetup for the SSG. With the recent DISA
publication of the draft STIG the timing seems right.
So, would anyone be interested in meeting up where we could do things
like:
     - Share knowledge on the installation of SSG. How do I run a scan? 
How do I customize settings? How do I get a report that I can show my
ISSE/ISSM? How do I generate a Certification Test Plan, based off my
customized rules?
- Go a bit deeper, and understand how the code works. What is
XCCDF? OVAL? OCIL? How do I add my own custom rules?
- Prep your environment to submit patches back to the SSG. How do I
setup git? How do I create a FedoraHosted account?
- Chat about what additional profiles are needed. How should we
handle CNSSI 12-53? What about PCI compliance?
I'd like to specifically go through the RHEL6 STIG content, performing 
scans and generating C&A artifacts. Part of the idea on this would be 
attendees could take this setup home and use it to start providing 
feedback against the draft STIG.
What do you guys think? Good idea? What topics should be covered?
Jeff and I were chatting, and we'll likely be able to host either at the
Red Hat office in Tysons Corner, VA, or at the IAD Mobility Lab in 
Annapolis Junction, MD. And there's nothing saying we wouldn't do two 
sessions, one per location.... we can work all that out once 
topics/agenda get sorted.
------------------------------
Message: 5
Date: Wed, 20 Feb 2013 19:24:03 +0000
From: Robert Sanders rsanders@TrustedCS.com
To: "'scap-security-guide@lists.fedorahosted.org'"
    scap-security-guide@lists.fedorahosted.org
Subject: RE: Interested in a SCAP Security Guide / STIG hack session?
Message-ID:
    848FB1215E2AD643A5E10D906091D3FB5B7A66@TCSEXCH1.tcs-sec.com
Content-Type: text/plain; charset="us-ascii"
I think this is an *outstanding* idea.  Most of my experience with the
STIGs was tied to the old SRR scripts, and the learning curve on the new
format has been steep.  I'd also suggest to cover topics that have been
addressed here a bit such as :
  False positives (both identification of said and how to refer
suggestions/fixes back to SSG/Disa)
-Rob
------------------------------
_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
End of scap-security-guide Digest, Vol 18, Issue 28
***************************************************