SLAs (Service Level Agreements) are pretty common among vendors and companies in the IT industries. This agreement defines all the expectations of a company from their service provider or vendor based on various metrics to measure the estimated performance.
The SLAs are also used by various departments within a company to smoothly run all operations based on certain expectations. The same goes for the Cybersecurity industry where companies sign SLAs to fix certain vulnerabilities in a 30, 60 or 90 days period.
This time period is pretty vague and arbitrary, therefore security experts rarely meet the expectations because of various reasons. Let’s dive deep and see how important is SLA for resolving vulnerabilities to help other counterparts such as developers work better.
Importance of SLAs in Vulnerability Management
Service-level agreements are adopted by many companies who deal with vendors in their industry. In the cybersecurity sphere, SLAs are also utilized by company executives to fix certain vulnerabilities in a fixed number of days or months. Many executives expect unachievable results in their SLAs, especially when it comes to fixing vulnerabilities.
For Example, many companies aim for fixing vulnerabilities with CVSS Score of 7 or above in a 30 days time frame. The security teams ask IT experts or other counterparts to fix vulnerabilities with a 7+ CVSS score in less than 30 days. These vulnerabilities are often counted as half of all other CVSS scores. It is extremely hard for security experts to achieve this goal within given time period.
Therefore, companies need to measure the extent of work before they impose an SLA to any counterparts within or outside their organization. They should use a data-driven approach to fix certain vulnerabilities first or extend the timeframe in the agreement.
Issues during SLAs Construction
Wrong vulnerability management is the root of unachievable SLA. The executives often set wrong expectations from their developers because they did not smartly manage all their vulnerabilities. The issue might arise from the wrong prioritization of vulnerabilities.
Above all, executives are also pressured to fix certain vulnerabilities before hackers find and use exploits. Hence, they often rush into fixing all major issues at once by setting wrong expectations based on faulty matrices.
Why get SLA?
SLAs give a clear direction to the counterparts who are working to resolve an issue or solve a specific problem. According to industry research and Phoenix Security data, it normally takes between 180-290 days to remediate all vulnerabilities on a corporate network.
Companies aim for high-risk vulnerabilities first, and it certainly shortens your time to fix the flaws. An SLA is effective to set the time interval for fixing vulnerabilities, but executives should use a data-driven approach to decide all factors of the agreement including service, time intervals, obligations and penalties.
It allows clarifying expectations and sets established standards for developers and other counterparts who are working to fix or patch certain high-risk vulnerabilities. A data-drive SLA is always an effective way to make developers focus better on their work rather than in internal debates.
Evidence-Based SLAs
All service-level agreements should be backed by some kind of evidence that could potentially ease the developers. This evidence is often data-driven. A normal organization only has the capacity to fix 1 out of 10 vulnerabilities. Organizations often debate over which vulnerabilities should be fixed under the SLA and these internal debates divert the attention of developers.
Today’s risk management platforms have real-time insight into mean time to remediation (MTTR) and mean time to exploit (MTTE), allowing them to provide SLA assurance recommendations that directly tie to an organization’s risk appetite. The lower an organization’s risk tolerance, the faster it will have to remediate.
Using Risk-Based SLAs
Risk-based SLAs might be the effective option for executives who are willing to support their dev teams. Companies need to assess their risk category before they determine any components of their agreement. These Risk-Based Factors are categorized as:
- Low Risk — A company having capabilities to remediate vulnerabilities extremely fast.
- Medium Risk — A company that wants to remediate on a faster pace than their previous performance.
- High-Risk — A company with the lowest risk tolerance, that wants to remediate vulnerabilities as quickly as possible before a hacker finds and exploits those flaws.
The Risk-Based SLAs allow organizations to assess their risk tolerance levels. It also helps analyze two other major factors, such as the prioritization of assets upon which SLA is being set. These variables are combined to determine the timeframe recommendation for the SLA based on their risk. If executives also rely on these factors for their SLAs then it can really help developers to fix issues while meeting all the expectations.
AppSec Phoenix’s Risk Solution – Risk Indication for SLAs
AppSec Phoenix offers real-time risk-based indicators to help executives make informed decisions and develop better SLAs to support developers who act to fix those vulnerabilities.
According to Bakermckenzie survey, the greatest third-party risks companies face in their supply chains are the insolvency of key suppliers partners and data/cybersecurity.
We have got you covered from all third-party supply chain risks by providing detailed insights under our single pane of glass to give you an overall review of threats. Also, we provide a single aggregation point across multiple platforms to easily identify and remediate vulnerabilities.
Bottom Line
Executives can use risk indicators to construct better SLAs for developers who work to resolve certain vulnerabilities in expected timeframes. Also, evidence-based SLAs are necessary to manage vulnerabilities effectively. Otherwise, attackers may find and exploit potential threats due to bad vulnerability management and unachievable expectations from developers.
The Phoenix Security Way
With Appsec phoenix you can set your policy based targets and see where the organization is in comparison to internal and external industry targets. Check where your organization is and how to improve application security with the most advanced frictionless platform, get an Phoenix Security demo today and try it yourself
