Mike,
there are generally a few sources of good guides out there for security hardening.
- The DISA STIGs
- The NSA SRGs
- NIST
- CIS Benchmarks
- Vendor guidance
- SANS
- Books specific to hardening
At my work, we use a combination of the DISA STIGs, along with puppet for Linux. I’d be more likely to say that is inadequate and push for some of the recommendations below.
Keep in mind that the hardening guides above do have overlap, and some missing areas. A best practice is to track all configuration options via guide in a database or spreadsheet, so you can have the most coverage.
An alternative way of doing the same thing is to create hardening or auditing scripts based on above, and then run audits of yourself to figure out where the gaps between the different standards are.
I don’t believe RHEL’s guides are sufficient – I prefer the outputs of the NSA, DISA and NIST. But, Red Hat’s guides are a great starting point.
As the NSA and DISA start working on hardening standards far in advance, in draft, that may be a good source for you. If you have a friend in DoD, you can get access to pre-release material too. Due to the current state of the DISA STIG for Red Hat, I’d say the NSA is likely to produce something faster. I can check in with them and see where they are. I’d recommend starting to move forward to 6 in a testing environment right now. Get your hardening scripts tested in 6.
Engaging outside assistance to develop security hardening guidance
Consider an engagement with a Security Engineer focused specifically on Linux security hardening to produce guidance for you. Red Hat can make available their employees for engagements as well in order to accelerate security engineering efforts.
Everything you’ve said thus far indicates a due diligence approach and reasonable security. Based on that, I think considering above, you are clear to move forward to RHEL6. However, I am going to add some additional tasks you could consider since I assume you are working in a regulated environment that is very security conscious.
Augmenting your approach with a Risk Assessment
If you wanted to take your approach to the next level, and justify it in a way would pass review by even the most retentive auditor, consider performing a full blown developmental risk assessment using NIST 800-30 along with the particular controls sets used in your industry. This, supported by security testing & analysis. Having a risk assessment formalized will enable a good documentation of the risks presented by going forward with RHEL6, and some potential compensating controls you could add to buttress any potential weaknesses.
Adding a penetration test
Taking it even beyond the risk assessment, you could engage a penetration tester with a strong Linux background to attempt white box or black box penetrations of your RHEL6 host after some secure configurations. A secured base operating system might not present much attack surface so loading it with applications would present a much more realistic platform for attack that would better enable you to understand potential attack vectors. Circling around at the end, using the pen test report you could augment your previous work, close any gaps, add additional controls and head towards operations with much more of a warm and fuzzy.