Agile cybersecurity, often referred to as “Agile Security” or “DevSecOps” (Development, Security, Operations), is an approach incorporating Agile principles and practices, usually through a framework like SCRUM (shown in the below screenshot), into an organization’s security practice.

Typically, the introduction of Agile cybersecurity aims to improve the speed and efficiency of security teams in responding to threats. By integrating a project management methodology that emphasizes iterative development, collaboration and continuous improvement, Agile cybersecurity aims to unlock the following benefits:

• Enabling faster response to threats: Agile security teams can quickly identify and respond to threats by using short, iterative development cycles. This allows them to deploy security updates, detection rules, incident response tools and patches more quickly, and to reduce the amount of time that attackers have to exploit vulnerabilities within an organization.
• Improved collaboration: Agile security teams are cross-functional and collaborative, which means that security teams can work more closely with other departments, such as cyber engineering. This can help improve the overall security posture of the organization.
• Continuous improvement: Agile security teams continuously review and improve their processes. This helps to ensure that security teams are using the best possible methods and automations to protect the organization from cyber threats.

While Agile principles and methodologies can theoretically be applied to any security department, they are best used to manage the interaction between security operations (including vulnerability management) and cyber engineering. By building a closed feedback loop with security operations and vulnerability management, cyber engineering teams can deliver tools and software that consistently speed up security response times.

Through the delivery of high-quality tools, software and automation the cyber engineering team can help decrease vulnerability windows, increase the efficiency of security operations and unlock cost savings. Additionally, harnessing a culture of collaboration, regular inspection of deliverables and open feedback should accelerate technical excellence as well as improve cooperation and trust between operational and engineering teams.

Agile cybersecurity, however, is not a silver bullet: while research confirms that Agile generally outperforms waterfall as a project management methodology, the reality is that both frameworks will work effectively if your security team operates in a high-trust, high-motivation environment. The key to unlock innovation and high-value delivery lies within the domains of team collaboration and trust, which are not necessarily fostered by the simple application of a project management framework.

The road to implement Agile cybersecurity is paved with challenges. However, five challenges exist that are particularly pernicious, mostly because they manifest themselves months after Agile has been adopted by security teams. If left unmanaged, they can seriously delay the implementation of Agile cybersecurity. In some cases, they could even entirely compromise it.

Challenge 1: preparing your security team for Agile

There’s nothing more counterproductive than executing change without sufficient preparation. Change requires buy-in and an understanding of end goals. As a result, failing to train and upskill a team before going through an Agile transformation can have several negative consequences.

More importantly, the scope of training and upskilling may not be restricted solely to Agile. In other words, if you are managing a security team that lacks key workplace communications and collaboration skills, you may need to first address these issues well before kicking off an Agile transformation. No project management framework is suddendly going to increase value delivery if the underlying teams cannot communicate and collaborate effectively.

Agile (and, in fact, any other project management framework) can only succeed if teams are trained in providing effective feedback, properly managing meetings, thinking critically, collaborating constructively, upholding professional standards and working in an outcome-based manner. With soft skills now becoming more important to businesses than technical skills, it is clear that large training investments are best concentrated in the soft skills department, rather than others.

Failing to equip your security team with the necessary Agile skills will typically produce the following effects:

1. Resistance to change: without proper training, team members may not fully understand the principles and practices of Agile. This lack of understanding can lead to resistance in adopting Agile methodologies as team members become accustomed to seeing them as a disruptive and unnecessary change to their daily business.

2. Misalignment of goals: Agile relies on close team collaboration and alignment of goals. Without training, team members may not understand the importance of this alignment, leading to conflicts, misunderstandings or, worse, spending more time and energy brainstorming how to apply Agile rather than actually performing their job duties.

3. Decreased morale: Agile transformations that waste everyone’s time and require enormous amount of attention will destroy morale. When cybersecurity teams are unprepared to integrate Agile methodologies and are forced to upskill while transforming, frustration and demotivation are inevitable. Decreases in job satisfaction are then brought into the mix, with a consequent need to manage potential resignations and departures.

4. Impaired communication: Agile relies on open and transparent communication among team members. Without training, teams may struggle with effective communication, leading to misunderstandings and bottlenecks.

To mitigate these consequences, it is essential for organizations to invest in Agile training as well as providing ongoing support and coaching to teams as they undergo the transformation. Trainings should cover Agile principles, practices, and the cultural aspects of Agile to ensure a successful transition to Agile methodologies. Even better, organizations should hire security leads with proven experience in successfully implementing Agile cybersecurity, so that individual teams may receive advanced support and coaching that is more aligned to their day-to-day job.

Challenge 2: hiring leaders with Agile experience

Hiring security leadership with Agile experience is going to be another challenge to manage. While no specific statistics exist on how hard it is to hire Agile cybersecurity leaders, it is well known that the industry as a whole is suffering from a skills shortage.

For example, a 2021 report by the Information Systems Security Association (ISSA) found that 64% of organizations are struggling to find qualified cybersecurity professionals. The report also found that 81% of organizations are facing a shortage of cybersecurity leaders.

This suggests a growing demand exists for leaders and CISOs with Agile cybersecurity experience, but there is a shortage of qualified candidates. Thus, while hiring top cyber security talent is hard, finding top talent with additional Agile experience is even harder.

While the overall evidence suggests that hiring leaders with Agile cybersecurity experience is a challenge, failing to manage it will have consequences on your implementation program. Some of these consequences include:

1. Slow implementation velocity: entrusting the implementation of Agile cybersecurity to inexperienced managers may lead to excessive experimentation cycles. While applying Agile, inexperienced security leaders will be unable to properly coach and direct their teams into applying Agile methodologies in the most effective and efficient way possible. This will result in a proliferation of co-creation initiatives that will inevitably increase implementation timelines.

2. Difficulty in prioritization: Agile requires teams to prioritize tasks based on value and risk. Without leaders experienced in balancing operational needs with Agile implementation activities, teams may struggle to prioritize work effectively, potentially leaving critical needs (or vulnerabilities) unaddressed.

3. Failure to learn and adapt: Agile is built on the principles of continuous improvement and adaptation. Inexperienced leads may not have the experience to facilitate a culture of learning, adaptation and feedback within a cybersecurity context. Additionally, security leads may not have the necessary experience to seek out feedback from senior management and the wider business, exacerbating the inability to adapt security operations to the needs of stakeholders.

When building an Agile transformation plan organizations must include a hiring strategy to be executed well before the implementation begins. Key leadership positions must be filled with adequately skilled professionals. Alternatively, existing leaders must be trained and upskilled while being paired with a CISO experienced in delivering Agile cybersecurity.

In addition, following the below hiring strategies could help increase your organization’s chances to secure the necessary talent. They are relatively low-cost and can be easily executed:

• Form a strong partnership with your organization’s Human Resources (HR) department. Ask for HR to identify internal recruiters with experience in sourcing technical roles and appointing at least one of them as cybersecurity recruitment lead. Focus for the HR team is, in fact, key. You HR department will deeply understand the recruiting processes of your organization and will be better positioned to incorporate your requirements in their hiring plan. Offer HR consistent support from a senior cybersecurity manager (or the CISO) to help formulate a recruitment strategy, set hiring goals and set up the necessary logistics to execute on your hiring plan

• Write solid job descriptions and be crystal clear about the expected requirements. In an effort to hire quickly, organizations will often write generic job descriptions in order to attract candidates with less experience or who have different certifications than originally sought for. If possible, avoid doing this and spell out all non-negotiable job requirements. Be flexible only on desirable skills and make sure those are clearly distinguished by must-have requirements.

• Ask your security team to help with recruitment, especially if they have a social media presence. Additionally, invest some budget in sending your team to attend industry events and conferences. Give them a specific mandate to network with potential candidates and learn about their skills and experience. If necessary, set company incentives to encourage referrals to HR.

It goes without saying that offering competitive salaries and benefits will be a major driver in attracting the right talent to your organizations. Cybersecurity professionals are in high demand, so competitive compensation and benefits are needed in order to attract and retain top talent.

By following these tips, you can dramatically increase your chances of hiring qualified cybersecurity leaders with the necessary Agile experience. With the right hiring strategy, focused on filling or upskilling key leadership positions, you can ensure your security team will be well supported, coached and led by competent leadership throughout the transformation.

There is nothing more counterproductive than pairing your security team with “generalist” Agile coaches who will, quite naturally, focus on Agile principles, practices, processes and form rather than bringing real-life experience to the table. Only leaders with Agile experience can help your teams successfully navigate an implementation program and adopt practices that accelerate, rather than hinder, your company’s security capabilities.

Challenge 3: applying SCRUM intelligently

SCRUM is a great expression of the Agile methodology wrapped up in a concise, easily graspable framework. Because it is simple and straightforward to understand, it is generally the first Agile framework applied by organizations. In fact, a 2022 survey by the Scrum Alliance found that 74% of respondents said that Scrum was the first Agile framework they used.

While SCRUM is an excellent framework, it is not best suited to equally manage all cybersecurity teams: security operations and cyber engineering are two classic examples of cybersecurity teams where applying SCRUM makes little sense. In such high-tempo, operational environments work is generally unpredictable or constantly changing. Additionally, consistent delivery of ouput is needed and a lot of work in progress needs to be executed during short cycle times. In such an environment, an alternative Agile framework like Kanban is more suitable.

When applying Agile to your security teams, you must ensure SCRUM is applied only to those areas which benefit from well-defined delivery windows where changes and improvements can be shipped in blocks (such as with risk management teams). Your team leads should posses the experience to know which Agile framework is best suited for the working needs of individual security teams.

Applying Scrum rigidly across all teams (especially security operations and cyber engineering) can, in fact, create several common problems:

1. Overemphasis on time-boxed sprints: SCRUM relies heavily on time-boxed sprints, which don’t align well with the rapid turn-around and delivery requirements of security operations. A rigid adherence to time-boxed delivery windows can inhibit the acceleration and scaling of security operations as well as induce a false sense of completion. This can become grinding for security analysts and incident responders, who may require cyber engineering to deliver urgent requests faster than SCRUM allows.

2. Lack of flexibility: an overemphasis on time-boxed delivery induces a lack of flexibility on the engineering team. When all requests need to be added to a backlog for discussion, sizing, estimation and ultimately planning into a sprint through rigidly defined (and time-consuming) ceremonies, engineering teams tend to pick up less and less issues from the backlog. The result is that requests tend to become slowly forgotten in the backlog. Form begins to overtake function and urgent issues need to be deferred for discussion during future sprint planning session. Thus, applying Scrum to teams that need to process endless streams of requirements can limit flexibility and hinder their ability to adapt to evolving security needs.

3. Difficulty in balancing priorities: after a while, lack of flexibility begins to interfere with prioritisation. When high-priority issues need to be parked in the backlog while waiting for sprints to finish, their priority has implicity been diluted already. Thus, it becomes difficult for cyber engineering teams to commit to more aggressive delivery timelines when everything needs to be developed in two week blocks (sometimes even 4 week blocks). While it’s true that critical issues can be surged (or spiked) within a SCRUM backlog, the engineering team is always free to drop urgent requests in order to protect the sprint backlog and developer focus. In these conditions, both cyber engineering and security operations will struggle to balance new requirements with existing sprint commitments.

4. Difficulty in scaling security operations: when all of the above effects compound, the result is that engineering work inevitably slows down. This almost always leads to conflict between engineering and security operations. Both teams will begin blaming each other for lack of improvements, rather than focusing on communication, prioritisation and collaboration. Eventually, the idea to merge cyber engineering with security operations will emerge in an attempt to fix the issues induced by the inefficent set-up, rather than addressing the underlying cause, i.e. using the wrong Agile framework.

To address these issues, organizations implementing Agile cybersecurity should consider adapting Scrum to better suit the needs of their security teams or, better, adopting more suitable Agile frameworks. This may involve customizing Agile practices, incorporating security-focused roles and responsibilities, and ensuring that security remains a top priority throughout the Agile development lifecycle. Ultimately, the goal should be to balance Agile principles with the unique requirements and constraints of cybersecurity to achieve effective security practices.

When it comes to the interplay between cyber engineering and security operations, special care is required. A good set-up should prefer Kanban over SCRUM so that requirements can be “streamed” within the engineering team’s backlog and picked up based on priority. The picture below illustrates an example set-up of Kanban optimised for cybersecurity operations and engineering:

To guarantee optimal collaboration between operations and engineering, two further elements are required:

• A priority system should be jointly defined by both cybersecurity engineering and operations. The priority system should not only define priority levels but also expected turnaround times and KPIs
• To prioritise work and keep both teams closely synced, a weekly handshake protocol should be used instead of backlog planning sessions. The protocol meeting should not last more than one hour and it should contain a well defined structure that covers, at a minimum, the below discussion sections:

|--------------------|-----------------------------------------------|----------|
| Section title      | Description                                   | Duration |
|--------------------|-----------------------------------------------|----------|
| Kick-off + sitrep  | - Sharing name of on-duty engineer            | 5 mins   |
|                    | - Sharing name of on-call analyst             |          |
|                    | - Reviewing development KPIs                  |          |
|--------------------|-----------------------------------------------|----------|
| Topics discussion  | - Discussing all operational topics and new   | 30 mins  |
|                    |   requirements to be added to the backlog     |          |
|                    | - Topics are provided before the handshake    |          |
|                    |   takes place. No more than 2 minutes are     |          |
|                    |   dedicated per topic. A maximum of 6 topics  |          |
|                    |   are discussed, including sharing feedback   |          |
|--------------------|-----------------------------------------------|----------|
| Backlog refinement | - The backlog for the weeks is reviewed and   | 15 mins  |
|                    |   issue priorities are reassessed. The aim    |          |
|                    |   of the section is to agree the backlog of   |          |
|                    |   work to be performed during the week        |          |
|--------------------|-----------------------------------------------|----------|
| Detections review  | - Detections that are to be released to       | 10 mins  |
|                    |   production are reviewed and approved by     |          |
|                    |   the security operations team.               |          |
|                    | - Feedback on exising detections is exchanged |          |
|                    |   and any fine-tuning requirements are added  |          |
|                    |   to the backlog                              |          |
|--------------------|-----------------------------------------------|----------|

All outcomes of discussions in the weekly protocol should be noted by the facilitator and uploaded to an internal wiki page immediately after the meeting. By meeting once a week and following a structured approach, cyber engineering and operations can ensure that the backlog is rapidly refined and delivered. Moreover, the protocol would ensure that critical and high urgency requirements are discussed and prioritised on a weekly basis. Finally, by starting the meeting with a discussion on development KPIs, both teams can review the engineering workload and jointly cooperate to keep development pressures under control.

Challenge 4: prioritising operations

Security operations, vulnerability management and threat intelligence sit at the heart of every organization’s cybersecurity team. While other cybersecurity teams (such as risk management, security architecture or the red team) also play a key role in guaranteeing organizational security, they contribute to enhancing core defensive capabilities in an indirect manner.

For this reason, while applying Agile cybersecurity an organization must always prioritise security operations over security management functions. Failing to effectively account for and prioritize the requirements of your operational teams will produce two major problems:

1. Inadequate threat monitoring: your security operations team is responsible for monitoring and responding to security threats in real-time. Failing to prioritize their requirements can result in insufficient tools and processes for threat detection and response, increasing the organization’s vulnerability to cyberattacks. In particular, failing to address lessons-learned during on-call shifts or incident response can produce pernicious second-order effects. For example, failing to automate security monitoring activities by not prioritising operational requirements will result in analysts spending the vast majority of their time manually triaging alerts. This reduces focus on high-vaue activities such as threat hunting, identifying new detection sources (missing logs or detection rules) or optimising security analytics. At the end of the road, this impacts the ability of security operations to improve and evolve their detection capabilities to match the latest threats.

2. Failure to address technical debt: operational teams typically accumulate technical debt during the course of their lifetime. When the focus is on addressing urgent security incidents, there is no time to properly write software or deploy technologies. Failing to handover tools that have been tactically developed (and the resulting technical debt) will lead to operational backlogs and slow incident response times. Analysts and incident responders often rely on specialized tools and technologies. Failing to integrate these tools into a cohesive, well architected, modern cybersecurity platform can result in data silos and limited visibility into security events.

The challenge of prioritising security operations can be more easily managed compared to some of the other challenges discussed above. Simply applying Agile intelligently and allowing security operations more freedom and time to adapt should be enough. However, there are a couple of additional steps that you can take to make sure an Agile implementation program does not interfere unnecessarily with security operations:

• Work with team leads to make sure security operations culture is preserved and respected. While the introduction of Agile will inevitably change the way teams collaborate and deliver, always avoid applying Agile practices that unnecessarily disrupt key operational principles helping your teams stay motivated, productive and performant. For example, if your security teams favour flat hierarchies where everyone, including managers, contributes to on-call activities in a focused manner, do not add extra “Agile hats” or “responsibilities” on individuals within the team. Asking a senior incident responder to become a “SCRUM master” just because the SCRUM framework requires it is a sure way to decrease focus on the job - with all of the frustrations which will inevitably follow.

• If you lack team leads with experience in Agile cybersecurity, ensure that new processes affecting security operations are collaboratively co-created with security analysts and responders. When designing new processes, ensure the needs of security operations are taken into account and that disruptive change is not introduced for the sake of it. Ensure security operations and cyber engineering jointly define their missions and agree together the job responsibilities of the differing teams. Avoid at all cost the imposition of new processes that conflict with analyst or responder’s ability to perform their duty in a focused manner. Apply the same principle to your security tooling: do not force the introduction of changes in your cybersecurity platform unless required by your analysts or responders, especially when they are caught in the middle of an Agile transformation. Harness Agile to optimise technology and think about reviewing your tools once the dust of implementation has settled.

• Promote an instantaneous feedback culture and ensure retrospectives are seamlessly embedded within operations, rather than treated as standalone ceremonies which require analysts and responders to switch context. Embedding feedback within a weekly handshake protocol is the best way for improvement suggestions to be addressed rapidly. If some Agile processes are not working despite best efforts, listen to the feedback and aggressively change them to suit operational needs.

In general, to mitigate the problems discussed above, any Agile cybersecurity implementation program should involve security operations from the outset and ensure that their requirements are considered when defining processes and practices. All necessary tools, training, and resources to effectively integrate security operations with Agile development teams should be provided. Finally, open collaboration and communication between all relevant teams must be ensured in order to maintain a strong organizational security posture during times of change.

Challenge 5: developing a low-disruption QBR process

Enterprise Agile transformation programs don’t just focus on introducing Agile project management practices. They also aim to introduce Agile objective-setting practices that neatly tie up department workstreams to organizational goals and must-wins. Within Agile transformations, this is normally achieved by introducing a Quarterly Business Review process (QBR).

The goals of the QBR process are to:

• Review performance over the past quarter. This includes identifying key achievements and challenges, and discussing customer feedback.
• Plan for the next quarter. This includes setting goals, identifying key initiatives and strategies, and discussing how to measure success.
• Strengthen relationships with customers and stakeholders. Using QBRs as an opportunity to build trust and rapport, and to demonstrate commitment to customer success or organizational must wins.

The end result of the QBR process is the creation of team Objectives and Key Results (OKRs) to be delivered by the end of the quarter. Broadly speaking, the QBR process is composed of four stages and is executed as illustrated in the below picture:

QBRs can be an incredibly effective tool to ensure organisations (large or small) have well defined strategic objectives which translate into relevant workstreams delivering high-value and that are aligned to the organization’s goals.

However, while QBRs takes place once every quarter, they can quickly become cumbersome if, like SCRUM, they are applied rigidly. Some large businesses organise “QBR weeks” bringing together different departments to brainstorm and develop OKRs. While the process can be an excellent opportunity to bring together different teams to collaborate with management on developing quarterly goals, it can rapidly turn into a time-sink for operational teams.

To avoid creating QBRs that turn into bloated, time-consuming events for your security team, consider applying the below tweaks:

• Ask security leadership to co-develop the QBR process with analysts and responders, at least before the first iteration. Aim to understand where, in the process, do operational security teams see themselves being involved and where, instead, leadership can represent them instead.

• Allow analysts, responders, team leads and product managers the possibility to execute QBR kick-offs and definition rounds independently between themselves and their stakeholders. Ideally, allow these teams to carry out kick-offs and definitions within their own time. Put operational teams and their managers in the driving seat, so they can work on aligning with stakeholders and defining provisional OKRs well before the QBR market takes place, all while balancing day to day operations and security incidents.

• Give team leads time to prepare and submit high quality, albeit provisional, OKRs before the QBR market takes place. Ensure that senior leadership reviews all provisional OKRs before the QBR market. Use the time during the QBR market productively by having your senior leaders, managers and stakeholders solely discuss feedback and outstanding issues. Avoid using QBR markets as a “brainstorming” forum where OKR presentations are improvised and most feedback inevitably turns towards whether OKRs are properly defined according to the rulebook or, worse, whether they make sense or not. That wastes everyones time and generates undue stress on all participants involved. If your operational teams ask for it, avoid involving analysts and responders in the QBR market and allow them to focus on on-call or engineering activities.

• Avoid squeeinzg the QBR process into a single week and asking all security team members to participate. Eventually, you should get your leadership to a level where QBR market sessions are executed rapidly, meaningfully and efficiently. Finally, OKR sign-off sessions should become more an occasion to celebrate and socialise, rather than a formal ceremony to mark the close of a week long “Agile retreat”.

By following the above suggestions you can empower your security teams to produce great OKRs while keeping the focus squarely on security operations, hopefully creating an enjoyable process in the meantime. Keep your ears open for feedback and keep improving the process to enhance preparation and reduce time wasted. Respecting the needs of your operational teams will ultimately guarantee better engagement and higher quality OKRs.

Conclusion

Agile cybersecurity can become a powerful tool to accelerate the rate of innovation and adaptability of your security teams. However, like many project management frameworks before it, Agile is just a tool and is not a one-size-fits-all solution. As a CISO, yourself and senior leadership must work hard to tailor its implementation to the specific operational needs and context of your organizations.

Recognizing common pitfalls, including the ones outlined in this post, and proactively managing them can significantly increase the likelihood of a successful and powerful Agile transformation for your security team.