Protecting databases from the inside

Commentary--We begin with a story: A wealthy man decides to protect his estate. He erects a high wall all around it, topped with barbed wire, motion sensors, CCTV cameras and infrared sensors that detect the slightest movement in its vicinity. A massive iron gate is placed at the only entrance, and the guards personally identify every visitor.

Despite all of this, the man’s wife discovers one day that a diamond necklace, worth $200,000, is missing. After searching through every corner of the house, she reaches the conclusion that it had been stolen. The police are called in to investigate--they discover that despite the strict controls at the perimeter, inside the house access is relatively easy. Sure, some doors are kept locked, but many people have the keys. They discover that between the maids, nannies, cooks, housekeeper, butler, chauffeurs and gardeners there are over 30 people working inside the estate. When also counting the delivery people and houseguests that have had access to the estate in the past month, this number reaches well over 100.

In the walk-in closet where the necklace had been, the police find custom-made velvet-lined drawers for each item of jewelry, but no safe. The officers are baffled: “Why did you not put your jewelry in a safe, or invest in an alarm system for the master bedroom and closet area?” they ask the owners.

The stolen data
If the story sounds incredulous, that’s because it is--at least in the real world. No wealthy person with enough money to invest in securing the perimeter of his estate to such levels would forget to safeguard jewelry and other valuables in a safe with adequate alarm systems. Yet, if we look at the investment in enterprise IT security infrastructure over the past decade, this is exactly what has happened. Enterprises have spent years shoring up their perimeters against intruders, and having done a good job of it, are continuing to do so by force of inertia--with diminishing returns. The evolution of how we do business has made the perimeter a nebulous concept at best and while it still works against “pure” outsiders, it may no longer be relevant to partners, consultants, customers and suppliers who often operate inside the firewall. Of course, it was never relevant to those who were inside the perimeter to begin with.

The threat landscape has changed too. Organized criminals, not anarchist hackers, are now behind much of cyber crime. Consequently, while previously, attacks focused on infrastructure, now they are increasingly targeting data and nowhere is valuable data to be found in abundance more than in enterprise databases.

In the infamous TJX breach, over 94 million records containing credit card records and bank account details were stolen, with tens of thousands of them later appearing in fraudulent transactions. The details of the breach have not all been publicized, but it is known that the criminals hacked point-of-sale devices’ weak WEP encryption. It is not likely, however, that intercepting point-of-sale devices yielded 94 million records on its own, even over a 17 month period. Rather, it was the point of entry to access those records elsewhere--and the only place where so many records can systematically be stolen is an enterprise database.

The data stored in enterprise databases is the "crown jewels" of corporate data--financial information, customer and employee data and intellectual property, but the database is far from being the bank vault suitable for safeguarding such data. Database management systems, as their collective name suggests, were created to manage data, not to protect it. Over the years, as DBMSs became increasingly complex, they developed security vulnerabilities. Such vulnerabilities are discovered on a weekly basis, and while vendors are doing their best to patch them, the reality is that in the vast majority of enterprise installations databases remain exposed. Additionally, some of those vulnerabilities stem from faults in implementation and configuration rather than in source code. Exploits are often published in hacking community websites and forums (e.g. milw0rm), with ready-to-use scripts that are ready to download and use with no expertise required. Some exploits allow users with minimal access to gain DBA privileges and others allow users that are not authenticated at all to become DBAs, rendering user authentication and access control mechanisms useless under such scenarios.

Finally, the threat from insiders and especially from privileged users has also grown substantially. This growth is due at least in part to the more secure perimeter: It is currently easier to bribe someone on the inside (or even implant them there) than to aimlessly try to hack your way in through sophisticated firewalls and IDS/IPS. In another incident in 2007, a DBA at Certegy, a credit card processing subsidiary of Fortune 500 company Fidelity National Information Services, was arrested after having stolen over 8 million customer records containing credit card and bank account details and selling them to a third party. That he was able to do that and go unnoticed for a long time is a testament to the risk posed by privileged insiders, especially when motivated by financial gain.

Protecting databases against the right threats
Ultimately, investment in security is a cost/benefit calculation, with the benefit usually expressed as reduction of risk--so what is the risk of not protecting databases adequately, and how can it be remedied?

Unfortunately, we have come to a point where a constellation of factors has combined to present a high risk:

• Vast concentrations of highly lucrative data are being held in enterprise databases
• Flaws in application development and implementation are enabling exploits that are publicly and freely available
• Attacks and data breaches are mostly financially motivated, coming from organized crime, industrial espionage or random opportunities to make a quick buck
• The probability of an insider with access privileges and technical skills succeeding in an attempt to steal data is much greater than that of an external intruder These factors combine to make breaches like the one at Certegy possible, but we should not delude ourselves by looking only at the headline-grabbing major incidents. There are numerous smaller incidents, most of which go unpublicized and often undetected and the damage they cause is mounting. All in all, the risk is significant and one that many enterprises are no longer able to ignore.

There is a variety of tools available (many of them free) that enable scanning, monitoring and hardening of the database, as well as preventing breaches in real time and protecting it even against some zero-day vulnerabilities. The only viable way of protecting the database is by using dedicated security tools and procedures that address the types of threat that are relevant to databases and understand enough of the intricacies of the DBMS to protect it against exploits. This simply cannot be done from a distance by a firewall or from the network, especially as pertains to privileged users. When you have “crown jewels” to protect, you do so as closely as possible--not from afar. Combined with overlapping requirements from regulators (e.g. Sarbanes-Oxley, PCI DS and HIPAA), there is a compelling case for changing priorities in this space.

P.S. The butler did it.

biography
Slavik Markovich is the CTO of Sentrigo.