News Stay informed about the latest enterprise technology news and product updates.

Locking down your sensitive Oracle data

Every company says that securing its databases is a priority, but almost every one that Kenny Smith has seen has unwittingly left a door open to attack. Smith, the director of services for Inplexus, the Norcross, GA-based security and availability arm of professional services firm Cnetics, makes a living trying to break into database systems. At next month's IOUG Live! 2005 show, he'll impart some of his wisdom so that you can make sure your systems are sealed tight. Here are a few of his hints.

In your presentation at IOUG, you'll be talking about HIPAA, CISP, and Sarbanes-Oxley as a few regulations that are pushing organizations to better secure their Oracle systems. Has Oracle responded directly to these initiatives to improve features, or are the companies themselves just realizing where potential trouble spots are?
Both -- I think there are three big components in securing the database space: First, the vendor has to have the feature or the function so that the database can meet the requirements, like auditing. Then the software vendors, like SAP, PeopleSoft, Oracle, have to be compliant. Then the company has to make sure that the things the regulations call for are implemented. The biggest onus is on the company. What are a few specific vulnerabilities in a typical Oracle system?
The main one you might see is the use of default user names and passwords, across the board on all kinds of hardware and software. If a system person has not changed the password or removed the account that is known to anyone, it's an easy way to break into the system. Another vulnerability is granting too many privileges to system users. A lot of times developers and DBAs, in order to get the system to work, they just grant a whole lot of permissions to someone, and that someone then has ability, though not usually maliciously, to create copies of credit card tables or whatever. The third vulnerability would be the fact that auditing is not turned on by default. If a breach happened or some problem occurs, there is no trail. All three of those things are a matter of people running database being so busy. They fail to have knowledge of setting up [a secure database]. Besides making the obvious changes to the vulnerabilities you list above, what sorts of changes are you having to make to get most systems in compliance?
One of [the services] we provide for people are the tools to look over obvious parameter settings. We also help with clustered databases and other availability issues. How easy is it to leave a database vulnerable?

ABOUT THE SPEAKER

Kenny Smith joined Cnetics in the fall on 2002. He specializes in Oracle database architecture, database administration and development. He began authoring Oracle technology in 1998 in Oracle Magazine and has published over fifty articles in several industry publications.

In the winter of 2002, Kenny co-authored "Oracle Backup and Recovery 101" from Oracle Press was published. Kenny has presented papers at Oracle's OpenWorld, HP's HPWorld, the international Oracle user group's (IOUG) conference and other conferences in the US and Europe.

He currently holds the Certified Information Systems Security Professional - CISSP Certification and is an Oracle Certified Professional - OCP (Version 7, 8, 9i). Kenny currently serves on the board of the Georgia Oracle User's Group.


It's easy, but it is getting harder with each new release of Oracle. What are some of the features that are new in 10g that make it harder?
Some of the standard user names and passwords that in versions 8 and 9 were set up by default are locked accounts on 10g. So, it starts up out of the box more closed than it used to. It has better encryption capabilities with the package dbms_crypto. And it has enhanced auditing -- fine grain auditing. Also, the concept of the virtual private database has gotten better. Some critics of Oracle say that the company isn't reacting fast enough with its patch updates to a growing number of publicized bugs and holes, and specifically that in the last release, several prominent vulnerabilities weren't addressed. What's your take on the situation?
There's a challenge for anyone who's going to patch a database. If you are running Windows on your computer, you can decide there is a new worm, so you go to Microsoft's site and click a button to get a patch. But a database runs a company, and you can't just apply a patch like that. You must plan a reboot, and if it doesn't work and the business can't run, you've got a problem. With the level of severity of a patch with Oracle, the stakes are higher. I'd rather they get it right. Just to patch a database can be very involved. And usually the database is inside a trusted area, so I am not as concerned that they are quick to make changes. I'd rather they be complete. How do you see Oracle's latest acquisition, identity management firm Oblix, fitting into and influencing Oracle's overall security plans?
I think it's a good move for Oracle to beef up identity management. One of the requirements of the Cardholder Information Security Program (CISP) is that all accesses to credit cards are audited. Oracle's out-of-the-box features provide much of what a company would need to uniquely identify someone, but by having integration with a vendor that has token devices or another way to authenticate a user other than by username and password -- and having that integrated with the database engine -- could be a big relief to lots of companies. Almost everyone has this problem. E-trade now provides tokens to customers, so if you want to make a trade, you've got to have this device to stick into your computer. It makes it harder [to break in]. And that's going to be what happens with database access. You'll need something you have with you, or some part of your body (biometrics). I think companies are going to go more toward using token devices. Since you said that the onus is on the companies to keep their systems secure, can you tell them the one thing they should be doing?
The management needs to understand consequences of failed database security. Look at a company that's been in the news the past couple of days -- how much has it cost ChoicePoint? And look at the cost versus what they could have spent in terms of internal staffing or external staffing, which I think is better. If you're going to build an application, it's good for internal staff to do it because they know the business. But when you're dealing with security, someone objective will see things that have been there forever that [insiders] have missed. One thing I am running into is that people try to keep costs low, so they overwork people, telling them that they must know new features, and do performance tuning, and oh yeah, also make sure that database is secure. But they haven't had anyone out of the group check it. I've never been in situation where I haven't found a key vulnerability. In all but one, I've been able to find a password to unlock. Management is overworking people to know and do too much. The body of knowledge for DBA is expanding -- they're expected to run a database with more features than it had five years ago, and in some cases also run an application server. If they bring someone like us to look at it, it's not a lot of money, and we can give an objective opinion. But, one of problems with security is that it's a hush-hush thing. They've actually have had to pass laws to get people to reveal security breaches.
FOR MORE INFORMATION

Kenny Smith  will be speaking at IOUG Live! 2005 on May 1 at 8:30 am.

Dig Deeper on Oracle database security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide.com

SearchDataCenter

SearchContentManagement

SearchHRSoftware

Close