Maybe I'm an oddball, but I like the action that surrounds a merger or acquisition. I guess I need a little unplanned activity every now and then to distract me from my day-to-day tasks. Whatever the reason, I was excited to hear that my company would be acquiring a small company. It had been years since we had done anything like that.
Trouble Ticket
At issue: The company acquired another firm, and it didn't involve the security team ahead of time.
Action plan: Conduct a thorough review of the acquired company's security measures before integrating the networks.
I just wish I had been informed earlier. When security isn't properly represented during the initial due diligence phase of a merger or acquisition, problems can go undiscovered. For example, during our last acquisition, we uncovered numerous application security problems. User credentials weren't encrypted, and applications had multiple SQL injection vulnerabilities that could be exploited to obtain the unencrypted passwords. But for that deal, the security team was involved early enough to take part in due diligence, so we were able to discuss the cost of remedying those problems during the negotiations.
Despite it being too late this time to affect the negotiations, my team still needed to conduct a complete assessment of the acquired company's security measures before allowing any network integration. The new company seemed to have done a good job with endpoint protection: An assessment of its PCs and servers disclosed up-to-date patches, antivirus software and server hardening. It also had robust firewall rules and solid intrusion detection.
Not everything was ideal, though. One problem concerned the processing of credit cards.
My company has made a point of not directly handling such transactions, so that we aren't compelled to comply with the stringent Payment Card Industry (PCI) security standards. By using third parties to process payments, we only expose the data entry frames within our website, and because we don't process or store any details regarding the payment information, we don't have to be PCI-compliant. But our new acquisition does process credit card transactions, and it stores the credit card data and payment information in its database. That means that it must be PCI-compliant, so "Yay!" to that, but we aren't, and we have no desire to go down that road. But we can't very well connect that PCI-compliant environment to our noncompliant environment without undermining the acquired company's PCI certification. What we're going to do is migrate the new company to our credit card processing standard, thereby avoiding the PCI requirements. That will take time, though, and it will slow down integration.
SaaS and Cloud Concerns
A couple of other issues will simply take some time to evaluate. One is that the company runs virtually all of its major corporate applications as software as a service, and it uses cloud-based file storage for sensitive data. SaaS and the cloud aren't problems in themselves; we use both ourselves. But we evaluate all of our cloud vendors so that we fully understand their security posture and the nature of the integration between us and them.
Finally, there's the consideration that the acquired company uses more than 30 partners around the world for things like software development, help desk and other corporate functions. That's a significant number for a company with just 40 or so employees. The thing about all those partnerships is that we have a very stringent review process for taking on partners, especially those who work in countries that are considered risky. We're going to need to review all existing contract agreements, nondisclosure agreements and the like to ensure that they meet our standards.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.