An SLA stands for service level agreement and is a documented agreement between a service provider and a customer that identifies the services required and the expected level of that service. SLAs play an important role in penetration testing. They establish a baseline understanding between the client and provider on what should be expected during the engagement. In this article, we will cover what an SLA is and how they are important for ensuring you get quality service from your service provider.
SLAs are essential in ensuring clients are satisfied with their pentest provider's performance. It's important to understand that SLAs do not define how the service is provided or delivered but rather focus on service standards. A good SLA is important because it sets clear boundaries and expectations between a customer and a provider. An SLA ensures services are delivered as expected and reduces the chances of disappointment. In the context of a pentest, some of the things you may want to include in your SLA are the testing methodologies that will be used, what infrastructure components will be tested when the testing will occur, the objective of the test and what will be included in the report.
SLAs should be customized to your organization's needs and reflect the amount of sensitive data that could be exposed in a cyber attack. If your application(s) collects sensitive or confidential data, there should be an evaluation to see what realistic and suitable timelines are for your team. In addition to the testing itself, SLAs are important for setting the guidelines and priority for the dev team regarding remediated vulnerabilities to meet customer expectations. Overall, SLAs are the customers' chance to ensure the service meets their expectations.
When implementing an SLA, it can be useful to use generic templates, but they will need to be customized based on your organization's specific needs. For example, the standard SLA timelines will not fit everyone, and it is crucial to set SLAs based on your particular situation. The following specific information must be defined in your organization's Service Level Agreement (SLA):
It would be best if you had specific internal SLAs for addressing vulnerabilities discovered during scanning or pen-testing activities. These should be assigned a severity level appropriate to the type of vulnerabilities that it addresses. These could vary based on the risk potential of the specific target or the context around the vulnerability.
Your SLA should mandate that known open security issues and/or defects should be tracked in a common database or issue-tracking system. This database should be regularly maintained and audited by a security leader. Any collection of issues approaching or expiring the SLA date should be discussed among management, security focals, and development to ensure that nothing is forgotten or overlooked. Regularly scheduled meetings with stakeholders could be an ideal way to discuss issues together.
The first step to meeting your SLAs is to set realistic expectations for delivery. You won’t meet your SLAs if there is no process for determining specific SLA-related numbers. These numbers need to take into account your IT and business context. Once you have quantified what it takes to meet your SLA’s goals, you can devise a process for meeting those targets. During the expectation setting, you should consider client and compliance requirements, not just your business requirements.
Depending on the application (web/mobile, desktop, cloud etc), there may need to be different SLAs based on the context of the application. Some may have more sensitive requirements than others, which needs to be considered when defining your SLAs. Each project should be looked at on an individual basis to create SLA requirements that make sense based on that situation.
The only way you can be sure that you are meeting the requirements of your SLA is to have data on your performance. You should ensure you are tracking data from your team when meeting SLAs. For example, for each vulnerability found during a penetration test, track how long it took to remediate the vulnerabilities compared to your SLA’s expectations. If you can measure metrics surrounding SLA timelines, you will better understand where your team is succeeding and meeting SLA timelines and when they are not. A common method for this is to assign a timeline for remediation for each severity of vulnerability, such as 180 days for lows, 90 days for medium, 30 for high, 15 for critical etc. This way you can ensure that all vulnerabilities are being remediated in a timely manner and the criteria for success/failure is clear.
Businesses and their environments are dynamic, things are always changing, and your SLAs should reflect continuous work and improvement. By reviewing and auditing regularly, you can change things that are not working for your team. You can also evaluate what is going well, how you succeeded, and how this can be implemented across the business.