it's my pleasure and honor to announce that SCAP Security Guide
release 0.1.30 has been created and is now available for download.
Highlights of this release:
* CNSS No.1253 (nist-CL-IL-AL) profile has been ported to Red Hat
Enterprise Linux 7,
* SCAP benchmark for Red Hat Enterprise Linux 7 now passes official
NIST SCAP ScapVal-18.104.22.168 content validation tool requirements,
* The XCCDF rules for Red Hat Enterprise Linux 7 has been equipped
with CCE identifiers,
* New CJIS "Criminal Justice Information Services (CJIS) Security Policy"
profile has been added to Red Hat Enterprise Linux 7 benchmark,
* Profile for each ANSSI hardening level for NP targets has been
added to Debian 8 benchmark,
* Remediation scripts don't rely on external
/usr/share/scap-security-guide/remediation_functions shell library
any more (instead starting from this release the remediation scripts
are part of the specific benchmark itself). This allows to perform
remediation without the need to have scap-security-guide RPM package
For a more detailed overview of changes (bug fixes, enhancements)
implemented in this release please have a look at more detailed changelog:
Full changelog at:
Zip archives with pre-built benchmarks in DataStream form:
(Zip archive using OVAL-5.11.1 language version)
(Zip archive using OVAL-5.10 language version)
Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team)
I just want to ask (maybe foolish) question, but
I couldn't find any SSG for SUSE or openSUSE.
Is there any SSG for SUSE, or it's under developing?
Kazuki Omo: ka-omo(a)sios.com
OSS &Security Evangelist
OSS Business Planning Dept.
With regards to BZ#1188570 , I, would like to propose inclusion of
below checks into the docker SSG profile:
1. Checking if docker-storage-setup is completed or configured:
- For using docker in production, the device mapper storage driver, with
loopback devices is discouraged . There are various ways of
configuring the devicemapper storage driver, and suggested ones are
aufs, direct-lvm. Choosing the right storage driver and backing
filesystem is crucial to stability and performance.
2. Ensuring that the LXC execution driver isn't used:
- LXC as an execution driver has legacy support at best, and should not
be used . libcontainer is the default docker execution driver. All
kernel interactions and manipulation of namespaces and control groups
are easily achieved from libcontainer without having to rely on other
3. A container should be created with a non-root user
- Newer docker versions come with user namespaces enabled. This largely
allows security by way of containment of users and groups so that
processes running root in a container are not root on the host system.
However, docker versions older than 1.9 do not utilize user namespaces
and hence any process started as root inside the container can exploit
loopholes within the system and lead to privilege escalation or even
denial of services. Even better is to create a non-root user solely for
the purpose of running the container
4. A container should be built from a trusted source
- Docker images should be built from trusted and official docker or
docker partner repositories. Examples would be
registry.access.redhat.com or registries marked official on docker.io.
To accomplish this, the image's hash can be inspected. For Red Hat, base
images, SHA is hosted at . I do not know of APIs to check SHAs of
official images hosted on hub.docker.com, this is something that I would
like to hear alternate approaches, should the members find this point to
5. Check for disabled kernel capabilities
- The report should mention the capabilities that the container runs
with and without. This will help user to gain an understanding of the
various capabilities that a container can run with and makes user aware
of the necessities of each. By running the container with only the bare
minimum capabilities, the attack surface is reduced to quite an extent.
6. A container should not have ssh package installed
- Running ssh inside the container necessitates the installation of
openssh server/client and adds to complexity of security management
because its difficult to audit and keep track of ssh keys. It also
becomes difficult to consume security updates to the openssh packages
caused by CVE/RHSA. Docker provides an inbuilt way to obtain shell
access to a container which should be used rather than an ssh package.
These suggestions are by no means comprehensive; I wish to merely use
these as a starting point to create more exhaustive tests in the profile
itself. Dan Walsh's container security guide is a good start.
Please feel free to critique or provide suggestions.
----- Original Message -----
> From: "Jan Cerny" <jcerny(a)redhat.com>
> To: open-scap-list(a)redhat.com
> Sent: Tuesday, July 19, 2016 9:19:04 AM
> Subject: [Open-scap] New COPR repository for OpenSCAP
> Hi all,
> We have created a new COPR repository that provides unofficial builds
> of latest versions of openscap, scap-security-guide, scap-workbench
> and openscap-daemon packages. The packages are suitable for use
> on Red Hat Enterprise Linux 5, 6 and 7 and CentOS 5, 6 and 7.
> The COPR repository is located on:
> The repo enables you to test the latest greatest OpenSCAP bits on RHEL and
> The former repository isimluk/OpenSCAP will not be maintained anymore.
> Sorry for inconvenience.
> Best regards
> Jan Černý
> Security Technologies | Red Hat, Inc.
CC-ing scap-security-guide. The new COPR repo contains latest SSG packages
and might be useful to our community members.
The repo is:
Instructions on how to enable the repo are on the page.
Identity Management and Platform Security | Red Hat, Inc.
For those following RHEL7 STIG, the latest draft was released today. We'll
be publishing a Google doc for centralized feedback and ways to help review
for those interested in helping!
Begin forwarded message:
*From:* "Defense Information Systems Agency (DISA)" <subscriptions(a)disa.mil>
*Date:* July 15, 2016 at 10:14:13 AM MDT
*Subject:* *STIG Update - DISA has developed the following DRAFT documents
related to Red Hat Enterprise Linux 7*
STIG Update - DISA has developed the following DRAFT documents related to
Red Hat Enterprise Linux 7 STIG Update - *DISA has developed the following
DRAFT documents related to Red Hat Enterprise Linux 7*
The following DRAFT documents are available for community review and
- Draft Red Hat Enterprise Linux 7 Security Technical Implementation Guide
(STIG) Version 0.2
The Draft documents and a Comment Matrix are available at:
http://iase.disa.mil/stigs/os/unix-linux/. Please provide comments by COB
27 July 2016 to disa.letterkenny.re.mbx.stig-info(a)mail.mil. One comment
matrix per email.
For all STIG related questions, please contact the DISA STIG Customer
Support Desk: disa.stig_spt(a)mail.mil
Update your subscriptions, modify your password or e-mail address, or stop
subscriptions at any time on your Subscriber Preferences Page
<https://public.govdelivery.com/accounts/USDISA/subscriber/new>. You will
need to use your email address to log in. If you have questions or problems
with the subscription service, please visit subscriberhelp.govdelivery.com.
All other inquiries can be directed to subscriptions(a)disa.mil.
GovDelivery, Inc. sending on behalf of the Defense Information Systems
Agency (DISA) · 408 St. Peter Street, Suite 600 · St. Paul, MN 55102 ·
Thanks to everyone who helped with my "notapplicable" problem!
Turns out that the problem was a typo in the changes I made to the security guide, so it was failing the OS part of the CPE comparison.
Greetings Awesome Scap Security Guide Developers,
I've been looking at this project and it is very exciting to see the work you are doing here. Thank you so much for helping make Linux more secure.
I'm not sure how all this works, so please forgive me in advance.
I've attached some tweaks to some of the RHEL 7 remediation scripts that might be useful.
Here are some issues that I didn't see an easy fix for found will testing this on CentOS 7.
* Enable Randomized Layout Virtual Address Space check is failing, despite being applied (content_rule_sysctl_kernel_randomize_va_space)
* Accounts password PAM retry check failing, despite being applied (content_rule_accounts_password_pam_retry)
* Mount option var temp bind check failing, despite being applied (content_rule_mount_option_var_tmp_bind)
* In the html report, add a Group rules by "STIG number" "RHEL-07-TBD"
Thank you so much for your work on this!
Molly Jo Bault | Design Engineer
11400 Airport Rd Ste 201 | Everett, WA 98204 | USA | P: +1.425.339.0281 x123 | F: +1.425.339.0915
This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail.
Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.