Being an Agile Security Officer: pwn the process

This is the third part of my 'Being an Agile Security Officer series'. As mentioned in my previous blog, in the Agile world the Product Owner is the person who translates business and customer desires into work items for the teams. To do this, product owners have several techniques and means at their disposal. In this blog I will focus on the backlog and the definition of done. As a security officer it's important to understand their purpose and to learn how they can help you achieve your goals.

Align with the process

As I mentioned in my previous blog categorizing requirements will help to minimize the workload on the teams. From a development perspective information security requirements can be categorized into 4 categories:

Out of scope: these are typically requirements where IT is not involved in like e.g. physical security, background checks on new hires, and fiscal compliance. Agile teams should normally not have to worry about these items as they are handled by processes outside of development. Procedural requirements; these are requirements that IT teams should comply with, but are not linked to development. Examples are BYOD policies, information classification & handling, and separation of duties. Usually these requirements are handled by on-boarding processes, awareness programs, and organizational processes. Generic requirements; requirements that are in scope of development and that should always be applied.Typically these are the 'non negotiable requirements' that form the security baseline. Examples are maintaining a CMDB, applying risk assessments, and apply cryptography standards. Specific requirements; requirements that are related to the actual development user story. These requirements are conditional and depend on the actual development. For example when a new form is being developed, the user input should be validated.

An agile security officer should split up the information security policy and make sure that development only has to worry about the last two categories. Identifying the first two categories is usually not the hardest part and often these are already backed by existing processes and procedures. The hard part is deciding which requirements are generic and which are specific. Generic requirements should be requirements that are always applicable, regardless of the actual development. These items should be placed on the Definition of Done. Specific requirements are requirements that are linked to the user stories in the sprint. An often seen error is placing too many requirements in the generic category. This will fail as it will result in teams having to go through it every sprint, which will take to much time and will ultimately lead to a situation where security will be ignored.

Definition of Done The definition of done is a crucial step in the SCRUM way of working. However, the actual contents are different among teams and companies. In essence the definition of the scrum alliance [1] covers the idea pretty well:

Definition of Done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.

The problem with this definition is that it seems to focus on the work being done, not the desired state of the increment. It also describes how full integration is only achieved at the system demo at the end of the sprint, which seems to indicate that the full extent of done is only achieved once every sprint. This poses a problem for security requirements as we want these to be taken into consideration continuously, and not just being checked in the end.

The scaled agile framework [2] attempts to improve that by defining different Definitions of Done on various levels. Scaled Scrum stresses that teams should strive to integrate more often and to make sure they have at least one integrated releasable increment every sprint, even at scale.

As a Security stakeholder it is therefore important to understand how the Definition of Done is being used in your teams approach of Agile so you can add security items in a way the is exactly right, for you, for now...

Regardless of the actual use of the definition of done, items that would make sense to place on it are:

There should be no open critical and high risk items identified by SAST and DAST scans All exceptions should be approved by the security stakeholder All applied cryptography should be implemented according to cryptography guidelines The backlog

The product backlog is a list of desired features, bug fixes, non-functional requirements, etc needed to successfully deliver a viable product. The Product Owner prioritizes the backlog based on considerations such as risk, business value, dependencies, and date needed. In Scrum, work is typically expressed as user stories. User stories start their live as high level ideas called epics. Since an epic is generally too large for an agile team to complete in one sprint, it is split into multiple smaller user stories before it is worked on. User stories can be written in various ways but usually are written from the perspective of the goal. A common format to define user stories is the following:

As a <type of user>, I want <some goal> so that <some reason>.

Once a product backlog item is sufficiently detailed to be called a user story and it has been given priority it will be moved to the sprint backlog. The sprint backlog contains all the user stories that a team will finish in a single sprint.

User Story Requirements Besides the goal, user stories also contain the requirements applicable for the solution [3]. It's important to realize that these requirements should preferably describe what the solution should achieve and not describe the solution itself. For security stakeholders these requirements are the most important as you can link the relevant requirements to these user stories. This way you minimize the work for the teams, which is the goal we're trying to achieve.

Some examples are of user story requirements would be:

When a customer provides his details, a secure communication channel should be used Customer details should be stored in a secure location Financial transactions should be registered in the general ledger Credit card details should be destroyed after payment

Helping a Product Owner to identify all the relevant requirements can be time consuming. Security stakeholders should therefor (help) develop tools to identify these requirements more easily. We will go deeper into the process of creating and improving user stories in the next blog.

Other parts in this blog series

Part 1: Being an Agile Security Officer

Part 2: The Security Stakeholder Mindset

Links

[1] https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod)