Talk:
Shift left has dominated the scene for application security and vulnerability management; we will analyse in this article, Shifting Smart: use a risk-based and contextual approach to vulnerability management. Bringing security tooling from production to the left (development) has generated enormous benefits and improved security practices but also created many vulnerabilities in the backlog.
Application security vulnerability management has been heavily influenced by shit left methodology. The shifting left approach is the method o embedding security tools early in the pipeline and surfacing vulnerabilities as early as possible. This has generated enormous advantages and visibility, creating an enormous sea of vulnerabilities.
Some tooling like Dast can reduce those vulnerabilities, but configuring it and fine-tuning it can take a lot of effort. In a recent Forbes article, longtime Application Security (AppSec) leader Jeff Williams made the case that the industry needs to mature from shifting security “left” to an approach of shifting “smart”.
Shifting smart vs shifting left what is the right approach? What are the benefits of Shifting left?
Shifting smart vs shifting left what is the right approach? This approach is fantastic, and there are tons o sources document the benefit of integrating early in-the-pipeline tools like SCA.
The primary goal of shifting left is to identify and address issues and defects earlier in the SDLC, which helps to improve software quality, reduce costs, and enhance overall efficiency. Here are some key aspects and benefits of shift left:
Early Bug Detection: Developers can identify bugs and defects early on by introducing testing and quality assurance activities. This allows for faster bug fixes and reduces the chances of bugs propagating further into the development process.
Faster Feedback Loop: Shift left enables quicker feedback on code quality, allowing developers to receive immediate information on the impact of their changes. This helps identify and rectify issues promptly, reducing the time and effort spent on rework.
Cost Reduction: Catching and fixing defects early in the SDLC helps to minimize the costs associated with bug fixing. Fixing bugs in later stages of development or even in production can be significantly more expensive and time-consuming than addressing them early on.
Improved Collaboration: Shifting left encourages collaboration between developers, testers, and other stakeholders from the early stages of development. This collaborative approach fosters better communication, a shared understanding of requirements, and alignment on quality goals.
Enhanced Software Quality: By identifying and fixing issues early, shift left promotes higher-quality software development. This results in a more stable and reliable product that meets user expectations and requirements.
Reduced Time to Market: Shifting left helps shorten the overall development cycle. By catching issues early and minimizing rework, development teams can accelerate the release process and bring software to market faster.
What is the drawback of shift left vs shift smart?
Shifting left will help with toolings like sca, sast, container scanners, and other small open-source tools, uncontextualized and noisy vulnerabilities have risen. Shifting Smart will help bring the context from right and the business alignment needed to run an effective application security program.
Testing a library that will be deployed on an internal system with vulnerabilities that won’t even be called generate noise. Moreover, the number o vulnerabilities being reported is increasing by 34% year on year, including application security vulnerabilities. The chart below shows how many vulnerabilities are reported following OWASP’s top 10.
F5 report on vulnerability being reported
Shifting left vs shifting smart, what is attribution?
Shiting left has often been interpreted as scanning everything in code, libraries, containers etc… but attributing findings to specific teams and letting them fix vulnerabilities has been an issue. Shifting smart enables bringing the context and hence the contributors of specific repositories automatically to the application they maintain.
Creating an enormous backlog of vulnerabilities, only security can see does not help anyone. Developers running security tools in the pipeline is a fantastic approach, but it also has the issue of consistency, control and attribution:
- Are the vulnerabilities been scanned consistently across all code bases?
- Are the vulnerabilities being fixed consistently
- Is the security team in control of vulnerability management and resolution?
Ultimately security is everyone’s responsibility, but the security team has to drive a strategic approach and demonstrate results. The ultimate objective of an application and security team is to enable the organization to operate at the risk level that they want to operate. How to translate this “fluffy” statement into something actionable tough?
Having a risk-based approach to vulnerability management for your application, contextualizing vulnerabilities and prioritizing accordingly is key for an organization to enable the business to operate at a risk level that they are comfortable with.
Check out the full article from Adam. When is a vulnerability not a vulnerability? https://www.classcentral.com/course/youtube-bsidessf-2023-when-is-a-vulnerability-not-a-vulnerability-overcoming-the-adam-berman-183999
Check also out Tanya Janca’s article on when a vulnerability is not a vulnerability: https://medium.com/microsoftazure/when-is-a-vulnerability-not-a-vulnerability-41ff9c880adf.
What is SLA and why is SLA still the key metrics for regulation
A lot o regulatory frameworks push organizations to fix by SLA. With the average scanner generating 100-1000 vulnerabilities is hard to stay aligned to sla
Some regulations (not an extensive list) is as follows:
Financial Services Sector: Regulations like the Office of the Comptroller of the Currency (OCC) Bulletin 2013-29 and the Federal Financial Institutions Examination Council (FFIEC) Cybersecurity Assessment Tool require financial institutions to maintain a strong vulnerability management program, including timely patching and resolution of known vulnerabilities.
Healthcare Sector: The Health Information Portability and Accountability Act (HIPAA) Security Rule requires covered entities and business associates to have a process for regularly reviewing records of information system activity, including actions taken to identify and mitigate vulnerabilities.
Government Agencies: Some government agencies, such as the United States Department of Defense (DoD), have specific requirements for vulnerability management. For example, the DoD’s Vulnerability Remediation Program (VRP) sets targets for resolving vulnerabilities based on their criticality and requires regular reporting on the status of vulnerability mitigation efforts.
Get an overview of your asset lineage
How Phoenix Security Can Help shifting smart
Phoenix Security is a platform that collects information from various sources, contextualizes, and prioritizes vulnerabilities from code to the cloud.
If you want to know more about Phoenix security and doing vulnerability management at scale, contact us https://phoenix.security/request-a-demo/
Other regulatory frameworks to mention:
Payment Card Industry Data Security Standard (PCI DSS): PCI DSS is a set of security standards organizations must follow when handling payment card data. While it doesn’t mention CVE timelines, organisations must promptly apply security patches and updates to address known vulnerabilities.
National Institute of Standards and Technology (NIST) Frameworks: NIST provides various cybersecurity frameworks and guidelines, such as the NIST Cybersecurity Framework (CSF) and the NIST Special Publication 800-53. While these frameworks don’t impose specific timelines for CVE resolution, they emphasize the need for organizations to manage vulnerabilities effectively, including timely patching and remediation.
The problem with an SLA-only approach
Approaching vulnerability management with SLA reduces the ability of o development team and security team to operate in a risk-based environment. Deciding which vulnerability to ix when should be driven by risk-based as it has been proven a powerful method. One o the latest research Gartner has shown that organizations doing just SLA for vulnerabilities consistently miss the target (see image below, representing an organisation’s SLA targets). A risk-based approach has been proven more effective in vulnerability resolution.
What is application security posture management and shift smart approach?
- ASPM is an increasingly essential tool for managing application security risks, with its adoption still in its infancy. The report predicts that over 40% of organizations that develop proprietary applications will adopt ASPM by 2026. It emphasizes that when selecting an ASPM vendor, organizations must ensure that the tool meets their specific use cases.
- For ASPM solutions to be successful, they must integrate seamlessly with other security tools and processes, replacing the traditional silos of visibility and responsibility with a consolidated view of security-related information. ASPM solutions must provide actionable insights and prioritize remediation efforts to enable teams to focus on issues that will provide the greatest return in overall risk reduction.
- The report also notes that ASPM solutions must support multiple deployment models, including on-premise, cloud, and hybrid environments. As such, organizations must ensure that the chosen ASPM vendor can support all legacy applications in their portfolio.
- Automation is also key to effective ASPM. The report recommends that ASPM tools automate the testing and remediation process as much as possible to reduce the burden on security teams. This includes automating the testing and remediation process and providing continuous testing and monitoring to promptly identify and remediate new vulnerabilities.
In summary, ASPM is a critical tool for managing application security risks, and its adoption is expected to increase significantly in the coming years. For organisations to benefit from ASPM solutions, they must integrate seamlessly with existing security tools and processes, provide actionable insights, prioritise remediation efforts, support multiple deployment models, and automate testing and remediation processes as much as possible.
Not all critical vulnerabilities are equal.
A critical vulnerability on a product that is externally facing that impacts top-line revenue generating application is more important than a critical vulnerability on a system that is not revenue generating and not business critical.
With a mature risk-based approach to application security vulnerability management, the security team can be ensured that:
- Business criticality is taken into consideration when resolving vulnerabilities
- The probability of exploitation is taken into consideration when resolving and reporting vulnerabilities. The probability of exploitation can be derived from several factors:
- type of vulnerability,
- the exploit vectors,
- cyber threat intelligence,
- Ransomware groups
- Threat actors leveraging the vulnerability
- Exploitability factors
- the location of the asset where the vulnerability manifests
Base severity is traditionally cve/cwss score
How can application security posture management help?
Application security posture helps the organization drive a resolution and remediation with context
Having a product and application view instead of an individual repository/codebase view has the following advantages:
- Enable a business and risk-based approach to vulnerabilities empowering product owners to set risk-based targets that are meaningful
- Enable the security and development team to track and create a narrative around security for the product.
- Enable deduplication and contextualization of vulnerabilities in a more precise way providing the product development team with the ability to link production targets (context) to the software that is running on those environments.
What is a risk-based approach to vulnerability management?
A risk-based approach on vulnerability management for contextualized applications enables the product team to agree on targets and stay within risk-based targets. This enables a powerful combination of risk-based target and SLA targets
We wrote extensively on risk-based approach to vulnerability managment in this book
“Organizations not doing cyber risk quantification are 48% more at risk of a higher cost of data breach than others that don’t.” (IBM Data Breach Report)
The ultimate objective of an application and security team is to enable the organization to operate at the risk level they want.
Translating this statement into actionable tasks is quite a hardouous task. Without appropriate tooling translating product risk into a target is almost impossible.
Contextualizing vulnerabilities and prioritizing accordingly is key for an organization to enable the business to operate at a risk level that they are comfortable with.
Shift Smart: What are the benefits of a risk-based approach
Having products risks based system enables the product owners to
- Control and balance the number of vulnerabilities resolved with the number of stories fixed
- Risk assess, agree, disagree on risk level and drive a risk-based approach to remediation.
- Have a more contextual view on vulnerabilities with shit left and shift right united in a single approach.
- Apply Business context, criticality, and impact on the business to vulnerability remediation.
Conclusion
In 2023 With the number of vulnerabilities increasing exponentially and the CVE database surpassing the 200.000 Vulnerability mark, we need to rethink the way security is being driven. Shifting left and security being the responsibility of every part of the organization is key. Security measurement o progress and accountability is now more important than ever to demonstrate the progress towards resolving vulnerabilities.
How can Security Phoenix Help
Phoenix security enables organizations to ingest vulnerabilities from multiple locations, aggregating them into products and visualizing the risk level of those products.
Phoenix security cutting-edge contextual risk-based algorithms enable organisations to prioritise application security vulnerabilities based on context and probability of exploitation and present a unified impact analysis.
The cutting-edge vulnerability selection engine enables organisations to set risk-based targets that translate into specific actions for engineers.
Get an overview of your asset lineage
Cyber Risk quantification visualization in Phoenix Security Platform
Moreover, Phoenix Security’s correlation capabilities can help organizations link the activities in the code with the context in the shift-right part, ensuring that issues are identified and addressed proactively. Using Phoenix Security’s scorecard, organizations can create a common language between the security, development, and business teams, ensuring everyone is aligned and focused on achieving the same goals.
Finally, Phoenix Security’s ability to create risk-based profiles can help organizations translate their security goals into dynamic and smart targets for engineers. By using risk-based profiles, engineers can prioritize their work and focus on the most critical issues, ensuring that they are making the most effective use of their time and resources.
Overall, by leveraging Phoenix Security’s powerful capabilities, organizations can implement a smart, risk-based approach to software development that ensures the success of their initiatives while minimizing risk and improving overall efficiency. With Phoenix Security as their partner, organizations can feel confident that they are taking a proactive approach to software development that is aligned with their business objectives and goals.
