Whose worms are they?

Security issues continue to be top-of-mind for most of us as worms, viruses and other germs plague us almost constantly, as last week’s Sasser worm demonstrated. In most companies, the necessary investment to counteract the on-going threats is significant and growing, which leaves organizations focusing their technology and policies on mitigating the security risks. But what if your IT services are outsourced? Who is responsible for the security of your corporate data?

One of the principle advantages of outsourcing is to reduce the management burden of the technology infrastructure. An outsourcing organization takes on the responsibility for managing all aspects of the outsourced services, including the management of the constituent technology components. Therefore, service providers take on the responsibility for maintaining the security of those components.

This security management includes both the obvious tasks of managing the operating system or firmware patches necessary to maintain the most defensive and resilient components possible, as well as ensuring the prudent design and administration of the overall technology infrastructure protects the environment from intrusion, infection, and attack. Given the service provider’s position as the expert, the provider can be expected to be particularly aware of possible threats and the best defenses. As a result, the expectations that the customer has of the provider are quite high.

Given these truisms, then, service-level agreements (SLA) should include specific language for securing the infrastructure and measurement of service-level objectives (SLO) to show the level of compliance that the provider is achieving. However, as I wrote earlier this year in Network World’s Network and Systems Management newsletter (link below), customers must be mindful of placing unreasonable requirements on their providers and providers should remain mindful of making promises that they can’t keep.

So, then, how can providers approach security SLAs in a way that provides a level of protection for their customers while not taking on all of the risk of possible attack? The key is dedicated security staff, clear security guidelines and policies, and constant monitoring of all aspects of the environment. The most difficult challenge of the process is defining specific SLOs to outline the areas of focus that both parties agree are the best options for avoiding the security issues and the associated risks. Part of the challenge is recognizing that there are likely broad differences in experience and expertise between the two organizations, with the customer effectively wanting a guarantee of complete security while the provider is forced to recognize that there are always at least some risks.

SLOs to consider include the currency of patches, timeliness of the provider’s security knowledge, testing of the infrastructure including both penetration testing and service-specific testing, and the up-to-date demonstrated expertise of the service provider’s security staff using industry-standard certifications as a measure.

While overarching SLOs such as availability and end-user performance metrics will be impacted by significant security events, other security events are not so obvious through these more traditional metrics. For example, the compromise of a customer information database may not negatively impact service available but is clearly a breach against which the provider must be actively working.

Recognizing security as an integral component of the overall service delivery and measuring and monitoring the various security metrics will provide some peace of mind and clear perspective on the boundaries of responsibility for both parties.