Database Security Demands Monitoring From Inception to Retirement

By Steve Hunt

When health insurer Anthem’s database was breached, attackers walked away with the unencrypted personal information of about 80 million members, including names, birthdates, physical and email addresses, employment information and Social Security/member identification numbers.

Attackers target databases for the same reason robbers like banks: They’re where the data, and money, are.

Yet database repositories are commonly overlooked by security professionals, even though they pose unique challenges. It’s very common for organizations to have extremely limited visibility into their database infrastructures. As a result, attackers operating strategically are able to remain active, stealing records, compromising credentials and installing malware, over many months.

It’s imperative to help customers intelligently and continuously monitor all of their database assets, from inception throughout the useful life cycle and into retirement, when the database is decommissioned. In addition, monitoring needs to be down to the “table level.” Otherwise, you won’t completely understand the database’s security profile, data ownership or purpose of the data, and you might miss changes to the data stores that could tip you off to an attack.

In short, without an in-depth understanding of every database, it’s impossible to put the right policies and procedures in place.

Helping customers rein in their databases begins with an assessment. Work with IT and business leaders to identify each and every database, then list the applications accessing it, the database’s business purpose, the nature and sensitivity of the data, the retention policy and what will be done with that database when its retention time has expired.

Then, establish policies based on data types, compliance, what apps and roles need access to the data, and any company-specific needs. Once policies are established and mapped to all databases, IT or a partner must continuously monitor the infrastructure to ensure policies and procedures are consistently and effectively enforced. Pay specific attention to identifying changes in usage patterns — these tipoffs can be the key to spotting and thwarting serious data breaches.

Beware of Zombies

Legacy databases that should have been decommissioned long ago are an open opportunity for attack. These databases may not be properly patched, credentials haven’t been updated and it’s likely no one is monitoring them.

What to do with rogue and zombie databases?

Rogue databases may have been created during the development phase of a new application and connected to the network without IT even being aware of their existence. Developers may believe they are doing something innocuous, but without operations going through the proper life-cycle steps, the data likely won’t be properly masked, for example, leaving the enterprise vulnerable. Without intelligent monitoring in place to identify when a new database is available on the network and checking the database against current data asset inventory, there is no way to properly manage it.

Then there are the zombies. These are databases that are unused but were not decommissioned and thus may become open targets thanks to an outdated security profile and, likely, old credentials. They are not being patched, updated or monitored. Unlike rogues, zombie databases may have had proper security initially; however, they’re now vulnerable to insider threats, APTs, compromised credentials and the like.

I understand that there’s a lot of attention and money being spent securing the perimeter, mobile devices and the cloud. But IT and partners cannot afford to neglect active, and inactive, databases on the network. All databases need to be identified, inventoried and continuously monitored to ensure data stays where it was intended to be — and out of the hands of attackers.

Steve Hunt is president and COO of DB Networks. Steve is responsible for leading the development and operation of the company. Prior to DB Networks, Steve was SVP, Engineering and Operations at Coradiant, and later was a member of their Technical Advisory Board before it was acquired by BMC Software.