Effective security on a tight budget

Effective security on a tight budget

Speakers: Felix Matenaar

Conference: BSidesSF 2024

YouTube: https://www.youtube.com/watch?v=H6G5fIrGh7E

Overview

In an era characterized by persistent budget constraints, amplified by recent tech downturns and increasing regulatory pressures, security organizations often find themselves in a precarious position. Felix Matenaar, Head of Product Security at Asana, delivered a compelling talk at BSidesSF 2024, titled "Effective security on a tight budget," addressing this pervasive industry challenge. Matenaar's presentation offered a dual-pronged approach: first, a framework for security organizations to critically assess their own effectiveness and prioritization of resources, and second, practical strategies to more effectively influence funding and maximize existing budgets.

The core of Matenaar's argument is that while external factors contribute to budget pressures, a significant portion of the pain experienced by security teams can be "self-inflicted" due to misaligned priorities and inefficient resource allocation. He introduced a novel "Pyramid of Security Needs" model, drawing parallels to Maslow's Hierarchy, to guide organizations in building a robust security posture from the ground up. This model emphasizes that higher-level security maturity cannot be effectively achieved without solidifying foundational security hygiene and compliance.

This article delves into Matenaar's proposed maturity model, exploring each layer of the pyramid with practical examples and considerations. It further dissects his four key strategies for smarter program funding, ranging from cultural shifts in responsibility to strategic financial negotiations and automatic scaling mechanisms. The insights provided are crucial for security practitioners, leaders, and even C-suite executives grappling with the complex interplay of security investment, risk management, and organizational growth in a resource-constrained environment.

Background

▶ Watch: Introduction of the 'Pyramid of Security Needs' as a maturity model. (02:00)

The security industry has long grappled with the perception of insufficient budgets, a challenge that has only intensified in recent years. Felix Matenaar highlighted that this problem has been exacerbated by a significant tech downturn over the past two years, leading to tighter financial controls across many organizations. Simultaneously, the regulatory landscape is becoming increasingly complex and demanding. Matenaar cited examples such as evolving privacy regulations, the emerging security implications of AI, and the push for greater transparency following incidents like SolarWinds. These factors collectively increase the liability and pressure on security practitioners, making the resource problem more acute.

Matenaar posited that the industry's struggle with tight budgets stems from two primary areas. Firstly, he suggested that some of the pain is self-inflicted, arising from how security organizations assess their own effectiveness and prioritize their efforts. This often leads to misallocation of resources, where teams might pursue advanced, "exciting" projects without adequately addressing fundamental security gaps. Secondly, there's a persistent challenge in effectively influencing funding decisions and securing adequate budget from the broader organization. Security teams frequently struggle to articulate the value of their work in terms that resonate with business leaders, or to offload security responsibilities to other departments that benefit from security investments.

To address the first challenge of internal effectiveness and prioritization, Matenaar introduced the Pyramid of Security Needs. This mental model is inspired by Maslow's Hierarchy of Human Needs, where basic physiological needs must be met before an individual can pursue higher-level self-actualization. Similarly, in security, Matenaar argued that an organization cannot achieve advanced security maturity without first establishing and consistently maintaining foundational security controls. Neglecting these lower levels in favor of more sophisticated programs, he contended, often results in a poor return on investment (ROI) and leaves the organization vulnerable to "stupid" but preventable breaches. The pyramid provides a structured approach to evaluate an organization's current security posture and make informed decisions about where to allocate limited resources for maximum impact.

Key Findings

▶ Watch: Understanding security posture through threat modeling, risk registers, and b... (05:00)

Felix Matenaar's presentation centered on two main contributions: a structured Pyramid of Security Needs for assessing organizational effectiveness and prioritization, and four actionable strategies for smarter program funding.

The Pyramid of Security Needs outlines five distinct levels of security maturity, each building upon the one below:

1. Adhere to Applicable Law, Compliance, and Regulation: This foundational level focuses on avoiding legal repercussions. The objective is simply "don't get sued." Matenaar noted that while this is a must-have area, its funding is often a trivial case as it's legally mandated. Compliance requirements vary significantly based on business type and customer location.
2. Establish Security Fundamentals and Hygiene: The objective here is "don't get hacked in a stupid way." Matenaar emphasized that most breaches today can be traced back to a lack of consistency or coverage in basic security fundamentals, such as missing two-factor authentication (2FA), unpatched systems, or inadequate employee training. Achieving this level requires consistent investment and comprehensive coverage across the entire organization.
3. Deeply Understand Your Security Posture: Once fundamentals are in place, organizations can move beyond checkbox compliance to genuinely understand their unique weak spots. This involves activities like threat modeling, maintaining a risk register, fuzzing, and running bug bounty programs. Matenaar stressed the importance of a breadth-first search approach, declaring what the organization is and isn't protecting against, rather than getting lost in deep, narrow analyses.
4. Establish Security Resilience: This level aims to "keep motivated attackers at bay." It builds directly on a deep understanding of the security posture. Examples include implementing zero trust architectures, adopting an assume breach mindset, and employing security in depth strategies. Matenaar raised a critical question for this level: whether the organization truly has the funding to achieve this without sacrificing lower-level hygiene, and whether some risks might be more effectively covered by insurance. He argued that investing here while fundamentals are weak yields an almost zero ROI.
5. Test Novel Attacks Against Your Systems: The pinnacle of security maturity, this level is designed to "keep sophisticated attackers at bay." It involves preparing for advanced threats like zero-day exploits, supply chain attacks (assuming third-party compromise), and even broken cryptography in critical systems, requiring stronger isolation and compartmentalization. Matenaar suggested that most organizations do not need to reach this level and should again consider if insurance is a more pragmatic solution. Executing at this level demands unique talent, often requiring external contracting.

Matenaar's key findings regarding funding strategies are:

1. Shift Security Responsibility: Cultivate a culture where system owners are implicitly responsible for security, unless the security organization explicitly provides support. This allows the security team to define its charter and, when asked to take on more responsibility (e.g., fixing vulnerabilities, patching, incident response), negotiate for additional funding or resource transfer from the benefiting teams.
2. Build If and Only If You Can Buy: Counter the common tendency for security engineers to build custom solutions. Matenaar argued that organizations often build too much, leading to sunken cost fallacy and missed opportunities with commercial or open-source vendors. He recommended making headcount and vendor budget fungible and incentivizing managers based on impact and scope, not team size, to encourage vendor evaluation and integration.
3. Shift Left, Shift Funding: When security investments mature and provide significant velocity or cost-saving benefits to other departments (e.g., static analysis findings exposed earlier to developers), use this as an opportunity to ask for funding contributions from those benefiting teams. Security teams often absorb this additional work without seeking compensation, missing a crucial funding opportunity.
4. Scale Security Automatically: Establish a clear, data-driven ratio for security staffing relative to the supported organization. Matenaar suggested a 2% security to engineering headcount for mid-sized and large companies, and at least one engineer per program for smaller ones. He warned against the anti-pattern of funding only "net new" work, which incentivizes shiny projects over the consistent scaling of foundational security, ultimately leading to "stupid" hacks.

Technical Deep Dive

▶ Watch: Shifting security responsibility to system owners as a cultural change. (11:00)

Matenaar's Pyramid of Security Needs provides a structured framework for understanding and prioritizing security investments. Each level represents a distinct stage of maturity, with specific objectives and technical considerations.

At the base is Level 1: Adhere to Applicable Law, Compliance, and Regulation. This is the non-negotiable foundation. Technically, this involves implementing controls and processes to meet legal mandates such as GDPR, CCPA, HIPAA, or industry-specific regulations like PCI DSS. The technical work here includes data classification, access controls, audit logging, and privacy-by-design principles. While seemingly basic, the specific technical requirements can be complex and vary significantly based on the type of business, the data it handles, and the geographical locations of its customers. Failure at this level results in legal and financial penalties, making it a "must-have" for any organization.

Level 2: Establish Security Fundamentals and Hygiene is where most organizations should focus significant, consistent effort. The objective, "don't get hacked in a stupid way," directly addresses common attack vectors. Technical implementations at this level include:

• Patch Management: Ensuring all systems (servers, workstations, network devices, applications) are regularly updated to address known vulnerabilities. This requires robust asset inventory and automated patching tools.
• Identity and Access Management (IAM): Implementing strong authentication mechanisms like multi-factor authentication (MFA) for all accounts, especially privileged ones. Enforcing the principle of least privilege.
• Security Awareness Training: Educating employees on common threats like phishing, social engineering, and secure coding practices.
• Network Segmentation: Limiting lateral movement for attackers by segmenting networks and applying appropriate firewall rules.
• Endpoint Protection: Deploying antivirus/anti-malware solutions and Endpoint Detection and Response (EDR) tools.

Matenaar stressed that achieving this level is not about having a program, but about consistent coverage across all systems and employees. A single unpatched system or an employee without 2FA can undermine the entire effort.

Moving up, Level 3: Deeply Understand Your Security Posture shifts from generic hygiene to specific risk identification. This is where organizations start to gain genuine insight into their unique vulnerabilities. Technical activities include:

• Threat Modeling: Systematically identifying potential threats and vulnerabilities in applications, systems, and infrastructure. This often involves frameworks like STRIDE or PASTA.
• Risk Register: Documenting identified risks, their likelihood, impact, and current mitigation status. This provides a structured view of the organization's risk landscape.
• Vulnerability Scanning and Penetration Testing: Regularly scanning for known vulnerabilities and conducting simulated attacks to find exploitable weaknesses.
• Fuzzing: Automated testing techniques to discover software bugs and vulnerabilities by feeding malformed or unexpected inputs.
• Bug Bounty Programs: Engaging external security researchers to find and report vulnerabilities, often for a reward.

Matenaar emphasized a breadth-first search here, ensuring a wide understanding of the attack surface before deep-diving into specific areas. The goal is to declare what the organization is and isn't protecting against, making conscious risk acceptance decisions.

Level 4: Establish Security Resilience focuses on maintaining operations even when under attack, aiming to "keep motivated attackers at bay." This level assumes that breaches will happen and focuses on minimizing their impact. Technical strategies include:

• Zero Trust Architecture: Shifting from perimeter-based security to a model where no user or device is trusted by default, regardless of location. This involves continuous verification of identity and device posture.
• Assume Breach Mindset: Designing systems and processes with the assumption that an attacker has already gained initial access. This drives investments in detection and response, containment, and recovery capabilities.
• Security in Depth: Layering multiple security controls to create redundant defenses, so that if one control fails, others are in place to prevent compromise.
• Incident Response Planning: Developing and regularly testing comprehensive plans for detecting, responding to, and recovering from security incidents.

Matenaar highlighted the critical question of ROI here, suggesting that if Level 2 fundamentals are weak, investing heavily in Level 4 might be less effective than shoring up the basics. He also provocatively suggested considering cyber insurance as a potential alternative for certain risks at this level, especially if the cost of full resilience outweighs the potential financial impact of a breach.

The apex is Level 5: Test Novel Attacks Against Your Systems, designed to "keep sophisticated attackers at bay." This is for organizations facing nation-state adversaries or highly resourced, persistent threats. Technical considerations are extremely advanced:

• Zero-Day Exploit Mitigation: Developing capabilities to detect and respond to attacks leveraging previously unknown vulnerabilities.
• Supply Chain Security: Proactively assessing and mitigating risks from third-party software, hardware, and services, assuming potential compromise. This might involve software bill of materials (SBOM) analysis and rigorous vendor security assessments.
• Stronger Isolation and Compartmentalization: Implementing advanced architectural patterns to severely limit the blast radius of a compromise, such as microsegmentation, containerization, and virtualization with robust security controls.
• Assumption of Broken Cryptography: Testing systems against scenarios where cryptographic controls might be compromised or bypassed, requiring alternative protection mechanisms.
• Chain of Exploits and Techniques: Simulating multi-stage, complex attacks that combine various vulnerabilities and techniques.

Matenaar explicitly stated that most organizations do not need to reach this level, and it requires unique talent often found in specialized red teams or external consultants. The cost and complexity are immense, making a strong case for outsourcing or relying on insurance for such extreme scenarios.

An AppSec example was provided to illustrate the pyramid in practice. Matenaar categorized various AppSec programs by their intended maturity level:

• Vulnerability Management (Level 2): Ensuring discovered vulnerabilities are tracked and remediated.
• Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) (Level 2/3): Automated tools for finding vulnerabilities in code and running applications.
• Threat Modeling (Level 3): Proactively identifying design flaws.
• Bug Bounty Programs (Level 3): External validation of security posture.
• Security Resilience Engineering (Level 4): Building systems that withstand attacks.

The key takeaway was that investing in a sophisticated bug bounty program (Level 3) is less effective if the organization lacks robust vulnerability management (Level 2) to actually remediate the findings. Foundational programs must be effective for higher-level programs to yield value.

Demo / Proof of Concept

▶ Watch: The 'build if and only if you can buy' principle for security tools. (13:00)

Felix Matenaar's presentation was a strategic and conceptual discussion on security program management and funding, rather than a demonstration of a specific tool, exploit, or technical proof of concept. The talk focused on frameworks, models, and organizational strategies for effective security on a budget. Therefore, no live demo or technical proof of concept was presented during this session.

Defensive Implications

▶ Watch: Proposing a 2% security to engineering ratio for automatic scaling of securit... (18:00)

The insights provided by Felix Matenaar offer several critical defensive implications for security practitioners and leaders aiming to build resilient programs within budget constraints.

Firstly, the Pyramid of Security Needs serves as a powerful prioritization framework. Defenders should use this model to honestly assess their organization's current security maturity. The primary defensive implication is to solidify foundational security hygiene (Level 2) before investing heavily in advanced programs. This means ensuring consistent and comprehensive coverage for basics like patch management, multi-factor authentication (MFA), and security awareness training. Neglecting these fundamentals leaves organizations vulnerable to "stupid" hacks, which Matenaar argues are the root cause of most breaches. A robust Level 2 posture acts as the most cost-effective defense against common attack vectors.

Secondly, defenders must cultivate a realistic assessment of their security needs and capabilities. Not every organization requires a Level 5 "test novel attacks" capability. Instead of chasing the latest shiny security trend, security leaders should determine what level of maturity is truly necessary to protect their specific assets against their most likely threat actors. This involves making explicit decisions about what risks to mitigate internally, what to accept, and what might be covered by cyber insurance, especially for higher-level risks (Levels 4 and 5).

Thirdly, Matenaar's funding strategies provide actionable steps for proactive budget management and resource acquisition:

• Shift Security Responsibility: Defenders should clearly define the security team's charter and responsibilities. By making system owners implicitly responsible for their systems' security, the security team can strategically offer explicit support for specific areas (e.g., vulnerability remediation, patching third-party software, incident response). This creates a leverage point to negotiate for dedicated funding or resource transfers from the benefiting business units, rather than absorbing the work silently.
• Prioritize "Buy" Over "Build": Security teams should resist the urge to build custom solutions when commercial or open-source alternatives exist. This means rigorous vendor evaluation and integration should become a standard path for career progression for senior security engineers. From a defensive standpoint, leveraging external vendors often provides access to specialized expertise, faster feature development, and reduced maintenance overhead, allowing internal teams to focus on unique, high-value problems. Finance departments should be encouraged to make headcount and vendor budget fungible to facilitate this.
• Shift Left, Shift Funding: When security initiatives, such as static analysis or dynamic analysis, mature to the point where they significantly improve developer velocity or reduce costs for engineering teams, security leaders should explicitly ask for funding contributions from those benefiting departments. This ensures that the security team is appropriately resourced for the additional work involved in providing these "shift-left" services, preventing the security budget from being silently drained by efforts that primarily benefit other teams.
• Scale Security Automatically: To ensure consistent defensive coverage as the organization grows, security leaders should advocate for establishing key ratios for security staffing (e.g., 2% security to engineering headcount for larger organizations, or at least one engineer per program for smaller ones). This proactive approach prevents the reactive scenario of constantly fighting for net-new project funding, which often leads to under-resourcing of foundational security programs and an increased risk of preventable breaches.

Finally, the defensive implication extends to organizational incentives. Security managers should be promoted and compensated based on the impact and scope of their programs, not merely the size of their teams. This aligns incentives with organizational efficiency and encourages strategic decisions like leveraging vendors rather than always building in-house, ultimately leading to more effective and sustainable defensive postures.

Key Takeaways

• Prioritize Foundational Security: Security maturity follows a hierarchical model (Pyramid of Security Needs); foundational levels like compliance and basic hygiene must be consistently achieved and maintained before investing in advanced programs.
• Prevent "Stupid" Hacks: Most breaches stem from a lack of consistent coverage in basic security hygiene (e.g., unpatched systems, missing MFA, untrained employees); focus resources here for maximum defensive impact.
• Realistic Assessment and Funding: Organizations must realistically assess their true security needs and funding capabilities, avoiding investment in advanced programs (e.g., resilience, novel attack testing) if basic hygiene is weak, and considering cyber insurance for very high-level risks.
• Strategic Responsibility and Funding Negotiation: Shift the implicit responsibility for security to system owners. When the security team explicitly takes on new responsibilities (e.g., vulnerability fixing, patching), use this as a strategic opportunity to negotiate for additional funding or resource transfer from benefiting teams.
• Embrace "Buy" Over "Build": Prioritize buying commercial or open-source security solutions over building custom ones. Make headcount and vendor budgets fungible, and incentivize managers based on impact and scope to encourage efficient resource allocation.
• Share Costs for Shared Benefits: When security initiatives (e.g., shift-left static analysis) provide significant velocity or cost-saving benefits to other departments, advocate for shared funding contributions from those benefiting teams.
• Automate Security Scaling: Establish clear, data-driven ratios for security staffing (e.g., 2% security to engineering headcount) to ensure consistent coverage and prevent under-resourcing of foundational programs as the organization grows.

About the Speaker(s)

Felix Matenaar is the Head of Product Security at Asana. His professional experience centers on building and leading security initiatives within product-focused organizations. Matenaar's insights shared during the conference reflect his expertise in navigating the complexities of security program management, particularly in environments with tight budget constraints. He explicitly stated that the views and opinions expressed in his presentation are his own and do not necessarily reflect the official policy or position of his current, former, or future employers.