M&A Activity Muddles Database Security

In spite of other more dour economic indicators, 2010 has proved to be a strong year for merger and acquisition activity: Struggling companies have been putting up their shingles for favorable deals while healthy organizations have been looking for stronger performing investments over traditional ones depressed by lowered interest rates. That's good for business, but it can certainly throw off businesses' database protection as they deal with the curveball of integration pitched their way during the M&A process, security experts say.

Financial experts from Thomson Reuters recently reported that through the first nine months of the year there were 22 percent more M&A deals on the books compared with the same time frame last year. This rise in consolidation means IT and line-of-business experts need to be ready to not only hone their business integration deal plans, but also their security road maps.

"[There are] lots of issues here, new complexities to merging and managing environments, especially as you temporarily share data across systems," says Adrian Lane, an analyst with Securosis. Lane says that mixed security policies and standards and different types of data repositories with different applications all cause problems, along with the institutional memory loss that occurs during the inevitable slimming down of staff redundancies.

The first issue of complexity comes by way of heterogeneity, says Thom VanHorn, vice president of global marketing for Application Security Inc. As is, most large IT shops run a wide range of databases containing soup-to-nuts business information. Marry the two together, and you have twice the confusion on the infrastructure front.

"There's nothing that says companies that are merging will have the same type of it infrastructure or the same database, DBMS platforms, or the same security systems," he says, explaining that organizations are going to need to be prepared to find a way to survey that varied landscape to keep an eye on the most sensitive pockets of data.

In order to do this, newly merged organizations must come to the table with a clear-headed plan to survey the database landscape, assess for vulnerabilities, and find a way to monitor it all in a timely fashion.

"Discover, document, and review network, systems, and data stores before you do anything. Then plan your steps to address critical issues, and a road map to implement your policies for the rest," Securosis' Lane says.

Database security pros say the issue of discovery is perhaps the biggest hot-button issue for merged companies, as teams don't always take the time to fully map out all of their data stores.

"One of the key problems due to M&A is that there is no single complete inventory of all the databases," says Noa Bar Yosef, senior security strategist for Imperva. "The first common mistake is that the security team really does not know where all the data is. As a result they do not have the correct controls in place to ensure that data is not accessible to prying eyes: external parties or insiders which should not have access rights to that data."

A thorough data discovery process lays the foundation for a much more controlled environment and the ability to better prioritize mitigation work down the line, VanHorn says.

"When we go into organizations that have been running on their own for a long period of time and I ask where their databases are, half the time they can't tell you. Sometimes when they think they do know where all their databases are, we'll do a discovery and find out that there's a boatload out there that they didn't even know existed," he says. "With a merger you compound that problem--data is going to be located in a bunch of different places, so you need to find those and make sure you know where those are, first off."

Depending on how careful the newly merged company has been with where it puts its data, this can be arduous, he warns. For example, many times the acquirer will get a list of production databases from the new company, but that list will fail to account for randomly located test databases containing sensitive information. During discovery, organizations should be compiling information on not only data and data classes stored by the database, but also about the database infrastructure, such as what kind of databases they are and what release they're running, whether the databases are patched, vulnerability assessment information, and password and configuration strength of each database. This will give the organization the ability to decide which databases are weakest and contain the most sensitive data and guide mitigation planning.

Also extremely important is entitlement work. "Due to the M&A individual roles change, business policies develop and new data is classified. Previous access controls -- who can access what data -- are according to the new business policies," Yosef says.

VanHorn agrees, explaining that a merged organization has to be careful to avoid identity management shortcuts. "When there is a big upheaval in an organization it's very easy to just go and take existing roles and assign those to new people," he says. "But when you do that, you run a real serious risk because the longer that goes on, the more those roles get passed on or redefined and the more difficult it is to make sure you're still maintaining those least-privilege requirements that you should be. You really need to go out there and look at every individual and what their new role is, and make sure that they've only got access to the data that they need."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.