This blog post was prompted by a comment on my website by Chris Peterson, where he asked why the 11g STIG checklist doesn’t work against Oracle Database 12c. This required a more comprehensive answer than I could give in a simple comment, so that’s what this blog post is all about. Let’s start off with a bit of an introduction for those of you that are asking, “What the heck is a STIG anyway?” 🙂
What the heck is a STIG anyway?
Well, firstly, “STIG” stands for Security Technical Implementation Guide. STIGs are published by DISA (the US Defence Information Systems Agency). According to the DISA website, “The STIGs contain technical guidance to ‘lock down’ information systems/software that might otherwise be vulnerable to a malicious computer attack.” They are available for Operating Systems, Applications (Application Servers, Databases, etc.) and much more. Many US Government agencies are required to follow them, and many US and non-US commercial companies voluntarily follow or base their internal standards on these benchmarks. Most of what I’m going to cover in this post relates to Oracle Database STIGs, but some of it is more generic than that.
There are a number of challenges to implementing STIGs. These include:
- It is mainly a manual effort to check / validate conformance (and of course, non-conformance)
- Over time, drift can result in undetected violations until the checks are repeated
- Validation is very costly and resource intensive, not least because some of the checks are related to process and cannot be automated. In these case, you need to follow an interview process to validate the process is being followed.
So the main requirement is to try to automate as much of the solution as possible, to continuously validate against the STIGs. It is also necessary to provide proactive alerting of change resulting in non-conformance. This is where Enterprise Manager comes into the picture.
The Process of “Productizing” a STIG
One of the questions I’ve been asked multiple times around STIG compliance is “can I just import a new version of the STIG into EM?” The answer is simply no. There’s a lot more work to it to “productize” a new version of the STIG. Here’s what actually happens behind the scenes which might explain why this isn’t as straightforward as most people would like.
- The first step in productizing a STIG guideline into EM is, of course, for DISA to release a new version of the STIG. Now that might seem obvious, but the reason I’m pointing this out is it can take quite some time for that to happen. Let’s take an example of the Oracle Database 12c STIG, as that is one that is of a lot of interest to people right now. The first release of Oracle Database 12c, version 220.127.116.11, was released in June 2013 if memory and Wikipedia serve me correctly. 🙂 According to this document on the DISA website, Release 1 of the Oracle Database 12c STIG was announced on October 7, 2015. Obviously, that’s quite a bit later than the database release date, so where does all that time go? Well, a fair chunk of it is in working out just what goes into the STIG. While an earlier version of the STIG (say the 11g release 18.104.22.168 release) can be used as the basis of a newer version, when there’s a major change in the Oracle Database version number there’s a lot of work done by DISA in conjunction with Oracle to determine what changes need to be made to the STIG to match the greatly enhanced functionality of the new database release.
- Once the STIG itself is released, we (as in Oracle) need to work out what can be done to address each guideline. Keeping in mind that there can be hundreds of individual rules within a STIG, that’s no short task in and of itself! Plus, of course, as I mentioned above some compliance rules based on a STIG need a process-oriented response, not a technical one.
- Once these responses are collated, we also need to build a reporting framework around the new guidelines, because it’s not just sufficient to work out how to address each guideline – we also need to be able to report that we are meeting the requirements of a new STIG. In other words, we need to create a STIG Checklist for each target with the current rule status.
It’s the second step in the productizing of a STIG that explains why you just can’t import a new version of a STIG from DISA into EM and be done with it. Coming back to Chris’s original question of why you can’t just import an earlier version of a STIG against a new release, I think you can also now understand:
- There will be new guidelines in a new release of a STIG to account for the enhanced functionality of a new release. The older version of the STIG just doesn’t have those guidelines to work with.
- And of course, there are new responses to match those new guidelines. Again, the older version can’t meet the needs of the new release here.
- And equally of course, the old version doesn’t have the relevant reporting capabilities to build the STIG Checklist which is such an important part of validating compliance against a new STIG.
I hope that helps to clarify the issue for you, Chris! And just to whet your appetite, let me just add in closing that productizing of the Oracle Database 12c STIG in Enterprise Manager is something we’ve been working on for a while, so watch this space!