Our security manager is willing to outsource some things, but others are simply out of the question.

I've been asked to send more of our security services offshore, and that request has me thinking about what I would be comfortable with outsourcing and what I would never want to risk putting in the hands of a distant provider.

Trouble Ticket

* At issue: More security services need to go offshore.

* Action plan: Think carefully about what can and can't be securely done from afar.

It's difficult to counter the cost argument for offshoring. India is the lowest-cost region that has reliable network connectivity, a workforce that is proficient in the English language, a favorable tax regime and a stable government. Since it is also safe and easy to get to, India is our offshore location of choice. And in India, we can get three security engineers for the cost of one in the U.S.

Currently, we offshore the management of security patches. Analysts in India continually monitor Microsoft's security updates, third-party sites and forums that discuss vulnerabilities and recommended security patches. The analysts apply predefined criteria to figure out whether a particular operating system or application patch is relevant for us and determine the risks of applying the patch or not applying it. They then provide us with the patches that they deem necessary to our desktops, servers and network so we can install them during our maintenance windows. If the patches are critical or need immediate action, they are escalated accordingly. All of this has been working quite well.

But there are some things that I would simply refuse to offshore. For example, investigative work, such as forensics or anything that would require administrative action against an employee or other company, is just too sensitive to be handled out of house. I also feel uncomfortable offshoring the administration of our data leak prevention infrastructure, because DLP devices contain some of our company's most critical data. I'd rather keep control of such information in the U.S.

Security

But other things do make sense. Intrusion detection is one example. Intrusion-detection systems are not plug-and-play. They require updates, continuous tuning and careful response and analysis of events. I don't have the staff to properly manage our dozen IDS sensors, and I would welcome additional hands and eyes to do much of the work necessary to ensure a successful deployment. I might even consider a fully managed service in which the provider installs its own sensors. That way, we could increase our coverage to 100%; we're currently at just 70% of our network.

Another example is vulnerability management. We are evaluating Qualys to control the devices we use to scan our internal address space. Since the Qualys service is an Internet-facing application, I wouldn't mind providing access to a third party in India to run the scans and process the results on a regular basis.

Of course, if I hand off all of this work to third parties, I will still be responsible and have to answer to the executive staff should anything go wrong. For that reason, I will still conduct periodic audits of our service providers to ensure that they are meeting service-level agreements and statements of work.

POP Update

In my previous column, I mentioned that I would be terminating POP and IMAP e-mail services because they pose a risk. As anticipated, there was some fallout, and I've had to make exceptions.

One is related to the e-mail of executives who serve on the boards of directors of other companies and want to download mail from those companies' e-mail systems into their Outlook clients here. The other exception is for the engineering collaboration sites that our engineers use as they work to improve our products. To accommodate the exceptions, we will make a rule in our firewall infrastructure to allow the outbound POP and IMAP connections to specific business-required sites.

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.