scap-security-guide September 2014

scap-security-guide@lists.fedorahosted.org

23 participants
27 discussions

sshd banner warning
by Jeremiah Jahn 22 Jan '15

22 Jan '15

We used to have to keep out banners under /etc/issue for the console, and /etc/issue.net for remote access. Would it be okay to make this rule deal with either one? diff --git a/shared/oval/sshd_enable_warning_banner.xml b/shared/oval/sshd_enable_warning_banner.xml index 0bd8d32..ace8b75 100644 --- a/shared/oval/sshd_enable_warning_banner.xml +++ b/shared/oval/sshd_enable_warning_banner.xml @@ -25,7 +25,7 @@ </ind:textfilecontent54_test> <ind:textfilecontent54_object id="obj_sshd_banner_set" version="2"> <ind:filepath>/etc/ssh/sshd_config</ind:filepath> - <ind:pattern operation="pattern match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue[\s]*(?:|(?:#.*))?$</ind:pattern> + <ind:pattern operation="pattern match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue(.net){0,1}[\s]*(?:|(?:#.*))?$</ind:pattern> <ind:instance datatype="int">1</ind:instance> </ind:textfilecontent54_object> </def-group>

5 9

scap-security-guide 0.1.19 is now live
by Jan Lieskovsky 07 Oct '14

07 Oct '14

Hello folks, I am pleased to announce the availability of scap-security-guide of version 0.1.19: [1] https://github.com/OpenSCAP/scap-security-guide/tree/v0.1.19 [2] http://repos.ssgproject.org/sources/scap-security-guide-0.1.19.tar.gz [3] https://github.com/OpenSCAP/scap-security-guide/archive/v0.1.19.tar.gz Major Changes since v0.1.18: ---------------------- * multiple bugfixes for RHEL-6 content (the list is too long to be detailed here, but major keyword for this release is / was 'stabilization'), * enhancements of RHEL-7 RHT-CCP profile content (68 rules now enabled by default + fixes to many other rules). For detailed (pre)view of changes since v0.1.18 version have a look at: [4] https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone:0.1.19+i… You are encouraged to check [2], [3] out. As always should you encounter some issue with the content, kindly report at: [5] https://github.com/OpenSCAP/scap-security-guide/issues/new Happy hardening. Jan (on behalf of the SSG team) -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

5 7

RHEL7 CCE additions
by Shawn Wells 27 Sep '14

27 Sep '14

For those tracking CCEs, NIST gave us guidance to dip into the RHEL6 CCE block when assigning RHEL7 CCEs. With the RHEL7 CCP profile getting prepared to ship, I went ahead and assigned the rules within the CCP profile a CCE: https://github.com/OpenSCAP/scap-security-guide/pull/260 Feel free to start assigning CCEs during any RHEL7 XCCDF signoff. Enjoy!

1 0

Fwd: scap-workbench 1.0.2 and 0.8.10
by Shawn Wells 25 Sep '14

25 Sep '14

cross posting to SSG -------- Original Message -------- Subject: scap-workbench 1.0.2 and 0.8.10 Date: Wed, 24 Sep 2014 09:03:43 -0400 (EDT) From: Martin Preisler <mpreisle(a)redhat.com> To: scap-workbench(a)lists.fedorahosted.org, open-scap-list <open-scap-list(a)redhat.com> Two new scap-workbench releases have just been published. https://fedorahosted.org/released/scap-workbench/scap-workbench-1.0.2.tar.b… This is a maintenance release with many usability fixes and improvements. See https://fedorahosted.org/scap-workbench/query?group=status&milestone=1.0.2 for the full list of changes. https://fedorahosted.org/released/scap-workbench/scap-workbench-0.8.10.tar.… Suitable for conservative users or users stuck with openscap older than 1.0.9. See https://fedorahosted.org/scap-workbench/query?group=status&milestone=0.8.10 for the full list of changes. Fedora packages are coming shortly. Happy scanning! -- Martin Preisler _______________________________________________ scap-workbench mailing list scap-workbench(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-workbench -- Shawn Wells Director, Innovation Programs shawn(a)redhat.com | 443.534.0130 @shawndwells

1 0

Two more days to update 0.1.19 content
by Jan Lieskovsky 25 Sep '14

25 Sep '14

Hello folks, jFYI mail that after review postponing the 0.1.19 release by two days yet (till this Friday). Originally wanted to create two upgrades (0.1.19 before & shortly after that 0.1.20 in shortened release cycle), but since release turn-around isn't time trivial operation, decided to make just one 0.1.19 release. As a result of this, there are two more days left till 0.1.19 merge window will be closed (changes submitted after this Friday will be moved to 0.1.20 milestone). Thank you for your understanding && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

1 0

[JFYI] Upstream 0.1.19 release to slip by two weeks
by Jan Lieskovsky 22 Sep '14

22 Sep '14

Hello folks, due to the increasing community demand on breeding the RHEL-7 SSG content (but not just limited to that) the SSG upstream has decided to slip the 0.1.19 release by two weeks (to give the contributors more wider time window to propose their changes). This should result into improving the shape mainly of the RHEL-7 SSG's rht-ccp.xml profile (but again not just limited to that). Therefore if you were considering proposing a change regarding this profile (or previously actually have dedicated more time to it but couldn't catch the originally proposed release date, today 2014-09-05), still feel free to submit them for review. On the other hand this decision will mean all main milestones will slip by two weeks as a result. Thank you for your understanding. Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

2 3

Re: DIACAP vs DIARMF & STIGs & CCEs.
by Chen, Wei (Contractor)(CFPB) 20 Sep '14

20 Sep '14

" A profile is just statement about a set of controls: a collection of controls plus variable settings." That brings up another important point regarding the controls. How would one configure the organizational defined values and feed it to the benchmark? Obviously, if the profiles are meant to be generic, the values can't be hardcoded in the OVAL file. You can setup the benchmark like USGCB content that allows default values to be overridden with external variables, but it is not as straight forward as one would like. Perhaps another shorthand XML that takes in organizational values or simply rebuild the SSG content with custom values? Regards, Wei ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Sep 2014 17:47:25 -0400 From: Greg Elin <gregelin(a)gitmachines.com> To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> Subject: Re: DIACAP vs DIARMF & STIGs & CCEs. Message-ID: <731BBC31-1900-4EAE-A76A-B79A62D1CA11(a)gitmachines.com> Content-Type: text/plain; charset="utf-8" Trevor makes an interesting point. Representing a specific security policy is just one use case for a "profile". A profile is just statement about a set of controls: a collection of controls plus variable settings. A profile explicitly about audit rules, for example, could be a useful training tool. Another profile focused on services or libraries, could be useful gathering an adhoc inventory across many systems. Greg Elin P: 917-304-3488 E: gregelin(a)gitmachines.com Sent from my iPhone > On Sep 16, 2014, at 6:06 PM, Trevor Vaughan <tvaughan(a)onyxpoint.com> wrote: > > "Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families" > > I'm not so sure about this one. Or rather, I'm wondering if a single SCAP benchmark can encompass the *maximum* required controls from the different control families. > > In theory, a cross matrix of all regulations should provide a system that meets all regulations (and is probably unusable, but that's a different issue). > > Do we have actual conflicting guidance between regs? > > Trevor > >> On Tue, Sep 16, 2014 at 9:39 AM, Chen, Wei (Contractor)(CFPB) <Wei.Chen(a)cfpb.gov> wrote: >> That sounds great on paper, but it's a one size fits all approach that neglects the fact that not all systems will have the same set of controls. The set of controls may be different based on the control selection and tailoring process that each system has to go through. Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families. >> >> Regards, >> Wei Chen >> >> On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield < trey.henefield(a)ultra-ats.com> wrote: >> >> > >> > >> > That is a great breakdown Shawn! >> > >> > I think it would it be useful to create profiles that align with >> > the RMF IA control baselines (low, moderate, high) and also include >> > profiles that build upon the IA control baseline profiles to >> > additionally support the current 5 overlays (CNSSI No. 1253). >> > >> > Best regards, >> > >> > >> > Trey Henefield, CISSP >> > Senior IAVA Engineer >> > >> > Ultra Electronics >> > Advanced Tactical Systems, Inc. >> > 4101 Smith School Road >> > Building IV, Suite 100 >> > Austin, TX 78744 USA >> > >> > Trey.Henefield(a)ultra-ats.com >> > Tel: +1 512 327 6795 ext. 647 >> > Fax: +1 512 327 8043 >> > Mobile: +1 512 541 6450 >> > >> > www.ultra-ats.com >> > >> > >> > -----Original Message----- >> > From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto: >> > scap-security-guide-bounces(a)lists.fedorahosted.org] On Behalf Of >> > Shawn Wells >> > Sent: Tuesday, September 16, 2014 6:26 AM >> > To: scap-security-guide(a)lists.fedorahosted.org >> > Subject: Re: DIACAP vs DIARMF & STIGs & CCEs. >> > >> > On 9/15/14, 5:02 PM, Greg Elin wrote: >> > > I was wondering if anyone was available to explain DIACAP >> > > transition to DIARMF and what it means for STIGS and SSG? >> > > >> > > Happy to have a public email thread, but also happy to take it offline. >> > > >> > > Here is my summary understanding. >> > > >> > > DoD developed its own list of information assurance controls >> > > under DIACAP (DoD Information Assurance Certification and >> > > Accreditation Process). >> > > >> > > In recent years (2010-2012), the DIACAP started transitioning to >> > > DIARMF (DoD Information Assurance Risk Management Framework) to >> > > align it with NIST RMF, and to bring the catalog of controls into >> > > alignment with the controls listed in 800-53, with some special >> > > overlays available for Defense-related systems. >> > > >> > > As of Spring 2014, that transition is complete. >> > > >> > > But I'm trying to make sure I understand how the STIGs play into >> > > all of this. When I look at the STIGs, I see different control >> > > number tracking than from the 800-53s or the CCEs. >> > > >> > > Is it the case that the Control catalog is now 800-53r4 for both >> > > civilian and DoD, but DoD is using STIGs to get to platform >> > > specific details while civilian side is using CCEs? >> > > >> > > If there were just 5 or 6 documents about current/active control >> > > catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ??? >> > > >> > > Thanks... >> > >> > The various RMF implementations call out NIST 800-53 as the place >> > to derive implementation requirements. >> > >> > When DoD (via DISA FSO) goes through NIST 800-53 and pulls out >> > things they care about, they call it a STIG. >> > When Civilian (via NIST) goes through, the output is called USGCB. >> > >> > NIST 800-53 has some high-level framework control, e.g. "ABC-1," >> > could say something along "Do secure passwords, using [agency >> > defined] values for length and complexity." >> > >> > DISA FSO then takes that requirement defines it further into >> > "Control Correlation Identifiers": >> > CCI-12345 Passwords must be 12 characters >> > CCI-12346 Passwords must contain 2 upper case >> > CCI-12347 Passwords must contain 2 special chars >> > >> > DISA has an entire spreadsheet of these CCI controls per product >> > category >> > -- they call these the Security Requirements Guide (SRG). The one >> > RHEL must follow is the operating System SRG, and you can find the >> > underlying RHEL7 STIG requirements here: >> > http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx >> > >> > When a vendor such as Red Hat creates implementation guidance -- >> > exactly what variable to change in some specific file -- that is >> > mapped to a Configuration Control Enumerator (CCE). >> -- >> SCAP Security Guide mailing list >> scap-security-guide(a)lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >> https://github.com/OpenSCAP/scap-security-guide/ > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaughan(a)onyxpoint.com > > -- This account not approved for unencrypted proprietary information > -- > -- > SCAP Security Guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20…> ------------------------------ -- SCAP Security Guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/ End of scap-security-guide Digest, Vol 37, Issue 36 ***************************************************

3 2

RE: DIACAP vs DIARMF & STIGs & CCEs.
by Chen, Wei (Contractor)(CFPB) 20 Sep '14

20 Sep '14

That sounds great on paper, but it's a one size fits all approach that neglects the fact that not all systems will have the same set of controls. The set of controls may be different based on the control selection and tailoring process that each system has to go through. Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families. Regards, Wei Chen On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield < trey.henefield(a)ultra-ats.com> wrote: > > > That is a great breakdown Shawn! > > I think it would it be useful to create profiles that align with the > RMF IA control baselines (low, moderate, high) and also include > profiles that build upon the IA control baseline profiles to > additionally support the current 5 overlays (CNSSI No. 1253). > > Best regards, > > > Trey Henefield, CISSP > Senior IAVA Engineer > > Ultra Electronics > Advanced Tactical Systems, Inc. > 4101 Smith School Road > Building IV, Suite 100 > Austin, TX 78744 USA > > Trey.Henefield(a)ultra-ats.com > Tel: +1 512 327 6795 ext. 647 > Fax: +1 512 327 8043 > Mobile: +1 512 541 6450 > > www.ultra-ats.com > > > -----Original Message----- > From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto: > scap-security-guide-bounces(a)lists.fedorahosted.org] On Behalf Of Shawn > Wells > Sent: Tuesday, September 16, 2014 6:26 AM > To: scap-security-guide(a)lists.fedorahosted.org > Subject: Re: DIACAP vs DIARMF & STIGs & CCEs. > > On 9/15/14, 5:02 PM, Greg Elin wrote: > > I was wondering if anyone was available to explain DIACAP transition > > to DIARMF and what it means for STIGS and SSG? > > > > Happy to have a public email thread, but also happy to take it offline. > > > > Here is my summary understanding. > > > > DoD developed its own list of information assurance controls under > > DIACAP (DoD Information Assurance Certification and Accreditation > > Process). > > > > In recent years (2010-2012), the DIACAP started transitioning to > > DIARMF (DoD Information Assurance Risk Management Framework) to > > align it with NIST RMF, and to bring the catalog of controls into > > alignment with the controls listed in 800-53, with some special > > overlays available for Defense-related systems. > > > > As of Spring 2014, that transition is complete. > > > > But I'm trying to make sure I understand how the STIGs play into all > > of this. When I look at the STIGs, I see different control number > > tracking than from the 800-53s or the CCEs. > > > > Is it the case that the Control catalog is now 800-53r4 for both > > civilian and DoD, but DoD is using STIGs to get to platform specific > > details while civilian side is using CCEs? > > > > If there were just 5 or 6 documents about current/active control > > catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ??? > > > > Thanks... > > The various RMF implementations call out NIST 800-53 as the place to > derive implementation requirements. > > When DoD (via DISA FSO) goes through NIST 800-53 and pulls out things > they care about, they call it a STIG. > When Civilian (via NIST) goes through, the output is called USGCB. > > NIST 800-53 has some high-level framework control, e.g. "ABC-1," could > say something along "Do secure passwords, using [agency defined] > values for length and complexity." > > DISA FSO then takes that requirement defines it further into "Control > Correlation Identifiers": > CCI-12345 Passwords must be 12 characters > CCI-12346 Passwords must contain 2 upper case > CCI-12347 Passwords must contain 2 special chars > > DISA has an entire spreadsheet of these CCI controls per product > category > -- they call these the Security Requirements Guide (SRG). The one RHEL > must follow is the operating System SRG, and you can find the > underlying RHEL7 STIG requirements here: > http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx > > When a vendor such as Red Hat creates implementation guidance -- > exactly what variable to change in some specific file -- that is > mapped to a Configuration Control Enumerator (CCE).

4 3

SCAP ecosystem test day results
by Martin Preisler 20 Sep '14

20 Sep '14

Hi all, Martin Zember kindly let us torture him a bit about SCAP scanning and tailoring so we can get a better idea about what we should document or completely change. We explicitly asked him not to study anything in advance so that we can figure out what's "easy" and what's not. And more importantly, where are users looking for information. I am cross-posting to share the results of this test because it involves all the SCAP projects. The test we performed is described at http://open-scap.org/page/TestPlan Please note that this is the first iteration and we will likely tune the test process in each iteration. Suggestions are of course welcome. Notable general pain points: * USGCB? What is it? Is it on paper or is it machine readable? * What does benchmark mean in this context? * How do I change a guidance? (tailoring confusion) * What is a profile? A lot of confusion about content vs profile. * It is easy to find some info about RHEL5 USGCB, the assumption was that RHEL6 should be similar which is sadly not the case. * usgcb.nist.gov provides content for RHEL5, doesn't even mention anything about RHEL6 * In general it's hard to figure out that SCAP is the way to automate paper guidances. Perhaps we want to use other keywords. * A lot of confusion about the difference between openscap and scap-security-guide. * xccdf Value vs xccdf Rule, which Rules use which Values. openscap specific: * openscap doesn't include any content, yet it was expected of it - user tried to look for "some version of openscap that can do USGCB" * if user selects a profile ID that's not in the content, openscap should either print `oscap info` on the file to help or at least hint the existence of `oscap info`. * ssg custom repo in documentation, outdated... * user didn't notice a report has already been generated using --report and generated it again * confusion about OVAL results and check system details scap-security-guide specific: * Upstream web mentions EPEL which is outdated and confusing - note: it is not actually outdated yet but will be soon * Upstream doesn't mention profiles that ssg provides * It is entirely ungooglable - user expected to find it with: "automate usgcb linux", "usgcb linux tool", "check linux against usgcb", "linux security compliance", "usgcb audit linux". - the only way to find it is to find openscap page first and then look at related projects, unfortunately openscap doesn't mention that scap-security-guide has USGCB... * stig-rhel6-server was renamed to stig-rhel6-server-upstream, documentation mentions stig-rhel6-server. Why would an ID like this change? scap-workbench specific: * user@target placeholder text disappears when you paste IP there. Then user doesn't realize that user@ can also go there. * Where does workbench get ssh password? User first searched for input boxes or settings before starting the scan and filling out the ssh-askpass box. * Ctrl+F or / was expected to search in both main window and tailoring window. * Enter doesn't confirm search in tailoring window, user had to click * No visualization of dependencies between rules and values * Save content vs Save tailoring, what is the difference, what do I want to use? * The user manual was not used unless explicitly talked about. * Opening tailoring file directly doesn't automatically open the content and then the tailoring file. * scap-workbench is not all that much advertised on scap-security-guide or openscap web pages. It is therefore quite hard to discover it. -- Martin Preisler

2 2

DIACAP vs DIARMF & STIGs & CCEs.
by Greg Elin 19 Sep '14

19 Sep '14

I was wondering if anyone was available to explain DIACAP transition to DIARMF and what it means for STIGS and SSG? Happy to have a public email thread, but also happy to take it offline. Here is my summary understanding. DoD developed its own list of information assurance controls under DIACAP (DoD Information Assurance Certification and Accreditation Process). In recent years (2010-2012), the DIACAP started transitioning to DIARMF (DoD Information Assurance Risk Management Framework) to align it with NIST RMF, and to bring the catalog of controls into alignment with the controls listed in 800-53, with some special overlays available for Defense-related systems. As of Spring 2014, that transition is complete. But I'm trying to make sure I understand how the STIGs play into all of this. When I look at the STIGs, I see different control number tracking than from the 800-53s or the CCEs. Is it the case that the Control catalog is now 800-53r4 for both civilian and DoD, but DoD is using STIGs to get to platform specific details while civilian side is using CCEs? If there were just 5 or 6 documents about current/active control catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ??? Thanks... Greg Elin http://govready.org - Making FISMA compliance easier for innovators email: gregelin(a)gitmachines.com phone: 917-304-3488

4 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide September 2014