scap-security-guide July 2016

scap-security-guide@lists.fedorahosted.org

18 participants
15 discussions

SCAP Security Guide 0.1.30
by Jan Lieskovsky 12 Sep '16

12 Sep '16

Hello folks, 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-1.2.14.1 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 being installed. For a more detailed overview of changes (bug fixes, enhancements) implemented in this release please have a look at more detailed changelog: * https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.30 Full changelog at: * https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.30 Zip archives with pre-built benchmarks in DataStream form: * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.30/s… (Zip archive using OVAL-5.11.1 language version) * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.30/s… (Zip archive using OVAL-5.10 language version) Happy hardening! Regards, Jan -- Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team)

2 2

Latest OpenSCAP changes to speed up SSG builds
by Martin Preisler 03 Aug '16

03 Aug '16

I found pretty bad inefficiencies in some of our XSLTs. Check out https://github.com/OpenSCAP/openscap/commit/a65bf27dec4a93e2b87cec8cbcd80be… or https://github.com/OpenSCAP/openscap/commit/1dd5573b2c964b00af57215cadb7f13… Long story short I was able to cut SSG build time on my machine from 2m21.061s to 1m08.771s. In other words my machine now needs roughly half the time to build SSG. I was timing `make -j 4`. It will take a while for these changes to make it into releases and into distributions but I am writing this email because the savings are significant and perhaps you want to enjoy them sooner. SCAP Security Guide contributors are doing a lot of content builds. This will only work if you !!! have OPENSCAP 1.2.x !!! If you want to speed up the build, replace /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl with https://raw.githubusercontent.com/OpenSCAP/openscap/maint-1.2/xsl/xccdf_1.1… /usr/share/openscap/xsl/xccdf-share.xsl with https://raw.githubusercontent.com/OpenSCAP/openscap/maint-1.2/xsl/xccdf-sha… and /usr/share/openscap/xsl/xccdf-guide-impl.xsl with https://github.com/OpenSCAP/openscap/blob/maint-1.2/xsl/xccdf-guide-impl.xsl Perhaps it would be worth it to deploy this on our Jenkins slaves even before it hits releases? What do you think? -- Martin Preisler Identity Management and Platform Security | Red Hat, Inc.

5 10

Question about SUSE/openSUSE SSG
by 面和毅 29 Jul '16

29 Jul '16

Folks, 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? Kind Regards, OMO -- Kazuki Omo: ka-omo(a)sios.com OSS &Security Evangelist OSS Business Planning Dept. CISSP #366942 Tel: +81364015149

4 5

TPM posture inquiry
by Brent Kimberley 28 Jul '16

28 Jul '16

Greetings. Are there automated methods for assessing TPM posture? For example - verify TPM is: enabled, activated, contains a unique EK (i.e. tpm_getpubek is not reflective of known compliance vector fragments.) ( I apologize in advance if this question is off topic or common knowledge.) Best Regards, Brent ref oval.mitre.org/community/docs/OVAL-and-TPM-06-14-2010.pdf scap.nist.gov/events/2011/saddsp/presentations/Charles_Schmidt-Trusted_Comp… scap.nist.gov/events/2012/itsac/presentations/day2/4Oct_1145am_Boyle.pdf csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2014.pdf cryptotronix.com/2014/08/28/compliance_mode/ THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

3 4

[xpost] BZ#1188570 Proposal for enhancement of Docker SSG profile
by Kaustubh Padegaonkar 21 Jul '16

21 Jul '16

Hello members, With regards to BZ#1188570 [0], 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 [1]. 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 [2]. 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 userland packages. 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 [3]. 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 their liking. 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. [Hyperlinks] [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1188570 [1]: https://docs.docker.com/engine/userguide/storagedriver/selectadriver/ [2]: https://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-an… [3]: https://registry.access.redhat.com/v1/repositories/library/rhel7/tags Best Regards, -- kdp irc: thetuxracer

2 1

[Proposal] Replace SSG feature milestones on GitHub with GH feature labels -- any objections?
by Jan Lieskovsky 20 Jul '16

20 Jul '16

Hello folks, so there are these SSG "feature milestones" on GitHub: * Infrastructure Enhancements and Fixes (https://github.com/OpenSCAP/scap-security-guide/milestones/Infrastructure%2…) * RHEL7 NIAP/USGCB Submission (https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL7%20NIAP/USG…) * NIST 800-53 identifiers assignment (https://github.com/OpenSCAP/scap-security-guide/milestones/NIST%20800-53%20…) * Unimplemented OVAL checks (https://github.com/OpenSCAP/scap-security-guide/milestones/Unimplemented%20…) * RHEL-6 USGCB Profile Review (https://github.com/OpenSCAP/scap-security-guide/milestones/RHEL-6%20USGCB%2…) * Draft RHEL 7 STIG (https://github.com/OpenSCAP/scap-security-guide/milestones/Draft%20RHEL%207…) There are two issues with the current approach: * they are updated very seldom -- basically only in moment new release is created, * they don't allow to reference all issues fixed in one particular release -- when some change is made (let's suppose it's related with RHEL 7 STIG effort), the corresponding change is tagged with "Draft RHEL 7 STIG" milestone. But it also belongs to some specific release (suppose 0.1.30 in this case). Trying to obtain all changes finished in 0.1.30 release this change wouldn't be present there, because it has "Draft RHEL7 STIG" milestone instead of "0.1.30" one. Therefore the proposal is to move this SSG feature milestones into GitHub labels instead. This way it will be possible to have just numeric milestones (0.1.31, 0.1.32, ...) and assign labels to pull request (so we won't loose the information some change / PR is relevant to "RHEL 7 STIG" effort). Simultaneously will be able truly to list all changes that have been finished in particular release. I can turn the feature milestones into feature labels. But prior to doing that wanted to know if there are some concerns / objections against doing that? Thank you && Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

6 6

Re: [Open-scap] New COPR repository for OpenSCAP projects
by Martin Preisler 20 Jul '16

20 Jul '16

----- 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: > https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/ > > The repo enables you to test the latest greatest OpenSCAP bits on RHEL and > CentOS. > > 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: https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/ Instructions on how to enable the repo are on the page. -- Martin Preisler Identity Management and Platform Security | Red Hat, Inc.

2 1

Fwd: STIG Update - DISA has developed the following DRAFT documents related to Red Hat Enterprise Linux 7
by Shawn Wells 19 Jul '16

19 Jul '16

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 *To:* shawn.d.wells(a)gmail.com *Subject:* *STIG Update - DISA has developed the following DRAFT documents related to Red Hat Enterprise Linux 7* *Reply-To:* subscriptions(a)disa.mil 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 feedback/comments: - 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 · 1-800-439-1420

2 1

Re: investigating "notapplicable"
by Radzykewycz, T (Radzy) 19 Jul '16

19 Jul '16

________________________________________ 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.

1 0

CentOS 7 SSG Remediation Test Results
by Bault, Molly Jo 18 Jul '16

18 Jul '16

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. Bugs: * 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) Features Request: * In the html report, add a Group rules by "STIG number" "RHEL-07-TBD" Thank you so much for your work on this! [Astronics-BT-Logo-Signature]<http://www.ballardtech.com/> 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.

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide July 2016