scap-security-guide January 2015

scap-security-guide@lists.fedorahosted.org

13 participants
14 discussions

2015 Red Hat Summit: Discounted passes for SSG & OpenSCAP community members
by Shawn Wells 25 Mar '15

25 Mar '15

Hey Guys, The 2015 Red Hat Summit (http://www.redhat.com/summit) will take place June 23-26 in Boston. The event may seem far away, but we all know how long it takes for integrators and govies to allocate training and travel budgets... :) This year we've ensured that _*any*_ member of the SSG & broader OpenSCAP community is eligible for discounted Summit passes at $950/pass (or $895/pass for groups of 4+). Doesn't matter if you're a code contributor, occasional voice on the mailing lists, or silent partner. For reference, the full conference pass is generally $1,975 (ref http://www.redhat.com/summit/rates/) In 2012 the SCAP session was standing room only, and in 2013 it was rated the #3 session (out of 196 sessions) by attendees. We hope to see you there this year! In full transparency: I don't get any RHT kickback or commissions off this. I received a special registration code that allows me to empirically show various managers/event staff how much interest there is in SCAP and Security Automation. For every 10 registrants that use the code, I get to send a RHT engineer to Red Hat Summit. Contact me _*off-list*_ if interested! -sdw

2 2

Handling various sysctl locations, runtime vs persistent checks
by Shawn Wells 02 Feb '15

02 Feb '15

Our current sysctl checks simultaneously check the runtime of the system (via unix:sysctl_test) and the persistent configuration (regex on sysctl.conf). We know these need to be broken out, and that's being tracked in Issue #321 [1]. So then, to actually take action, it seems like we need to: (1) Breakout the *runtime* checks into unique XCCDF and OVAL elements. The OVAL will utilize unix:sysctl_test; (2) Breakout the *persistent* checks. On the persistent/static configuration side, from the sysctl manpage [2] there are now 6 locations to bury persistent sysctl settings: /etc/sysctl/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf I can't find documentation on the "order of operations" on how sysctl directories are scanned (aka, if a setting is placed in /usr/lib/sysctl.d/, will /etc/sysctl/*.conf overwrite it?). Has anyone seen any order of operations documentation on sysctl? My google-fu is failing today =/ From the upstream source, I get the idea that /etc/sysctl.conf overwrites everything [3], but unsure of the other paths. The closest indication I could find was where PreLoadSystem() defines their dir[] array [4], which shows: - /run/sysctl.d (ignored, will be checked by runtime OVAL check) - /etc/sysctl.d/ - /usr/local/lib/sysctl.d/ - /usr/lib/sysctl.d/ - /lib/sysctl.d/ As a side note, it looks like the code only checks *.conf files in those directories, so we can ignore everything else [5]. [1] https://github.com/OpenSCAP/scap-security-guide/issues/321 [2] http://man7.org/linux/man-pages/man5/sysctl.conf.5.html [3] https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b886324767… [4] https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b886324767… [5] https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b886324767…

3 2

Fwd: [FEDRAMP-COMMERCIAL] Request for Comment: FedRAMP High Baseline
by Shawn Wells 30 Jan '15

30 Jan '15

The FedRAMP PMO released the draft FedRAMP High controls for public comment. Since most of the SSG crowd is federal, and at some point we're likely to create a FedRamp High profile within SSG, wanted to make sure everyone was able to review these before they became policy. Happy to include SSG community feedback in Red Hat's formal response back to GSA (for those not providing feedback through their own companies/sponsors)! Shawn ------------------------------------------------------------------------ *From: *"info fedramp" <info(a)FEDRAMP.GOV> *To: *FEDRAMP-COMMERCIAL(a)LISTSERV.GSA.GOV *Sent: *Tuesday, January 27, 2015 5:09:58 PM *Subject: *[FEDRAMP-COMMERCIAL] Request for Comment: FedRAMP High Baseline The FedRAMP PMO is releasing a draft high impact baseline for public comment. The draft baseline is at the High/High/High categorization level for confidentiality, integrity, and availability in accordance with FIPS 199. This baseline is mapped to the security controls from the NIST SP 800-53, Rev. 4 catalog of security controls. FedRAMP worked with key government stakeholders to develop the baseline. As a part of the creation of this baseline, justifications for each control selected was provided. This baseline is being released for 45 days to our industry and agency stakeholders. The public comment period will end 3/13/2015. Attached is a spreadsheet detailing the security controls. This spreadsheet includes the full list of NIST controls. Notes about the columns within the spreadsheet: * Column E is the control description provided by NIST. This description is not being put to public comment but is provided for context. * Column J identifies the controls selected for the FedRAMP high baseline * Column K identifies the justification for the selection of that control. Any control that is a part of the FedRAMP moderate baseline or NIST high baseline is a mandatory control and comments are not requested on these controls as they will automatically be a part of the FedRAMP high baseline. * Please provide comments to the selections in column N titled "Questions / Comments" DO NOT EDIT THE STRUCTURE OF THE SPREADSHEET. ANY SPREADSHEET WITH THE STRUCTURE EDITED WILL BE DISCARDED. The FedRAMP PMO will be holding a webinar regarding the release of this baseline and to address any questions or concerns regarding this tomorrow, Wednesday January 28, 2015. To register for this webinar, please go here <https://attendee.gotowebinar.com/register/8195985436656456193> . All comments should be provided to info(a)FedRAMP.gov with the subject title "FedRAMP High Baseline Comments." Once comments are received, FedRAMP will convene government stakeholder to review and address all comments received. The baseline will then be released for a second round of public comments to provide adjudications of the comments received prior to finalization. The second round of public comments is expected in Summer 2015. Thanks you. Sincerely, FedRAMP PMO ------------------------------------------------------------------------

1 0

sshd banner warning
by Jeremiah Jahn 21 Jan '15

21 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

Can you recommend a way how to share more detailed release changelog information via GitHub web UI?
by Jan Lieskovsky 19 Jan '15

19 Jan '15

Hello folks, in effort to create new SCAP Security Guide v0.1.20 release and mainly trying to provide more detailed Changelog information, that would be reachable online (yet before the actual tarball has been downloaded & expanded) has been investigating GitHub web UI possibilities for this purpose. One approach how this could be implemented is to provide the Changelog information in the particular milestone's description. But the problem seems to be there isn't a direct link provided how such milestone's description could be referenced later. Example content is visible at: 1) https://github.com/OpenSCAP/scap-security-guide/milestones to get the list of milestones 2) then click the "(more)" pseudo link below "Version 0.1.20: USGCB profile remediation and kickstart support" milestone to see the actual description. >From what I have searched looks this "(more)" pseudo link is handled by JavaScript (thus at the side of the client's browser) and it's not possible to use it for referential purposes. The vision behind future SCAP Security Guide updates is to provide also more detailed Changelog information for each release, basically split into three sections: * New Features: This not so much detailed section would be dedicated to briefly list main new features expected to be provided in this release (like support of new products etc.) * Enhancements: Here list of enhancements would be detailed (IOW enhancements for existing products like new remediations or new OVAL checks). * Bug fixes: Here list of bug fixes would be described (which build failures / OVAL checks / remediations have been corrected in this release). Given (after the short review so far) the GitHub's milestone's description doesn't seem to be providing functionality for this kind of "web Changelog" was thinking of creating new GitHub SCAP Security Guide wiki page for each of the new releases and detailing that information there. But prior doing that wanted to check experiences of other people / other ideas / suggestions, how this could be implemented. Comments / recommendations / experience / proposals welcome. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

3 4

"Official" SSG
by Lesley Kimmel 16 Jan '15

16 Jan '15

Is this the "official" SSG source? If I am primarily interested in SCAP content for RHEL5/6/7 would there be any benefit for me to subscribe to the mailing list at the Red Hat website or is this the place to be? Thanks, -Les Kimmel

3 2

scap-security-guide-0.1.20 is now live
by Jan Lieskovsky 15 Jan '15

15 Jan '15

Hello folks, let me introduce the new stable version of SCAP Security Guide, version 0.1.20. Containing more than three months of development the list of new features, enhancements and bug fixes is pretty long [1]. For the sake of brevity let me focus just at two areas of this new release: * Inclusion of kickstart for USGCB profile for Red Hat Enterprise Linux 6 Server, which can be applied to install USGCB compliant RHEL-6 Server system with GUI right from the scratch. * Multiple modifications of SCAP Security Guide code base towards wider code universality & reusablement across multiple products. Full changelog for 0.1.20 release is available at: [1] https://github.com/OpenSCAP/scap-security-guide/wiki/scap-security-guide-0.… Happy hardening. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

1 0

RE: RHEL7 Content Status
by Lesley Kimmel 14 Jan '15

14 Jan '15

Simon; I understand WHY the items weren't checked/tested I was just more curious if, in this case, the OVAL tests didn't yet exists because the RHEL7 content was still in the works and if it will be added in the future. If so is there an ETA on the completed content? Thanks, -Lesley Kimmel On 01/08/2015 09:14 PM, Lesley Kimmel wrote: > I noticed, in running the RHEL7 data stream, that there were many checks > with status 'notchecked'. Inspecting the data stream document I see that > several of the check references in the XCCDF refer to checks that do not > exist in the OVAL. Is this a known deficiency? I assume that the RHEL7 > content is still being refined. > I have answered very similar question yesterday at https://github.com/OpenSCAP/openscap/issues/35 > PS- I'd love to get involved in this project but I'm really just getting > exposed to SCAP and trying to really understand the interrelationships > between the various SCAP components. Does anyone have a really concise > reference to get me started? > > Thanks, > Les > >

2 1

RE: SCAP Platform Applicability
by Lesley Kimmel 13 Jan '15

13 Jan '15

Greg; I am using RHEL7 SSG content 0.9 (I assume based on the <version> tag in the XCCDF component). I am also using OpenSCAP (oscap) 1.0.8. The good news is that in querying the version of oscap ($ oscap version) I was given a lot of other information. One of the sections in the output was entitled "Inbuilt CPE names". This section listed a slew of Red Hat related products (RHEL, Fedora, CentOS). One of the entries listed was "cpe:/o:centos:centos:6". Based on this output I searched my system for CPE files and found '/usr/share/openscap/cpe/openscap-cpe-{dict,oval}.xml. Inspection of these files indeed shows that there are CPE dictionary mappings to OVAL rules which test for the appropriate OS version, presumably using rpm -qi or the like. Thanks again! -Lesley Kimmel ---------- Forwarded message ---------- From: Greg Elin <gregelin(a)gitmachines.com> Date: Jan 12, 2015 7:04 AM Subject: Re: SCAP Platform Applicability To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> Cc: Lesley, what version of SSG and OpenSCAP are you using? Greg On Sat, Jan 10, 2015 at 5:53 PM, Lesley Kimmel <ljkimmel99(a)hotmail.com> wrote: Thanks a ton for all of that information, Greg. From what I've been reading I would have expected just what you described. However, all I had to do to run the RHEL content on CentOS was to add <platform>"cpe:/o:centos:centos:6"</platform> near the top of the benchmark (xccdf) with no modification to the CPE or components... On Jan 10, 2015 1:54 PM, Greg Elin <gregelin(a)gitmachines.com> wrote: Lesley, I know how you feel. SCAP seems like it should be easy because it is "just XML". Then you dig into looking for a test and it gets confusing fast. SCAP (Security Content Automation Protocol) is actually a set of multiple standards and specifications that are used together to enable automatically testing hundreds of nerd settings. Let me emphasize that: SCAP is not a single XML specification -- SCAP is multiple standards and specs. Whenever you give "SCAP Content" to a scanner to check a system configurations you are giving the scanner multiple XML files representing multiple standards. - XCCDF describes the checklist (Extensible Configuration Checklist Description Format). [1] - CCE are unique identifiers and descriptive material for specific configuration settings (Common Configuration Enumeration). [1] - OVAL is the XML that describes tests, including multi-part tests, that assess if a CCE identified configuration setting is correct on a system. (Open Vulnerability Assessment Language) [1] - CPE is as unique string of text to uniquely identify a "platform" of software, hardware, or application (Common Platform Enumeration). The idea is that CPE string can be used to associate a checklist (XCCDF), a configuration setting (CCE) or test (OVAL) with a specific platform. (Oy!) [1] And the list goes on. But to understand how to use SCAP-Security-Guide on CentOS we only need to worry about XCCDF, CCE, OVAL, and CPE. (At least I think...) Almost all RHEL CCE's (config settings) and OVAL (test criterion) work on CentOS. The exception are those settings/tests like the RHEL GPG key installed which only make sense in relation to a RHEL subscription and do not apply to CentOS. So why does OpenSCAP run SCAP-Security-Guide on CentOS, but the results come back "not applicable?" Two reasons: 1) Because the XCCDF in RHEL refers to CPE XML file that specifies RHEL and not CentOS. 2) Because CPE platform string is verified with an OVAL test that checks the RPMs for platform identification. Thus, to get OpenSCAP to work on CentOS, we need to tell OpenSCAP to use a CPE-dictionary.xml file that includes a CPE string for CentOS and we need to have a corrected OVAL test that validates we are on CentOS. And how do we do this reliability? Part of what I'm trying to do with my software, GovReady [2], is to make things like this easier. But you don't have to use GovReady. If you read the CentOS quick start in the GovReady README, you will see link to a CentOS ssg-centos6-cpe-oval.xml and ssg-centos6-cpe-oval.xml file that make the necessary adjustments. You just need to copy them to your local CentOS server and then correctly specify their path when running OpenSCAP. Like so: oscap xccdf eval --oval-results --profile server --cpe scap/content/ssg-centos6-cpe-dictionary.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml Alternatively, you could manually update the CPE and OVAL XML file using (e.g., using a sed statement). It's still kind of confusing for me. So I hope I have the above correct. [1] http://wiki.gentoo.org/wiki/SCAP [2] https://github.com/GovReady/govready Greg Elin http://govready.org - Making FISMA compliance easier for innovators email: gregelin(a)gitmachines.com phone: 917-304-3488 On Fri, Jan 9, 2015 at 5:20 AM, Simon Lukasik <isimluk(a)fedoraproject.org> wrote: On 01/08/2015 09:04 PM, Lesley Kimmel wrote: I just downloaded the RHEL7 SCAP content and was 'playing' with it on a CentOS 6 system. I found that in order to make the checks run I needed to add 'cpe:/o:centos:centos:6' in a <platform> tag near the beginning of the XCCDF component. I found this, in part, from various posts on the interwebs. I'm really curious how this validation occurs and where the information comes from on the target OS. Can anyone give me insight to this issue? If you really wish to understand the things, your best bet would be to read the actual standards. For example XCCDF Standard document (NIST Interagency Report 7275) gives basic insight into CPE matching. Best regards, -- Simon Lukasik Security Technologies, Red Hat, Inc. -- SCAP Security Guide mailing list scap-security-guide(a)lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide <https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide> https://github.com/OpenSCAP/scap-security-guide/ <https://github.com/OpenSCAP/scap-security-guide/> -- 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/

1 0

Re: SCAP Platform Applicability
by Lesley Kimmel 12 Jan '15

12 Jan '15

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide January 2015