Every organization needs to decide whether it will build and maintain their security infrastructure themselves or pay another entity to fulfill this need. It is the common build-versus-buy decision. It is important that the decision makers are properly informed of the aspects, pitfalls and benefits of each approach before writing a check or signing a contract. When outsourcing, a service level agreement (SLA) helps to spell out those details.
It is important to understand the scope of coverage the MSSP will provide, and to set up and enforce an acceptable service level agreement (SLA). An SLA is a legally binding contract that outlines the provisions of performance and service quality parameters. Each SLA may be different because of the services that are being provided, the response time that is required, if 24x7 coverage is required, the size and complexity of the environment, and the legal and regulatory compliancy requirements that must be met. But the following outlines many of the core items that must be understood, communicated and agreed upon before signing a contract with any MSSP.
To ensure that there are no assumptions or holes in what is or is not being covered in the provided service, the MSSP should provide an extensive and documented explanation of their service.
The parameters can include the number of hours of technical support that is provided, response time to an incident, and extent of responsibility in prevention, remediation and recovery procedures. This is where an organization stipulates the acceptability of availability ranges; for example, the Internet connectivity must be available 99% of the time.
The metrics can dictate that response time to an incident must take place between two and four hours after detection, quality-of-service requirements, percentage of availability of all systems and services being monitored, downstream and upstream bandwidth, and so on. Without the correct metrics, an organization cannot properly track the performance and worth of an MSSP.
An SLA defines the MSSP's obligations. Ramifications need to be documented before an MSSP fails to meet those obligations. The ramifications could be a month of free service or the option to prematurely end the contract. If the MSSP exceeds its documented obligations for six months straight, the ramification could be an automatic renewal of the contract.
Because something will go bad some time, the SLA should provide crisis management processes and a resolution clause. For example, if there is an overwhelming and unstoppable denial-of-service attack under way, the MSSP should help the organization in providing an alternate Internet connection, alternate equipment and possibly a deployable recovery team.
The organization needs to manage the MSSP, because the organization is still ultimately liable for any security breach, legal activities or regulatory deviation. The organization's IT team should be continually updated about the health of the organization's security posture.
The MSSP needs to be informed about the organization's most critical equipment and data because they may require a higher level of protection than other resources. The MSSP needs to understand what data is confidential or trade secrets, and what the ramifications will be if this information is leaked. A non-disclosure agreement and possibly a confidentiality contract should be put into place.
This topic can be approached from two different aspects. Since the organization is extremely dependent upon the MSSP for protection of company resources, how is the MSSP prepared to deal with any disasters they may endure. The other aspect is what are the expectations and requirements of the MSSP if the organization itself endures a disaster.
An MSSP may ensure legal and regulatory compliance for an organization or it may leave that solely up to the organization to manage. Either way, it is very helpful if the MSSP is experienced and knowledgeable about the legal and regulatory requirements the company must comply with so that it can be a helpful resource in these missions.
Just because an organization is using an MSSP does not mean that it no longer needs to be concerned with security themselves. An organization needs to understand what employee security skill set and availability is required for proper company protection.
Trusting another organization to protect critical assets should be a concerning task. Investigate the service provider's reputation, communicate with previous and current clients, and ask the MSSP how they screen individuals prior to employment. You don't want an ex-hacker having privileged access to your company jewels.
Changing configurations within a network can negatively affect production or the current security posture in unforeseen ways. A change control process should be documented and followed. This means that the MSSP must get approval from the organization before it makes a major change to the environment and the organization must alert the MSSP of changes, because the changes could open new vulnerabilities.
Organizations need to protect themselves if the MSSP is not meeting its contractual requirements or if the MSSP files for bankruptcy.
The contract must stipulate that the MSSP does not share any of the organization's "dirty laundry" to any of its other customers or other entities in the industry. If this type of information is released, it can cause serious damage to the organization's reputation.
Finally, the organization should have a lawyer that is familiar with the organization's legal and regulatory requirements review the MSSP contract. This will usually end up with a co-developed SLA that meets all of the organization security and service needs.
About the author
Shon Harris is a CISSP, MCSE and President of Logical Security, a firm specializing in security educational and training tools. Shon is a former engineer in the Air Force's Information Warfare unit, a security consultant and an author. She has authored two best selling CISSP books, including CISSP All-in-One Exam Guide, and was a contributing author to the book Hacker's Challenge. Shon is currently finishing her newest book, Gray Hat Hacking: The Ethical Hacker's Handbook.
This was first published in February 2009