What needs to be done?
In my last post I talked about the legal rules of the road in regards to designing and implementing a database information system, starting from the top level and driving down to the nitty gritty step-by-step hardening instructions, including the STIG. Once the applicable rules are understood, it is important to harden your system according to them.
I’ve posted several times on the DISA Database Secure Technical Implementation Guide (STIG) and how it is the standard for Oracle database hardening within the Department of Defense, but it isn’t the only standard out there. In this post I’m going to highlight some of the other hardening checklists available, as well as some tools (free, of course) that can be used to help you conduct audits and evaluations of your system.
How can I do that?
So what resources are out there to help you harden an Oracle database? Lots. In fact, I would be tempted to say too many. A quick Google search for “Oracle Security Checklist” will produce dozens of possibilities. Here’s a couple of the most prominent:
- The Oracle Database Security Guide – Often the best place to start is with the official documentation. While the documentation is certainly complete, it is also big. It makes it clear how daunting a proposition securing an Oracle database can be.
- The Center for Internet Security’s Oracle Database Server 11g Benchmark v1.1.0 – This is a very comprehensive checklist for Oracle 11, worked up in cooperation with the National Security Agency.
- The SANS Institute has a couple of different Security Consensus Operational Readiness Evaluation (SCORE) checklists. They are very similar to the CIS benchmarks.
- The DISA STIGs (my favorite) are the the most up to date checklists. DISA posts updates once or twice per year.
Even a cursory review of these checklists reveals hundreds and hundreds of control items. Some are technical (set this parameter, enable or disable that option sort of things) that are easily checked. Many others are procedural or policy controls that take a more thorough investigation and defy any sort of automation. Just to work through any checklist from beginning to end requires a significant amount of time and effort. Fortunately there are some tools available to lighten the load a bit.
- The Java-based DISA STIG Viewer can generate an XML form of any STIG checklist and allows you to save results that can be exported as XML or an Excel spreadsheet. It’s only shortcoming is that it works with flat files and doesn’t support a multi-user format. If you’re the only one working on a checklist that’s fine, but if you’ve got multiple people trying to participate in the review then working from a single file can be a bit of a pain.
- The Scuba Database Vulnerability Scanner by Imperva automates many of the controls that are defined in the STIGs, CIS Benchmark, and Oracle Database Security Guide. It’s a good first step in evaluating your database. The downside is that the vulnerability profile hasn’t been updated since 2009, so it may not identify some vulnerabilities correctly if your version of Oracle is more recent.
- The Oracle Enterprise Manager can conduct security evaluations based on recommendations of the Oracle Database Security Guide. OEM carries a fair amount of infrastructure and administrative overhead, so this isn’t for everyone, but if your organization is already using it then this may be a feature you could take advantage of.
Once your security review is complete and your system has been hardened, a variety of other tools are also available to help you test the effectiveness of your configuration.
- tnscmd is a Perl script that can be used to send commands to a remote Oracle listener.
- Metasploit can be used to test a wide variety of infrastructure components.
- Oracle Database Attacking Tool (ODAT) can exploit a variety of internal and external vulnerabilities.
How does that help?
At this stage of the process it’s a little hard to quantify exactly how proper hardening and security testing can help the bottom line. I look at it as proper investment in the infrastructure. It’s not enough just to know the rules. If you are really going to enforce them, you need to get down and dirty with the details and harden your system (and your application design!) as best you can. You’re going to have to get all your policies and documentation in order. You’re going to have to test your configuration to be sure it is resistant to known exploits, both internal and external. Some time and effort spent up front to do things correctly will save you a lot of time and money down the road. It could also mean the difference between your data – or your customer’s data – falling into the hands of someone it shouldn’t. The process can be time consuming, even with the tools I’ve listed here, but in the long run this investment will save you in more ways than one.