A service-level agreement (SLA) lays out the obligations of both service providers and their customers to ensure both parties are on the same page and aligns expectations with regards to the functionalities the service is able to provide. Meeting SLA requirements is therefore critical to the success of the company providing the services. But as the number of cyber-security incidents in the software world grows, SLAs can be easily broken.
For example, the company has several critical vulnerabilities found in the system that their client wants them to fix in three days. However, due to the complexity of the solutions and their impact on the system, the company only manages to fix them in one week.
Using a risk-based approach to create and maintain the SLA will ensure its requirements are being met.
Problems with traditional SLAs
Traditional SLAs generally prioritize functionalities, delivery speed, and product performance, without sufficient emphasis on— and sometimes even completely neglecting—the security aspect.
1. Neglecting security issues
Companies sometimes fail to address security issues in their SLA. If a product is designed and built without taking security risks into account, there is a high chance it will have exploitable vulnerabilities. This can escalate to other critical issues, such as broken product functionalities, violations of customer data privacy, or being unable to access the application. These issues can seriously harm a company’s reputation.
2. Failure to take into account actual risks and technical complexity
When it comes to security SLAs, it’s not enough to speak generally about security concerns; the SLA needs to be specific. Rather than say, “We will ensure your data is stored securely in the system.” for example, the SLA should describe exactly how this is achieved. For instance, “by applying blockchain technology to encrypt customer data” or “by enabling multi-factor authentication if the system detects suspicious activity in the user account.” With Vulcan’s vulnerability management program, you can spot your actual risks, with features that help you efficiently understand risks, properly communicate them, and reduce them in the end.
When defining security SLAs, security teams also need to take into account the technical complexity to ensure that security issues are properly addressed in the service they offer. For example, resolving security issues may require implementing an entirely different software architecture or updating the current database scheme. Such major updates to the software system could break the product’s existing functionalities.
3. Neglecting compliance
SLAs often tend to focus on ensuring the security aspect of the service it covers is met, while neglecting to address compliance between the provider and consumer sides. Security compliance, however, is a critical part of an SLA.
Meeting the expected security level requires that both service providers and their customers share the responsibilities. For example, companies are responsible for protecting customer data and ensuring the applications they build are not vulnerable to security attacks. At the same time, when using the application to view sensitive data, customers should follow best practices such as activating multi-factor authentication, not sharing their passwords with others, and keeping printed reports somewhere safe.
In addition, service providers also need to be aware of security compliance that is given by the security councils of governments. Let’s say your company is an e-commerce platform that supports users’ purchases via credit cards. If this is the case, you must comply with the Payment Card Industry Data Security Standard (PCI DSS). PCI Requirement 6.2 requires ensuring “that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Additionally, PCI DSS needs to be implemented within 30 days to identify a critical or urgent security patch.”
Complying with PCI compliance is obviously not an easy task since there are many components and aspects you have to cover. Check out this article to see how Vulcan Cyber can help you comply with PCI DSS.
4. Failure to take business requirements into account
Security SLAs should be well defined and applied to those risks that are actually relevant to the services that SLAs cover. This will enable security teams to focus on resolving security issues that affect the business. By adding context to the assets affected by security issues, the SLA program can be much more powerful in identifying spots that require attention first.
A risk-based approach to SLAs
When creating SLAs, it is important to consider the risks that may exist after launching your company’s product. You should determine those risks that are tolerable as well as critical risks that can lead to SLA breaches.
In order to meet security SLAs, it is important that the risk report include:
- Risk profile: Description of the risks and other relevant information such as their background, history, and quantifiable value.
- Risk capacity: This metric identifies the level of risk an organization can afford to take in terms of budget, revenues, or time to resolution of security risks, for example.
- Tolerance levels: A measurement of the level of risk an organization is prepared to take, which is generally significantly lower than the risk capacity.
- Key risk indicators: Quantify the risk with a number so that if any of the key risk indicators are under or exceed the expected value, an SLA breach will occur. For example, for the risk of data loss, you can have the key risk indicator for measuring the number of system backup failures. If the number of failures in total backup times is more than 20 percent, then there will be an SLA breach.
How to set a proper SLA
In order to set a proper SLA your organization can realistically meet, there are a number of factors to take into account.
1. Organization risk appetite
SLAs should be implemented based on your organization’s risk appetite. For example, a securities company must minimize risks as much as possible since they can directly affect the customer trading results or lead to exposure of sensitive customer data.
2. Execution capabilities
An SLA should always reflect your execution capabilities. For example, if it generally takes your team four to five days to remediate an exploited vulnerability and deploy the update to the production environment, the SLA should set a realistic time frame for remediating security issues rather than make false promises to impress users. This can also differ between teams; each team should set an SLA they can execute, depending on their constraints and capabilities.
3. Application
Every application may require a different assurance level for remediating security issues. Some applications may be able to recover from security problems without much difficulty, while in other cases the process may be complex or time consuming.
For example, let’s assume a genetics testing application user report page includes a link for users to download their genetics report but fails to enable password verification prior to accessing the report. Because the link is automatically generated for each user after their genetic data has been analyzed, fixing this security issue would require rerunning all of the users’ data in the genetics testing pipeline. This would take significant time and system resources.
In another scenario, however, if an e-commerce website with an API that retrieves users’ personal information neglects to add an authentication header to it, the code for the particular API can be updated and the change applied to the production environment right away.
4. Technology
Technology is another important aspect to consider when creating a security SLA, as it can impact the time and resources required of the software product teams as well as product implementation and maintenance costs. For example, a website code in Python or JavaScript might be easier to update versus a runtime component in C++; or, a data science algorithm might take longer to test after a library update.
Tracking SLA breaches
Evaluating performance against your SLA involves tracking SLA breaches across the entire organization, then ensuring you have the resources needed to resolve the breaches.
Effectively tracking SLA breaches entails:
- Identifying SLA breaches: The breaches can be identified by collecting key risk indicators or from customer support teams.
- Prioritizing: Not every SLA breach bears equal importance. Organizations should address those with the greatest business impact first.
- Monitoring: SLA breaches should be continuously monitored to ensure issues are addressed and do not recur.
Meeting SLA performance
The following processes should be implemented in order to meet the expected SLA performance:
- Set the baseline for the security SLAs. This is the minimum requirement security SLAs have to meet.
- Create a policy for exceptions that allows omitting security SLAs related to those vulnerabilities that cannot be remediated anytime soon.
- Ask managers and business leaders to review a draft of the SLA before it is published.
Monitoring SLAs
Monitoring your SLAs is key to ensuring you are meeting the outlined requirements. For example, if a system scan reveals a vulnerability in which all the AWS EC2 ports are open to public use, the vulnerability instance should be assigned to the responsible personnel immediately. Or, if it appears a key risk indicator is about to exceed its threshold value, the team in charge should be notified and respond accordingly.
A security posture rating can help track and monitor your security SLAs, allowing you to prioritize remediation resources and pinpoint strategic risk pitfalls. In addition, the SLA compliance KPI specifies the percentage of assets complying with your SLA so you’re aware of the work that remains to reach 100%.
Handling SLA breaches
Security teams should track vulnerabilities that breach SLAs and collaborate with other teams to remediate them. If the SLA requirements cannot be met, the SLA policy should be updated. Teams should also think about creating multiple SLA policies covering compliance, risk appetite, and organizational limitations.
In cases where there is a backlog of old vulnerabilities that are breaching your SLA, a one-time dedicated project or “task force”may help resolve the issue and get you back to baseline. If the vulnerabilities cannot be resolved in the near future—whether due to technological limitations or business requirements—teams should consider this a risk exception and set a realistic deadline for resolution.
Creating and managing SLAs using a risk-based approach helps ensure your SLA requirements are practical while minimizing the risk of SLA breaches. But the infrastructure required and establishing a dedicated team to address the cyber-security risks can be costly. Moreover, if not properly implemented, it can lead to inefficiencies and poor SLA management.
The Vulcan Cyber® risk management platform offers built-in security best practices, vulnerability prioritization, and easy collaboration to help you manage SLAs efficiently so you can own your risk. Get your free demo today.
