Before you lose something precious, govern your data.
Your company doesn't have to fall victim to a sinister SQL injection attack for its sensitive corporate or customer information to come pouring out of a database. Shoddy data governance can do as much to poke a hole in a data store as sloppy data input validation.
It's the CISO's job to balance the business need that data be available and shared with partners, suppliers and customers, while putting controls in place to fend off trusted insiders and malicious outsiders--and appease auditors. All the while, data grows in near immeasurable volumes and is accessible via many avenues on the Internet and corporate extranets. Adding to the stress is the often routine practice of replicating databases for backup, high availability and--too often--for development. Their content is accessed and stored by myriad applications, partners and customers, sometimes in ways you don't appreciate or even suspect.
In short, data lives everywhere, and security constantly tries to keep up with a moving target.
Whether your company is built on a strong foundation of data governance and intelligent risk management, or has been forced to "do something" because of PCI, Sarbanes-Oxley, HIPAA, SB 1386 or other regulatory mandates, it's obvious that the cost of weak data security is greater than the implementation of strong
Sink or Swim
There are a number of high-level mistakes, misconceptions and practices that put companies' data at risk. In order to have strong data controls, it is best to avoid these common pitfalls.
Failing to aggregate insecure data. Often, companies don't know where all their data is, much less start to classify it based on its importance to the business. What's more, they have little or no grasp on which applications create data or use existing data, or where they might store it outside the primary databases they access.
Without central control and policy oversight, large, distributed organizations may lack consistent controls over their databases. How do you know what to encrypt, how to restrict access or what to monitor? Each business unit is on its own. Mergers and acquisitions exacerbate the problem.
Assuming perimeter defenses are enough. Companies are comfortable with what they know and what they have invested money and expertise in. Firewalls and gateway IPSes don't protect against the careless or malicious insider who copies sensitive information to a laptop or thumb drive, or the rogue DBA who changes a database schema without authorization.
Inability to protect unstructured data. While databases are where the beef is, and probably the targets of choice, gigabytes of unstructured information are probably sitting on file servers in Excel spreadsheets, Word docs, PDFs, scanned documents, or on backup tapes or old mainframes.
Coding on production data. Developers use real production data. Why? It's easy. They've always done it that way. But it's an undocumented, uncontrolled use of sensitive data in the hands of people who don't need it.
Failing to account for the complexity of grid architectures. In the old days, databases were islands, each administered by one DBA. Now, grid technology makes it more likely that the same DBA is responsible for one large database servicing many applications. While it's efficient and makes sense from a business perspective, enforcing privileged user access and separation of duties gets sticky.
Making security an afterthought. Security can be a hard sell in just about any company. Add to the mix a busy IT staff juggling a myriad of applications and conflicting priorities. As a result, busy IT staffs may be prone to let security initiatives lag, because they're not a priority. Typically IT managers evaluate a business application based on performance and availability before they evaluate its security. This type of thinking makes it difficult to bridge the gap between policy and practice.
Pulling the trigger too soon. Instead of going through the arduous yet rewarding and essential process of embedding data security in the corporate fabric of an organization, companies typically attack point problems--stronger authentication, encryption, and data on laptops. The result is a series of expensive, resource-intensive projects that may do little to improve the company's security posture or satisfy a PCI or SOX audit.
While those are the common pitfalls when it comes to protecting data, there are also best practices that can be implemented to build an effective data security program.
Inventory, track and classify data. If the worst thing a company can do is not know where all its data is, it stands to reason that knowing where it lives and is duplicated, and which applications access and change it, is vital. This applies to databases, logs, and all sorts of unstructured data. This makes classification feasible, enabling companies to establish appropriate controls for mission-critical information, and, on the flip side, not waste a lot of time and money protecting benign data, whose loss or exposure will have little or no impact on business.
"Mature organizations find out they have data risk," says Paul Proctor, vice president of research at Gartner, "because they have good classification, know where data is, and can make good decisions about controls."
Consolidation or destruction of data is generally an important byproduct of this process: Ask why you are collecting and storing this. Data may be unnecessarily duplicated or scattered among disparate databases and file shares.
Maintain separation of duties. This is absolutely critical for privileged users, particularly DBAs. DBAs historically have had full privileges to manage and make authorized changes to the databases, and unbridled access to application data. Modern databases have the control mechanisms to prevent this. It's also critical to ensure the people who validate critical changes to databases, and monitor usage and controls, are different from the people who manage and alter them.
Don't use production data for development. It's easy for developers to simply copy real production data for developing, modifying and testing applications.
"Ideally, you want to separate development from the production environment so it's almost a separate entity--different polices, different infrastructures," says Barak Engel, CSO at Loyalty Lab, which provides outsourced CRM solutions to businesses.
It may be a little more work to produce scrubbed data, but it gives developers what they need and doesn't expose potentially sensitive data in an uncontrolled environment.
Establish and enforce change controls. Secure organizations rigidly enforce not only what database changes are made and by whom, but who authorized it and how the authorization was made. Change-control committees call the shots. Security participates because it's their job to make sure database changes go by the book.
"If someone makes a change in the database, they have to create a change control record to show what they are doing. If not, there's an investigation," says an information security specialist for a Fortune 500 financial corporation. "We take a snapshot and monitor for changes to crucial components."
It's not just about the data, but schema and database structure. If someone deleting a table would affect financial reporting because they didn't go through process, you want to be able to show the SOX auditor you detected and addressed the problem.
Always monitor. Assuming you know where your critical data is and have policies controlling who can access it and change it (and under what conditions--e.g., only Monday through Friday from 9 a.m. to 5 p.m.), you can monitor for anomalous behavior.
"We're always monitoring what's out there," says David Giambruno, director of engineering and security at Pitney Bowes, where he's responsible for the security of some 30,000 servers and 37,000 employees. "Our job is to know everything that's going on in the enterprise. How else do you know if you're secure now and tomorrow?"
"Watch the watchers," advises Gartner's Proctor. "Monitor the keys to the kingdom: the DBAs, the Windows domain admins, anyone who has any type of privilege."
Encrypt. As with monitoring, the key is understanding where your critical data lives and encrypting what's important. But don't underestimate the magnitude of the job. Key management is crucial and difficult: rotating and revoking keys without disruption, making sure the right people have the right keys, and ensuring they aren't lost--and access to your data with them.
"Realize how hard crypto is--the time frame should be years," says Loyalty Lab's Engel. "There are performance considerations, key management, and recovery. The architecture alone--rollouts take a long time."
Separation of duties is an important consideration. It's not that you don't trust DBAs, but best practice means that you have two systems--one providing access to data and one providing keys--managed by different people. Finally, encryption is just part of a layered solution. Many organizations leapt at encryption as a quick fix to satisfy regulatory pressures, but it is neither easy nor a complete fix. Encryption ensures that the external hacker or someone who finds or steals a laptop or backup tape can't read your data. However, the insider threat remains, and encryption won't stop a malicious user who has legitimate access.
Grab low-hanging fruit. Attention to the little things, eliminating the simplest, most obvious risk factors, pays big dividends. You'd find a surprising number of databases still using default admin passwords and IDs.
"Understand and manage easy targets--like blank passwords. If you scan for that, you'd be stunned," says Giambruno. "You've got to fix the basics; that's where protecting data really starts. Follow the top 10 basic security rules, and you'll be fundamentally secure."
This was first published in January 2008