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