blog

How can you drive better resolution times for vulnerabilities? Context-based incentive in application and cloud security

Context based incentive in application and cloud security
Context-based incentive in application and cloud security

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 Appsec Phoenix 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

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Explore ASPM’s role in modern application security, offering a panoramic view that extends beyond code vulnerabilities. This guide demystifies concepts like traceability, reachability analysis, and asset lineage, pivotal for securing digital assets. Learn how ASPM empowers organizations with actionable insights for precise vulnerability management. #Cybersecurity #ASPM #ApplicationSecurity
Francesco Cipollone
Explore the transformative role of ASPM in cybersecurity. Uncover how Application Security Posture Management aligns business and security objectives for effective vulnerability management and risk reduction. Discover Phoenix Security’s innovative approach to tackling the staggering challenge of CVEs with a strategic focus on prioritization. #ASPM #Cybersecurity #VulnerabilityManagement
Francesco Cipollone
Explore the critical insights into the latest container security vulnerabilities named leaky vessels, including CVE-2024-21626, CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652, BuildKit flaws, with our comprehensive guide on mitigation strategies, best practices for application security, and tips for robust vulnerability management in Docker and Kubernetes environments. Stay ahead in securing your container deployments against potential threats with ASPM help
Francesco Cipollone

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.