Page 2

 
 
By Lisa Vaas  |  Posted 2006-01-24 Email Print this article Print
 
 
 
 
 
 
 


Oracle is also evaluating an automatic black test, which checks at boundaries to see if SQL injections can get through. Its identified a possible vendor and is looking at rolling it out across the company, but Heimann declined to state the vendors name or timing specifics. Of course, this isnt the first time Oracle ever tested code in a big way.
Oracle first started security evaluations in 1990 to pass the Department of Defenses TCSEC (Trusted Computer Security Evaluation Criteria, also know as the orange book) in the United States and Europes ITSEC (Information Technology Security Evaluation Criteria). 1990: Thats before the Internet, before Web applications blossomed to leak SQL injections and other poisons into back-end databases.
According to Duncan Harris, senior director of security assurance, when Oracle 7 was first evaluated under the governmental security schemes, Europe found one hole. Up until Dec. 1, 1999, there was only one other reported security vulnerability, and it was handled in a similar way to the first hole: by creating tapes and those newfangled things, CDs, to ship a patch to affected customers. In February 2001, Oracle was tracking nine bugs. By September 2001 it crept up to 17. By December 2002 it leapt to 62. "Thats primarily because external researchers really started turning their attention to Oracle, and that was in the early days of my ethical hacking group, and they had started to make a small impact as well," Harris said.
Then came August 2004, the time of the ill-fated Alert 68, the first security alert that contained more than one fix for more than one vulnerability. Its problems were legion—for a sampling, go to Pete Finnigans Weblog and do a search on "Alert 68." Ouch. Oracle has already been working with Fortify for over one and a half years. Also, some two years ago, Oracles customers started taking the company to task on code quality. Oracle responded by signing a volume purchase agreement with Mercury to bring in a volume testing tool and thereby launch an initiative to test better before releasing software. In spite of it all, according to Downing, a "high level of skepticism" persists regarding quality when new patches or Family Packs—a group of previously released patches—are released. "Theres an increasing recognition that at your peril do you put these patches and Family Packs into production without some real testing," he said. Bear in mind, part of Downings business is testing. But Oracle itself admits—has had to admit—problems with code quality. It was the infamous Alert 68 that ushered in an era of profound process change, according to Fallon. "The processes changed dramatically since we did Alert 68," Fallon said. "Now were making sure [development] follows exactly the same thing we do for everything," he said. Namely, Fallons team crosses all development groups and holds the chokepoints to whether a product gets out the door. Would the new chokepoint holder have choked Alert 68 in its cradle? Hard to say. Fallon said he just doesnt know what details people had at the time and whether the information would have aborted the bad patch set. Other changes spawned by the flawed Alert 68 include getting customer communications out as quickly as possible, Heimann said. Alert 68 also resulted in Oracle supplying risk matrixes so customers could get an idea of whether they should patch or not. Aaron Newman, database security expert, chief technology officer and co-founder of Application Security Inc., said that when Alert 68 first came out, he had a number of customers call "specifically begging for information" on if they needed to apply the patches, and what exactly were the issues around the vulnerabilities. "They havent been able to get that information from Oracle," Newman said at the time. We can see Oracles move to faster communication in the aftermath of the malicious Voyager non-worm code (Oracles touchy about the use of the word "worm," since the code doesnt automatically replicate and spread) that was tweaked and re-released earlier this month. Even though the non-worm was a result of insecure configuration on Listener accounts and not the result of a code flaw, on the day of eWEEKs visit, Oracle was rushing to get information to customers regarding proper configuration in order to batten down the hatches. "Were being more responsive," Heimann said. "We have a new security response process specifically targeted at that. We saw the response to the original Voyager posting. So were going out today [with an e-mail blast], on the second iteration of Voyager. We [now] have the ability to get this information out quickly." Next Page: The complexity problem.



 
 
 
 
Lisa Vaas is News Editor/Operations for eWEEK.com and also serves as editor of the Database topic center. Since 1995, she has also been a Webcast news show anchorperson and a reporter covering the IT industry. She has focused on customer relationship management technology, IT salaries and careers, effects of the H1-B visa on the technology workforce, wireless technology, security, and, most recently, databases and the technologies that touch upon them. Her articles have appeared in eWEEK's print edition, on eWEEK.com, and in the startup IT magazine PC Connection. Prior to becoming a journalist, Vaas experienced an array of eye-opening careers, including driving a cab in Boston, photographing cranky babies in shopping malls, selling cameras, typography and computer training. She stopped a hair short of finishing an M.A. in English at the University of Massachusetts in Boston. She earned a B.S. in Communications from Emerson College. She runs two open-mic reading series in Boston and currently keeps bees in her home in Mashpee, Mass.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel