Agile Security

I recently helped SANS review curriculum for an exciting new course coming out soon on a topic near and dear to my heart. While reviewing this course I started thinking about how security processes might evolve. I've often thought about the term Agile Security but not sure people would buy into this idea. It could be a great time for security teams to revisit how they operate. It could be the evolution of the cloud is driving the need to reconsider security perspectives. If what you are doing works just fine then don't change a thing. However, if you find the need to move faster and respond to threats more quickly, consider the following.

Agile: A word that makes some software engineers cringe because use of the word has transformed - like many other abused and overused words in the technical space by consultants and people jumping on bandwagons to sell products and services. But agile as a word is not the problem. It's the people who are talking about agile but doing quite the opposite. Agile just means you have a process that gets out of the way so you can work fast and adjust your plans quickly as your needs change. This is most important in a security environment with 0-days and rapidly evolving threats to organizations. 

Consider the transformation that occurred in the software industry. When I got my master’s degree in software engineering I took classes with and from people who worked at Boeing. We discussed how to write lengthy, detailed requirements documents with very precise numbered hierarchies. The document would cover every single implementation detail. In theory, this very thorough coverage of the requirements would save money.

Of course, when building something like an airplane details are crucially important. Lives are at stake. The same would apply for medical devices and software. But we were writing similar documents for internal business applications and web sites at the time. Companies would charge sometimes millions of dollars to spend three months or longer writing "Requirements Specifications".

In the end...when the programmers got the specifications, they didn't really work as planned and threw most of the spec out the window by the end of the project. Or worse, the developers followed the specifications precisely even though they didn't meet the need or solve the problem. Often the team would stumble upon information not known at the time of writing the requirements and would find that certain aspects of the requirements were not technically feasible or cost-effective.

About that very same time the idea of Extreme Programming was evolving. I read a book and thought, well this is much more practical. I started a business and wrote my own form of task tracking system much like what Version One is today. My former co-workers who are groaning at the thought of Version One should consider whether they would rather use Microsoft Project...not me, but to each his or her own. Version One has a list of tasks and you can mark the status of each task, track dependencies, time and more. In my case I had contractors working on billable assignments so I added in a time tracker. They could hit a button to start and stop work on a task so I could create very detailed invoices for customers. I could also arrange the tasks in priority order and break them down into small enough pieces so I could see precise progress. In the event priorities changed I could move a task at the bottom of the list up to the top at any given moment and adjust the deliverables and schedule.

How does this relate to security? In large organizations, many security teams are writing lengthy documents that I equate to the old software requirements specifications. And just like those specifications, I can tell you from the trenches of the development teams in these large organizations...you're lucky if people even know they exist. Sorry. It's true. Even if they do the most well-intentioned employee will have a hard time remembering and following all your rules.

What to do? I would suggest that security people learn from the software development processes how to move faster. Instead of writing documents, create agile backlogs. Create the "Epics" or large work items that need to be completed to maintain security in your organization. Prioritize and fund the Epics. Create stories for the Epics. This may be before or after funding, but either way the stories will evolve over the life of any project. Prioritize the stories. Assign the stories to teams. The teams work the stories in 2, 3 or 4 week sprints. Make sure you work the must-have stories at the beginning so you don't have a half-baked project at the end when the money runs out and you deliver nothing.

Before you hire some expensive consultant to make this all more complicated than it needs to be (which I have experienced), see if you can work with these definitions as a starting point. If you are talking about how to implement the process instead of doing work, the process is failing. Keep it simple and focus on whatever helps get work done most quickly and accurately - and exclude extraneous things that get in the way of getting work done.

1. Team: A team of people with certain expertise or assigned to a project or product.

2. Backlog: Typically associated with a team. A backlog contains the work items assigned to a team. The work items should be in priority order from most to least important. Most large companies have multiple backlogs and teams.

3. Backlog Owner: The person who creates the stories in the backlog. When a story is completed the backlog owner gets a demo of the deliverable and "accepts" the work or sends it back for additional fixes before it is accepted. The team closes the stories after the backlog owner accepts the deliverables. The backlog owner is generally a product manager in the case of a product or a technical owner in the case of architectural or security requirements.

4. Epic: Typically, an epic is a project or subset of work that requires approval and budget. Business executives fund "Epics" just as you would for any other project or initiative.

5. Stories: Deliverables associated with an Epic. The story should define WHAT in business terms not HOW in technical terms. Each story should be short and describe how the deliverable will be tested and demonstrated to the backlog owner to prove that the work was completed as required.

6. Sprint: A 2, 3 or 4-week period. A team commits to complete however many stories it can each sprint from the top of the backlog. If a story takes longer than one sprint to complete, break it into multiple smaller stories.

7. Sprint Planning: At the beginning of each sprint the team holds a planning meeting and commits to as many stories from the top of the backlog as will be possible to complete. In my case I had my each team member prepare their individual commitments in advance so these meetings were typically short.

8. Demo or Sprint Review: At the end of the sprint the team demonstrates the deliverables of each story to the backlog owner and stories are closed. 

I'm not going to get into planning poker, capacity planning, retrospectives, cards and Fibonacci numbers right now. If you just start with the above that will get you going. Keep it simple and focus on getting work done versus lengthy process discussions and meeting overload. Once you master the above you can get fancy. I do believe in certain methods for poker planning and capacity planning that help keep projects on track but the main points for now:

• Put the requirements into a backlog instead of a document.

• Define requirements in business terms (what, not how).

• Break down the work into small pieces.

• Demonstrate work as it is completed and prove it works.

• Prioritize and adjust as needed.

My definition of Agile Security. In a nut shell.

But wait. We're not done. If you put all sorts of things in a backlog that define your requirements and deliverables, how will you enforce your policies?

Write software. You may have an overarching document that defines security policies. Preferably it is on an internal web site - or better yet in a database - and adjusted quickly as policy requirements change. Then, turn as many of those requirements as possible into software that at least monitors for infractions in an automated way, but preferably enforces adherence to policies up front. I have some ideas about this in a white paper on event driven security automation.

What, you don't want to write software? Hire a software programmer. This is the convergence of software and security. I predict that security people who embrace this wonderful relationship with those pesky software developers who are causing all your security headaches will be most successful in the future. And those pesky software developers probably need to learn a thing or two about security!

Epilogue:

Before I tell you that Agile or Scrum or whatever your favorite word is for what is basically a Work Breakdown Structure is the silver bullet that will solve all your problems and all your security initiatives will be completed on time and under budget, I will tell you that Agile has a flaw when not properly managed. You need to have a beginning and an end of a project and make sure things are prioritized correctly to actually achieve a deliverable. Time and money are not endless. Some agile teams assume they are and operate as such. 

Make sure you have a way to determine whether your epic and stories can be completed within your time and budget and manage to that time and budget. This means your backlog truly needs be prioritized so the must-haves are the top and the things at the end of the list can be cut if not completed when time and money runs out on the project. There is also an art to managing people's time and keeping distractions away from the team - one of which can turn out to be your "scrum master" if they are more focused on process than deliverables. Additionally, it's a good idea to understand points, burn downs, capacity planning and how to use those in your estimation process to keep the project on track. 

But generally, I think agile, scrum and extreme programming concepts are better than alternatives for many projects.