Our company is frequently involved in mergers and acquisitions, and we typically don't know the security posture and integrity of the IT resources in the company we're acquiring.
In the past, rather than conducting an upfront security audit, we simply opened the floodgates to allow network traffic to flow from the acquired company into our trusted environment. In one case, that allowed a virus to propagate through several parts of our network, requiring many hours of cleanup.
A security audit could have prevented that. But unless an upfront audit is written into the acquisition agreement, it can't be started until after the merger or acquisition is completed. Many target companies resist such upfront agreements, however, fearing the loss of sensitive information if the deal doesn't go through.
But that's not the worst of it. Once the acquisition deal is signed, the executive staff is in such a rush to integrate the companies that security assessments typically take a back seat to bottom-line profitability concerns.
Fear of the Unknown
It's difficult to determine the integrity of another company's infrastructure prior to establishing a trust environment between our environment and theirs. Here's what usually happens: The network team configures a dedicated circuit to the acquired company, throws up a firewall and asks the acquired company to configure its servers to set up trust relationships with ours. The most important goals are to give new employees access to our e-mail, human resources applications, company intranet and a few other critical applications. If the company we are acquiring sells a software product, its engineering team also needs access to our source code -- our company's bread and butter.
What we fear most is that the newly introduced resources may be infected with a virus. It's also possible that the other company's servers don't meet our security configuration requirements and are vulnerable to an attack, or have already been compromised.
I've seen incidents where the e-mail server at the acquired company had been fully compromised when someone added a packet-sniffing device to the network. The company had contracted out the installation and configuration of its e-mail server, and no one on staff was capable of managing the resource. The server was never maintained properly, so the packet sniffer went unnoticed for more than three months.
We need a security gateway product that can act as an interim measure until a full assessment can be completed, mitigating the most common problems we might encounter during an acquisition. We want something that offers good protection at a low cost and with few hardware requirements. The product must also be easy to manage.
We have other requirements as well. In the past, each company that we've acquired has had fewer than 200 employees and used minimal bandwidth. This is important, because any gateway product must be able to cope with expected traffic levels.
Symantec Gets the Nod
After a search, we selected the Symantec Gateway Security appliance from Symantec Corp. This appliance combines virus protection, Internet content filtering, a virtual private network and an intrusion-detection system in one box.
We planned to buy several appliances and preconfigure them for easy and rapid deployment. We planned to use them only until we had validated the integrity of an acquired company's infrastructure. Then we would remove them, apply our current standards and put the gateway aside until the next acquisition. But our plan ran into opposition from the network group, which is responsible for the day-to-day management and configuration of our firewalls.
The network team currently manages Cisco Pix firewalls with Solsoft Inc.'s centralized management software, Solsoft NP, and they were uncomfortable introducing another firewall product -- especially if they had to manage it. Doing so would mean additional training, familiarity with the product, support issues and extensive lab testing, the team complained. Like other departments within our company, the network group is already spread thin.
I explained that Solsoft NP may be able to manage the Symantec appliance's firewall component. This would mean that the network team wouldn't need to be intimate with the syntax or configuration of the access lists for the gateway device.
But they stood firm: They absolutely didn't want to manage any aspect of the firewall portion of the Symantec gateway. Instead, they suggested, why not use some of the extra Pix products they had lying around? These could work as an interim solution. But we'd still need the Symantec appliance for the other security functions.
We may end up not using the firewall portion of the Symantec product. But at this point, we'll get an evaluation unit in. Once we start lab testing, we'll have a better understanding of just how difficult the administration of the firewall is before making a final decision.