Security: be Agile, be effective

In a blog post I wrote not too long ago, I dove into the reasons why security teams need to learn how to code. In short, as the lines between security practitioner and developer continue to blur due to the rise of infastructure-as-code, automation, and security tools becoming more developer-friendly, it is very hard to be a top-performing security team without coding. Today, I’ll take this topic a bit further and talk about why security teams need to use Agile as well.

What is Agile? There are many different interpretations of Agile and countless books, videos, and blogs on the subject. Since I don’t come from a formal development background, I’ve never done software development following the Agile methodology, but inexperience doesn’t need to be a barrier to using it. The way our security team uses Agile at Code42 encapsulates several key concepts::

• Iterative development using small chunks of work effort
• Ongoing and timely feedback from stakeholders
• A willingness to experiment that focuses on outcomes rather than jumping to solutions

One of the core tenets of Agile is to iterate and break work up into small pieces in order to rapidly develop, test and deploy. In this regard, it is the opposite of the Waterfall method, with its structured project plans and multi-month timelines. Agile doesn’t mean that complex projects or features can’t be implemented, but that each iteration in the journey to the end state should be able to stand on its own.

It is fairly common in security to see a lot of major projects that have a waterfall-like mentality. Think of implementing a SIEM tool, or maybe rolling out a new endpoint security tool across the organization. Those kinds of projects typically rely on everything coming together perfectly over the entire timeline, and when things inevitably go wrong, the result is slipped deadlines, finger pointing, and angry stakeholders.

With Agile, you can still get to the end, but the path is much more flexible and reactive — it is called “Agile” after all! Instead of rigidly defining the exact order of steps in a project and creating a lot of dependencies between large work efforts, which are inherently fragile, Agile’s goal is to break it up. That massive SIEM project timeline becomes smaller, more independent work efforts like stand up a collector, send one kind of log and validate it, and so forth. That way, if the project priorities or needs change, there isn’t a massive amount of planning that needs to be redone.

That brings me to my next concept: Ongoing, rapid feedback from stakeholders. One of the promises of Agile is that it can prevent the divergence between what stakeholders want and what practitioners deliver, which often happens when large projects run into problems. Flexibility is a must in today’s rapidly-changing world. Take our SIEM project example: what if a SIEM project that started in February had a timeline for onboarding VPN logs in June with a lot of dependencies beforehand? The realities on the ground, and the need to reprioritize that VPN work, would have resulted in a lot of rework and wasted effort put into that original timeline.

With Agile, the goal is to finish your work quickly, then sit back down with your stakeholders and ask questions like “Did this deliver? What is your next priority? What has changed since we last spoke?” This ensures that security teams are delivering real value to stakeholders, instead of going down rabbit holes for months at a time and ending up with a solution that doesn’t improve the security posture of the organization.

The last concept is probably the hardest for security teams to be comfortable with: having a willingness to experiment and fail, while focusing on the outcome instead of the solution. Too often security teams jump to the solution (SIEM, EDR, firewall) before identifying the desired outcome (alerting on events of interest, identifying and acting on C2 traffic). This narrow focus can result in poor resource allocation, or even worse a fundamental misunderstanding of the problem that results in a tool that doesn’t solve it.

There are many, many ways to solve security problems, and experimenting with alternate solutions or questioning the status quo may result in less complex and more efficient ways of achieving goals. These simpler solutions may not have the cachet of a major project, but if your desired outcome is to alert on certain events from a security tool, a one-week effort at leveraging a script, an API, and a cron job may be much more effective than a long SIEM implementation.

How does a security team start to leverage Agile? If you work in an environment where you have Agile development teams, you are in luck: you can reach out to them and start learning the tricks of the trade. Even if you don’t, however, you can become more Agile by breaking your work efforts into small pieces, setting up ongoing feedback both internally and externally, and focusing on the outcome rather than jumping to the solution. Do all of this and you’ll find that you are able to deliver more security value to your organization.