Empower your counterpart

The main aim of DevSecOps is to integrate security into every stage of the software development lifecycle. While this sounds good in general, it also means that responsibilities must be handed over to the software developers. It is still the security team's duty to take care of the organization's security but the settings are made by other teams as well. Shared responsibility is in place!
What needs to be done from an organizational perspective to minimize the effort for the developers to integrate a web application and, at the same time, ensure that certain security controls are configured is outlined here.

This article gives an overview of common tasks while subchapters explain a specific topic.

One of the first things that must be accomplished is to define the high-level architecture as described in System architecture. Each architecture has its benefits and directly influences how policies can be enforced, how blueprints look like and what should be part of a Microgateway configuration template.

Afterward, Blueprints should be created. They describe what a web application can expect from the upfront security components. E.g. that the traffic is filtered, the users are authenticated and their identity is propagated in a JWT.

Knowing what the architecture looks like, you can start identifying security settings.

The objective of identifying security settings is to later apply the required measurements and ensure that particular settings are enabled in production.

• Possible sources for security settings:
• Regulatory compliance.
• The Company's desired security risk level that is also reflected in the blueprint.
• Current attack vectors (e.g. Log4Shell, ...).
• Feedback from pen tests.
• The functionality of the security components.

It might be obvious that these sources change over time and must be re-evaluated as well as some of them might be optional while others are mandatory.

By going through the settings Airlock Microgateway provides, candidates for configuration templates can be identified.

• Sources for Airlock Microgateway settings:
• Consider the Airlock Microgateway manual.
• Go through the Airlock Microgateway CustomResourceDefinition with kubectl explain.

Depending if a certain security setting is mandatory or not it should be part of a policy and enforced or in a template and facultative.

After identifying the settings that should be configured, either mandatory or optional, the required actions could take place.

As mentioned in Identify security settings, the settings might change over time and must be re-evaluated.

• Therefore, it is crucial to do the following:
• Identify the team responsible for maintaining the templates, policies and guidelines and communicate that.
• Oversee the active configurations, which violate policies or do not follow guidelines.
• Incorporate new findings from development or operation into new versions of these resources (templates, policies, guidelines).
• Re-evaluate if the policies differ in context (e.g. development stage vs. production).

Enabling your counterpart with templates reduces the time to integrate a web application. Policies ensure that unwanted settings are not staged accidentally to production. Nevertheless, do not forget to educate your counterparts to use these resources accordingly.

Templates, policies, guidelines and education already help ensure that only the desired configuration is staged for production. In order to establish a config review, it could make sense to establish a GitOps process. This way, mistakes that might be difficult to identify by tools can be mitigated by humans.