Back to Newsroom

16/06/2020

A noticeable paradigm shift has been seen in software development over the course of about the past three years or so: the waterfall model has been replaced with agile development methods – often in combination with DevOps approaches. In the field of IT security, this development has also changed which work models IT security experts employ. Whereas the goals of the software development process used to be defined relatively early on using technical specifications, now the functions of a planned software product can continue to change until shortly before go-live. Consequently, many security requirements now have to be dynamically developed parallel to agile sprints. What exactly does this development mean for an IT security officer’s tasks and responsibilities? msg offers five tips for agile security.

1. Exchange of know-how between all stakeholders

All stakeholders – whether security teams, developers, operations or business units – must be involved in projects from the very beginning to ensure know-how is exchanged between everyone involved and is also continuously maintained. When developers set up a system architecture, for example, they should involve security experts in the project right from the start as that allows the security experts to compare the security requirements to the proposed solution and immediately detect any fundamental vulnerabilities. Necessary measures can then be defined, thereby ensuring the security of the project.

2. The role of the application security expert

The roles in the software development process have also changed, in part due to agile process methods: today, an application security expert is there to guide projects and processes as a whole, in more of a coaching role. As a result, their responsibilities cover more than just writing and drafting security concepts. They steer the entire process and share their know-how with the team. Furthermore, the role of the application security expert does not end with the project. Instead, their expertise is required long after go-live. This development makes sense and is underscored by the fact that product development continues even after a product has gone live.

3. Security user stories for security requirements

In agile software development, security requirements are addressed and scheduled using so-called “security user stories”. The user stories provide a clear overview of all of the security expert’s tasks, while also promoting collaboration and creativity. Security experts should be actively involved in the creation of the security user stories and should alert software developers to any missing scenarios. This also means they are responsible for pointing out when a product owner has failed to schedule and execute a security user story, even though the user story is necessary. For that reason, the organization should be designed to allow suspected defects to be escalated to the appropriate central security organization. Upon conclusion of the security user story development, the relevant security requirements and functional processes are documented. With the user stories covering the key aspects, the relevant scenarios will have been address by the development team as well.

4. Penetration tests for the security audit

Penetration tests conducted before live use (“go-live”) serve to verify whether the security requirements have been adequately provided for. For example, they allow any technical vulnerabilities to be identified and eliminated.

Automated static code analysis using a CI/CD cycle should be standard as it permits experts to address the results of source code analysis from the outset and automatically detect errors. This raises the question, especially with the DevOps model, of when further penetration tests should be scheduled after the initial go-live. Since testing usually involves considerable effort, it is important to define in advance when the tests should be performed. Potential options include testing before a go-live, annually recurring tests or even tests triggered by risk-based incidents, such as criticality tests following software modifications. Ideally, fully-automated dynamic software tests would be performed that repeat cyclically and quickly detect vulnerabilities. However, the reality looks somewhat different at the moment, since most dynamic penetration tests still have to be performed manually.

5. Company-wide security requirements and architectural specifications 

Basic security requirements that are well known throughout an organization, such as checklists and policies, and that provide basic protection remain necessary. The review and release of sample solutions that can be used throughout a company are important, as is the provision of security components for cross-product use. Failure to do so can cause the support provided by security experts to become extremely time-consuming, especially in larger organizations, or it can result in insular solutions that have to be constantly evaluated and re-evaluated simply to ensure security. All of which would, of course, tie up considerable resources unnecessarily.