Turning security assumptions around and have them work for you in agile.

While agile development is going mainstream, information security is having difficulties to keep pace. The result of this struggle is that new systems are insecure, or that they are loaded with point solutions for security. What is so hard about security in Agile environments? In the previous article, we deducted four assumptions that are at the heart of the problem. In this follow-up article, we propose the ASEM model to help fit information security in the agile development process.

To be able to address the bottlenecks that were mentioned in the previous article, the authors propose a new model, the Agile Security Engagement Model (ASEM) that helps to address security in agile projects.

Important characteristics of the ASEM are:

• All choices are risk-driven:
  • There is no such thing as 100% secure and we don’t aim for that;
• Security is facilitating the development process and provides security solutions:
  • Just setting requirements is not the way to go. They need to be mapped to useful solutions that can be implemented by the agile team. A security services catalog supports that;
• The security policy exists of sub-policies that address specific issues:
  • The days of an 80-pager security policy are over. The security policy should be cut up into a policy framework that contains pieces of the policy that are relevant for specific processes and understandable for users;
• Security monitoring is independent of the development process:
  • If keeping up with the development planning is impossible, then don’t try to synchronize with project planning at all.

An overview of the ASEM is given in the following diagram. Each part of it is worked out in a separate paragraph.

A. Add security expertise to the development team

It starts with people. Make sure that at least some understanding of security is present in the dev/ops team, making it a Dev/Ops/Sec-team.

Very often, organizations perceive security as a tollgate that should be passed at the beginning and the end of a project. In the ASEM model, security is added to the stream and enables the team to adapt to the risks they assess. This requires another kind of security specialist, one that has technical expertise and development skills

B. Add security-related user stories to the backlog

The security objectives are derived from business drivers, security risks, and compliance duties. The security objectives or measures should be described in user-stories and be added to the backlog. Dedicated user stories can be like the:

• As a customer, I want to be sure that the credit card data that I provide for payments are processed and stored securely so that access by third parties or hackers is impossible.

The other option is to extend user stories with assurance requirements like this:

• As a supplier I want to be able to provide this server, guaranteeing the confidentiality and integrity of the user data.

C. Analyze the risks

A quick risk assessment should be done in each sprint to assess the priorities and urgency of security risks on the backlog. This way, risk assessment is integrated into the cycle and the backlog functions as a risk register during the development.

D. Provide security building blocks

Security building blocks are ready-to-use services, policies, configurations and processes that help to make the product secure, which speed up the development and guarantee the required security level.

Security management should maintain this catalog based on the demand of the organization.

An example of a Security Services Landscape.

E. Integrate automated security tests in daily automated testing

Perform automated security testing during the development process, to safeguard the security level of the developed product.

These tests include source code analysis, OWASP verification, and checks on system hardening.

F. Add security to Definition of Done

The Definition of Done (DoD) exists for both the sprint and the release-level.

For a Sprint, it should contain the security controls that are in place to assess the selected risks. For a release, the requirements from the definition of ready should be fulfilled.

G. Independent continuous monitoring and testing

This is an independent operational process that observes what comes alive at the network or system and tests these new additions in a continuous mode.

Security testing can thus be embedded in the continuous delivery model that is part of agile.

This article is the second in a series written by the authors to explore the options for embedding information security into an agile development strategy.

PECB

Matching Information Security in Agile environments is coming down to being a necessary requirement. Thus, we must give significant importance to the implementation of various Information Security frameworks. Likewise, implementing ISO 27001 in agile environments will certainly increase your organization’s likelihood of success. Harmoniously, PECB is pleased to offer you with thorough training on effective implementation while certifying you in ISO 27001. Check the PECB Information Security here.

Co-Authored By:

Pascal de Koning, a highly skilled professional on Information Security, Security Architecture, Software Development, PCI DSS, Identity Management, TOGAF, Network Security, Integration, Business Continuity, and IAM. As a Chairman of Security Services Catalogue project supported by OSA and a Chairman of the TOGAF-SABSA integration project at KPN Telecommunications, his expertise becomes of great value to provide.