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/0004...
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