Interested in a SCAP Security Guide / STIG hack session?

Mackanick, Jason W CIV (US) jason.w.mackanick.civ at mail.mil
Mon Feb 25 14:33:06 UTC 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 at lists.fedorahosted.org [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of scap-security-guide-request at lists.fedorahosted.org
Sent: Monday, February 25, 2013 8:23 AM
To: scap-security-guide at lists.fedorahosted.org
Subject: scap-security-guide Digest, Vol 18, Issue 28

Send scap-security-guide mailing list submissions to
	scap-security-guide at 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 at lists.fedorahosted.org

You can reach the person managing the list at
	scap-security-guide-owner at 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 at redhat.com>
To: scap-security-guide at lists.fedorahosted.org
Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
	XCCDF	1.1.4 schema URI
Message-ID: <5126E760.6010103 at 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 at nasa.gov>
To: "scap-security-guide at lists.fedorahosted.org"
	<scap-security-guide at lists.fedorahosted.org>
Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
	XCCDF	1.1.4 schema URI
Message-ID: <5126EA12.8070901 at 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 at nasa.gov>
To: <scap-security-guide at lists.fedorahosted.org>
Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical"
	XCCDF	1.1.4 schema URI
Message-ID: <5126EAC1.3050902 at 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 at eclipse.ncsc.mil>
To: scap-security-guide at lists.fedorahosted.org
Subject: Re: [PATCH] [RFC] Modularized the fix scripts
Message-ID: <512A3C7B.5060109 at 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 at eclipse.ncsc.mil>
To: scap-security-guide at lists.fedorahosted.org
Subject: Re: [PATCH] [RFC] Modularized the fix scripts
Message-ID: <512A495E.3040607 at 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 at eclipse.ncsc.mil>
To: scap-security-guide at lists.fedorahosted.org
Subject: Re: Interested in a SCAP Security Guide / STIG hack session?
Message-ID: <512A61EF.5040002 at 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 at lists.fedorahosted.org 
>> [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On
>> Behalf Of Shawn Wells Sent: Wednesday, February 20, 2013 2:06 PM 
>> To: scap-security-guide at 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 at lists.fedorahosted.org 
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>>
>
>> 
_______________________________________________
> scap-security-guide mailing list 
> scap-security-guide at 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 at navy.mil>
To: <scap-security-guide at lists.fedorahosted.org>
Subject: Interested in a SCAP Security Guide / STIG hack session?
Message-ID:
	<9E3670CE3E72114D8FDF5E0384EC030901966DE9 at 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 at navy.mil (Preferred)
SPAWAR email: saxon at spawar.navy.mil
Desk:         757.443.0359
Cell:         757.292.3237
Chat:         william.saxon at chat.dco.dod.mil

Message: 4
Date: Wed, 20 Feb 2013 14:06:13 -0500
From: Shawn Wells <shawn at redhat.com>
To: scap-security-guide at lists.fedorahosted.org
Subject: Interested in a SCAP Security Guide / STIG hack session?
Message-ID: <51251EA5.3010404 at 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 at TrustedCS.com>
To: "'scap-security-guide at lists.fedorahosted.org'"
	<scap-security-guide at lists.fedorahosted.org>
Subject: RE: Interested in a SCAP Security Guide / STIG hack session?
Message-ID:
	<848FB1215E2AD643A5E10D906091D3FB5B7A66 at 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 at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


End of scap-security-guide Digest, Vol 18, Issue 28
***************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5649 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130225/5ff56ffe/attachment.bin>


More information about the scap-security-guide mailing list