Agile Security

There has been a fair amount of smoke blown in the security field about "Agile Security". In some cases, the community has questioned the impact of agile practices on security (see my post about that). In other cases, the term seems to be applied as a buzzword without much concrete meaning. This post is the first in a series that will talk concretely about Agile methods and how they can be applied in the security field. It will not only present agile concepts, but provide several parallel fictionalized case studies that evolve over time illustrating an ongoing process of trying to manage security through an agile process.

Introduction to Agile

In the field of software development, Agile project management has grown in importance and evolved to the point where it is widely respected as a viable alternative for running projects. Agile has been codified in Scrum, XP (Extreme Programming), and other specific "styles". In my experience it is rarely practiced the same way twice, but generally holds to some key common tenets that inform project activities. What it is NOT is a way to simply get to a given destination faster or more cheaply. Sometimes that can result from clearer direction, but agile is not about speed so much as course correction.

Agile Manifesto

The Agile Manifesto was developed by a group of developers in 2001 to describe the core values of the process:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Interpretation Applied to Security

The core values of agile methodologies themselves suggest some important perspectives that many in security could learn from.

• Individuals and interactions over processes and tools  -  Security has a disproportionate emphasis on tools and compliance process over the ability for smart people to think about security and take appropriate action. In the software world, we have learned that processes and tools and be brittle while individuals, empowered to take an active role are a primary resource in directing us to the end goal.
• Working software over comprehensive documentation  -  Valuing actual security over CYA risk management. Without trying to get into a discussion of compliance, as a community we need to recognize that customers have limited resources to spend on security and the best result is a more secure system - however it is achieved. We don't need the bells and whistles - we need the fundamentals and we need them working, now.
• Customer collaboration over contract negotiation  -  Although there are many products targeting customers, I think customers can sometimes feel like the victim after an engagement with a security team. What is it that they really need? How can we in the security community deliver that?
• Responding to change over following a plan  -  Security is inherently an ever changing field. New vulnerabilities are discovered on a daily basis. Using a process that can adjust and respond to these changes is essential to focusing on the most important tasks.

Characteristics of Agile Process

Every agile process is different when expressed through implementation within a given organization. This is to be expected. Below are some common properties / processes of an applied agile process.

• Multi-disciplinary team: Bringing business owners, operations, quality and engineering is key to success with agile for software development. In security, it might mean also including legal, risk management, other functional departments that have important security related responsibilities.
• Transparency: In an Agile software project, the product owner should be able to find out what is done and what is not done very easily. The tasks are publicly represented in such a way that the whole team knows what is happening.
• Early and frequent deliverables: In software, this means show a working screen before the whole system is done. That will ensure that wrong turns are detected early. In security, this may mean that a large implementation of a new security system could be broken into client visible chunks.
• Periodic standup: A standup is usually a daily meeting where the dev team shares their status, notes any obstacles and triages new issues. An issue could come up today and be put into somebody's task list for today or tomorrow. Alternatively, it could go into backlog. This format encourages team interaction and communication.
• Visual representation of tasks: Using a story board where agile stories are tracked is the foundation of the transparency mentioned above. This is best done with physical cards, but tools like Trello can be used for distributed teams.
• Sprints: A sprint is a set period of time - often two weeks. In planning a sprint, the team collectively identifies the most important tasks and responsibilities are assigned for completing the tasks. At the end of the sprint, all tasks should be completed. In development, these sprints help teams to better judge how much work to commit to - leading to a more predictable delivery. In security, this may not apply as easily.
• Backlog: Backlog is the list of todo items that are not in the current sprint. Keeping a clear, prioritized backlog helps the organization to understand what is coming in the future. I usually try to ask product owners to review the backlog with me to ensure that they understand what is not happening in the scope of a given sprint or series of sprints.
• Metrics: Sprints and story cards allow us to track metrics such as velocity (tasks per sprint), burndown (progress toward a given milestone), test coverage and other indicators of quality.
• Retrospective: At the end of each sprint, we actively seek out areas for improvement. How can we do better? What did we screw up. We do this so that the process overall continues to improve.
• Testing: Testing is a cornerstone of Agile because code needs to be unit tested in order to prove it is working. In security, there are many opportunities to improve the testability of a successful security control or system.
• Quality: One goal of agile is to encourage buy in from developers and business owners. Developers are committing to complete their work to a high standard within the scope of the original story.
• Debt: Most often mentioned in the context of technical debt (basically tasks that were put aside and should be completed later), debt refers to compromises we make along the way to meet a deadline. This is inevitable. In Agile, we try to measure it and track it so that if levels of debt get too high, we can push new goals aside while we clean up.

What is Agile Good For?

I'll put the answer in a simple picture.

Case Studies: Applying Agile Process

The following case studies try to show examples of three companies starting out with new security programs using an Agile methodology. These case studies are FICTION.

Kodacell

Background

Kodacell is a large electronics company. Their infrastructure supports global operations with supply chain (ERP), R+D (IP), stores (PCI), complex financials, and customer information (PII). Although they have had extensive security operations in the past, they were generally isolated to specific applications or organizational areas. Security is largely part of IT / Operations.

This is a nod to @Doctorow's "Makers": http://craphound.com/makers/download/

Agile Approach

Kodacell decides to look at using an Agile approach toward a new cross team security initiative. In an initial meeting, several key stakeholders agree to start the work toward using an agile approach. They agree vaguely that getting a team together and starting work on a threat model will be the focus of the initial Sprint. They agree to meet every week for a standup and to set up Monthly sprints.

Their initial story board looks like this (and can be publicly accessed here on trello):

Feverbank

Background

Feverbank is a small but fast growing online bank. Feverbank is focused on providing services through online services and as such is largely a software oriented organization. It has a renewed focus on security due to one of its competitors being involved in a recent highly publicized breach. Being primarily in the financial services space, it has had requisite penetration tests of its customer facing banking portal, but it is concerned about other attack vectors and wants to practice better defense in depth using appropriate tools.

Agile Approach

Feverbank is highly motivated to improve their security quickly, but they are anxious about moving too fast and spending money on projects that don't make sense. They are quick to assemble a team representing IT, Engineering, Finance, HR and other important organizational groups. They agree to meet every day for a standup and to make their sprint duration two weeks. The following represents the work they want to commit to for the first Sprint.

Their initial story board looks like this (and can be publicly accessed here on trello):

BioBrack

Background

BioBrack is a global biotech company with complex enterprise infrastructure. Although they do process financial data, the intellectual property and clinical study data they have is a focus for their security efforts. Their interest in security has increased with FBI reports that private companies have lost billions of dollars through IP that was stolen through computer systems. They think APT is a protein. They have large coffers of cash to spend on the problem.

Agile Approach

BioBrack starts by gathering a security team and tasking IT with identifying technologies that can help them protect their IP. They agree to meet when IT has a short list of items to consider purchasing and vendors selected.

Their initial story board looks like this (and can be publicly accessed here on trello):

Next Steps

In the next installment, we'll talk more about Agile and see what happens next in each of these case studies. They may be simple now, but they are already showing good and bad signs. Can you identify where the focus is in line with the agile process?