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 Share: