The Agile Security Team: Reason and Discovery

We have to do more with less. According to the 2019 ISC2 Cyber Security Workforce Study we will need an additional four million trained workers to close the skill gap in security. Four freaking million. That’s a lot of people. That’s a lot of money. Good luck getting funding for that at your organization. I propose that we could look at how we’re doing work and see if we can do it better.

Previous state

Prior to discovering agile, I use Outlook for all my tracking. Oh, and a whiteboard. I used different symbols in front of task to prioritize work in my Outlook task list. The whiteboard had a variety of colors depending on task and prioritization. It wasn’t good. It was very frustrating to follow and I often forgot where I was with the task. Especially, when I came in the next day. 

I needed a better system.

Discovering agile

I moved to Nashville in 2016 to sit with a development group as their security liaison. I would bring concerns to the security team and vice versa. My first order of business was to understand the development team. Their goals; their frustrations; their process. One of the first groups I partnered with were the scrum masters. They oversaw the whole development process. I researched and studied agile. 
Some of what I learned I didn’t agree with. I found their manifesto contradictory and I their rules often seemed a bit heavy for titling the process agile. Like whiskey or craft beer, though, there are many flavors of agile. No one really does true agile, they just do some form of it. I eventually landed on kanban. 

Kanban

It started with Toyota in the late 1940s. It was used to optimize the manufacturing of cars. In it’s simpliest form it has three columns for work to move through: To Do; In Progress; and Done. You have a bucket of, “To Do” prioritized for workers to grab and do from the top. They pull it into the, “In Progress” column and work that item until it’s, “Done.” I like simple and practical things and kanban fits that bill. 
This works great for developers who have specific tasks that need to be accomplished before the next one. I’ve found it’s also great for pentesters, because that work can be planned out a little more. It’s not so great for blue team work. My security engineers often have several things in progress at once and can’t have only one task in progress at a time. Just today my work day was interrupted by two new tasks that took priority over everything else. I created two new tickets and put them in progress with my other eight tasks in the column. 

Next time

I like reading short blog posts, so I plan to keep blog posts short. The next blog post will include the setups I have for my three different teams. Each one has a little different setup from the other.