Anyone thinking about outsourcing such a mission-critical aspect of their network should understand in detail the potential implications to their IT security infrastructure as well to as their company. One of the biggest differences among providers of security services is the service level agreement (SLA). In this five-part series of articles, we will dive deep into the various aspects of the SLA and attempt to explain in details what the SLA should contain and why each of the items is necessary. In general, a MSSP SLA should cover the following areas: Service Summary or Description The service summary section usually appears in the introductory section of the SLA. It should always state the name of the provider and the name of the customer.
This summary will enumerate the obligations you, the customer, have in order to satisfy the SLA. For example, you may be asked to provide up-to-date contacts, network topologies, and customer escalation paths. This section will usually list the support level (e.g., Gold or Platinum) you have purchased. The support level determines how fast the service provider will respond to your service requests, how many service requests you're allowed per week or month, how often you will be notified during emergencies, and most importantly, what your general service availability guarantee is.
Hardware
Service providers host security services in a variety of ways. Some will install dedicated hardware at your site. Some will provide you with dedicated hardware, but it sits in the provider's own NOC. And others will provide the security service through virtual domains that share, with other customers, the same physical hardware located (again) at the service provider's site.
Regardless of the method used, the service provider should state clearly in the SLA how the service is to be provided. Once you're sure of the hardware in use, you will be able to ask intelligent questions about hardware specification, performance, throughput, size, upgrades, and so forth. Software Most service providers use products from name-brand companies such as Check Point, ISS, Cisco, and others. Other service providers will use open source software such as Snort for IDS.
It's important to know what software will be used for the service you have purchased. Your company may have specific requirements, such as avoiding unsupported open source software on any of your IT infrastructure. In that case, software such as Snort may be out and the service provider must use vendor-supported products .Knowing what software is used also allows you to better understand the relationship between the service provider and the software vendor. For instance, if your service provider is using Cisco PIX as the firewall software but there's no CCIE on staff, that would certainly be a cause for concern.
Service availability
Perhaps the section with which readers will be most familiar is the service availability section. This section describes exactly what the service level guarantee you will receive as a customer. For example, one of the most critical service level guarantees is uptime percentage. 99.5 percent uptime means that your site can potentially be down for 216 minutes per month without any penalty for the service provider. If the service is down more than the guaranteed level, the service provider will compensate you for that period of time . It is critical to understand what the service provider considers to be downtime. For example, most service providers will not consider upgrades to constitute service downtime; therefore, you will not be compensated for those periods of unavailability.
Other service level guarantees the agreement may specify include how fast the service provider will respond to your service requests, how long upgrades will take, how fast service providers will detect and report problems, and so fort h.Another critical consideration is how the service provider will be penalized if the service level guarantee is not met. In most cases it simply means the service provider won't bill you for that period of time.
Service requests
SLAs generally provide for a number of standard service requests per month and a number of emergency service requests per month. Understanding when the service call will be considered an emergency request will allow you to properly plan for changes. For example, if the service provider considers any requests you want performed outside of standard business hours (8-5, Mon-Fri) to be emergency, and most of the changes you want fall into that timeframe, you may have a problem. There are other considerations when negotiating your service-request needs. Some service provider may limit the number of IT personnel from your company allowed to open service requests.
Some providers may consider certain service requests to count as two. Some service providers may charge extra for certain service requests. Naturally, the list goes on.
Monitoring and reporting
Network administrators can find it extremely frustrating when they're unable to quickly perform troubleshooting when the network is unexpectedly down, or not by having the resources to quickly do forensic analysis when an incident is detected.Service providers are doing a much better these days in providing reports to customers on bandwidth utilization, uptime analysis and log management.
However, there's still quite a bit of difference among service providers, and a number of questions you'll need to know to ask.Does your service provider provide the most up-to-date configuration online for your review? Will you receive daily, weekly or monthly reports based on your firewall/IDS/VPN logs? What about ad-hoc or custom reports so you can perform troubleshooting or forensic analysis? And will you be assured of backups of all configurations?Availability, responsiveness, quality, and communication are important elements to consider for any service provider SLA. In the next four articles in this series, we will discuss each of the above sections in details, including the specific considerations for each topic, why it matters, what you should expect and the norms are among service providers.
About the author: Jian Zhen, CISM, CISSP, is the Director of Product Management at LogLogic, a log management vendor in Sunnyvale, Calif. He has been in the information security industry for nine years. He can be reached at zhenjl@gmail.com or through his blog at Operational Intelligence.