On January 25th I’ll be giving a ZDNet webcast (sponsored by Oracle, but objective content, as always!) on database security resolutions for 2008.
I’m taking a bit of a different approach on this one; the presentation is targeted at both database administrators and security professionals. Yes folks, I’ll be bridging the great divide. (I used to be a DBA, so I know a little of what I’m talking about).
For each of the resolutions we’ll discuss the implications for both sides- what does the DBA need to do? How about the security admin?
Here are the Top 5 Resolutions with a little descriptive text. Let me know what you think, and if you have a better suggestion and I use it I’ll make sure you get full credit in the webcast…
- Identify, and classify, databases with sensitive information: one of the biggest database security issues we face is just figuring out where the heck our databases with sensitive content are in the first place. If you think you know, you’re probably wrong. I can’t tell you how many calls I’ve been on with clients where the application, database, and security admins in the room each think they have a good idea and are proven wrong within 30 minutes. We’ll discuss how to locate these systems and prioritize them for later remediation. We’ll also discuss tools that can help with the process (generically- I’m not pushing any products). We’ll also discuss how security and database teams can work together on the process, and where their mutual interests overlap (killing rogue DBs).
- Implement database configuration and vulnerability management for your highest-priority systems: no, not all at once. And while tools help, you can also do much of it manually. We’ll talk about the roles of configuration and vulnerability management, who is responsible for what, and how teams can work together. Yes, it’s basic, but not something that everyone has down, and like making that annual resolution to lose 5 pounds, it’s worth revisiting every now and then.
- Enforce separation of duties between DBAs and security: now we’re getting into the more interesting stuff. As much as we trust DBAs and security, when sensitive information is concerned (especially regulated information) we have to… enforce that trust. We’ll talk about the different ways to to this, and how to implement it without interfering with anyone’s ability to get their jobs done. While DBAs might not be happy with this change in trust, security pros have a large burden- to start learning how to protect databases they won’t manage (SoD works both ways).
- Start Database Activity Monitoring (or at least better auditing): no surprises to those of you who read this site. I’m a huge fan of DAM. We’ll talk about using it for separation of duties, for security, and even for regular old database tuning.
- Control ad-hoc access: I hear from a LOT of clients that ad-hoc query access by users is out of control, often on data users shouldn’t get near outside a business application. Here we’ll talk about how DBAs and security managers can team up to end this bad habit, without pissing off the entire business. For once, compliance will be your friend.
- Bonus Resolution: Start paying attention to web applications and connection pooling: I’ll save this one for the webcast.
Over time I’ll cover most of these issues in blog posts as well.
Let me know what you think. Are your database security resolutions any different? Am I just full of my usual $#%^?
I’ll post the webcast details when I get them; the registration page should be up later this week. And don’t forget to pass it on to your DBA friends…
<
p style=”text-align:right;font-size:10px;”>Technorati Tags: Oracle, Database Security, Database Activity Monitoring, Compliance, Separation of Duties
Reader interactions
7 Replies to “Your Top Five Database Security Resolutions For 2008”
You make a number of terrific recommendations, but let me point out that I have a vested interest in agreeing with you. I am the co-founder of SoftTree Technologies, http://www.softtree.com. Our DB Audit Expert was developed to address the very issues you highlight.
It’s nice to hear that industry experts are beginning to tout the need we saw five years ago.
[…] has opened registration for my webcast on database security. As mentioned before, this one is designed to walk the line between DBAs and security admins- taking 5 key […]
The only alternative I am aware of is to not use connection pooling, as normal connections pass the correct information, but you will have to tolerate additional latency. I am somewhat surprised the database vendors have not made the alterations to the ODBC/JDBC driver objects to make the job easier as they are all touting products for compliance and security. You would think fixing a simple variable pass would be a high priority.
And “reprogramming the application” makes it sound worse than it is, as you are adding one step in the application’s DB connection code before it hands off the connection thread to the process that requests it. Simple, but annoying to have to do. The contortions we go through could be easily addressed and make this a non-issue with a few changes to the database connection objects, but database vendors have been sitting on their hands for years now. Oh well.
By the way, there are some pretty cool scripts that are publicly available to disconnect users who perform ad-hoc connections, like Toad or Embarcadero for example. I wrote a couple here for a customer that disconnect the session and send an alert. Fairly easy and can be incorporated into DAM products or implemented as stored procedures or login triggers. It’s a bit of a two-edged sword as DBA’s are more productive with these sorts of tools, and these tools provide safety and accounting features, but some organizations want tighter controls on change management and therefore implement these policies.
Rani’s comment is right on target, the hackers are going to try the easy stuff first. Pen Test for weak passwords and assessment for operational and security vulnerabilities to get the easy stuff. I retract my earlier statement that addressing connection pooling should be at the top of the list.
1) IMHO, suggesting a comprehensive solution to connection pooling is snake oil. Specific components of the problem (some Web apps with a little work) are possible, but anything beyond that is marketing run amok.
2) Connections between these components (“resolutions”) are critical to the success of any database security project. For example, without a linkage between configuration / vuln management and monitoring organizations will need to tune their monitoring manually (or risk a flood of alerts for irrelevant events, inability to flag important conditions, etc.). This isn’‘t just a theoretical concern, either. Without it, keeping your monitoring up to date as you slowly and progressively roll-out patches (or monitoring policy updates, new system configurations, etc.) will rapidly drive you insane (not to mention out of compliance).
Rich, you won’‘t get any argument from me on number 4… seriously though, I don’‘t know whether this is the kind of thing you’‘d include under configuration, but simple things like least default user names and strong passwords are still often neglected. These are the first things any hacker tries (easy things first).
I see config management in the DB group, but vulnerability assessment in security. Unless, of course, the DB group can’‘t organize well enough to manage configurations. And standards are established by security and DB working together.
Any suggestions for connection pooling that don’‘t involve reprogramming an application or buying a separate product? I know you’‘ve been looking at that (even though you also work for a vendor that handles this well as part of the product).
I think it’s a good list. If I had to pick a top 5, I would throw out ‘‘Ad Hoc Access’’ and move the connection pooling and web access to the top. Connection Pools are not that hard to address and make your auditing better. Most web based applications just don’‘t do enough to filter and validate requests to the database, and become a primary culprit for many vulnerabilities and weaknesses. These safeguards are just not that difficult to implement and provide a lot of value.
Proper separation of duties can address many of the ad-hoc connection issues, especially when you combine division of the DBA role with auditing of activity. This is a powerful combination, both from a security and workflow perspectives.
Question: If database monitoring should be owned by security, who do you think should own configuration management and assessment?