eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
It used to be, an Oracle database would ship ready to run on one port. Youd lock that one port down, and youd be reasonably secure. Nowadays, all bets are off, as vendors crank up feature sets and complexity skyrockets.
A recently reported, high-level Oracle security vulnerability underscores this problem. This particular vulnerability, which has to do with SSL (Secure Sockets Layer), affects certain releases of Oracle9i Database Server, Oracle8i Database Server, Oracle9i Application Server and Oracle HTTP Server.
If Oracle9i is vulnerable, 10g is guaranteed to have holes, security experts say. While vendors such as Oracle are balancing increasingly complex iterations with ever more security features in order to manage security more granularly, its still harder to manage security. As you have more and more features, there are more opportunities for more security holes to pop up, as fewer and fewer people in the data center understand what all those moving parts do. “Today, theres a dozen services running on a dozen ports,” said Aaron Newman, CTO and co-founder of Application Security Inc. “Most people dont understand what those ports do.”
So how will Oracle be addressing the potential for security leaks? I went to Oracle Chief Security Officer Mary Ann Davidson to get the answer. Between addressing the National Cyber Security Summit last week, presenting at the Infosecurity 2003 show in New York this week, and grappling with new Oracle security vulnerabilities announced this week, she managed to squeeze in some time to answer, and heres what she had to say.
Next page: Oracles top security guru on securing the database.
Oracles top security guru
on securing the database”>
eWEEK.COM: Relating to the fact that you just addressed the Cyber Security Summit, Im wondering, are databases a particular point of weakness in national security?
DAVIDSON: Consider the human body, which also includes a number of organs with disparate functions, all of which are geared to preserving the life and health of the individual. You might ask whether the heart is more at risk than the liver? Or the immune system? Or the brain? You cant answer the question without understanding what the risks are to each organ, and what other risks there are to the system as a whole (e.g., people who skydive are at greater overall risk than those who sit on the porch knitting).
As with any other type of systems, national security systems are themselves subject to risk mitigation. That is, what is the threat (to the system)? What are the remedies for those threats? Can we completely mitigate the threat, or is there risk that we cannot reduce? Some of these risks will vary “body by body.” It is not as if there is only one database for all national security; there are many, used for different purposes, in different configurations.
At the macro level, databases are actually part of our ability to ensure national security because they are the workhorses for so many defense and intelligence entities in terms of data collection, analysis, including our ability to tie seemingly unrelated events together (connecting the dots), and the like.
eWEEK.COM: What about when it comes to small/medium database users—are their database protection practices prone to being compromised—more so than large enterprises or government usage?
DAVIDSON: Again, you cant come up with a blanket statement without looking at the overall “body of health.” For example, if you dont secure the operating system, the database that runs on it can be at risk even if the database itself is configured securely. For example, if I lock my jewelry box, but the burglar breaks into my house, she can walk off with the jewel box—so much for the lock!
Also note that many users have databases in their systems they may not even know about. This was one of the reasons Slammer spread so virulently, because of the embedded databases in other products that the customer/user did not even know was there and thus did not know to patch. Its as if your basement flooded in a hurricane, and you were astonished because you did t even know you had a basement, or youd have sandbagged it. [Editors Note: Click here to read about last springs infamous SQL Server onslaught.]
Next page: Common mistakes made when securing the database.
Most common mistakes when
securing databases”>
eWEEK.COM: What are the most common mistakes made when it comes to securing databases?
DAVIDSON: The most common mistake overall is for anyone to assume that something “behind the firewall” will not be attacked, or alternatively, that their insiders are all upstanding citizens. I believe John Pescatore at Gartner has a quote that states, “Seventy percent of the attacks are from the Internet, but 70 percent of the damage is from insiders.”
Start with basic security (lock unused accounts, require strong passwords or strong authentication, ensure least privilege, audit regularly and maintain secure configurations).
Next, think defensively: assume that someone gets past your firewall and the middle tier; now, how do you protect the database? Assume someone wants to get your data, not that “nobody would ever do that.”
If you expect that a burglar will try to break into your house, you are going to plan and act differently than if you think, “Well, I live in a nice neighborhood, so I dont need to worry about being robbed.” Cyberspace is not a safe neighborhood.
eWEEK.COM: What are, or can, vendors do to make their databases more secure/more easy to secure? For example, what is Oracle doing differently with 10g than it did with 9i?
DAVIDSON: Making default configurations more secure out of the box is important, but surprisingly difficult because of the “dependency problem.” For example, if I change one security setting (in the database) from “true” to “false,” what happens to all the products that run on that database? Do they require the security setting to be “true?” Coming up with security settings is not difficult; it is making sure that changing those settings does not break anything else.
We have built some security health checks into 10g that help automate best practices. Also, we are able to determine if customers have applied the latest security patches. Both of these enhancements make it easier for customers to secure their systems and maintain that security.
Will locking the database down by default help secure this vital enterprise component? Can vendors do more to help? Tell me your thoughts at lisa_vaas@comcast.net.
Database Center Editor Lisa Vaas has written about enterprise applications since 1997.
Do you trust Oracle to inflict a more complex database on you without compromising your enterprises security? Chime in on the discussion at eWEEK forum.