Agile has been spreading across several industries for many years now, with consulting companies promoting it since at least 2017. Through the vehicle of company transformations, agile methodologies such as SCRUM and SAFe are now being adopted by many commercial enterprises.

Cybersecurity teams are often at the receiving end of such transformations. Agile methodologies are frequently imposed by the business with little guidance. As a result, a solid understanding of agile fundamentals (and how to apply them to cybersecurity) is crucial to ensure security teams can successfully integrate these methodologies.

What is agile cybersecurity

In a nutshell, agile cybersecurity is implementing an adaptive and iterative approach to securing information systems. By integrating agile software development methodologies, security teams can become more adaptable, collaborative and respond more accurately to the needs of the business. Ultimately, this should enable security teams to be even faster in responding to emerging threats and vulnerabilities.

To date, there is no conclusive proof that integrating agile within cybersecurity makes teams faster in responding to threats. Still, agile can help security teams improve collaboration and alignment with the business. In particular, agile methodologies can help improve the following areas:

• Team collaboration: Security teams often operate in silos. This is exacerbated by cybersecurity’s nature, where success is based on hiring the right experts who can deal with specific security challenges thanks to dedicated technical skills. When teams are required to focus on a narrow scope of work in order to deliver successfully, silos can easily form. By promoting frequent interaction between team members, agile can help security teams counterbalance the tendency to form silos that is inherent within cybersecurity work
• Business alignment: Security teams often run at maximum capacity and have limited time for non-essential activities. Moreover, they typically operate in the backend, enjoying little visibility within the business. If left unchecked, the focus on mission-critical, operational work can lead security teams to drift away from business stakeholders. This will typically result in a misalignment of business goals and expectations. By demanding frequent stakeholder touchpoints and a transparent approach to product/service delivery, agile can help security teams stay in close sync with business stakeholders
• Change adaptability: Security teams operate in an industry subject to high-frequency change. In this environment, project management methodologies that encourage fixed service and product delivery may stifle a team’s ability to rapidly adjust to changing security priorities. By breaking down service and product delivery into smaller and shorter iterations, cybersecurity teams can more effectively deal with the constant stream of ever-changing security priorities

The case for agile cybersecurity mostly boils down to the above three bullet points. If applied correctly, agile can speed up the delivery of cybersecurity products and services while maximising alignment with stakeholders. However, it must be understood that agile is not a silver bullet. On its own, it will not make your team suddenly faster in responding to threats. Moreover, if implemented incorrectly, it can introduce significant disruptions and make things worse.

Agile cybersecurity should be viewed as a tool to increase alignment and visibility with the business. Also, it should be viewed as a set of practices to help security teams iterate and retrospect aggressively, to consistently improve tradecraft over time. However, it will not be the solution to fixing team dysfunctions, poor security tooling, or an inadequate budget.

Agile cybersecurity pillars

The fundamentals of agile cybersecurity rest on four basic pillars. Each pillar helps with the correct implementation of a basic, functioning agile cybersecurity system. The pillars are the operating pillar, the planning pillar, the developing pillar, and the releasing pillar. Let’s look at each one in order.

Operating pillar

Under this pillar, you define the foundational operating model that governs and operates each team within your cybersecurity practice. When thinking about agile cybersecurity, a common misconception is that you need an agile-compatible operating model for your teams to adopt agile successfully. However, this is often not necessary.

Classic, hierarchical operating models can be perfectly sufficient, as long as the ownership of products and services is delegated to specific team leads. These leads should then be trained in agile project management so they may effectively coach their teams with adopting agile methodologies effectively and efficiently.

Moreover, during an agile transformation, hierarchical operating models can provide two distinct advantages: first, they help set clear lines of accountability within security teams. Secondly, they ensure all employees have a defined place and clear reporting lines within the hierarchy.

hierarchical operating models can be the perfect starting point when implementing agile. They can be used to give teams a well-defined, more structured operating model. This would help focus their efforts exclusively on introducing agile within their processes while avoiding the politics involved in reorganising teams around a new operating model.

However, hierarchical models are criticised for not being sufficiently flexible. Also, they are perceived as being unsuitable for promoting a “leadership in every seat” approach. An alternative to hierarchical models is provided by matrix operating models. Matrix models, originally developed by Spotify, are designed to break down silos and encourage collaboration between different departments.

Central to matrix operating models is the concept of squads. Squads are formed by bringing together specialists with all the different skills necessary to achieve the squad’s development goals. However, while such specialists perform their day-to-day duties within the squad, they do not belong to the squad or report to the squad’s product owner. Instead, they belong to chapters: groups of professionals with similar skills, each reporting to a chapter lead. Just like in a matrix, chapters are overlayed across squads, as shown in the below image:

The main driver behind the matrix model is that highly specialised professionals may want to rotate between different projects (carried out by the Squads) while maintaining their career development and HR reporting duties tied to a specific home base (the chapter). You can read more about matrix models through this excellent blog post by Atlassian.

A matrix operating model is often the starting point for many teams carrying out agile transformations. However, such a model is better suited to teams that are already well-versed in using agile methodologies. During your agile transformation, avoid tasking your team with updating their operating model and processes together.

This will add too many layers of complexity. If you can, opt for a phased approach: firstly, task your team with integrating agile in your cybersecurity processes. Once your processes are updated and your team is satisfied with the result, then task them with updating their operating model.

Allow your team to first focus on simplifying any existing team structure, rather than design a new one based on the matrix model. It will be simpler for your team to adapt their existing team structure to accommodate agile practices, rather than the other way around.

Finally, matrix organisations are not free of criticism. Ironically, Spotify itself progressively abandoned the original matrix model it pioneered. New operating models are emerging seeking to address the shortcomings of Spotify’s matrix model, such as unFIX. However, these are even more complex and should only be considered by security teams with a high level of agile maturity. Most security teams are best served by hierarchical models such as the one shown below (operating model taken from page 94, Designing and Building a Security Operations Center, D. Nathans, 2015, Syngress):

Planning pillar

The planning pillar incorporates two key concepts: the Quarterly Business Review (QBR) and Objectives and Key Results (OKRs). Both are implemented together to ensure agile teams maintain consistent alignment with the business.

QBRs are regular meetings held between product/service owners and their stakeholders. They take place every three months and give stakeholders the chance to validate progress on yearly objectives. When properly implemented, QBRs allow agile security teams to demonstrate how their products and services contribute to overall company goals.

More importantly, QBRs give agile teams the ability to surface challenges or obstacles before they become impediments to yearly goals. Thanks to this, QBRs can become a valuable tool for managing stakeholder expectations, increasing transparency and strengthening trust.

At a basic level, a QBR process should include four stages and must be executed as illustrated in the below picture:

The result of the QBR process is the creation of OKRs. OKRs offer a conceptual framework for setting quarterly goals to be delivered by teams. An OKR combines two parts:

1. The objective, which is a qualitative description of what you want to achieve (for example “We effectively manage vulnerabilities across the company”)
2. The key results, which are specific metrics that track progress towards that objective (for example “Achieving 100% vulnerability management coverage of key compute environments”)

OKRs give agile teams specific objectives that are measurable and key results that are realistic to achieve. From each key result, tasks (such as “Deploy vulnerability management agents to 90% of production servers”) can be defined to help the team achieve the agreed goal.

Good OKRs are ambitious yet achievable. Objectives must be expressed in an inspirational, yet clear manner. Conversely, good key results must be quantifiable, time-bound and directly linked to the objective. This combination keeps teams focused on the big picture while ensuring they have clear milestones to measure success in alignment with the business.

Developing pillar

This pillar is the most important one: when implementing agile, your team must focus most efforts on correctly incorporating agile within its product and service development processes.

There are two agile development frameworks that cybersecurity teams can reference: these are Scrum and Kanban. Scrum is particularly suited for cybersecurity teams that have a product-oriented output, such as:

• Cyber engineering teams maintaining security tooling for the SOC
• Security architect teams building secure configuration baselines
• Detection engineering teams developing new detections in response to threat intelligence

Scrum can help such teams with breaking down big projects into iterative cycles. Within scrum, these cycles are called sprints. Each sprint is a short development period, typically lasting one to four weeks, that focuses on delivering a specific set of features or functionalities.

Within Scrum, customer requirements are logged in a product backlog. This backlog is consistently refined by a product manager who works with the scrum team to plan each sprint. The sprints themselves are each planned so that a specific goal is achieved by the end of the development cycle. To achieve this goal the team assembles a sprint backlog by picking requirements from the product backlog and converting them into tasks.

Then, once the sprint starts, the development team works through the sprint to accomplish all of the originally planned tasks. While the sprint takes place, developers meet daily to discuss progress and coordinate work. Once the sprint is complete, the product feature or update is released and reviewed with the stakeholders. During the review, feedback from stakeholders is recorded in the backlog for it to be addressed in a later sprint cycle.

Unlike Scrum, Kanban is a system to manage a continuous flow of work without breaking it down into sprints. It utilizes a Kanban board with columns representing different work stages. Work items move across the board as they progress (from “to do” all the way to “done”), with a set limit on the number of items allowed in each stage to prevent bottlenecks.

Kanban is much more flexible, allowing new tasks to be added anytime. This is in direct contrast to scrum, which focuses on completing a defined workload within each sprint. This makes Kanban ideal for ongoing projects with unpredictable requirements. As a result, kanban is well suited for teams that have a service-oriented output, such as:

• Threat intelligence teams delivering CTI updates in a constant flow
• Security engineering teams delivering time-critical automation to the SOC
• SOC teams when not “on-call” and working to improve processes and tooling

Developing an initial understanding of how Scrum and Kanban work is not hard. The Scrum guide, for example, is only 14 pages long and can be easily learned. However, the real challenge lies in applying the correct methodology to the right security team.

When implementing agile cybersecurity, you should avoid an implementation strategy that focuses on the rigid adoption of agile processes (such as those described in Scrum). Rather, you should prioritise a co-development approach.

In a co-development approach, individual teams work with managers to identify all those agile practices that bring tangible improvement to their daily workflows as well as alignment with stakeholders. Once these improvements are identified jointly with management, then teams can be tasked with actually implementing the selected agile practices.

Releasing pillar

Under this pillar, agile cybersecurity teams deliver value to stakeholders. While the other pillars also play important roles, none are as central as the release process. It is through the release process that stakeholders benefit from the output of security products and services.

In the software development world, the agile release process offers several advantages over traditional waterfall methods. Thanks to the shorter, time-boxed development iterations, stakeholders can inspect the results faster and provide frequent feedback loops. Thanks to this, developers can incorporate stakeholder insights early and often.

This adaptability helps ensure that the final product is aligned with the user’s needs. By promoting regular communication and transparency, agile methodologies keep everyone aligned. Finally, by breaking down projects into smaller chunks, risks are better managed and problems are addressed early on.

The Scrum methodology incorporates a specific product release step. This happens during the sprint review. During this ceremony, a collaborative meeting is held at the end of each sprint. The development team showcases the product increment incorporating the new features developed during that sprint.

During the review, the development team gathers valuable feedback from stakeholders on the functionality and direction of the product. This feedback is then used to refine the product backlog, potentially adding new features or prioritizing existing ones, ensuring the project stays consistently responsive to user needs.

Security teams can adopt the same agile principles. Not only can they break down work into smaller, time-boxed cycles. They can also demonstrate product updates to stakeholders during security-specific sprint reviews.

However, for many security practioners, it is hard to intuitively visualise how sprint reviews can be effectively incorporated into day-to-day operations. After all, how can a SOC perform sprint reviews when constantly working in a fire-fighting mode? Again, the key is to understand which security teams are product-oriented and which are service-oriented.

For product-oriented teams, such as cyber engineering, it is easier to adopt a sprint-based development cadence. As a result, this makes it also easier for them to incorporate sprint reviews into their release method. For example, product-oriented security teams can leverage handshake protocols during their sprint reviews.

A handshake protocol is a weekly or bi-weekly meeting that follows a structured agenda. It allows cyber engineers to meet with security analysts and present them with the latest software features and upgrades added to the SOC tooling. Through the protocol, SOC analysts can inspect the updates to their tooling, add them to their toolbox and provide feedback on upgrades that need refining.

For service-oriented teams sprint reviews make less sense. In their case, a monthly service review meeting may be more suitable. Such a meeting may still adopt the principles of transparency and inspectability embedded in the sprint review concept.

However, the content of such a review would focus less on product upgrades of developed features. Rather, the review would concentrate on inspecting service performance (through, say, the review of service level agreements) as well as added value (for example by looking at key performance indicators over 180-day trendlines).

Conclusion

Agile cybersecurity is an approach that integrates agile software development principles into cybersecurity practices. It aims to make security teams more adaptable, collaborative and responsive to business needs. While there’s no proof that it makes teams faster in responding to threats, it can improve collaboration and alignment with the business. Agile cybersecurity should be seen as a tool to improve communication, visibility and iteration. It should not be seen as the ultimate solution to fix all security performance problems.

For most security teams, understanding and adopting the fundamental pillars of agile will be enough to put them on a successful path. These four pillars are operating, planning, developing and releasing security products and services. Operating defines the foundational model, planning incorporates QBRs and OKRs to ensure business alignment. Developing focuses on how teams deliver value, with Scrum suited for product-oriented teams and Kanban for service-oriented ones. Finally, releasing highlights how value is delivered to stakeholders through frequent inspections and feedback loops.

By fully understanding the four fundamental pillars of agile cybersecurity and correctly implementing them, you can successfully transform how your security teams deliver products and services. As a bonus, you’ll help your teams achieve amazing levels of alignment with their stakeholders and, ultimately, the overall business.