Important factors for security team to consider while adopting Agile practices

Brenden Smith, Ciso, Firstbank

Brenden Smith, Ciso, Firstbank

Cyber security is a complex and everchanging environment. As a result our priorities are constantly shifting and adapting to changes in the threat landscape as well as within our own organizations. Amidst this chaos is the need to get work done quickly and prioritize appropriately. These problems aren’t unique to the security space however; software developers deal with similar challenges every day. Many of these teams have taken to adopting an Agile mindset utilizing Scrum methodologies. It’s even best practice for security teams to integrate with the development pipeline to be a part of this work stream. While many security teams are partnered with developers in their workstreams, those same teams are rarely adopting those same practices themselves.

At its core Agile and Scrum practices are ways of getting work done faster and rapidly adapting to change. However the terminology and practices can appear to be complex and confusing, which is a deterrent to adoption. There is a path forward though, and one that doesn’t require a host of certifications and training. With no certifications and minimal formal training we have adopted these methodologies in our security program and substantially improved our ability to get work done. We would conservatively estimate that we at least doubled our capacity to get work done through these processes, and that benefit only continues to grow. In addition we have a documented library of all work we’ve attempted, even discarded projects, to reference in the future.

Framing the Approach

The single most important factor in adopting Agile practices in your security team is the willingness to continuously improve what you try. You don’t need expertise, certifications, or a Scrum expert to move forward. There are a few key steps you can take to start adopting these practices and immediately realize the process improvement benefits described above.

In the cyber security space we are constantly engaged in projects, implementations, and other efforts. It is reasonably safe to assume that we have all been part of a project that went of the rails or didn’t meet expectations. In many of those cases it can take months or even years to recognize that a project isn’t going to deliver on its promise. The first step we can take to improve this problem is breaking work down into smaller components. A reasonable objective is to break down any project into two-week iterations of work. What will you do in the next two weeks? It’s a small objective with clearly defined acceptance criteria.

How does focusing on work in two-week iterations help? In security, more than most disciplines, change is a constant. In large projects requirements will change and shift over time. Looking at work in smaller chunks allows us to more dynamically respond to changing conditions in the environment. It also enables employees to more clearly understand deliverables and objectives.

These benefits are more fully realized by taking the second step in adopting Scrum practices, which is creating a tight feedback loop. Every two weeks our Security Architects, management, and key stakeholders get together to review all work being completed in a two-week chunk. Each employee presents for 5 minutes on their progress in the last two weeks, and highlights any challenges they encountered.

The objective of this meeting is to provide brief tactical insight into an effort, and provide clear feedback as to if the project is proceeding appropriately. Using this method employees are accountable for their results, and it ensures that the right work is always happening at the right time.

This methodology creates an efficient mechanism to respond quickly and consistently to new and emerging threats. For example, what if you discovered a critical vulnerability in a key system within your environment? Fixing a vulnerability in a key system can be complicated and fraught with risk of outages or downtime if its done incorrectly. Breaking that effort into two week cycles of work, and regularly reviewing progess, ensures management maintains visibility into progress and that any hurdles are overcome quickly.

We’ve used this process to run everything from Red Team exercises to large product implementation. For example when implementing a new Data Loss Prevention system, we broke the project down into numerous small chunks of work. There are a variety of planned two-week sessions of work to do things like: build out a rule for a specific type of sensitive data, develop a report for executives, and create a new policy for a certain type of threat.

Agile processes can seem intimidating and complicated to take on. The approach laid out here is intentionally simplistic. Start breaking your work into small iterations, and create that tight feedback loop. You will very quickly find you are getting better results on the work your team is doing, and the speed at which they can work will accelerate very quickly. Once you have that momentum started, then you can start to read and learn more about Agile methodologies like Scrum. There is no one right way to adopt processes like this in a Security team, but the benefits of even getting started are compelling.