For around three years now, a noticeable paradigm shift has been observed in software development: Instead of the waterfall model, agile development methods are now used – often combined with DevOps approaches. In IT security, this development is also changing the working models of IT security experts. In the past, the goals of a software development process were defined relatively early on using specialist concepts.
Still, today the functions of the planned software product can change until shortly before it goes live. As a result, many security requirements have to be developed dynamically and parallel to the agile sprints. What does this development mean in concrete terms for the tasks and work areas of the IT security officers? Msg gives five tips for agile security.
Table of Contents
Exchange Of Knowledge Among All Stakeholders
All stakeholders – security teams, developers, operations and specialist departments – must be involved in the projects from the start to guarantee and continuously maintain knowledge exchange among all those involved. For example, when setting up a system architecture, developers should involve the security expert at the start of the project to compare the security requirements with the proposed solution and immediately discover fundamental weaknesses. He can then define the necessary measures to ensure the safety of the project.
The Role Of The Application Security Expert
The roles in the software development process have changed, not least due to agile process methods: An application security expert should now support the projects and processes holistically as a coach. This means that his field of work encompasses more than just writing and setting up security concepts.
He controls the entire process and brings his knowledge to the team. In addition, the role of the application security expert does not end with the end of the project. His expertise will also be needed after the go-live. That this development makes sense is also proven because a product continues to develop even after it has gone live for the first time.
Security User Stories For Security Requirements
In agile software development, security requirements can be addressed or planned using security user stories. In this way, a general overview of the tasks of the security expert becomes clear, and they also promote cooperation and creativity.
The security expert should be actively involved in creating the security user stories and informing software developers about missing scenarios. It is also his responsibility to determine if the person responsible for the product does not plan and carry out a security user story, although it would be necessary. For this reason, the organization should be built so that any suspected deficiencies can be escalated to the responsible central security organization.
At the end of the security user story development, documentation of the relevant security requirements and the technical processes must be created. Because the user stories covered the most important aspects, the development team addressed the relevant scenarios.
Penetration Tests For Security Testing
Penetration tests before use in production (“go-live”) serve to verify whether security requirements have been adequately taken into account. In this way, technical weaknesses can be discovered and remedied.
Automated static code analysis in the CI / CD cycle should be standard. They enable the experts to deal with the results of the source code analyzes right from the start, and recognize errors automatically. Therefore, after the initial go-live, especially in the DevOps model, the question arises when further penetration tests should be planned. Since tests are usually associated with a lot of effort, it is important to determine when they will be carried out in advance.
Tests before going live, annually recurring tests or tests on risk-based occasions, such as criticality tests for software changes, are possible here. Fully automated dynamic security checks that are repeated cyclically and reveal weak points promptly would be desirable.
Company-Wide Security Requirements And Architecture Specifications
Fundamental security requirements are known throughout the organization, such as checklists or guidelines that provide basic protection, remain necessary. It is important to check and approve sample solutions that are used company-wide and the provision of security components for cross-product use. Otherwise, especially in larger organizations, the support by security experts becomes very time-consuming or isolated solutions result, which would have to be constantly reassessed in terms of security. This ties up an unnecessarily large amount of resources.