scap-security-guide December 2015

scap-security-guide@lists.fedorahosted.org

14 participants
14 discussions

OpenSCAP Ecosystem :: Year 2015 in Review
by Šimon Lukašík 23 Dec '15

23 Dec '15

Hello Everyone, Let me express heartfelt gratitude to everyone who has contributed to OpenSCAP ecosystem successes during the year. Following list is the feature highlights from 2015. The list of people who had contributed, however, would be at least 4 times longer. * The new portal www.open-scap.org has been put online with respectable load of documentation * Red Hat Enterprise Linux 7.2 Installer was integrated with OpenSCAP, allowing users to remediate system before the first boot * Red Hat Satellite 6.1 was integrated with OpenSCAP, allowing users to scan whole infrastructure by mouse click * Red Hat Insights offering leveraged OpenSCAP tool, allowing customers to easily notice vulnerabilities on their systems * The initial OpenSCAP support has been added into ManageIQ project * The `atomic scan` command has introduced as a short-cut to audit containers * openscap-daemon upstream project has started * The community started to focus on Debian support * 8 upstream releases of scap-security-guide project, the hightlights include * PCI-DSS profiles has been introduced and finalized for Red Hat Enterprise Linux version 6 and 7 * U.S. Government Commercial Cloud Services (C2S) has been profile introduced for Red HAt Enterprise Linux 7 * NIAP OSPP v4 profile has been introduced for Red Hat Enterprise Linux 7 * USGCB profile for Red Hat Enterprise Linux 6 has been finalized and it is ready for review at NIST * CNSS No. 1253 profile has been introduced for Red Hat Enterprise Linux 6 * The initial profile has been introduced for Debian 8 (Jessie) * An upstream STIG guidance has been introduced for applications like: JRE, Firefox, and Chromium and OpenStack (RHEL-0SP-7) * 7 upstream releases of scap-workbench bringing MS Windows and MacOS X support * 8 upstream releases of openscap, highlights include: * vastly improved HTML reports and introduced verbosity mode * oscap-docker tool for assessing containers and images * oscap-vm tool for assessing cold virtual machines * oscap-ssh tool for assessing remote systems * OVAL 5.11 and 5.11.1 support * jenkins bot joined openscap team on github to all projects * and hundreds of other feature and bug fixing patches landed in On behalf of whole team, I wish you merry Christmas and successful year 2016. Please accept the attached card as a small gift. Audit, Fix, And Be Merry! ~š.

1 0

SSG_CWS 2016-01-11: Subscribe
by S, Gautam 23 Dec '15

23 Dec '15

I would like to sign up for the SSG Contributor Q/A WorkShop. Thank you! -Gautam.

1 0

[SSG_CWS 2016-01-11: Subscribe]
by Bryant, Trevor N 17 Dec '15

17 Dec '15

Trevor Bryant SRA International, Inc. E&V Scanning DS/SI/CS/MIRD/E&V bryantt1(a)state.gov<mailto:bryantt1@state.gov> 571-345-9661 This email is UNCLASSIFIED.

2 1

SNMP for the SSG?
by Trevor Vaughan 17 Dec '15

17 Dec '15

Hi All, I was tinkering around with various monitoring tools and finally gave up and decided to go back to good old SNMP. It then occurred to me that the SSG would be perfect for reporting compliance output via SNMP and I was wondering if anyone was interested in pursuing this? The CCE numbering structure lends itself heavily to mapping to ASN.1 notation and it would allow users to get reports using pretty much any tool on the market right now. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information --

1 0

Fwd: AWS GovCloud (US) Updates for FIPS 140-2 Compliance
by Shawn Wells 17 Dec '15

17 Dec '15

Appears AWS is phasing out 3DES, pointing back to NIST 800-131A that reminds us 3DES moves to "disallowed after 2015." Seems appropriate that we update our XCCDF and OVAL content to phase out 3DES. We'd be slightly ahead of the end of year, but any objections to writing a patch to phase out 3DES from approved algorithms now? -------- Forwarded Message -------- Subject: AWS GovCloud (US) Updates for FIPS 140-2 Compliance Date: Fri, 4 Dec 2015 21:55:45 +0000 From: Amazon Web Services, Inc. <no-reply-aws(a)amazon.com> To: Shawn Wells <shawn@.....> Dear AWS Customer, We are contacting you to explain some configuration changes to enhance FIPS 140-2 security and system performance for the AWS GovCloud (US) region. Please review this information carefully to determine whether your use of services will be affected, and if so what you need to do. 3DES Deprecation ----------------------- Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are cryptographic protocols that used to encrypt data sent over untrusted networks such as the Internet. The TLS protocol is a newer version of the SSL protocol. In this documentation, we refer to both SSL and TLS protocols as the SSL protocol. In support of our customer’s requirements, AWS GovCloud (US) provides FIPS 140-2 compliant SSL endpoints. NIST Special Publication sp800-131A specifies the approval status of the 3DES block cipher algorithm as "Restricted through 2015" and "Disallowed after 2015" for FIPS 140-2 encryption. AWS GovCloud (US) currently supports AES-128 and AES-256 algorithms compliant with FIPS 140-2, and will be deprecating support for the 3DES algorithm on March 31, 2016. As an intermediate step, AWS GovCloud (US) has deprioritized the 3DES algorithm to the least preferred position in the available cipher options proffered by SSL endpoints. For most customers there is no action required as a result of this change. However, customers that have either configured their clients specifically to use only 3DES, or which have clients that don’t support AES, will need to update their systems to avoid impact prior to the 3DES deprecation date. If your client is configured to prefer 3DES, but supports AES, it will continue to work with no interruption in service after the deprecation date. The administrators of your system or Information System Security Officer may know if you have specified 3DES as the only acceptable cipher suite. In that case, you’ll need to make a configuration change to accept AES if your system requires or desires compliance with FIPS 140-2 standards. Software Load Balancers ------------------------------- AWS is transitioning the FIPS endpoint systems used for AWS GovCloud (US) from hardware load balancers to software load balancers for SSL/TLS offloading. We have measured at least a 4X improvement in performance for data downloads using FIPS approved software load balancers over the current hardware implementation. The new software load balancer is implemented using industry leading TLS 1.2 with AES cipher suites, which represents an improvement in the security of connections to GovCloud while adhering to current compliance requirements. This transition changes the AWS GovCloud FIPS 140-2 implementation from Level 2 (hardware required) to Level 1. Note that FIPS 140-2 Level 1 implements the same level of security in the encryption as Level 2 and does not impact the AWS GovCloud (US) FedRAMP authorization, as FedRAMP does not specify a required FIPS 140-2 Level. We recommend however, that customers review and update their System Security Plans or other documentation that may refer to AWS GovCloud (US) utilizing Level 2. For more information, see the list of frequently asked questions (FAQs) below. Of course, AWS Support is always available to assist and can be contacted at https://console.aws.amazon.com/support/. Remember to use the credentials for the standard AWS account that you used to sign up for AWS GovCloud (US) to authenticate to the AWS Support Center. Thank you for being an AWS customer! Sincerely, The AWS GovCloud (US) Team ----------------------------------------------- Frequently Asked Questions: AWS GovCloud (US) Updates for FIPS 140-2 Compliance Q. What is FIPS 140-2? The Federal Information Processing Standard (FIPS) Publication 140-2 is a US government security standard that specifies security requirements for cryptographic modules protecting sensitive information. To support customers with FIPS 140-2 requirements, the AWS GovCloud (US) region provides SSL terminations (a.k.a. service endpoints) that operate using load balancers with FIPS 140-2 certified modules. Q. Why is AWS deprecating support for the 3DES algorithm? The 3DES algorithm (a.k.a. Triple DES, TDEA, and Triple Data Encryption Algorithm) is an older data encryption standard that will no longer be recognized as a FIPs 140-2 approved cipher after December 31, 2015. After this date, customers with FIPS 140-2 requirements will not be compliant if they bind to the 3DES cipher. The 3DES algorithm was designed for legacy generation hardware implementations and may be vulnerable to brute force attack with increasingly powerful computing technology. AWS is therefore deprecating support for the 3DES cipher in the AWS GovCloud (US) region. To support customers that don’t have FIPS requirements, the region will continue to support the 3DES cipher until at least March 31, 2016. We recommend that customers review their applications to ensure appropriate use of the latest ciphers. Q. How do I determine if I’m using the 3DES cipher? The algorithm used to encrypt data for transport is determined by your application and the supported client configurations for your application. Your application may be supported by legacy software components that do not support AES cipher suites (although this is not common as AES has been a Federal Government standard since 2002). There are no customer settings to configure for choosing your preferred cipher in AWS GovCloud (US). The FIPS 140-2 compliant load balancers are able to detect which suite is cipher is used. Q. How do I migrate off of the 3DES cipher? Customers with FIPS 140-2 requirements should review their applications and supported clients to ensure appropriate support for the latest approved encryption ciphers. Customers without FIPS 140-2 requirements can continue to use AWS GovCloud (US) by utilizing the available non-FIPS SSL endpoints. Q. Could anything break when I change from the 3DES cipher? Customers will need to evaluate the impact of any changes to their application. For example, their users may need to upgrade their web browser or other software dependencies to ensure uninterrupted application availability. Q. Why is AWS changing from FIPS Level 2 to FIPS Level 1? Is this a lower level of protection? FIPS 140-2 Level 1 implements the same level of security in the encryption as Level 2. This change does not impact the AWS GovCloud (US) FedRAMP authorization, as FedRAMP does not specify a required FIPS 140-2 Level. The updated software load balancers now operate independent of any specific hardware device, which provides improved system performance, easier upgrades, and more flexible scaling to meet the needs of AWS GovCloud (US) customers. Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message was produced and distributed by Amazon Web Services Inc., 410 Terry Ave. North, Seattle, WA 98109-5210

2 1

SSG_CWS 2016-01-11: Subscribe
by Oliver Skiebe 16 Dec '15

16 Dec '15

1 0

SSG_CWS 2016-01-11: Subscribe
by Shawn Wells 16 Dec '15

16 Dec '15

1 0

SSG_CWS 2016-01-11: Subscribe
by Jones, Jeff 16 Dec '15

16 Dec '15

Jeff Jones, CCSFP, ITIL, COBIT IT Infrastructure Analyst [cid:image001.png@01D13806.64BF4170] 120 Fifth Avenue Place, #513, Pittsburgh, PA 15222 P: (412) 544-7484 F: (412) 544-4109 ________________________________ This e-mail and any attachments to it are confidential and are intended solely for use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this e-mail without the author's prior permission. The views expressed in this e-mail message do not necessarily represent the views of Highmark, its diversified business, or affiliates.

1 0

Save the date -- SSG Contributor Q/A WorkShop Volume #2 (Mon, 2016-01-11 09:00am - 11:00am ET)
by Jan Lieskovsky 16 Dec '15

16 Dec '15

Hello folks, since according to the feedback received so far for the initial version of the SSG Contributor Q/A WorkShop this session / event seem to have been pretty useful, we are happy to announce the second volume is planned to happen on: Monday, 2016-01-11 09:00am - 11:00am Eastern Time Please save this date && consider subscribing (information how to do that is in [1] below). I have put together a SSG Wiki page to hold the information necessary to be able to join this event. Also small FAQ section is included there (for the issues from the previous session I was able to identify. Should you find answer to your question missing there, feel free to send RFE to this list). [1] https://github.com/OpenSCAP/scap-security-guide/wiki/SCAP-Security-Guide-Co… Looking forward to see you there. Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team P.S.: Be sure to see the Disclaimer considering joining this event. The plan is to have this session recorded, and reachable online later.

1 0

XCCDF variables associated with "sysctl_net_ipv4_conf_*" do not seem to be getting used.
by S, Gautam 15 Dec '15

15 Dec '15

Hello folks, I am new here, so I am not sure if this was discussed and closed earlier. If so, I am sorry for bringing it up again. I notice that some of the OVAL checks and remediation scripts for network-kernel parameters seem to ignore the XCCDF input variable. For example, the rule "sysctl_net_ipv4_conf_all_accept_source_route" has an associated XCCDF variable "sysctl_net_ipv4_conf_all_accept_source_route_value" which it seems to be passing to the OVAL check: <oval id="sysctl_net_ipv4_conf_all_accept_source_route" value="sysctl_net_ipv4_conf_all_accept_source_route_value" /> However, the OVAL check and remediation script seem to be ignoring it: <unix:sysctl_state id="state_runtime_net_ipv4_conf_all_accept_source_route" version="1"> <unix:value datatype="int" operation="equals">0</unix:value> </unix:sysctl_state> Fix: /sbin/sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0 This is a problem only when someone decides to alter the default variable value from "disabled" to "enabled", which I understand is not very likely. Nevertheless, someone using "refine-value" gets an incorrect evaluation and remediation result. I would like to fix this but I am not sure what is the right way forward. Most of these sysctl parameters are binary valued and one of those is the conventional "good" value you'd expect. So unless these XCCDF variables are here for a reason, the simplest solution (I would assume) is to remove these XCCDF variables altogether and just evaluate against the "good" value. The other approach would be to make OVAL and the fix use the variable. The OVAL sysctl_state's value field should be able to refer to an external variable if I am not mistaken. Please let me know what you think. Thank you for your time. Best Regards, Gautam.

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide December 2015