On 4/24/15 12:03 PM, Nathanael D. Noblet wrote:
Hello Greg,
This is fantastic information and nearly perfectly what I was looking
for. I think it would make a great first read for people trying to get
into this area. Apologies for the top post but most of my resulting
questions don't fit nicely into what you've provided.
The remaining questions are.
#1 - If Scap-Security-Guide is trying to provide OSS SCAP content, why
isn't CentOS included by default?
Support for CentOS represents a non-trivial amount of work with little
applicability for many of the development and user community. It's
important to note that CentOS is not a RHEL clone. It's a derivative, a
unique operating system of its own.
Foundationally, Red Hat does not put CentOS through certifications such
as Common Criteria and FIPS. The lack of such certifications largely
disqualifies CentOS from deployment in many US Government agencies (yes
yes, DAA/ISSO/security staff can always approve waivers, and they very
often do!). Because of the original focus to open source government
baselines, CentOS simply wasn't on the radar.
Extending support for CentOS involves a few things:
- Updating select OVAL checks (e.g. FIPS) to always fail unless on RHEL,
as CentOS does not have these certifications;
- Because CentOS is a derivative of RHEL, XCCDF and OVAL rules will need
to be re-validated on each CentOS release;
- CCEs are platform specific (RHEL6, RHEL7). Someone will need to
request CCEs and maintain them for CentOS;
- Figuring out how to handle Government profiles (e.g. the STIG) being
ran on CentOS. Opinions vary if all rules should come back
"notapplicable," as there is no STIG for CentOS or if select rules
should fail (e.g. the FIPS as mentioned above). This will need to get
sorted.
There's been a few requests for supporting CentOS in the past, however
there hasn't been a large pool of developers who were be willing to
port, and support/maintain CentOS content. Such an undertaking would
likely be hundreds to thousands of man hours. That changed a few weeks
ago when a PR landed to do some of the initial porting; work on that
seems ongoing [1].
#2 - If I were able to get proprietary SCAP for a desired standard. Is
it so proprietary that it isn't likely to be useful with scanners like
openscap-scanner?
Content specifications are maintained by NIST as an open/published
standard. As long as your interpreter supports the SCAP version(s) your
content is authored in, your content can be from anywhere.
#3 - Are there places that sell the relevant SCAP files that I may be
interested in that are considered by the community as 'good quality'? If
so what are some of these companies? (With my new found understanding of
all the different pieces I'll be googling around today to see if I can
find some on my own but if people here already know that would be
great).
This is a really good question. Quality of SCAP content varies greatly.
NIST attempts to create a centralized repository, however much of the
content there is stale:
https://web.nvd.nist.gov/view/ncp/repository
It'd be interesting to hear what other repositories exist.
#4 - It seems the OpenScap Security Guide is converting some type of
'list of rules' into the scap format for RHEL 6 & 7. And 7 being a work
in progress. Where is it getting the list of rules? What standard are
those rules based on?
SSG represents a large catalog of security-relevant configuration
options. From this catalog, selections are made and form what are called
profiles.
Some of these profiles, such as "General Purpose Operating System"
represent a body of community-derived "good ideas." There is nothing
formal/regulated about them.
Other profiles, such as the DoD STIG, are driven by specific
requirements imposed by a regulator (DISA FSO, PCI, NIST...). DoD states
passwords must be a specific length, so we created a rule documenting
how to verify said password length and put it into the general catalog.
From there, the rule is enabled in the DoD STIG profile.
A side question that no one here can likely
answer, why isn't RHEL setup by default with those rules as 'passing' if
its a good default?
RHEL must support laptop to mainframe, consumer to enterprise. Your
average consumer would scream if you made them encrypt all partitions,
use a bootloader password, create 14 character alpha-numeric passwords,
disable USB, etc.
Work is progressing to future versions of RHEL7 having an installer
plugin that, during the OS installation, allows users to select a
security profile. Once selected, the OS will auto-configure itself to
said baseline.
[1] https://github.com/OpenSCAP/scap-security-guide/pull/507
--
SCAP Security Guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/
