How to establish security controls

From an organizational point of view, a perimeter-based security model is easy to establish and maintain: a dedicated team is responsible for security controls. It is the team's duty to maintain the configuration, oversee the activities and take all required actions to operate the security devices.

With DevSecOps or Zero-Trust, such a model is difficult or impossible to maintain. Either there is no longer a classic perimeter, or delaying updates to security controls results in obstacles to the rollout of new product versions due to the speed of the project.

DevSecOps aims to integrate security into every stage of the software development lifecycle, package the software with security controls, and roll them out. Security no longer is an obstacle but a first-class citizen enabling quick but secure deployments.

While this sounds good in general, it also means that responsibilities must be handed over to the software developers as they must implement security controls early. This goes against the old adage that security must be handled by trained personnel only. However, there are undeniable advantages to involving the application developers in implementing security rules: they have in-depth knowledge about the application and easily understand the most problematic areas. Your existing, dedicated security team becomes the guardian of the overall level of security in accordance with compliance requirements. This dedicated team prescribes the guidelines and oversees what security controls are in place. Ideally, your operating platform automatically enforces adherence to these rules.

0. With DevSecOps, two types of teams are required:
1. A dedicated security team that is responsible for
• security controls.
• training of project team members.
• oversight of what security controls are in place.
• maintaining and implementing the newest security features of Airlock Microgateway.
2. Trained project teams that can implement security controls to secure web applications into every stage of the development lifecycle.

The tasks listed here must be addressed and defined company-wide by the dedicated security team.

Enabling project teams to secure web applications by creating templates and guidelines and educating the project team members is required. It is also required to ensure that insecure setups from the development stages are not moved unintentionally into production.
Besides that, templates also have a lifecycle – new security features may become available in newer Airlock Microgateway versions or security assessments change over time and influence the templates' contents.

DevSecOps aims to integrate security into every stage of the software development lifecycle. Software development team members must understand security risks and configure security controls (unlike in a classic security perimeter solution). These tasks require empowerment by the security team.

The security team accomplishes the following tasks :

It is hard to correctly implement such blueprints and templates without experience. We recommend to establish channels and processes for project members to ask for guidance and consultancy to assist them in their daily business.

It is best practice to deploy web applications in stages.
Starting in the Development stage, where new versions of the web application are developed, also perform integration with Airlock Microgateway and testing. Later stages, such as the Integration environment, expand on the number of integrated components and focus on ever broader aspects for testing, until you reach Production.
Next to stage-specific settings it is important to define the relevant policies.

The company-wide framework frees project teams from repetitious definition of common security guidelines, instead allowing them to focus on their project plans knowing that the basics have been taken care of.
The different project phases are illustrated in the graphic below and show that security is part of each phase.

In this phase, the above-mentioned communication channel between DevSecOps and security teams is essential to incorporate feedback, for example on exceptions and update requirements.

Shift left is the practice of integrating security, quality and performance in an earlier stage of the development lifecycle. Traditionally, security testing and validation activities are performed at the end of the development cycle, after the application has been built.
However, this approach can result in security vulnerabilities being discovered late, making them more expensive and time-consuming to fix. By shifting left, security testing, integration of security solutions and validation activities are part of the development process at an earlier stage, such as during code development, code review, and automated testing.
This approach enables developers to identify and fix security issues earlier in the development cycle. It effectively reduces the risk of security vulnerabilities being introduced into the final product or postponing the going life because of known security issues.

Shield right is the practice of ongoing monitoring and protection of applications and systems after they have been deployed to production. While shift left focuses on integrating security into the development process from the very beginning, shield right describes the ongoing efforts to protect the application or system in production from attacks and vulnerabilities.
To achieve shield right, organizations may use a variety of tools and techniques. This includes security information and event management (SIEM) tools, intrusion detection and prevention systems, Web Application and API Protection (WAAP) and Identity and Access Management (IAM) with 2FA for strong authentication as well as incident response plans.
The goal is to create a comprehensive and adaptive security posture to detect and respond to threats in real-time.

Shift left and Shield right complement each other to provide comprehensive application protection at all stages of the software development lifecycle. Airlock Microgateway can help to close the gap between the two initiatives: It allows to integrate runtime protection already at development or build time.