On 9/5/14, 9:18 AM, leam hall wrote:
Shawn,
I'd like to respond to several points made in your e-mail. The first,
and most critical, is that one cannot watch "to (sic) much Star Trek".
You should be ashamed of yourself for implying such and I'm sure your
next performance report will reflect these sorts of failures.
Hah. I've been NetFlix binging. Now on Season 7, ep 160. No spoilers
please ;)
Since we haven't met I'll simply accept your apology and admit that
that part of your e-mail impressed me. Often the ones who can't
apologize are the ones most needing to do so. If your behavior follows
your apology then the world will be a better place.
Parts of the world, however, are crap. It seems that not enough
decision-making Hatters "get" the "E" in RHEL, especially when it
comes to STIG environments. If that part was graded today it would go
down in flames.
In the past, Red Hat STIGs have certainly been rather haphazard. I'd
argue one cause was lack of community in their development. There
was to much disjointedness between those who wrote the STIGs and
those who had to implement them. Also, Red Hat itself wasn't fully
engaged which lead to support issues when deployments would call Red
Hat for support.
These two issues -- community consensus on what should be in a STIG,
and how to properly support the baseline at the Vendor level --
became raised at very high levels within industry and government.
DISA FSO did their part by forming the Vendor STIG process.
Classically DISA FSO would develop a STIG on their own, and because
technology turnover rates are so high, FSO was constantly behind on
publishing STIGs. Under the new Vendor STIG process FSO effectively
hands over STIG creation to the vendors. Vendors have free realm to
develop the STIGs however they wish (as long as SRG requirements are
fully met). Once complete, Vendors hand over a formal package to FSO
for their review and final approval before an official STIG is
published.
On the Red Hat side, to address the community and support issues, we
partnered with NSA IAD to form the SCAP Security Guide project. The
charter was to create a large body of security controls from which a
STIG could be derived. I recall the initial meeting was Jeff Blank,
Trevor Vaughan, Mark St. Laurent, Dave Smith, Maura Daily, myself,
though it was ~3yrs ago and I may be mistaken. While the origins
were small, I would argue the community has grown into something
amazing. Contributions range from agencies such as NIST, NSA, FBI,
Oak Ridge, NRO, NASA, and industry partners like Lockheed Martin,
Harris, and Secure Innovations. The establishment of community has
helped connect the "policy makers" to the "policy consumers" in a
single project. Hopefully this collaboration will drive
enterprise-ready baselines (and in many ways, I think it has).
The formation of community is no trivial task and security
compliance efforts have incredible visibility at Red Hat. It's no
secret that part of my formal job is to manage U.S. Government
compliance baselines, but I don't know if where I fall
organizationally is widely known. To give you an idea, here is
screenshot of my reporting chain:
I share only to demonstrate:
(1) According to Red Hat's investor relations report from
31-MAY-2014 [1], Red Hat has some 6,500 employees. My participation
reflects full support at a level three tiers below the CEO;
(2) Red Hat's compliance efforts are organizationally backed by Vice
Presidents and General Managers. If something can't be accomplished
at my level, the immediate escalation path is to Lynne (my boss, a
Vice President) or to Paul (the General Manager of Red Hat Federal);
Hopefully this clears up concerns that Red Hat doesn't have
decision-making staff focused on security compliance. There's also
support of a wide network of influencers, ranging from the Chief
Architect of Red Hat Federal (Dave Egts) to Steve Grubb (Leads
Security Engineering), etc.
Concerns and comments relating to Red Hat's processes and overall
support for compliance initiatives get equally high levels of
attention, and we take feedback very seriously.
SSG seems to not get the Unix philosophy of "small tools that do one
thing well". When you had a scanning tool that could take criteria and
identify issues it was awesome. Now it seems to be growing into a
bloated mongo thing that only works with certain versions of certain
products from certain vendors and only ingests certain criteria that
are not related to the criteria actually used by the customer.
I share the mindset of small functional tools, which is why OpenSCAP
was broken into parts:
- OpenSCAP interpreter, now a NIST certified scanner [2], that can
parse any source of valid SCAP content, not just SSG. While I'm not
intimately familiar with the details, other communities have began
building OpenSCAP interpreter for their platforms. Ubuntu's last
build appears to be 27-AUG-2014 [3].
- SCAP Workbench, an optional GUI tool to scan and manipulate SCAP
content. The last build was just today.
- SCAP Security Guide: A framework for developing SCAP guidance for
specific technologies. Yes, today content exists for primarily Red
Hat technologies, however just last week I had a conversation on how
a 3rd party could start contributing nginx or ElasticSearch SCAP
content.
Functional limitations -- "certain versions of certain products from
certain vendors" -- are limited only by the available body of SCAP
content. This has nothing to do with OpenSCAP itself.
If you want to be successful you need to take a big step back.
1. Do not put your idea of "best practices" into the core measurement
criteria. The last time I looked at this:
1.a. The criteria was not a really good practice.
SSG content reflects a large body of checks from several agencies,
industry, academic partners, and Red Hat proper.
When forming an official baseline, such as the RHEL 6 STIG, we hold
"consensus calls" to take feedback from the various stakeholder
communities. The RHEL 6 call was on 25-OCT-2012, and the Aqueduct
community was invited:
https://lists.fedorahosted.org/mailman/private/aqueduct/2012-October/000418.html
It's unlikely that we'll be able to appease every individual
stakeholder. Well reasoned arguments for/against a rule should be
submitted to the mailing list for discussion, and patches are most
welcome.
1.b. The test flagged the issue as if it were equal to a STIG violation.
Well, since SSG is the upstream of Red Hat's STIGs, it's likely that
it *is* a violation. Review section 1.1 of the STIG Overview from
DISA [4]:
The consensus content was developed using an
open-source project called SCAP Security Guide.
The project’s website is
https://fedorahosted.org/scap-security-guide/. Except for
differences in
formatting to accommodate the DISA STIG publishing process, the
content of the RHEL6 STIG
should mirror the SCAP Security Guide content with only minor
divergence as updates from
multiple sources work through the consensus process.
In reality this divergence is a bit more pronounced. We didn't
expect SSG to take off like it did (not that it's such a bad thing!)
1.c. The test actually wasn't testing what it was said it was.
I get the impression this view is historical, so I'd invite another
review of the content to see if the comments on good practice and
false positives hold true today. There are most definitely bugs
though, and as you find them, it'd be great if you could open a
ticket:
https://github.com/OpenSCAP/scap-security-guide/issues
Fixes make their way into RHEL, and for any effecting the STIG
baseline, make their way into the content off iase.disa.mil. SSG
represents the democratization of the STIG -- the more feedback the
better.
STIG environments are accredited by people that seldom have a deep
knowledge of all technical areas. The STIG is the measurement, not
what you think things should be like. Separate your opinions from
actual criteria. Test against documented criteria.
2. Include active OS versions in the tools.
2.a. Few STIG environments are running nothing but RHEL 6 yet. If you
don't deal with RHEL 5 your product is useless to your paying
customers.
The OpenSCAP scanner is certified by NIST and is provided natively
on RHEL5+.
$ sudo yum install openscap-utils
Creating RHEL 6 content was an easy choice. It's the latest release,
and new technologies (e.g. OpenStack) are layered on top. RHEL 6
content was foundational for those needing baremetal and VM-level
deployments, and serves as a catalyst for future Docker and
OpenStack STIGs.
Today RHEL 5 content can be downloaded from DISA:
http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx
or directly @
http://iasecontent.disa.mil/stigs/zip/u_redhat_5_v1r8_benchmark.zip
RHEL 5 content can also be found from NIST:
http://usgcb.nist.gov/usgcb/rhel/download_rhel5.html
So then, in terms of SSG providing RHEL 5 content: The initial was
no way. RHEL 5 is in "Production 3 Phase" which is defined as [5]:
During the Production 3 Phase, Critical
impact Security Advisories (RHSAs) and selected Urgent Priority
Bug Fix Advisories (RHBAs) may be released as they become
available. Other errata advisories may be delivered as
appropriate.
New functionality and new hardware
enablement are not planned for availability in the Production 3
Phase. Minor releases with updated installation images may be
made available in this Phase.
Generating SSG content is nontrivial and takes considerable time to
make reputable content. RHEL 5 is scheduled for EOL on 31-MAR-2017
[5]. The time investment for a product that EOL's in a few years
isn't worth it. And even if we did develop content, RHEL 5 is to far
along in its lifecycle to add new RPM packages. We couldn't ship it
to customers.
With that said, the USGCB content is effectively abandoned and needs
a home. There's talk about importing the RHEL5 USGCB content into
SSG to give it a home. This would allow those who care about/need
RHEL5 SCAP content to build off the RHEL5 USGCB. If this is
important to you (you the reader, not just Leam) then please +1 on
the list.
2.b. Almost no STIG environment is purely RHEL. If you create a mongo
tool that only works on RHEL you have no value to the customer who
also supports Solaris, HP/UX, and AIX.
Ultimately adding SCAP functionality to an operating system is the
OS vendor's responsibility. If SCAP functionality is needed on
HP/UX, AIX, etc I suggest contacting your OS vendor rep. SCAP is an
international standard, so I'd be surprised if they don't provide
SCAP interpreters.
Note that OpenSCAP is open source and porting to other platforms
would be most welcome. As mentioned above, it appears other Linux
distros may be working on this [3].
2.c. This seems to be a RH problem as well. Upstart and systemd are
bad ideas for anyone that actually works in an Enterprise, just like
SMF is on Solaris. If you make an interface like chkconfig, awesome!
If you have to change how you do business because some vendor can't
work with a System V standard, well, maybe that vendor needs to be
re-evaulated.
This is total troll bait.
I firmly believe RH has the intellects and capabilities to change the
Enterprise world for the better. The behavior I'm seeing says they
just don't have the desire to be any more than a new flavor of has
been ideas like forking, control by lock in, and exclusion.
[1] http://investors.redhat.com/faq.cfm
[2] http://investors.redhat.com/releasedetail.cfm?ReleaseID=843440
[3] https://launchpad.net/ubuntu/+source/openscap
[4]
http://people.redhat.com/swells/rhel6stig/U_RedHat_6_V1R1_Overview.pdf
[5] https://access.redhat.com/support/policy/updates/errata