If you've read the IT press at all these days, you know that SQL Injection (SI) attacks are very common and can be devastatingly effective. In fact, SI attacks-equally easy to execute against Oracle, MySQL, IBM DB2, or Microsoft SQL Server-are among the most common hacks on the Internet today. If a web application runs a relational database on the backend, it can be subject to an SI attack, which ironically, is among the easiest web hacks to prevent.
While plenty of SI attacks hit SQL Server database, Microsoft has done much to strengthen and reinforce SQL Server's attackable surface area. In fact, in the last couple releases, SQL Server has had fewer security holes and critical flaws than the other leading database platforms. After the SQL Slammer virus of the early 2000s, SQL Server made security a huge aspect of its feature set, and, as a database, is ahead of the pack in terms of security features. It is SQL Server users- its DBAs, developers, and IT managers-who bear the blame for security hacks that succeed against their systems.
So what is SI? An analogy might explain the ease of defending against an SI attack better than a full technical description (For a technical description, visit http://en.wikipedia.org/wiki/Sql_injection). Imagine you're driving home from work and see all the doors and windows open at a neighbor's house. You peek out the window as you lock up for bed that night. All their doors and windows are still wide open. You get ready to leave for work the next morning and see your neighbor driving away with all the doors and windows completely open. A few days later, the house is burglarized. Well, no wonder! They never even shut the door, let alone lock it. They'd probably be safe and secure today if they'd taken that simplest of steps.
SI is practically the same situation. All it takes to prevent SI is to ensure your web applications test for allowable values in their input fields, and send their own error messages, rather than the default. SI is ridiculously easy to prevent, and if I managed a team where this happened, I'd fire the responsible parties, on both the development and administration teams. We know as much about preventing SI attacks today as we did the very first time they occurred. If it happens to you-just like a burglary in a house where the doors are never shut-you must blame yourself, not the locks on the doors.
Microsoft has implemented many new and improved security features in the wake of the SQL Slammer virus. Their entire development process for SQL Server includes rigorous security checks. When SQL Server is installed today, most security holes and surface areas have been closed off by default, requiring the DBA to consciously open them up after installation.
There also are a few best practices to keep in mind. First, as with disaster recovery, you should plan for the inevitable attack ahead of time. To prevent security breaches, ensure that applications and services run with the least possible privileges. Monitor login activity and raise an alarm when too many failed logins occur within a certain time period. Make sure applications run under their own account, not SA, and that guest accounts and the public role are dropped or not available. Finally, disable any system and extended stored procedures on your SQL Servers that aren't explicitly needed to support production operations.
Brasher’s Auto Auction Group Makes Bid for New Database Technology
Posted Nov 11, 2009 - November 2009 Issue
A modern architecture, system stability and strong behind-the-scenes support are key attributes to consider when evaluating new database technology.
The Brasher's Auto Auction group is among the oldest auto auction companies in the country, serving major markets throughout the western U.S. Brasher's remarkets vehicles for auto dealers, manufacturers, rental car companies, banks, finance and leasing institutions, and offers a full range of services, including reconditioning, inspections, transportation and inventory financing, and operates auto auction facilities in Salt Lake City, Utah; Reno, Nev.; Sacramento, Calif.; Eugene, Or.; Portland, Or.; and Boise, Idaho.
Generating in excess of $1.5 billion in vehicle sales annually and employing roughly 1,200 people, Brasher's is also a technology innovator. Brasher's was among the first auctions in the industry to implement a computerized auction management system, and Brasher's was also one of the first auctions to offer vehicles on the internet in the late 1990s. With two partner auctions, Brasher's founded the Auction Pipeline, which is now a premier online sales channel for independent auctions in the U.S.
In December 2008, Brasher's initiated a phased roll-out of its enterprise applications on the InterSystems CACHÉ high-performance database with MultiValue technology, concluding the implementation in January 2009. In all, the migration involved more than 8,000 programs and cataloged procedures ranging from accounting applications through real-time bid processing systems in auction venues. In going live with CACHÉ at each location, says Ty Brewer, Brasher's CIO, "our goal was for people to go home on a Friday and come back on a Monday and not notice anything different, other than things being faster. By and large, that's exactly what happened."
After deciding to move from its existing vendor, Brasher's initial evaluation of its database technology options began in December 2007, Brewer explains.
Brewer and other members of his team made a spreadsheet outlining the different feature sets of alternative products they wanted to evaluate and ranked each of those feature sets by relevance to their operation. They sought a stable platform which Brasher's could rely on as it continues to grow. Among other considerations was Brasher's use of PROC, a MultiValue procedural language, for its menuing system. "We didn't want to have to rewrite a lot of existing PROC code," explains Brewer. The company also wanted the ability to do phased migration across its six locations in order to have a safer implementation.
After considering its choices, Brasher's opted for CACHÉ because it best fit his company's needs, Brewer explains. "We just went through in a very calculated approach, looking at the positives and negatives of the different vendors that were out there. By far and away, this product of InterSystems' - CACHÉ - stood out as being our best move," he says. A leading database in enabling transactional systems, CACHÉ enables rapid web application development, high transaction processing speed, scalability and real-time queries against transactional data.
"The overarching and most compelling reason was the more modern architecture. The way they take MV and tie it into an object-oriented model is really phenomenal and it greatly expanded our toolset and how we can get at our data," Brewer notes. "We did a lot of benchmarking on the different platforms and in most every case, the InterSystems product performed orders of magnitude better. The toolset they provide is very rich. They have a lot of tools that enable commonly performed operations to be done very easily, the web service consumption and creation is fantastic, and we are able to develop code a lot quicker with their environment." Moreover, he adds, due to CACHÉ's powerful debugger, the move has enabled the Brasher's team to find bugs that Brewer is convinced they would not have been able to locate otherwise. "We have cleaned up several issues that have plagued our system for some time, and we have been able to improve our overall system stability just from being able to better clean up our code."
With the decision made by the early spring of 2008 to go with CACHÉ, the team opted to go to the annual InterSystems developer conference, which turned out, according to Brewer, to be another major selling point. "Just the community of developers and the general culture was very favorable and very cutting edge. It was a contrast to what we would see at other MV conferences."
Reflecting on the move now, Brewer says he has no changer's remorse. "The biggest concern was system stability. It has been a major issue that we have wanted to ensure and our system stability now is many times better than it was previously." Another improvement, he notes, is that Brasher's backup windows before the migration used to take the company offline at night. "We were forced off of our system for several hours at each location previously and with the backup procedures that CACHÉ provides, with journaling and some different things, it allows for us to really minimize that window of time where we need to have people off of the system. And frankly, now, for backups, they don't have to anymore. We just have a few processes where it might require a few minutes a day now where we are offline."
And, Brewer adds, a final added benefit of the move to CACHÉ has been that the support has been "world-class." If there is a problem, he says, InterSystems is on it. "We set the priority. If we say something is a ‘crisis priority,' they have people that work on it 24/7. We have witnessed that and we have absolutely no complaint whatsoever about their support. We would recommend them with no reservations."
