Sweny M. Sukumaran
Foreword
When I first became aware of Adrian Neagu's intent to author a book on Oracle security, I sent him a congratulatory note. This is an important subject area, and I felt a special need to pass on my best wishes. His first book IBM DB2 9.7 Advanced Administration Cookbook, Packt Publishing , had a chapter devoted to database security that shared some of the knowledge he had learned as an IBM Certified Advanced DB2 Administrator. I was excited to hear that he was now going to put on paper some of the knowledge he has gained from real-world security experiences as an Oracle Certified Master Database Administrator. He was going to help educate Oracle IT professionals on techniques they could use to protect the data and server assets placed under their stewardship.
The title he chose for his second book, Oracle 11g Anti-hacker's Cookbook , really grabbed my attention as well. The book's title seemed to conjure up images of evildoers on the internet placing their sights on attacking systems and attempting to steal or compromise the data they contained. We've all heard stories about hackers that have broken into systems and stolen our data. They've actually gotten some of my personal data by compromising the systems of a couple of companies whose products I have purchased. The same group or others like them may have taken some of your data as well. There are bad guys out there, and there are certainly many that try to get into systems for amusement, malice, or profit. But hackers are not the only ones that can harm or inappropriately access your data. I've been personally involved in situations in which identified risks were traced back to an authorized internal user who was doing some things he or she should not have done. Those situations could have been prevented with some of the controls described in this book. They may not have been available then, but they are available now in the enhanced Oracle 11g security-oriented features.
As someone who has worked with databases for over 20 years, across a number of industries including aerospace, manufacturing, financial, government, educational, and retail, I've seen firsthand how reducing security risks has become more and more a key part of an Oracle professional's responsibilities. What interested me about Adrian's latest book endeavor was that it offered an opportunity to help educate more people about the increasingly important topic of database security. The cookbook and recipe approach he had chosen to use sounded like an interesting way to convey the main concepts and techniques behind the threats he wanted to describe to the reader. More importantly, the recipes he was going to create were going to show some ways those security risks could be mitigated or reduced. He had me hooked and ready to read his book. The only problem for me at that time was that he hadn't completed it yet. Only a few of his recipes had been cooked up, and when I sat down to get an early taste, they were being brought to me one selection at a time.
But the full course is now ready to be served. It's at your table and on your plate, and I recommend that you take the time to check out his menu of security-flavored delectables. There is a logical flow to his cookbook style, and certain recipes do build on and complement each other, so I would suggest starting from the beginning. But don't be afraid to dive straight into any selection that piques your appetite. You will learn something important about Oracle security no matter where you start or end, and that's the main desire of this IT chef. Unless you have spent many years working in the area of database security, there is a good chance that you may have never tasted beforehand some of the recipes he presents. Have you ever really seen how a hacker can hijack a database session? If not, there is a recipe that shows you how it can be done. Have you tried to crack a password for a trusted Oracle account? There's a recipe for that too. Do you know how to keep the privileged root user from modifying important database files such as listener.ora
? If not, you will learn how to lock this down tight, in another recipe. Has a hacker or malicious user gotten in and modified something in the database or in a file that shouldn't have been changed? You will find out how to know that it has occurred and how to prevent it from happening, with some of his audit and modification detection and prevention recipes.
You'll also sample some information related to limiting access to trusted users such as database administrators. In the past, this group usually had the keys to your data kingdom. They could see and do anything they needed or wanted, there. Sure, you could trust them. You knew their name and they sat right next to you at the office table. But is that the case anymore? Does your junior DBA staff need as much access as your senior DBA staff? Do your systems administrators need to see your database data? Does your remote contractor resource need access to everything, or do they only have to be able to do the tasks you want them to do and see only the data they really need to see to do their job? With powerful Oracle 11g features such as Database Vault, if your risk profile and data sensitivity needs warrant it, you can place tighter restrictions on what a DBA user can and cannot do with your data. There is a recipe that will help show you that as well. If you want to encrypt your data so it can't be deciphered by someone that may have access to it but doesn't need to know what it is, there are recipes here that are going to help explain how to do this too. You probably also have certain regulatory requirements that require you to prove to auditors that you know who can do what in your database as well what they have been doing. Guess what? The Audit Vault recipes are going to help you here.