scap-security-guide April 2015

scap-security-guide@lists.fedorahosted.org

17 participants
5 discussions

Shared Checks/Fixes ...
by Trey Henefield 27 May '15

27 May '15

Greetings, I wanted to propose a change to the current structure in place for shared checks (shared/oval) and fixes (shared/fixes/bash). I was curious to get everyone's opinion before committing. So the problem I see is with the symbolic linking of checks and fixes to the shared folder. I have found it problematic when working between different operating systems, file systems, and version control systems. Rather than creating symbolic links to certain oval checks in the shared/oval folder, we could choose to just process all oval checks in both the project's checks folder and the shared/oval folder. However, not all checks in the current 'shared/oval' folder are shared by all OS. For example, there are some that only apply to RHEL7 and Fedora, and not RHEL6. Any thoughts? Thanks! Best regards, Trey Henefield, CISSP Senior IAVA Engineer Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA Trey.Henefield(a)ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450 www.ultra-ats.com Disclaimer The information contained in this communication from trey.henefield(a)ultra-ats.com sent at 2015-04-08 17:13:55 is confidential and may be legally privileged. It is intended solely for use by scap-security-guide(a)lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide(a)lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.

7 17

RHEL7 Content Status
by Lesley Kimmel 28 Apr '15

28 Apr '15

All; I'm checking in on the status of the RHEL7 SCAP content. Also, I was hoping someone could explain to me the plan for SCAP content on RHEL7. I ask because I was going over the RHEL7 Security Guide today (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pd…) and it states in section 6.1: 'Note that Red Hat does not provide any default compliance policy along with the Red Hat Enterprise Linux 7 distribution. The reasons for that are explained in section 6.2 "Defining compliance policy."' I don't really see any direct explanation of the above note, and it makes me wonder if the plan is really to include this content at some point or not. RHEL7 does include the 'scap-security-guide' package but last I checked it was missing a lot of "meat" as compared to the RHEL6 'scap-security-guide' content. Thanks ahead of time, Les Kimmel otethatRedHatdoesnotprovideanydefaultcompliancepolicyalongwiththeRedHatEnterpriseLinux7distribution.ThereasonsforthatareexplainedinSection6.2,“DefiningCompliancePolicy”."Note

4 3

CentOS / PCI DSS / Vulnerability Scans etc
by Nathanael D. Noblet 25 Apr '15

25 Apr '15

Hello, We tend to use CentOS for most of our servers. All legacy servers are 6, we have two new v7 servers. I would like to learn how to perform some of these audits that the guide provides. I looked at it a few months back but never got to the point of having it work successfully. Does anyone know of documentation on how to use the guide with CentOS? I know v7 isn't quite ready? I'm also wondering if there are public locations for standards like PCI DSS, HIPAA, or other high security 'generally accepted' standards etc. -- Nathanael

4 6

OVAL 5.11 Woes
by Šimon Lukašík 22 Apr '15

22 Apr '15

tl;dr: Why I think we need OVAL 5.11 in SSG/Fedora. And what problems does it pose. The OVAL 5.11 is the latest (released) version of OVAL standard. Version 5.11 adds support for assessing systemd properties, hence this version is important for anyone auditing nowdays linux. The most notable user is SCAP-Security-Guide project that develops configuration baselines (STIG, USGCB, etc.) for RHEL7. OVAL 5.11 is very similar to the previous versions, thus one would conclude that the upgrade should be straight forward. Indeed, from tool implementation perspective upgrade is easy. OpenSCAP 1.2.2 brings in the support for OVAL 5.11. With prior OpenSCAP versions, certain DataStream operations with OVAL 5.11 are not possible. This is due to standard DataStream 1.2 schema including OVAL 5.10 XSD. Hence, for developing OVAL 5.11 content you need OpenSCAP 1.2.2 or greater. And here comes the problem, SCAP-Security-Guide contains multiple separate guidances each for a different target (RHEL6, RHEL7, or Fedora). Majority of contributors are used to build all the guidances by a single build process on RHEL6 or RHEL7. At the time of writing neither RHEL6 nor RHEL7 tooling include support for OVAL 5.11. So, the tools on RHEL6 and RHEL7 will be limited in processing OVAL 5.11 (SSG/Fedora) content. At the same time, there is value in moving the edge and start building OVAL 5.11 (systemd) content for Fedora target. We will test systemd checks in Fedora and move them to RHEL7 STIG later on. Hence, it seems that the best way to proceed is buildtime magic: Build Fedora content only when the tools are capable building it. Downside is that RHEL6/RHEL7 contributors will not be able to build Fedora content (until OpenSCAP 1.2.2 update hits their systems) Jan Černý has already started adding systemd support to SSG/Fedora in https://github.com/OpenSCAP/scap-security-guide/pull/527 Ideas? ~š.

4 3

Xinetd, VNC, and TFTP
by Trevor Vaughan 09 Apr '15

09 Apr '15

Hi All, Since the new-ish (6 and 7) guides indicate that xinetd should be disabled, what is the preferred method for running VNC and TFTP sessions to a host? The tftp-server package installs the /etc/xinetd.d/tftp file but could certainly drop an init script/systemd script with associated sysconfig file. The VNC one is a bit more difficult since it gets difficult to have dynamic SSH-based terminals without something like xinetd (or, again, a highly configurable init script). I know this falls under the "if you need it, use it" category but I was wondering if there were 'more compliant' alternatives that didn't involve epic amounts of work and/or maintenance and that stuck within the RHEL software stack. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan(a)onyxpoint.com -- This account not approved for unencrypted proprietary information --

5 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide April 2015