Protect – how is the System Secured?

What Can I Expect from this Stop?

The following topics are included in the Protect stopover:

A common problem in software development is that security-relevant activities are postponed until the testing phase. Often until a relatively late phase of the Software Development Lifecycle (SDLC), in which a large part of the critical design and implementation processes have already been completed.

Problems discovered in this late phase of the SDLC process often lead to delays in production. At this point, problems are more time-consuming and expensive to fix because they may require redevelopment and retesting.

The implementation of effective security processes requires a “Shift Left” from the teams, whereby security concerns must be taken into account in all phases of the SDLC, from the beginning to the end of the implementation project. An approach that follows this paradigm is called a Secure Software Development Lifecycle (SSDLC).

That sounds quite simple in theory, but it is a major challenge in practice. Above all, the additional cognitive load that is placed on development teams is enormous, as not every developer is automatically a security expert.

To actually achieve the “Shift Left” of security topics, it is necessary to introduce them iteratively and in small steps and, on the other hand, to provide appropriate tooling that optimally supports the teams (e.g. Snyk).

Why should I Stop at this Stop?

Secure software systems and processes help to minimize the risks of data being manipulated or stolen. This in turn strengthens trust in the software system, but also in the company itself. Especially trust is usually decisive for whether a company is successful in the long term. And loss of trust occurs faster than trust can be built.

As already described, the costs often increase exponentially at the time within the software lifecycle when a problem is found. It is therefore essential to identify and fix any problems as early as possible.

Another point that should not be ignored is compliance with regulatory requirements, which of course can also include security-relevant characteristics. Failure to comply with these can lead to negative consequences for the entire company.

How Does this Stop Work?

With the OWASP Security Culture, the OWASP offers a framework for the introduction of security processes into the development process. As already mentioned at the beginning, however, the introduction of these concepts generates additional cognitive load within a DevOps team.

This means that the DevOps teams need a lot of support, especially at the start of the introduction. This is where the ideas from Team Topologies come into play in order to further develop the DevOps teams into DevSecOps teams.

Security-focused enabling teams provide support by carefully introducing the security champions within the DevSecOps team to the task. This also changes the focus of security teams. They no longer ensure security aspects at the end of a development cycle, but actively work with them and thus become “enablers” instead of “security gatekeepers” from the developer’s point of view.

In order for a company-wide exchange of all employees with a focus on security to take place, the establishment of a “Community of Security Practice” is a good idea. This community serves to exchange knowledge, but also to iteratively and continuously develop the SSDLC or security guidelines/specifications.

In order to deepen this stopover even further, in the next posts we will describe how Snyk as a tool helps to create a “Shift Left” of security topics and, on the other hand, how the topics Secrets & Certificates State-of-the-Art are covered by HashiCorp Vault.

Finally, we would like to point out a post on the topic of Service Mesh:

> To the article

This post discusses how a Zero-Trust approach can be implemented using a service mesh and mutual authentication 😎.