The post-acquisition blues
The CFO broke the news that we were acquiring a smaller software company in a meeting with most of the executive staff and other department heads. It was greeted as a welcome development, since we had been struggling with the question of whether we should divert resources to develop a needed feature in our product or instead purchase a company that could fill that gap. The problem for me was that I was learning this news along with the other department heads, even though the deal was already signed. I would be given a couple of weeks to conduct due diligence, but it was too late for any discovery that I made to be used as leverage to reduce the acquisition price tag — or even to scuttle the deal entirely.
The risks that might be uncovered in such a review can have tremendous implications. For example, it isn’t unusual for a small software company to use someone else’s proprietary software code as a base platform to build upon (why re-create the wheel, right). The acquisition target might infringe on copyrights in less significant ways, as well, requiring fees to be paid. Those are just two of the many land mines that can be hidden from view in an acquisition, and both of them carry potentially large financial burdens that could fall on the acquiring company.
Although there was no chance of backing out of the deal, it was still important that I conduct a review, so that we would at least know what sorts of problems were in store for us. I dusted off my M&A questionnaire and got to work. After several sessions with the company’s small IT team, engineering department and customer service folk, I had a decent handle on the security maturity of the company — or rather, it’s security immaturity. It fell short on several measures.
This didn’t surprise me, since the company doesn’t have anyone dedicated to overseeing security matters. In fact, it was obvious from my review that security wasn’t a priority. Nearly all of the company’s infrastructure was installed on virtual servers located in a small data center closet, with all the servers on the same network and several exposed to the public Internet. One of the servers was hosting Subversion (used for source code management) as well as a wiki to manage product ideas and changes. Another was being used for the open-source PBX phone system Asterisk. The company’s public-facing Web server was also acting as the corporate mail server.
The Asterisk server had Secure Shell (SSH) available to the Internet. I asked the IT guy why, and he said a contractor maintained the server and needed remote access. Remediation of those problems wouldn’t have been difficult for them; they just had to set up a “demilitarized zone” for all Internet-facing resources and configure a VPN to provide restricted and secure access to those resources. The problem in my mind was that, when you run into big security risks that can easily be fixed, it’s a red flag that alerts you to the extremely low priority that security considerations have been given.
Next, a quick Nessus scan turned up many vulnerabilities. The company was running outdated software for Apache, DNS, Asterisk and other things. No server had been patched in over a year. Some of the servers were even running Telnet, which is an unencrypted method for accessing a Unix server. Such servers should never be exposed to the public Internet; due to the lack of proper hygiene and network segmentation, I had to consider the entire network compromised. Although what I had already seen had prepared me for some real problems, I was still surprised that, in an age of breaches, a company could be so irresponsible about securing its infrastructure.
I then turned my attention to the cloud-based enterprise applications that the company was using, including Salesforce, Google Docs and QuickBooks. The big problem here was that the list of active users retained many people who had been terminated — and some of them were still actively logging in. In the case of Google Docs, many sensitive documents had been recently modified by a user who had been terminated more than a year earlier. On top of that, password policies hadn’t been implemented, and many users had weak passwords with no expiration.
Obviously, I had my hands full.
My first order of business was to secure the source code, which is our main interest in this company. I had the entire source code tree evaluated for any signs of manipulation; luckily, it was clean. I then had it moved to our own source code repository and decommissioned the old server.
I drafted a remediation plan to close the egregious security holes, the eventual plan being to decommission all of the acquired company’s internal infrastructure and migrate data and people to our own corporate servers. I felt it was too risky to even attempt to integrate its network with ours. And of course, with the enterprise cloud-based applications, we’ll be terminating accounts and securing data.
It’s a long list of problems, but it gives force to my message to the executive staff: Next time you think about acquiring another company, get security involved early.
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.
Click here for more security articles.