Whether you're a CISO planning your team's evolution or a security leader evaluating AI adoption, this guide provides a framework for successfully integrating AI agents while maintaining essential human expertise and control.

First thing first.. What is an Agent?

The distinction between simple LLM-based tools and true AI agents has crucial implications for cybersecurity teams. While chatbots (LLM) might help with documentation or basic queries, AI agents can actively participate in security operations - from threat hunting to incident response. This capability to act autonomously while accessing multiple data sources and tools makes them potential "virtual team members" rather than just automated tools.

The main difference of AI Agents with just LLM models bots, is that they have access to Data sources (RAG, DB), External tools (API,Code, etc), Language Models and Machine learning in order to perform their tasks, and produce the results needed.

Understanding how to integrate these AI agents effectively requires a structured approach to team organization. The Team Topologies methodology provides an excellent framework for mapping where and how AI agents can deliver the most value in your security organization. Let's explore how AI agents can enhance each team type's capabilities while maintaining clear boundaries and responsibilities.

Introducing AI Agents into Cybersecurity teams:

In the previous article discussed how we can leverage Team Topologies methodology for organizing Cybersecurity teams in Startups and Scale ups. The emergence of Agentic AI is going to transform how we structure and operate cybersecurity teams. Here's my view on how Agentic AI could fit into different team types described in the article based on Team topologies methodology:

Stream-Aligned Teams:

Focused on a single, valuable stream of work, such as a product or service. They are cross-functional and empowered to build and deliver end-to-end functionality. In these teams the Agents could be part of the team as a virtual team member or we can have fully automated teams:

• AI agents acting as "virtual team members"

  • For continuous security monitoring and initial incident triage, for example having a Tier 1 SOC team made up completely of Agents.

  • Automated threat hunting and anomaly detection with human oversight.

  • AI-powered security testing and vulnerability assessment integrated into CI/CD pipelines.

  • AI agent monitoring an application’s deployment in real-time, automatically detecting anomalies such as unusual API behaviour, and alerting the team while containing the issues.

• AI powered autonomous Offensive team, finding vulnerabilities, exploiting them and recommending fixes (that can be hand over to Security Engineer agent that will apply the fix)

Enabling Teams

Provide expertise and support to Stream-aligned teams, helping them overcome obstacles and build up their capabilities. Security experts who help bridge knowledge gaps, and provide guidance:

• AI assistants that help scale security knowledge sharing and training, contextualized to team domain and way of working.

• Automated security documentation generation and maintenance

• AI-driven security architecture recommendations based on historical data and best practices

• AI secure coding copilots that follows company standards and principles.

• AI Security Fixing Agents (Code or patching)

AI-driven interactive knowledge bases (Agents) could enable developers to implement secure code without relying heavily on security engineers, finally democratizing security amongst developers. This is where many people is currently investing at the moment. We can have AI Security champions customized for every engineer or team.

Platform Teams

These teams build and maintain a set of security tools and services that other teams can leverage. This might include identity and access management solutions, logging and monitoring infrastructure, and vulnerability scanning tools.

AI could dynamically adjust firewall rules, access permissions or cloud configuration in response to detected threats, ensuring a self-healing infrastructure. AI-enhanced security platforms that learn and adapt to organization-specific threats and behaviours.

Complicated Subsystem Teams

Specialized teams that deal with technically complex domains that require deep expertise.

• AI agents specializing in complex security domains (cryptography, zero-trust architecture)

• Automated research and analysis of emerging threats

I believe the main two types of teams that will see the influence of Agents are the Stream aligned and the Enabling teams first, many of the early AI Agents Cybersecurity solutions are currently focused on:

-Offensive security like XBow

-Security operations like Torq

-Application Security like Zeropath

-Code Copilots and autofixers like Github Copilot

New Interaction patterns with AI Agents

How would the Interactions patterns could look like in the future with the adoption of AI Agents? Here we focus in the interaction patterns with AI Agents, instead of between teams, but we should consider that there could be fully autonomous teams that will need an interaction pattern with human teams or other autonomous teams.

AI-Human Collaboration (Human in the loop)

AI agents and human professionals will need to function as a cohesive team, balancing autonomy and human expertise. This collaboration can take many forms, each requiring clear processes and protocols.

• Clear Handoff Protocols: AI agents excel at handling routine tasks but must know when and how to escalate to human experts. For example:

An AI agent monitoring a Security Operations Center (SOC) detects anomalous outbound traffic indicative of data exfiltration. It quarantines the source, logs detailed diagnostics, and alerts human analysts for a deeper forensic investigation.

• Defined Escalation Paths for Complex Security Decisions: Certain tasks—like deciding on a trade-off between shutting down a system to block an attack versus maintaining availability—require human judgment. AI can provide analysis and options but must defer to human decision-making.

• Collaborative Workflows: AI Agents suggest remediation steps for vulnerabilities, and human teams validate and refine the suggestions before implementation. These workflows foster trust while maintaining human oversight.

• Dynamic Role Reassignment: AI Agents could step in to handle surge tasks during incidents, such as analyzing thousands of phishing emails simultaneously or log entries, freeing human teams to focus on critical decision-making.

AI Supervision Models

Integrating AI into security workflows requires robust supervision to ensure that AI systems operate as intended and align with organizational goals and ethical standards.

• Human Oversight of AI-Driven Security Operations: When an AI system recommends blocking a user account for suspicious behavior, a human supervisor reviews the AI’s reasoning to ensure it’s not based on flawed logic or biased data.

• Quality Control Frameworks for AI-Generated Security Controls: Organizations must validate the efficacy of AI-generated policies.

Before implementing an AI-generated WAF rule, a platform team could simulate the rule in a sandbox environment to confirm its impact on legitimate traffic.

• Regular Assessment of AI Performance and Decision-Making: AI systems need periodic audits to evaluate performance, accuracy, and adherence to regulatory requirements.

A quarterly review of AI incident triage outcomes can highlight areas where the AI needs retraining or where false positives are too frequent.

AI-to-AI Collaboration (Agent Networks)

As AI Agents become more prevalent, they will need to interact not just with humans but also with other AI systems.

• Autonomous Agent Communication: AI Agents could coordinate responses to incidents, sharing insights and dividing tasks. Example: One AI Agent might focus on isolating affected systems during an attack, while another investigates the source of the breach.

• Agent-Orchestrated Workflows: Multiple AI Agents working together can streamline complex tasks. Example: During an incident, an AI network could handle threat detection, forensic analysis, and containment actions simultaneously, reporting progress to human supervisors in real-time.

AI-Driven Training and Mentorship

AI agents can act as a mentor or trainer, helping human teams scale their expertise.

• Interactive Security Training:

AI provides dynamic, scenario-based training modules tailored to individual skill levels. Example: A junior analyst might engage with an AI-powered simulation that mimics a live cyberattack, honing their skills in a controlled environment.

• On-the-Job Guidance: AI Agents provide real-time recommendations during active incidents. Example: During a ransomware attack, the AI suggests containment strategies and guides the team step-by-step through remediation processes. Or a Coding Copilot that will advise while coding on recommendations based on the context of the codebase.

AI as Mediators

AI Agents can serve as intermediaries, bridging communication gaps between human teams or systems.

• Centralized Decision-Making: AI consolidates data from disparate tools and teams to provide a unified perspective.Example: An A I Agent compiles insights from threat intelligence platforms, endpoint detection systems, and SOC logs to present a prioritized action plan for the incident response team.

• Contextual Insights for Human Decisions: AI delivers tailored insights based on the role and expertise of the human team member Example: Forensic analysts receive deep-dive technical data, while executives get high-level summaries with recommended actions.

Considerations for AI Integration in your team, Are you ready?

In this exciting journey we are experiencing, companies will have to consider multiple challenges to ensure that they are prepared and adapt to these changes. Here are a summary of the main considerations when adopting AI Agents:

Skills Evolution: The introduction of AI agents needs a shift in skill sets and roles within cybersecurity teams.

• Security teams will need to develop AI literacy, team members should receive training on how to interpret AI outputs, customize AI models, and intervene when necessary.

• Focus on higher-level decision making and AI supervision.

• New roles emerging for AI-security specialists.

I have noticed recently that many teams are not even experiencing with AI solutions, and are thinking on traditional approaches for next year plans, still many people is sceptics of AI capabilities and dismisses these solutions in favour of traditional approaches.

When it comes to AI literacy, I recommend Deeplearning.ai courses, particularly the short courses https://www.deeplearning.ai/courses/ where you can learn many of the concepts, and frameworks in a short period of time.

Organizational Impact: AI integration can fundamentally alter how organizations structure and operate their cybersecurity functions.

• Potential for improved security engineer to developer ratios through AI augmentation. A SOC with 10 engineers managing 1,000 incidents monthly could handle the same workload with 5 engineers supported by AI triage systems.

• New team interaction patterns with AI mediating communications: An AI-driven SOC might automatically prioritize incidents and allocate them to specialized teams, reducing bottlenecks in triage and response workflows.

• New security governance models incorporating AI oversight

As cybersecurity teams embrace AI agents, the focus must remain on collaboration, transparency, and ethical implementation. The journey toward an AI-augmented Cybersecurity team future is both exciting and charged with challenges—are you ready to adapt?

🎯 Reality of Security Team Ratios - With security-to-developer ratios of 1:50 to 1:120, traditional scaling isn't sustainable - Success requires shifting from "doing security" to "enabling security at scale" - Platform teams and enabling patterns can help security teams achieve 3-5x impact

Team Topologies provides a framework to balance security needs with business growth.

Introduction

A few years back, as result of a reorganisation in a company I worked for, I came across with a book that proposed different ways to organise teams and collaboration for engineering organisations, based on the needs of the business to enable fast flow of value. The book is called "Team topologies", introduced by Matthew Skelton and Manuel Pais. I had seen this methodology used in many companies to reshape their whole organisation for better productivity and efficiency.

"Team Topologies is the leading approach to organizing business and technology teams for fast flow of value, providing a practical, step-by‑step, adaptive model for organizational design and team interaction."

Based on Conway's Law, which says that software architectures inevitably reflect the organisational communication patterns of the companies that create them. The way teams communicate and collaborate directly shapes the systems they build. Team Topologies builds on this principle by deliberately designing team interactions to produce desired architectural outcomes.

In the dynamic world of startups and scale-ups, where agility and adaptability are crucial for survival and growth, security organisations must evolve alongside the companies they protect. The Team Topologies model offers a promising solution to address these challenging ratios, providing a team-oriented framework that helps security groups deliver value efficiently despite limited resources.

The challenge of organising security teams becomes particularly important in large engineering organisations, where hundreds of developers may be supported by only a handful of security engineers. Industry surveys and my experience indicate that the ratio of security developers to engineers typically ranges from 1:50 to 1:120 (depending industry), creating significant odds against security teams' effectiveness.

The Four Fundamental Team Types in team topologies:

When it comes to teams, Team topologies advocate for the following four types:

Stream-Aligned Teams: Focused on a single, valuable stream of work, such as a product or service. They are cross-functional and empowered to build and deliver end-to-end functionality.

In cybersecurity, these teams focus on specific security domains or products:

• Examples include Application security teams, Infrastructure security teams, or Security Operations teams.

They operate with high autonomy and are responsible for end-to-end security in their domain

Platform Teams: These teams build and maintain a set of security tools and services that other teams can leverage. This might include identity and access management solutions, logging and monitoring infrastructure, and vulnerability scanning tools.

• Create self-service capabilities for other teams

• Example: Security tooling team that maintains SIEM, vulnerability scanners, and security automation platforms

Enabling Teams: Provide expertise and support to Stream-aligned teams, helping them overcome obstacles and build up their capabilities. Security experts who help bridge knowledge gaps, and provide guidance:

• Reduce dependencies on security experts by teaching rather than doing the work. Think of Security Champions concept for example.

  Example: Security architecture team that assists other teams in implementing secure designs

Complicated Subsystem Teams: Specialised teams that deal with technically complex domains that require deep expertise.

• Focus on specific security domains that need deep technical knowledge

  Example: Cryptography team or security research team

In my experience the most common team patterns in cybersecurity are the Stream aligned teams and Enabling teams, at least when talking about Startups and Scale ups.

Team Interaction Patterns

The book introduces another important concept, which is the way these team interact with other teams in the organisation. We have the following options:

1. Collaboration: Deliberate working together between teams with a defined mission and timeline, requiring high bandwidth communication.

• Security platform teams working closely with stream-aligned teams

• Regular knowledge sharing sessions between enabling teams and other security teams

• Cross-team security incident response exercises

2. X-as-a-Service: One team provides something for other teams to consume asynchronously with minimal collaboration, typically through self-service platforms or APIs.

• Security platform team providing self-service security tools

• Automated security scanning in the SDLC (Static Analysis, Dependency scanning, Secret scanning, etc.)

• Security policy as code frameworks

3. Facilitating: One team helps another team learn or develop a new capability through teaching and mentoring, with the goal of making the receiving team self-sufficient.

• Enabling teams conducting security training

• Security architecture reviews and consultations

• Threat modeling processes and workshops

Team Topologies for Security teams in Startups

As cybersecurity needs expand across organisations - whether they're innovative startups disrupting markets or scale-ups experiencing rapid growth - security teams face a transformation challenge. The evolution from a single security generalist or small team handling all security concerns to a multi-tiered security organisation requires careful planning. This transition point typically emerges when the traditional "security does everything" approach starts showing signs of strain, often manifesting in delayed responses to security incidents, mounting security technical debt, and overwhelmed security professionals trying to juggle too many responsibilities. The introduction of specialised security platforms and dedicated platform teams becomes not just beneficial but essential for sustainable scaling. However, this transformation requires thoughtful decisions and clear organisational principles to ensure that security operations maintain their effectiveness while becoming more scalable.

So what are the options we have when we look at the different phases of growth of a startup? Let's see some examples:

Early-Stage Startup (1-100 employees)

At this stage, security is often handled by a small (one person usually, depending the core business), versatile team that combines multiple roles:

• One stream-aligned team handling both application and infrastructure security

• Security lead acting as an enabling team to support developers

• Leverage managed security services to fill gaps

Growth Stage (100-300 employees)

As the organisation grows, the security structure evolves:

• Dedicated small stream-aligned teams for application security and infrastructure security, usually same small team covering both domains.

• Small platform team creating security tooling and automation

• Part-time enabling team providing security guidance across the organisation

Scale-up Stage (300-3000 employees)

The security organisation becomes more sophisticated:

• Multiple stream-aligned teams focused on different security domains

• Dedicated platform team for security infrastructure

• Full-time enabling team for security architecture and consultation

At this stage we have a full security organisation

Common Pitfalls in Security Team Evolution

Based on my experience helping organisations transform their security teams, here are critical pitfalls to avoid and strategic approaches to consider:

Early-Stage Pitfalls (1-100 employees)

1. The "Security as Afterthought" Trap

What Usually Happens:

• Security person hired too late

• No security considerations in early architecture decisions

• Accumulation of security debt (Link to my other article)

Strategic Approach:

• Engage security expertise even as a part-time consultant early

• Build security into architectural decisions from day one

• Create lightweight but scalable security processes

2. The "One-Person Army" Syndrome

What Usually Happens:

• Single security person trying to do everything

• No documentation or knowledge transfer

• Burnout and potential single point of failure

Strategic Approach:

• Focus on high-impact, automated solutions

• Build security champions program early

• Create documented processes and playbooks

Growth Stage Pitfalls (100-300 employees)

1. The "Tool Proliferation" Problem

What Usually Happens:

• Too many security tools purchased without integration strategy

• Teams overwhelmed with alerts and notifications

• Limited return on security investments

Strategic Solution:

• Develop a tool integration strategy

• Focus on platform team development

• Implement automated correlation and prioritisation

2. The "Scaling Wall" Challenge

What Usually Happens:

• Security becomes a bottleneck

• Increasing friction with development teams

• Rising number of security incidents

Strategic Solution:

• Implement security-as-code practices

• Develop self-service security capabilities

• Create clear escalation paths and SLAs

Scale-up Stage Pitfalls (300-3000 employees)

1. The "Communication Breakdown"

What Usually Happens:

• Siloed security teams, little communication and alignment across different security teams.

• Inconsistent security practices across teams

• Duplicate efforts and inefficiencies

Strategic Solution:

• Implement clear interaction patterns

• Regular cross-team security forums

2. The "Legacy Drag" Effect

What Usually Happens:

• Old security practices don't scale

• Technical debt in security infrastructure

• Resistance to change from established teams

Strategic Solution:

• Regular security architecture reviews

• Planned technical debt reduction

• Change management strategy for security evolution

Do these sounds familiar to you?

Recommendations when implementing Team Topologies

If you are looking to implement team topologies or improve your security organisation, I recommend focusing on:

1. Quick Wins First

   • Identify immediate pain points

   • Implement high-impact, low-effort solutions

   • Build credibility for larger changes (Iterative approach)

2. Sustainable Growth

   • Design for scale from the start

   • Build automated and self-service capabilities

   • Focus on knowledge transfer and documentation

3. Cultural Transformation

   • Create feedback mechanisms

   • Celebrate security wins and learnings

These are simple but powerful tips when considered in any process to improve the security team organisation.

Final thoughts

Remember that team structures should remain flexible and adapt to changing security needs and organisational growth. Regular review and adjustment of team topologies ensure continued effectiveness of your security organisation, remember that what brought you here wont take you to the next level your business will need.

Team Topologies provides a flexible and scalable framework for organising cybersecurity teams in startups and scale-ups. By understanding and implementing these patterns appropriately, organisations can build security teams that effectively protect their assets while supporting rapid growth and innovation.

The key to success lies in starting with a minimal viable structure and evolving it gradually based on organisational needs. Regular assessment and adjustment of team structures ensure that security capabilities grow in alignment with business requirements.

Stay tuned for the follow up on how teams could evolve when adding AI agents into the mix.

If you want to discuss this topic or have ideas on how to organise better security teams, please contact me via Linkedin or drop some comments in this article.

What is Security Tech Debt?

Security tech debt refers to the accumulation of security vulnerabilities, weaknesses, and non-compliance within a software system. This type of debt arises when immediate pressures to deliver functionality lead to shortcuts or compromises in security. Like financial debt, security tech debt incurs "interest" in the form of increased risk, potential breaches, compliance failures and higher future remediation costs.

So how is security Tech Debt Generated?

There are points in the company journey when engineers ask themselves, how did we get to this point? And this is not single reason problem, but has many components:

1. Rapid Development Cycles: Pressure to meet deadlines often leads to security being an afterthought. Quick fixes and bypassing thorough security reviews contribute to vulnerabilities. This affects more Startups and Scale-ups where finding product market fit and fast growth is key.

2. Lack of Security Expertise: Inadequate training and a lack of dedicated security staff can result in the implementation of insecure coding practices and overlooked security considerations. Also the inconsistency in security practices across different teams or projects can lead to inconsistent application of security controls and processes if any.

3. Lack of security awareness and culture: Many development teams may not have a strong understanding of security principles. This lack of awareness can lead to poor coding practices, insufficient threat modeling, and neglect of security best practices, ultimately contributing to the accumulation of tech debt.

4. Legacy Systems: Outdated technologies and legacy code that were developed without modern security standards in mind contribute significantly to security tech debt. Legacy systems tend to be overlooked and maintaince of such systems is not prioritized. Operating system and libraries tend to be End of Life and not support provided by vendors aka "no security patches".

5. Neglecting Regular Updates: Delaying updates and patches for third-party libraries and dependencies introduces vulnerabilities that could have been avoided. Sometimes the lack of proper testing processes, and the worry of incompatibility of newer versions with your system makes team to push these changes to a future that never arrive.

6. Resource constraints: Limited budgets and personnel can hinder an organization's ability to invest in security. When resources are stretched thin, security initiatives may be deprioritized, resulting in tech debt as teams are unable to address known vulnerabilities or implement necessary security controls.

It mostly boils down to prioritising releasing product features, and  focusing on other areas like availability and performance over Security, due to the perception of customers on the product experience. Security is not perceived as a problem if customer dont see it, while availability and performance could mean the difference when building a new product, particularly in the early stages of growth of a company.

Tech Debt at Different Company Stages

Security tech debt impacts companies differently depending on their stage of growth. Understanding these differences is crucial for tailoring effective strategies to deal with security technical debt.

Startups:

1. Limited Resources: Startups often operate with limited resources and tight deadlines. This environment can lead to significant security tech debt as the focus is primarily on rapid development and market entry.

2. Ad Hoc Security: Security practices may be inconsistent or ad hoc, increasing the risk of vulnerabilities.

Scale-Ups:

1. Rapid Expansion: As companies grow, the complexity of their systems increases. The initial tech debt can quickly become unmanageable if not addressed.

2. Increased Exposure: With growth, the potential impact of security breaches also increases, as the company handles more data and transactions.

Enterprises:

1. Complex Systems: Large enterprises often have numerous legacy systems, each contributing to a substantial security tech debt.

2. Regulatory Requirements: Enterprises are subject to stringent regulatory and compliance requirements, making security tech debt even more critical.

Also it is the case that if a company incurs in Security tech debt, this will grow together with the company through all the phases, reaching to the point that when the company is big and complex fixing the security tech debt will become big and complex as well. (Captain obvious)

So how can we deal with Security tech debt?

There are many things that we can do to reduce the Security tech debt, but we can group them in these four categories:

1. Prioritize Security in Development:

   • Shift Left/Secure by design: Integrate security practices early in the development process. Conduct regular security training for developers, introduce tooling in the developers processes, and provide visibility to the security posture of the code, libraries, images used in their projects.

   • Security Requirements: Clearly define security requirements and ensure they are part of the acceptance criteria for every project.

   • Threat Modeling/Design reviews: Conduct thorough threat modeling exercises to identify and prioritize security issues based on potential impact and likelihood.

2. Adopt a Risk-Based Approach:

   • Risk Assessment: Continuously assess and prioritize security tech debt based on the severity and exploitability of vulnerabilities.  Evaluate security vulnerabilities based on their potential impact and exploitability. Focus on high-risk issues first. Context here is king, the more context you have the better.

     

3. Refactor and Update Legacy Systems:

   • Modernization Plans: Develop plans to refactor or replace legacy systems incrementally to adhere to current security standards.

   • Patch Management: Implement a robust patch management process to keep all systems and dependencies up to date.

   • Slipstreaming:  Usually generic tech debt activity mitigation will involve keeping libraries and OS updated to the latest version, which on its own will reduce the number of vulnerabilities to the bare minimum. If there are initiatives for patching, upgrading system and libraries, ensure Security team contribute, participate and leverage those projects as it will contribute positively to reduce the security tech debt. For example if there is a Quality process or initiatives, this is a great opportunity to embed security there and join forces.

   • Golden Images and version drifting: In cloud native environments where is easier to manage the fleet with IaC and CI/CD pipelines the goal should be to have the latest Golden Image available, and monitor drifting against it. There are Secure containers and image providers like Seal.security and Chainguard.dev to ensure that you have a vulnerability free base golden images.

4. Foster a Security Culture:

   • Awareness Programs: Conduct regular security awareness programs to keep security top of mind for all team members.

   • Security Champions programs: Appoint security champions within development teams to advocate for security best practices and act as liaisons with security experts.

   • VIsibility on the security posture: You cant fix what you dont know. Surfacing the security posture of the systems, assets and components

   • Transparency across the organization: Communicate the importance of prioritizing security to all stakeholders, including leadership and engineering teams. Provide regular updates on the status of security tech debt and the efforts to address it, highlighting successes and areas needing attention.

   • KPIs and Metrics: Establish key performance indicators and metrics specifically for security tech debt reduction.

   • Incentives/Gamification: Create incentives for teams to prioritize and effectively manage security tech debt, recognizing and rewarding their efforts. Work with positive reinforcement instead of focusing on the negatives, in security we have a long track record of focusing on the negative, the bad and the ugly, we know that it doesnt work as we think, and it is time to move to positive reinforcement, celebrating the wins and achievements.

Allocating Time to Address Tech Debt

Managing security tech debt requires a deliberate allocation of time and resources. Without this dedicated effort, security issues can quickly accumulate, becoming more difficult and costly to address in the future, so the longer we wait the more difficult it will be for us. Here’s a couple of ways I am familiar with, to incorporate time allocation into your workflow:

1. Scheduled Tech Debt Sprints:

   • Dedicated Time: Allocate regular intervals (e.g., one sprint per quarter) specifically for addressing tech debt, with a significant focus on security issues.

   • Team Involvement: Ensure all team members understand the importance of these sprints and actively participate in identifying and resolving security tech debt.

2. Continuous Improvement Cycles:

   • Integrate into Agile Practices: Make tech debt remediation a part of the ongoing development process by including it in your backlog and sprint planning. Many companies allocated around 20-30% for dealing with general tech debt which includes security work. This is in theory, if you ask engineers usually it´s difficult to prioritize and use this time, as product features and other priorities tend to require all the sprint time, this will be highly related with the maturity of the Engineering and product organization.

   • Review and Reflect: Regularly review progress on tech debt reduction and adjust strategies as needed to ensure continuous improvement.

3. Bug Bash Sessions:

   • Focused Collaboration: Organize regular “security bug bash” sessions where cross-functional teams gather to find and address security-related bugs and vulnerabilities. These sessions can create a sense of urgency and excitement around tackling security tech debt, as well as surface issues that might be overlooked during regular sprints.

   • Reward & Recognition: Recognize and reward the team for contributions during these sessions. Positive reinforcement encourages team members to actively participate and prioritize security.

No matter your company’s stage, addressing security tech debt early is critical to sustaining long-term growth and resilience. Here are some tips for the different phases of company growth:

• Startups: Start integrating security into your development process today. Even with limited resources, a proactive approach will help avoid costly, unmanageable security debt in the future.

• Scale-Ups: As you scale, so does your exposure to security risks. Take immediate steps to assess and prioritize your security tech debt, ensuring you don’t carry vulnerabilities into your next growth phase.

• Enterprises: With complex systems and strict regulatory requirements, incremental improvements in your security infrastructure are essential. Focus on refactoring and patch management to modernize legacy systems and maintain compliance.

Remember,  like financial debt, security tech debt incurs "interest" in the form of increased risk, potential security breaches, compliance failures and higher future remediation costs. Security debt grows alongside your company, but by dedicating time and resources now, you can keep it manageable. Whether you’re a startup, scale-up, or enterprise, make security a key part of your strategy—schedule tech debt sprints, dedicated % time for tech debt, foster a security culture, and celebrate every win. Your future self and company will thank you!

Long time ago I discovered the 80/20 rule when I got my hands on this book by Richard Koch:

I remember being  pretty shocked at the concept, but the more I delved into it, the more it became a key tool in my decision-making and analysis.

What I am surprised is that not everyone is familiar with it, and I was assuming that everyone knows and apply it, but it is normal to assume that something you know is easy and everybody knows it.

So what is it about?  the 80/20 rule says that roughly 80% of the results are obtained with 20% percent of the effort.  Think about that for a moment, most of what you accomplish comes from just a small fraction of what you do.

This rule is also called the Pareto Principle, named after Vilfredo Pareto (1848–1923) an Italian engineer, sociologist, economist, and philosopher. Originally, Pareto observed this phenomenon in wealth distribution, noting that 20% of Italy’s population owned 80% of its wealth.

I have seen it and applied in many aspect of my life, more heavily at work, and particularly in Cybersecurity.

The first example I have noticed, was when doing vulnerability assessments usually 80% of vulnerabilities where found in 20% of the assets. In Internal security assessment I remember that is was consistent, usually due to legacy system concentrating the majority of the vulnerabilities, or the assets belonging to particular teams that for different reasons they were struggling with patching or decommissioning services. I remember that at one point we started to add this observations in the audit/vulnerability assessment reports, to show how focusing in a few assets would reduce the amount of vulnerabilities. Usually the discussion on the customer side went  “Do we need these systems? can we decommission them?” (I understand that this approach could be focusing just in volumen and not presicely on risk, today we have much more context to make better prioritization desicions with Vulnerability indicators like KEV, asset exposure, attack path and the likes).

If we look into security controls, we can find that 80% of the incidents could be prevented by implementing 20% of available security controls, you should  implement the most effective controls first, for example multi-factor authentication, regular patching, and employee security awareness training could prevent the majority of potential security incidents.

Another example could be that 80% of policy violations may involve 20% of security policies, focus on enforcing and improving the most frequently violated policies.

When it comes to Threat intelligence 80% of relevant threat intelligence may come from 20% of sources. Focus on the most reliable and applicable threat intelligence feeds. You should understand which sources where most useful over the time, and which sources provided the most actionable intelligence.

The 80/20 principle is especially relevant in project management. When starting new projects, it’s important to recognize that 80% of the results will come from just 20% of the effort. However, completing the remaining 20% of the work will still require significant effort. By adopting agile practices and an iterative approach, you can deliver value early on with that initial 20% of effort, ensuring progress and impact from the start.

When looking at compliance we may see that 80% of compliance requirements might be satisfied by 20% of your security controls, thus Implementing multi-purpose controls that address multiple compliance needs will provide time and resources savings.

When it comes to Data protection, 80% of sensitive data may reside in 20% of your databases or systems, focus encryption and access control efforts on these critical data stores first.

So how can you start applying this principle in your way of working?

Step 1: Identify Your 20%

Begin by assessing your daily activities. Reflect on the following:

• Which tasks or actions yield the most significant results?

• Which clients, projects, or relationships offer the highest return on your time and energy?

In a cybersecurity context, this could involve identifying the systems, controls, or protocols that contribute most to your security posture.

Step 2: Focus on the most impactful Tasks

After pinpointing your 20%, shift your attention. Dedicate more time to these high-impact activities and less to those that don’t significantly advance your goals. This might involve delegating tasks, saying “no” more often, or reorganizing your priorities to concentrate on work that adds the most value—whether it’s in managing key clients, projects or securing critical assets.

Step 3: Cut the Low-Value 80%

This step can be challenging: reduce or eliminate time spent on low-value tasks. These are the activities that consume time but contribute little to your objectives. It could be excessive meetings, unnecessary emails, or even habits that drain your energy. By minimizing these, you’ll free up valuable time to invest in your 20%, such as focusing on essential security measures or client relationships.

Step 4: Continously reevaluate

The 80/20 Rule isn’t a one-time task. It requires regular reevaluation. Every few months, take a moment to reassess your 20%. As your goals and priorities evolve, so will the activities that deliver the highest returns. This consistent evaluation ensures that you stay focused on what matters most, whether in life or in maintaining a strong cybersecurity stance.

I hope this principle will help you improve your decision making and prioritization skills making your cybersecurity teams more efficient.

Take a moment to assess your cybersecurity strategy today. Identify the key areas where the 80/20 principle can make the most impact, and start focusing your efforts where they count the most.

Particularly in cybersecurity teams, the process usually starts with a simple Python script running on a server via crontab. For the first few days, everything works smoothly—until it doesn’t. The script stops delivering results, and the team discovers the server crashed after a certain number of runs. To mitigate this, they add a second script to monitor the first one and set up email or Slack alerts for failures. Vulnerabilities in the OS and libraries start to pop, now upgrading, patching and maintaincnace in general gets added on top.

Then, one weekend, it fails again, but this time it impacts a larger process, requiring on-call support. Now, that simple script has grown into a full-fledged operation—complete with monitoring, runbooks, on-call shifts, and ongoing maintenance. And we are not considering if the engineer that built it and maintained it leaves the company, and someone else that doesn’t have the right experience needs to pick it up. In hindsight, the cost of building and maintaining this custom solution often ends up being comparable to (or even exceeding) the price of a vendor solution.

The Strategic Dilemma: Build vs. Buy

The decision to build in-house or buy from a vendor is one of the most fundamental in operations strategy. (Actually I learnt about this in Operations Strategy course in the while doing the MBA). Yet, too often, it’s made based on short-term cost savings—especially when companies are trying to stay competitive or cut their cost base (very relevant now in 2024).

Efficiency should be the guiding principle behind any build vs. buy decision, but this strategic choice affects operational performance in complex ways. It can also stifle or enable innovation, which is increasingly critical for companies aiming to stay relevant in fast-changing industries.

When you build in-house, you have full control, allowing you to experiment, iterate, and potentially innovate faster. However, the question becomes whether this innovation is core to your business or a distraction from your primary goals. And you dont want wasting resources where you don´t need them. In some cases, relying on external vendors can foster innovation by freeing up your team to focus on what truly matters—allowing them to explore new ideas rather than getting bogged down in maintaining internal systems.

When Does buying Make Sense?

The first thing to consider is whether the task or component has long-term strategic importance to the company or your team in particular. If it does, buying likely isn’t the best option. Similarly, if your team possesses specialized skills or knowledge in this area, it usually makes more sense to keep the work in-house.

However, innovation must also be factored into this equation. If the task or solution you’re considering building plays a central role in fostering innovation within your team—driving new business models, improving customer experiences, or developing a competitive advantage—then it’s worth keeping in-house.

On the flip side, if the task is routine or the solution became a commodity and doesn’t contribute directly to innovation or your competitive edge, buying can be a smart move. A good vendor may even introduce innovative features or processes that would be too resource-intensive for you to develop on your own. (Vendors partnerships is another topic)

Once these strategic factors have been evaluated, you can turn your attention to operational performance and cost. If your in-house performance is far superior to any supplier, buying may not be worth it. However, if your performance lags behind and you can’t realistically improve it in-house, buying becomes a more attractive option—especially if achieving the desired improvement internally would be too costly or complex.

Here is simple visualization of the considerations when making this decision:

Ultimately, the build vs. buy decision requires careful consideration on your company’s core capabilities and how they contribute to your competitive advantage. Innovation plays a crucial role in this evaluation. If developing a solution in-house would lead to breakthrough innovations or strengthen your position in the market, the additional costs and complexity may be worth it.

But once you’ve determined that the activity is neither strategically important nor critical to your competitive edge or innovation efforts, the focus should shift to finding the most effective solution. Remember, buying a solution isn’t just about saving money—it involves significant effort and resources. You’ll need to research vendors, run proofs of concept, negotiate contracts, and plan for a migration process that often includes running parallel systems until the new solution is fully functional, onboarding the new service, learning, etc. This is a major project in its own right, which is why many companies only go down this path when every other option has been ruled out—or when internal costs have become unsustainable.

Newton's Flaming Laser Sword (Alder's Razor) 

Is a philosophical principle introduced by cognitive scientist Mike Alder. It states: “What cannot be settled by experiment is not worth debating.”

This razor emphasizes the importance of focusing on practical, testable questions rather than wasting time on abstract or theoretical arguments that lack empirical evidence. You might be wondering why Alder's chose this name? He chose the term “Flaming Laser Sword” to make it sound more dramatic and memorable than other philosophical “razors” like Occam’s Razor. The “sword” represents its power to cut through pointless or unresolvable discussions. 

Here are some scenarios where we can apply it in Cybersecurity:

• Evidence-Based Security: Focus on strategies and tools with proven effectiveness, usually this will take you back to the basics. Avoid getting bogged down in theoretical debates without practical data.

• Vendor Claims of “100% Security” Some vendors may claim that their product offers “100% protection” from all threats. Instead of debating the impossibility of perfect security, apply Alder’s Razor: demand real-world testing. Conduct penetration testing, threat simulations, or review independent security audits to assess the actual performance of the solution under attack scenarios, rather than engaging in theoretical arguments about absolute security.  If you can obtain third party assessments and other customers testimonials that can help you support and speed up this process much better. 

• Risk prioritization:  Imagine a security team is debating whether to focus on a hypothetical risk from quantum computing breaking encryption algorithms versus addressing known vulnerabilities in their existing systems like weak passwords and the lack of MFA. According to Alder’s Razor (“What cannot be settled by experiment is not worth debating”), the focus should be on the proven risks that can be empirically tested and mitigated, such as patching vulnerabilities or implementing stronger password policies. Theoretical discussions about future risks like quantum computing encryption-breaking should be set aside until there is concrete, testable evidence that those risks are imminent. 

Why is this important?

Resources and Time: In cybersecurity, resources and time are finite and scarce. Focusing on risks that can be directly mitigated today, rather than on theoretical risks that cannot be tested or quantified, leads to more effective risk management.

Evidence-Based Action: By applying Alder’s Razor, the team avoids getting caught up in speculative debates and instead addresses real, measurable risks that are more likely to impact the organization now.

Sagan Standard  - “Extraordinary Claims Require Extraordinary Evidence”

The Sagan Standard, coined by astronomer Carl Sagan, is a principle that emphasizes the need for strong, compelling evidence when extraordinary claims are made. Essentially, the more unlikely or exceptional a claim is, the higher the burden of proof should be. This standard is a tool for critical thinking, helping to avoid accepting extraordinary assertions without the necessary validation.

One of the most famous and common application of the Sagan Standard is in UFO sightings or claims of alien life. While there are many claims about UFO encounters, extraordinary evidence (such as physical proof or high-quality documentation) is required to seriously entertain the idea that aliens have visited Earth. Simply seeing a light in the sky is not enough; such an extraordinary claim demands extraordinary, undeniable evidence. (the Alien presented in the Mexican Congress don’t think it counts)

Threat Intelligence: Threat claims of new, sophisticated attacks with skepticism until strong evidence is provided. Before going after the latest shiny actor, make sure that there is enough information from reputable sources about this threat/actor. 

Attributing an Attack to an actor

Attributing a cyberattack to a sophisticated actor, like a government-backed group, is an extraordinary claim. The Sagan Standard would require extraordinary evidence such as detailed forensic analysis, indicators of compromise (IoCs), and corroboration from multiple intelligence sources before such an attribution can be made.

Zero-Day Exploit Detection

A vendor claiming that their product can detect and block all zero-day exploits would need to provide extraordinary evidence, like independent testing data or successful real-world use cases against previously unknown threats. The more exceptional the claim, the more data is needed to validate it.

Vendor Claims of Unhackable Systems

When a vendor claims their system is “unhackable” or “100% secure,” the Sagan Standard suggests that this extraordinary claim requires extraordinary evidence. Instead of accepting the claim at face value, you should demand rigorous third-party testing, audits, and penetration testing reports that support this claim.

Why is this important?

• Impact of Attribution: Incorrectly attributing an attack to a nation-state can lead to misaligned resources and effrots, or even get you into legal and financial troubles. (depending on your organization)

• Skepticism: The Sagan Standard prevents security teams from jumping to conclusions based on extraordinary claims without adequate proof. It encourages evidence-based approach before accepting such attributions.

Hitchens’ Razor - “What Can Be Asserted Without Evidence Can Be Dismissed Without Evidence”

Hitchens’ Razor, attributed to author and journalist Christopher Hitchens, is a principle of skepticism that emphasizes the importance of evidence when making assertions. It states that if someone makes a claim without providing evidence, there is no obligation to accept or even entertain the claim until evidence is presented.

Vendor Claims: Require solid evidence before investing in new security technologies or services.  If a security vendor claims that their product is the “best on the market” but offers no data, case studies, or independent reviews to back it up, Hitchens’ Razor allows you to dismiss this claim until real evidence (such as performance benchmarks or client testimonials) is provided. You are under no obligation to consider or trust the claim without solid evidence.

Unverified Incident Attribution

An IT staff member might claim that a recent security breach was caused by a particular hacker group without providing forensic evidence, logs, or any indicators of compromise. According to Hitchens’ Razor, this claim can be dismissed until actual proof is presented. Without evidence, the claim holds no weight.

False Positive Security Alerts

Security tools often generate false positives. If an analyst claims that a particular alert represents a real threat without offering detailed analysis or correlating evidence, Hitchens’ Razor suggests that this assertion can be ignored until they provide concrete proof that the alert represents an actual security incident.

Why This is Important:

• Avoiding Unnecessary Investments: By applying Hitchens’ Razor, cybersecurity teams avoid investing in tools or technologies based on exaggerated claims that lack evidence, preventing wasted resources and potential security gaps.

• Promoting Evidence-Based Decision Making: It encourages a culture of evidence-based decision-making in cybersecurity, where solutions are evaluated on their merits, not on unverified promises.

Each of these principles contributes to cutting through unnecessary assumptions, exaggerated claims, or overcomplicated theories, helping us focus on the most likely and evidence-based explanations. I noticed through the years, that seasoned experienced Cybersecurity professionals tend to apply many of these razors in their thinking and when making decisions, while more juniors and unexperienced professionals tend to get bogged down in the complexity and the hype of claims from vendors and media. Hopefully, this article inspires you to adopt these principles early, empowering your teams to make smarter, faster decisions—while cutting through complexity and making security simpler.”

*Images created with Microsoft Designer

I’ve decided to adapt these on the context of Cybersecurity, as I found that this could be very beneficial for Security practitioners.

When it comes to Razors you might be familiar with Occam's Razor, this is a fundamental concept in science and critical thinking that emphasizes the importance of simplicity and parsimony when evaluating explanations or theories. It was named after the English philosopher William Ockham (1287-1347).

A great example of Occam Razors, can be found in medicine, with the principle “when you hear hoof beats, think horses, not zebras” which means that when diagnosing a patient, doctors consider the simplest and most common explanation for the symptoms. (Horses represents the common, simplest most likely conditions, and Zebras the less likely conditions). 

 So how can we be apply Occam´s Razor in Cybersecurity?  

1. The simplest explanation: When analyzing a security incident, consider whether the most straightforward explanation (e.g., a malicious actor exploited a known vulnerability) is more likely than a complex one (e.g., a sophisticated nation-state attack). Can we simplify this explanation further? Yes, how many times the root cause of an incident turn up to be a misconfiguration? It's pretty common to first assume that you are under attack, when in reality there was a problem in the latest update of the CI/CD system or a new change in a service that is generating more traffic than expected. When testing a security hypothesis, prefer simpler explanations over more complex ones. 

2. Prioritize simplicity in design: When designing security systems, protocols and processes, favor simplicity over complexity. This can help reduce the risk of errors, improve maintainability, testing and make it easier to understand and implement the system. The simpler the system the more reduced the attack surface will be, less opportunities for vulnerabilities, abuses and errors. Simpler system will have less components, interfaces and interactions, as demonstrated by threat modeling the interactions of these components are the ones where the threats manifest. Less components and interactions means less potential threats.  

“Simplicity is the ultimate sophistication.”​— Clare Boothe Luce

3. Avoid unnecessary assumptions: In threat analysis, don't assume that a particular actor or group is responsible for an incident without sufficient evidence. Instead, start with the simplest explanation (e.g., a single individual or a known adversary group) and add complexity as needed and evidence supports it.   Occam's Razor suggests starting with this simpler explanation and adding complexity only if there is sufficient evidence to support more complex theories. It's common that people start assuming that the actors that are in the latest news are the ones behind our incidents.

Another useful razor is the Hanlon's Razor, which is a relative modern aphorism, attributed to Robert J. Hanlon’s coined as part of his book “Murphys law Book two: More reasons why Things go wrong!” (1980).  

Hanlon’s principle states: “Never attribute to malice that which can be adequately explained by stupidity.” In this context, stupidity can be also understood as ignorance, not knowing, lack of awareness. And here are a couple of examples of its application: 

• Error/cause analysis: When investigating security incidents, consider human error before assuming malicious intent. Misconfigurations or mistakes often lead to vulnerabilities as discussed in the previous paragraphs. This part is the one that makes Hanlon’s close to Occam's, Human error will be the simplest explanation over more complex ones like "we are under attack". Many incidents end up being users who are not familiar or aware of certain company policy and perform a task using a program or website that is not allowed, but the security team identifies as an attack.

• User Behavior: Human actions should be interpreted as ignorance or error rather than deliberate malice.  Here is the importante of educating users on common security practices rather than assuming they are intentionally bypassing protocols. How many times have you heard a security team member complaining that users are bypassing controls, or not following processes, and when you ask if the users were trained on that process, the answer is “No”.  Hanlon’s razor is very useful to avoid unnecessary conflict and escalations, by avoiding attributing things to malice.

That’s all for now. In the next article, I’ll explore more razors and principles that are highly valuable for cybersecurity. Remember… if you hear hoofbeats, think horses not zebras.