DevSecOps – how to make your DevOps Secure using Microgateways

In a world where software is gaining ever more importance, a company's success hinges on how quickly services can be developed and rolled out. This means that today, the decisive factor is how well a company understands its target group. This is the only way to serve customer needs more effectively and to be faster than the competition. Of course, the security of the services offered cannot be overlooked. All this calls for DevSecOps. In this blog post, we will show you how to implement this in practice.

In a world that is increasingly digital and software-based, a business's success depends on how quickly (and securely) services can be developed and delivered. We demonstrated this to you last week. DevOps plays an important role in this. DevOps represents a culture of cross-functional, collaborative cooperation. Something that sounds so simple is actually a fundamental “mind shift”, because historically, development and operations have been pursuing different goals:

• Software development needs to be agile, creative and at the cutting edge of technology to be
  able to constantly deliver new features.
• In contrast, IT Operations is designed to be stable, secure and reliable.

DevOps reconciles this apparent contradiction between flexibility and stability. To achieve this, the entire value chain, from software development to operations, is combined in an interdisciplinary way. This breaks down silo thinking by bridging the gaps between silos, and orients the organisation towards the shared goal of delivering new functions quickly and in stable, secure steps. In this blog we want to show you how to achieve this.

From DevOps to DevSecOps – what's hiding behind it?

So let's start right at the beginning. Traditionally, security has been a “gatekeeper” to complete software development, much like operations before DevOps. The “Sec” in “DevSecOps” is the phrase that makes the collaboration and the shift in responsibility explicit. In DevSecOps culture, every agile team has a security expert. This person fulfils non-functional requirements (like data classification and other parts of risk analysis) to ensure that, in the development plan, the product owner also takes security into account. This proactive approach means that teams take overall responsibility for the scope of their services. Furthermore, when security is coupled with product development and done out of sync, it allows the product owner to manage speed and security without sacrificing either. That's why agile development also needs agile infrastructures and agile security.

The way in which software is protected against external and internal threats is evolving in response to the threat environment we are facing. The most recent step in this evolutionary chain is the move towards zero-trust architectures. As you know, the rationale behind perimeter security architectures is to separate a non-secure external network from a secure internal network. All traffic is inspected at the perimeter and the potentially dangerous traffic is blocked. With zero-trust architectures, inspection and blocking are shifted away from the perimeter directly to the services themselves. To put it another way: each service inspects its own traffic and only authorises the traffic that it has identified as being secure. This obviously reduces the complexity of the security system and makes it more manageable. Implementing zero-trust architecture therefore requires technology that is similar to what is used at the perimeter, but in a smaller and more resource-efficient version. This is where the idea of the microgateway originated.

The Microgateway as an Enabler for DevSecOps

However, the switch to zero-trust architecture is not going to happen overnight. It sounds much more complicated than it actually is, but the transition to zero-trust can be done gradually.

The inherent strength of zero-trust lies in its ability to distribute and scale resource development, process flows and security, but this is also its weakness because not everything can be shared out as easily. One of these functions is Identity and Access Management (IAM). The best way to achieve a seamless single sign-on user experience is by using central authentication and identity management services. The edge gateway acts as the policy enforcement point, with the actual decisions being made by the IAM service. The identity information checks and user authorisation are carried out by the individual services.

Illustration: Zero-trust architecture with Edge & Microgateway

The central gateway remains important

Putting an edge gateway in front of the micro gateways is not a technical requirement. It is a design decision based on the fact that it is better to implement some tasks on an edge-oriented device, whereas others need to be closely connected to the respective service. This is why the edge-oriented gateway has a more generic configuration that enables fast, seamless integration of new services protected by microgateway instances.

The Microgateway changes DevOps into DevSecOps teams

Conversely, typical integration tasks like adding rule exceptions and URL rewriting are done on the microgateway. The gateway represents a lean security component that protects a specific service. Zero-trust architecture also ensures that each service not only protects itself against unwanted traffic, but validates each request to guarantee that only correctly authenticated users have access to the services and data for which they have received authorisation. The decision to open a service or application to the outside world can still be made at the perimeter.

The microgateway is managed by the protected service's DevOps team and provides various kinds of assistance:

• Agility:
  A number of independent development teams benefit from the existing infrastructure. The microgateway configuration is maintained by the development team, so a new service release requires little to no coordination with the gateway administrator.
• Scalability and availability:
  Microgateways are deployed directly with their services and they scale up with them. The microgateway functions ensure that session information is made available, regardless of which microgateway instance is handling the request.
• Time to market:
  Microgateways impose authentication before granting access to the service. This eliminates the need to build these features into each individual service. These critical security tasks are handled by the standardised infrastructure component, so developers can spend more time focusing on business features.
• Bespoke security:
  Microgateways have a very small footprint, which enables developers to use them throughout the development process. This means that the service works with microgateways and this allows the developer to configure the filtering rules to achieve optimal security. Integration errors and security issues are detected at a much earlier stage in the development cycle, long before the service goes live.

Therefore, microgateways are an important tool for assisting DevOps teams on their way to implementing zero-trust architectures and thereby becoming DevSecOps teams.

Implement DevSecOps efficiently with Airlock

In a detailed whitepaper, our partner Airlock has collected the most important insights into how to successfully and efficiently implement DevSecOps, what security components are needed for this and what advantages a microgateway architecture can bring.

The Airlock-Portfolio includes both a microgateway and an edge gateway, making it the ideal partner for transforming DevOps into DevSecOps teams. Contact our experts if you would like to learn more about DevSecOps, Zero Trust or Airlock's products – which, by the way, are also available from InfoGuard as a managed WAF-as-a-Service . We would be pleased to accompany you on the journey to DevSecOps.