I have shunned offshoring and have written about my concerns in the past. But I worked for a different company when I shared those thoughts, and years have passed since that time. When my current employer started sending some IT activities to an office in India, I was more satisfied than I was in the past that security was being well addressed. For starters, our network and server operations team has moved monitoring offshore. That led to the offshoring of several other activities, including the administration of our network and of the Windows and Unix systems, as well as the help desk and quality assurance operations.
No security-related activities were sent overseas, though. I always wanted to keep security tightly under my control. But it's impossible to ignore the savings that offshoring makes possible, so after talking with peers at other companies, I learned to let go of some of that direct control.
These days, my team is running a number of technologies that are extremely intensive from an operational standpoint, including security incident and event management (SIEM), data leak prevention (DLP) and file encryption. I could keep two to four full-time analysts busy caring for those technologies and responding to incidents, but we just aren't going to be handed the budget to do that in the U.S. So I am now offshoring several security activities, and thus far, none of my fears has been justified.
For every activity that I let our offshore partners handle, I specify their responsibilities versus ours at corporate. I then list the tools and applications to be used and define metrics for measuring performance.
The weekly security scans of our applications and infrastructure are quite time-consuming, so they were a great candidate for offshoring. In this case, the corporate security team is responsible for identifying the tools to be used, establishing a scanning policy and schedule, and specifying the assets to be scanned. The offshore team is responsible for coordinating the scanning, filing change controls if necessary, running and monitoring the scans, validating results, creating reports and managing the remediation activity to completion. They report back to me the status of scan activity, tell us the mean time to remediate issues and identify anything that puts the organization at risk.
Collecting metrics can also be done well overseas. We regularly do this in a process that can be painfully slow, simply because of the number of metrics we produce. For example, we collect URL filtering stats from our firewalls, incidents from our incident response reporting tool, patch and antivirus compliance updates from our systems management tools, and time allocation data from our project management tool. Now, we at corporate simply define the metrics to be collected, and the offshore team actually collects the data and prepares pivot charts and other graphs. As a bonus, the offshore team has automated what it could, giving us a nice dashboard with metrics updated in almost real time.
Next up will be a more complex activity: SIEM administration. This will require some deeper skills; we will need a couple of people who can write scripts, do malware analysis, solve problems, and handle networking and system administration. I've interviewed over a dozen candidates so far, none of them qualified.
Once that is squared away, though, I plan to offshore audit/compliance, incident response, initial response to customer questionnaires, document preparation, response to certain security-related help desk tickets and DLP administration. Within a year, I expect to have doubled the size of our offshore team.
I'm a convert. Even though time-zone differences require meetings at odd hours, the benefits far outweigh the inconveniences.
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 firstname.lastname@example.org.
Join in the discussions about security! computerworld.com/blogs/security
This story, "Learning to Let Go and Offshore" was originally published by Computerworld.