Shared Checks/Fixes ...
by Trey Henefield
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.
9 years
RHEL7 Content Status
by Lesley Kimmel
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/...) 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
9 years, 1 month
CentOS / PCI DSS / Vulnerability Scans etc
by Nathanael D. Noblet
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
9 years, 2 months
OVAL 5.11 Woes
by Šimon Lukašík
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?
~š.
9 years, 2 months
Xinetd, VNC, and TFTP
by Trevor Vaughan
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 --
9 years, 2 months
