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.
Sign up for Computerworld eNewsletters.