Putting the Brakes on Net Integration

Assessment of acquisition target's network tells our security manager he'll almost have to start from scratch.

My company is moving ahead with an acquisition I mentioned back in August, and last week I completed my initial assessment of the security issues that will arise in integrating the two networks. Brace yourself — it’s not pretty.

I visited our acquisition target’s main offices in Connecticut and New Mexico. I brought along a contractor to conduct much of the assessment work while I met with the management team to learn about the company’s business processes, intellectual property issues, policies and so on.

We could just install Multiprotocol Label Switching (MPLS) to connect these offices and their 600 employees to my company’s network, but that would essentially grant them access to a majority of our internal infrastructure. As the security manager, I can’t allow that until I can vouch for the integrity of the acquired company’s network and the efficacy of its policies. Most likely, we will want to bring the new company’s policies in line with ours, since this year we suffered only one major virus outbreak, the result of an employee connecting a personal laptop to our domain.

In assessing the issues we faced, I focused on several key areas. The first was malicious code. I need to ensure that we don’t introduce anything like viruses, spyware or Trojan horses into our network. To determine if this company has any malicious code running free, I had the consultant conduct some scans. Right off, he found indications of spyware — network traffic symptomatic of desktops “calling home” to transmit keystroke capture files or other collected data. Nessus, a freely available port scanner, detected indications of malicious code listening in on nonstandard ports.

Next, we focused on questionable external connections. We had to make sure that this company didn’t allow third-party access to its network and that the firewall, routers, VPN and wireless access points wouldn’t allow unauthorized access. This time, we ran into a couple of problems. One was the configuration of wireless APs. The company was using WEP with a shared key, but it hadn’t changed the key in years, and the AP terminated on the internal network.

My company’s standard is to use WPA with the Temporal Key Integrity Protocol, and we terminate the access points on a virtual LAN so that the only device that can be reached is a VPN gateway. This forces all employees to use a VPN to get into our network from the access point. I’m not touting this as the most secure means of providing wireless access, but it’s a lot more secure than a shared WEP key that hasn’t been changed in years.

The other problem was a firewall rule that allowed access to the company’s internal network from a very large network range completely outside the company’s registered network addresses. No one seemed to know what it was about. Some Internet searches revealed that the address range belonged to a third-party network integration company, one that I learned was hired for a 30-day contract more than two years ago. This was not good.

Next up was unacceptable use. I impose strict controls to block many of the common peer-to-peer software technologies, and we filter Web traffic at our caching servers to prevent employees from browsing Web sites that we deem to be unacceptable, such as porn or gambling sites. This time, scan data showed that many employees are using peer-to-peer software. And the company doesn’t block outbound Web access, so employees are free to visit any Web site at all. My company’s view is that unfettered access can lead to various legal, human resource and productivity problems.

More Problems

Areas of concern were mounting, and we still hadn’t looked into issues that might arise from the company’s critical devices: domain controllers, source-code repositories, file servers, firewalls, VPN concentrators and so on. When we did so, it was obvious that no one had taken the time to conduct any type of configuration management or general maintenance after the servers were built. Patches were out of date. No password policy was being enforced; administrative passwords were left blank or were easily crackable. There was even a SQL payroll database that used the default password for the administrative account. The desktop and server virus-protection engines were more than three years old.

As you can guess, there’s no way I’m going to allow our company to install the MPLS circuit without some serious remediation. To start with, I’m mandating that all desktops and servers receive the latest recommended patches for both operating systems and applications. The latest virus engine and pattern file will need to be installed, and all systems must be scanned and free from malicious code. Anything that can’t be cleaned will need to be rebuilt.

The company will have to configure its domain to enforce a strong password policy, and all administrative and privileged account passwords will have to be changed. I’m having the critical servers checked with RootkitRevealer, a useful utility that can be downloaded from Microsoft’s Web site. It essentially lists registry and file-system API discrepancies that may indicate the presence of user- or kernel-mode rootkits.

Now, I know that some systems, such as engineering, development and lab servers, will be exceptions. And of course, we won’t know about all resources. So I will also be mandating the installation of two intrusion-protection devices. One will sit between the two companies (on the MPLS circuit), and the other will be between the acquired company and its Internet circuit.

I’m hoping that with this plan, plus some additional policy enforcement, I’ll be able to limit any illicit activity from reaching my company’s network. I’ll keep you posted.

What Do You Think? 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, or join the discussions in our security blogs: computerworld.com/blogs/security. To find a complete archive of our Security Manager’s Journals, go online to computerworld.com/secjournal.

Copyright © 2006 IDG Communications, Inc.

  
Shop Tech Products at Amazon