It’s no secret that cybersecurity businesses today face more threats than ever before. And with the COVID-19 pandemic forcing more businesses to move their operations online, the risks are only increasing. So how can you protect your business from these threats?

One way to do this is by using rewards and incentives to fix vulnerabilities in your business. By offering rewards for finding and reporting vulnerabilities, you can encourage your employees and customers to help you identify and fix potential security risks. And by offering incentives for implementing security best practices, you can encourage your employees to take the necessary steps to protect your business.

So if you’re looking for a way to improve your business’s cybersecurity, consider using rewards and incentives. It’s a simple and effective way to make your business more secure.

Why are the incentives for fixing issues? How can a team be incentivised to fix vulnerabilities? 

Google: “it is a cultural thing; we know certain vulnerabilities are bad and need to be fixed, period. ”

By offering rewards and incentives for employees who help you identify vulnerabilities, you can encourage them to come forward and help you make your business stronger. So if you’re looking for a way to fix vulnerabilities in your company, consider using rewards and incentives to get employees on board.

Now, how can you apply that philosophy to your organisation?

– Contextual view of who is responsible for specific vulnerabilities and drives ownership 

– Make a timeline and fixing specific vulnerabilities a mandate and enforce SLA

Context:

Specify which vulnerability is associated with assets that are exposed externally and which assets are exposed internally. Monitor/discover your surface.

Even with context, you need to track ownership.

One of the first steps is to understand who is responsible for specific vulnerabilities and who drives ownership. By understanding this, organizations can more effectively manage their risk. For example, if an organization knows that a particular vulnerability is owned by the security team, it can take steps to mitigate the risk. Alternatively, if the development team owns a vulnerability, the organization can work with the team to resolve the issue.

Techniques (hate it or not) to encourage fixing

– Champion programs, dashboards, and competitions

– SLA and reporting/escalation for a specific severity

– Dashboard reporting for what’s outside SLA

– Escalating vulnerabilities

– Driving a top-down approach based on targets and risk 

Security Champion programme and competition

Security champion programs are designed to engage and empower employees to be proactive about security. These programs typically involve assigning champions to different departments or business units. The champions then work to educate and raise awareness about security within their respective groups.

The security champion programme can be used to find the supporter in every group that will lead the engagement. The responsibility of fixing cloud and application security vulnerabilities remains with the business owners, but this programme helps scale the security team.

In addition to security champion programs, companies can also use dashboards and competitions to motivate employees. Dashboards can track progress and identify areas where employees need more education. Competition can encourage employees to take more action and make better security decisions.

SLA and reporting/escalation for a specific severity

SLA/ SLO / SLI is used to prioritize vulnerability. Those timers need to be contextualized and linked as much as possible to when a ticket/resolution is open and needs to be closed.

Timeline escalation and reporting based on those triggers could be key elements to stimulate the business to track and record breaches of timelines.

Example of SLA

This document describes the Service Level Agreement (SLA) for severity levels of Incidents and Requests. It also provides guidance on when and how to escalate an Incident or Request. Those are by no means to be taken as resolution time.

Severity Level 1 – risk level critical

– Response time: 1 hour

– Resolution time: 4 hours

– Escalation: CIO/CISO/ Board

Severity Level 2 – risk level high

– Response time: 4 hours

– Resolution time: 7 days

– Escalation: Line of business / CIO

Severity Level 3 – risk level medium

– Response time: 2 days

– Resolution time: 14 days – 30 days

– Escalation: line of business

Severity Level 4 – low

– Response time: 15 days

– Resolution time: 100 days

– Escalation: application owner

Another guideline from the industry can be found at https://blog.palantir.com/how-palantir-manages-continuous-vulnerability-scanning-at-scale-9fbe25039ff5.

The time for resolution broken down between patching and software could be a red flag, but for the sake of this article, we will supersede and address this in a different article

Resolution time (palantir)

For vulnerabilities in underlying infrastructure, containers, or hosts, we adhere to the following maximum SLAs:

• CRITICAL: 72 hours
• HIGH: 30 days
• MEDIUM: 90 days
• LOW: 120 days

For vulnerabilities in Palantir-developed software products, which may be significantly more complicated to remediate, we adhere to the following maximum SLAs:

• CRITICAL: 30 days
• HIGH: 30 days
• MEDIUM: 90 days
• LOW: 120 days

Escalating vulnerabilities

Escalation might be a bad word for security because it can cause friction. Nonetheless, it can sometimes become an effective incentive, even though not the only one.

Severity Level 1 – risk level critical

– Trigger: Breach of SLA for more than 10%

– Escalation: CIO/CISO/ Board

Severity Level 2 – risk level high

– Trigger: Breach of SLA for more than 20%

– Escalation: Line of business / CIO

Severity Level 3 – risk level medium

– Trigger: Breach of SLA for more than 30%

– Escalation: line of business

Severity Level 4 – low

– Trigger: Breach of SLA for more than 40%

– Escalation: application owner

So what is the best way

• Driving changes and security as organizational culture
• Driving ownership of assets and tracing who is responsible for what in a programmatic way
• Prioritizing what’s most important leveraging a risk-based approach https://staging-appsecphoenixcom.kinsta.cloud/context-is-king-in-appsec-cloudsec/
• Focusing on actionability first and delivering high-quality signals to the right teams.
• Reporting and being clear on the escalation timelines

Conclusions

Organizational culture, Tracing ownership, driving change and fixes from the top down, focusing on actionability. No matter what you do, consider a holistic view of cybersecurity resolution and incentives. Even better, discuss options with the team on the ground. Usually, the best answer is something that is already implemented (in most cases informally) inside teams.

Most importantly, celebrate victories and achievements with teams that support change and reward achievements during resolution. Positive reinforcement is always a great driver to incentivize people to do better and more.

How Can Phoenix Security Help

Appsec phoenix is a saas platform that ingests security data from multiple tools, cloud, applications, containers, infrastructure, and pentest.

The phoenix platform Deduplicate correlates, contextualises, and shows risk profile and the potential financial impact of applications and where they run. 

The phoenix platform enables reporting, setting the context and delivering the vulnerabilities that matter most to the right team.

The business can set risk-based targets to drive resolution, and the platform will deliver a clean, precise set of actions to remediate the vulnerability for each development team updated in real-time with the probability of exploitation.

Appsec phoenix enables the security team to scale and deliver the most critical vulnerability and misconfiguration to work on directly in the backlog of development teams. 

Request a demo today https://staging-appsecphoenixcom.kinsta.cloud/demo