scap-security-guide February 2013

scap-security-guide@lists.fedorahosted.org

24 participants
50 discussions

note for the USGCB tickets
by Jeffrey Blank 11 Jul '13

11 Jul '13

Shawn (et al), The ticketing system shows me you'd opened up a bunch of tickets to add a "New rule" for items which were in the old RHEL 5 USGCB profile. Okay, great, this helps with ensuring there is continuation of that profile/baseline with some consistency. A few notes: 1) I've been able to close some of the tickets as "fixed", providing explanation as to why. Some of them are being handled through other mechanisms for RHEL 6. 2) If anybody starts executing on the other tickets, the goal is NOT to add new rules as the ticket says, but rather to conduct investigation to see if the Rule is applicable to RHEL 6 in the same way it was applicable to RHEL 5. 3) In the ticket titles, there is some of the odd CCE language which talks about disabling/enabling things "as appropriate". That's fine as an identifier (and the RHEL 6 USGCB did use some of this language). However, this style of language, which is intended for neither a human nor a machine, should never appear in the project's XCCDF. (Just in case anybody gets any ideas.) Thanks, Jeff -- ___________________________ Jeffrey Blank 410-854-8675 Technology and Systems Analysis / Network Components NSA Information Assurance

5 10

xsl:attribute: The attribute name 'xmlns' is not allowed.
by Brian Millett 05 Jun '13

05 Jun '13

Hello, I'm trying to get started with making the latest clone from the git repository and I get the following error: [bpm]$ git clone http://git.fedorahosted.org/git/scap-security-guide.gitscap-security-guide Cloning into 'scap-security-guide'... remote: Counting objects: 14016, done. remote: Compressing objects: 100% (5257/5257), done. remote: Total 14016 (delta 10574), reused 10664 (delta 7718) Receiving objects: 100% (14016/14016), 3.18 MiB | 2.17 MiB/s, done. Resolving deltas: 100% (10574/10574), done. [bpm]$ cd scap-security-guide/RHEL6/ [bpm]$ make all xsltproc -o output/rhel6-shorthand.xml input/guide.xslt input/guide.xml xmllint --format --output output/rhel6-shorthand.xml output/rhel6-shorthand.xml xsltproc -o output/unlinked-noprofiles-rhel6-xccdf.xml transforms/shorthand2xccdf.xslt output/rhel6-shorthand.xml compilation error: file transforms/shorthand2xccdf.xslt line 19 element attribute xsl:attribute: The attribute name 'xmlns' is not allowed. make: *** [shorthand2xccdf] Error 5 I've a fedora 18 , x86_64 installation. Any ideas? Thanks. -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

4 6

scap-security-guide v0.1-10 released -- now with JBossEAP5!
by Shawn Wells 01 May '13

01 May '13

Friends, A rebase of the scap-security-guide RPM was *long* overdue! Please see the "Consume" section of the project wiki for download information: https://fedorahosted.org/scap-security-guide/ Highlights of SSG v0.1-10 include: - JBossEAP5 content! Utilizing content from the SCAP Security Guide project, on 29-JAN-2013 Red Hat corporately submitted paperwork to DISA FSO to begin the JBossEAP5 STIG process. SSG v0.1-10 reflects the OCIL, OVAL, and XCCDF content of this submission. Please refer to /usr/share/xml/scap/ssg/guide/JBossEAP5_Guide.html for details. We look forward to your feedback via the SSG mailing list! [1] - `man scap-security-guide` now provides sample usage of the content. - Several bugfixes relating to OVAL content. Many thanks to Brian Millet, Kenneth Stailey, Logan Rodrian, and all other members of the SSG community for the reports and patches! - The RHEL6 STIG profile was renamed "stig-rhel6-server" - A RHEL6 checklist has been included (/usr/share/xml/scap/ssg/guidestig-rhel6-server-guide.html). This outlines what specific rules are currently part of the profile. - A number of updates against NIST 800-53 mappings has been completed. Please see files under /usr/share/xml/scap/ssg/policytables/. [1] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

1 1

[PATCH] Add support for zipfile creation
by Shawn Wells 14 Mar '13

14 Mar '13

6 7

(no subject)
by Kenneth Stailey 01 Mar '13

01 Mar '13

Makefile:67: *** unterminated variable reference. Stop. Even in comments you must terminate variable references. Fix: ]$ git diff diff --git a/Makefile b/Makefile index d2e5e59..3a0f190 100644 --- a/Makefile +++ b/Makefile @@ -71,7 +71,7 @@ zipfile: # to cd into $(RPM_TMPDIR) cp RHEL6/output/ssg-* $(RPM_TOPDIR)/ZIP/ cp JBossEAP5/eap5-* $(RPM_TOPDIR)/ZIP/ - # Originally attempted to `cd $(RPM_TOPDIR/ZIP` and + # Originally attempted to `cd $(RPM_TOPDIR)/ZIP` and # make the zip from there, however it still placed it # at working directory. Should look into this sometime #

3 3

RHEL6 Draft STIG to DIACAP 8500 controls mapping?
by Philip Shuman 01 Mar '13

01 Mar '13

We are currently trying to map 8500 controls to the RHEL6 draft content (either the version from git or DISA's website would work). The RHEL5 STIG benchmark contains references to the IA controls, which allows the auditors to tie each check back to 8500. Here is an example from RedHat_5-V1R1_STIG_Benchmark-xccdf: Rule Title: The operating system must be a supported release. STIG ID: GEN000100 Rule ID: SV-27049r1_rule Vuln ID: V-11940 IA Controls:VIVM-1 Is there any mapping either between RHEL6 and 8500 or even between RHEL6 and RHEL5 that we could use to map these? It seems none of the RHEL6 identifiers in either the build from git or the DISA website are common with the past STIG content. Thanks, Philip

2 4

Interested in a SCAP Security Guide / STIG hack session?
by Saxon, William G CIV SPAWARSYSCEN-ATLANTIC, 58810 25 Feb '13

25 Feb '13

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(a)navy.mil (Preferred) SPAWAR email: saxon(a)spawar.navy.mil Desk: 757.443.0359 Cell: 757.292.3237 Chat: william.saxon(a)chat.dco.dod.mil Message: 4 Date: Wed, 20 Feb 2013 14:06:13 -0500 From: Shawn Wells <shawn(a)redhat.com> To: scap-security-guide(a)lists.fedorahosted.org Subject: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <51251EA5.3010404(a)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(a)TrustedCS.com> To: "'scap-security-guide(a)lists.fedorahosted.org'" <scap-security-guide(a)lists.fedorahosted.org> Subject: RE: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <848FB1215E2AD643A5E10D906091D3FB5B7A66(a)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

2 1

RE: Interested in a SCAP Security Guide / STIG hack session?
by Mackanick, Jason W CIV DISA RE (US) 25 Feb '13

25 Feb '13

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(a)lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of scap-security-guide-request(a)lists.fedorahosted.org Sent: Monday, February 25, 2013 8:23 AM To: scap-security-guide(a)lists.fedorahosted.org Subject: scap-security-guide Digest, Vol 18, Issue 28 Send scap-security-guide mailing list submissions to scap-security-guide(a)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(a)lists.fedorahosted.org You can reach the person managing the list at scap-security-guide-owner(a)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(a)redhat.com> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI Message-ID: <5126E760.6010103(a)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(a)nasa.gov> To: "scap-security-guide(a)lists.fedorahosted.org" <scap-security-guide(a)lists.fedorahosted.org> Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI Message-ID: <5126EA12.8070901(a)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(a)nasa.gov> To: <scap-security-guide(a)lists.fedorahosted.org> Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI Message-ID: <5126EAC1.3050902(a)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(a)eclipse.ncsc.mil> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: [PATCH] [RFC] Modularized the fix scripts Message-ID: <512A3C7B.5060109(a)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(a)eclipse.ncsc.mil> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: [PATCH] [RFC] Modularized the fix scripts Message-ID: <512A495E.3040607(a)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(a)eclipse.ncsc.mil> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <512A61EF.5040002(a)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(a)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(a)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(a)lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >> > >> _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)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(a)navy.mil> To: <scap-security-guide(a)lists.fedorahosted.org> Subject: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <9E3670CE3E72114D8FDF5E0384EC030901966DE9(a)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(a)navy.mil (Preferred) SPAWAR email: saxon(a)spawar.navy.mil Desk: 757.443.0359 Cell: 757.292.3237 Chat: william.saxon(a)chat.dco.dod.mil Message: 4 Date: Wed, 20 Feb 2013 14:06:13 -0500 From: Shawn Wells <shawn(a)redhat.com> To: scap-security-guide(a)lists.fedorahosted.org Subject: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <51251EA5.3010404(a)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(a)TrustedCS.com> To: "'scap-security-guide(a)lists.fedorahosted.org'" <scap-security-guide(a)lists.fedorahosted.org> Subject: RE: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <848FB1215E2AD643A5E10D906091D3FB5B7A66(a)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(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide End of scap-security-guide Digest, Vol 18, Issue 28 ***************************************************

1 0

Interested in a SCAP Security Guide / STIG hack session?
by Shawn Wells 24 Feb '13

24 Feb '13

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.

3 2

[PATCH] [RFC] Modularized the fix scripts
by Shawn Wells 24 Feb '13

24 Feb '13

6 15

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide February 2013