What is most valuable?
I'm going to be discussing the enhancements to the PL/SQL language in what I'm going to call the bad old days, what we did was we put all of our application code and all of our application objects into one schema. What happened when you would do that is you would have say a SQL injection bug in one piece of code and you could easily point it to very sensitive information. As a matter of fact, I believe Barclay's said 97% of the data leakage is from SQL injection.
Oracle made an enhancement to the language. They added two things that were very powerful. One was the ability to add roles directly to a PL/SQL package. The other thing they added was an accessible by clause such that if I am going to have objects in one schema, instead of granting access to those objects to an entirely other schema such as your app code, I can just grant the access to that object to the program that actually calls it so I could have sensitive objects granted to a sensitive access code. Anybody else tries to get to it, you're not going to be able to get to it.
Then they added one other thing because what you want to do is you want to layer your security. Then they said make it accessible-by. When you accessible-by clause in, the object that is granted access to it, it'll execute, but if anybody else tries to execute that package to get to the object, they're going to get failures. That is what's got me most excited right now about the Oracle language and what they've been working with.
The value is in locking down your data, every time we turn around, we see on TV, GAO got hacked. Somebody's losing their information. You have companies out there going, "We'll protect your private information if you ever lose your information." We shouldn't have to do that. As stewards of this sensitive data, we need to build a security solution around what's sensitive and now Oracle's given us more and more powerful tools in order to implement that.
How has it helped my organization?
The biggest benefit is you're closing holes to SQL injection bugs. If I have a program, say program unit A has a PL/SQL injection bug, and you haven't implemented this, if I can inject into A, I can get to the sensitive information. But now by granting the role to the package and also granting accessible by, saying this package is only accessible by this other package, if A tries to get in, it says no, you don't even have rights to execute the code to get to the data.
What needs improvement?
In the next release, I'd like to see the ability to shred ghost data. I'd like to see the ability to when you run a data pump export of encrypted data and you did not specify encrypted in the command line, the data will be saved unencrypted and it'll spit up an error message, but it's just a warning saying, "otherdata is unencrypted." That does not get into the audit trail. That needs to be in the audit trail so an auditor can later go and say, "Why did we save data unencrypted that's sensitive?"
What do I think about the stability of the solution?
The stability is fabulous. I have one customer that has scaled this out and the application's now reaching over 100,000 users and we have not had any problems with it.
How are customer service and technical support?
Oracle's technical support, I use it about once or twice a year. Normally, if I call support, we've got a real problem and they've always been very helpful.
Which solution did I use previously and why did I switch?
My current customer, it's because a law was passed. This is a new architecture. Similar in terms of the language, but it's enhancements to the language, but what we're doing is building an architecture on top of what the language is now giving us.
What about the implementation team?
It is much easier to set up this solution, designing it in from the beginning because if you try to go back and retrofit your code, it can be done, but it's much more labor intensive. You should always build your security in upfront. Retrofitting code, it's difficult. It can be done because you have to separate your stuff out and sometimes, it may seem like trying to pull the salt out of soup. It depends on just how tightly integrated it is.
Which other solutions did I evaluate?
Considering the work was already being done in the Oracle and PL/SQL, this was just an enhancement to what we were already doing.
What other advice do I have?
I would give it a 9 because when we first started doing it, we found just little irritating niggles. I wish they had implemented it a little bit different, but overall a 9.
Absolutely do it because if you value your data, you want to be able to secure your data from SQL injection flaws.