2015 Red Hat Summit: Discounted passes for SSG & OpenSCAP community members
by Shawn Wells
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
9 years, 1 month
Handling various sysctl locations, runtime vs persistent checks
by Shawn Wells
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/fc7cb8dd4cd91da3d2df35b8863247...
[4]
https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b8863247...
[5]
https://gitorious.org/procps/procps/source/fc7cb8dd4cd91da3d2df35b8863247...
9 years, 2 months
Fwd: [FEDRAMP-COMMERCIAL] Request for Comment: FedRAMP High Baseline
by Shawn Wells
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
------------------------------------------------------------------------
9 years, 2 months
sshd banner warning
by Jeremiah Jahn
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>
9 years, 3 months
Can you recommend a way how to share more detailed release changelog information via GitHub web UI?
by Jan Lieskovsky
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
9 years, 3 months
"Official" SSG
by Lesley Kimmel
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
9 years, 3 months
scap-security-guide-0.1.20 is now live
by Jan Lieskovsky
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-...
Happy hardening.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
9 years, 3 months
RE: RHEL7 Content Status
by Lesley Kimmel
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
>
>
9 years, 3 months
RE: SCAP Platform Applicability
by Lesley Kimmel
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/
9 years, 3 months
