The Agile Security Team: The Setup

In my previous post I covered reason and discovery of agile.

As I mentioned in my previous post, I moved to Nashville and started working with a development team. I quickly discovered that my Outlook task list wasn’t up to the task of (heyo!) tracking all the work I needed to do. I decided as part of my research and understanding of agile that I would setup a kanban board. I made a To Do, In Progress, Holding, and Done column. Three plus years later and I still have the same setup with different approaches for each area.

The framework

This being the genesis was simple. Create tickets and stick them in the To Do column. I didn’t really have a backlog because I was the only one doing them and I decided not to do sprints. Sprints are a defined period of time in which to complete work. Usually this is one to four weeks long. Meetings are setup to set what work would be done during this time. Shorter time frames help protect teams from shifting priorities. You want something new? Next sprint.

With the way security is we can’t really do that. I can’t tell my boss we’ll respond to an incident or research the latest vulnerability in the next sprint. It just doesn’t work. So, sprints are out and I decided to have work flow from left to right, with the exception of holding which tasks could be moved in and out of. We’ll get to that in a few sentences. In Progress seems fairly self explanatory. It’s what I’m working on. Ideally there’s one thing. At times I’ve had up to 12 things in the In Progress column. Again, being in security things tend to pop-up and sometimes tasks can take weeks at a time.

The Holding column is for when I have tasks that are waiting on another team. Once that team responds I move the task back to in progress or done. Done is done. The task is completed.

Application Security

The application security board has morphed over the years. It used to be my task board. Now it’s just my appsec board as I’ve taken on other responsibilities. Epic’s is not something I’ve talked about yet. Those are used for categorization. They’re very helpful in showing what people are working on from a metrics standpoint (another post). For AppSec I have multiple teams and areas, so I have Epic’s broken out as team categorization.

Pointing is something we’ll talk about in a future metrics post. It allows us to gather effort level for workload. It’s typically used for planning sprints. I use it for monthly and yearly metrics. I don’t point on the appsec board because I’m the only one working it and I use maturity models for measuring appsec programs.

I grab a task from the backlog and move it to in progress. Then if I’m waiting on something from another team it goes in holding, otherwise it’s moved to done. Simple, which is how I like it.

Security Engineers

Engineering has a lot of the work coming in from service desk requests, to projects, to random stuff that pops up. We follow the same flow. I expect people to have multiple things in progress regularly. We’ve integrated our kanban board with our ticketing system. When a ticket is put in our queue in the ticketing system it creates a ticket in the to do list. I or the team lead reviews it and if it needs to be worked by us we move it to the top of the priority list.

Tickets are in priority order in the To Do column. When new tickets are created I move them into the area I want them worked based on priority. The engineers once complete with a task will grab a new one from the top of the queue. They work it move it holding or done. Then they point the ticket for effort level. This is where I’m able to get monthly reports on how much work we’ve gotten done. Again, a future post to go more in-depth.

Security Assurance

The pentesters are the opposite of the engineers. They usually only have one or two tasks. We point tickets before they are worked, because we can plan out their work more and funnel the pentest requests that come in. When you point doesn’t really matter. As long as you do it one way or the other. Either before or after. If you mix them it doesn’t provide a good reflection of effort level.

Next time

Metrics and effort.

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.