Microservices Transformed DevOps — Why Security Is Next – InApps Technology 2022

Microservices fundamentally changed the way we build modern applications. Before microservices, engineers had a small number of huge chunks of code that made up their application. Many apps were a single monolith of code, and some might have been broken out into a frontend, backend and database. So, when a team needed to update or patch their code, they had to do it slowly and with great care because any change to any part affected every other part of their app.

In contrast, microservices break that same application into tens or hundreds of small individual pieces of software that address discrete functions and work together via separate APIs. A microservices-based approach enables teams to update those individual pieces of software separately, without having to touch each part of the application.

Development teams can move much more quickly and software updates can happen much more frequently because releases are smaller. This shift in the way applications are built and updated has created a second movement/change: how software teams function and work. In this modern environment, software teams are responsible for smaller pieces of code that address a function within the app. For example, let’s say a pizza company has one team (Team 1) solely focused on the software around ordering and another (Team 2) on the tracking feature of a customer’s delivery. If there is an update to the ordering function, it shouldn’t affect the work that Team 2 is doing. A microservices-based architecture is not only changing how software is created, but also changing the way teams interact and work together.

A Shift in Mindset

As microservices become more adopted and the de facto approach to building modern applications, there needs to be a similar shift in the way compliance and security teams operate. The complex nature of modern applications introduces new risks and challenges, despite the advantages that service-based architectures provide. There’s the complex nature of modern applications — composed of multiple microservices, housed in containers — and then there’s the dynamic nature of platforms like Kubernetes running those applications. Everything, from the cloud on up is delivered “as code” and managed via the software development life cycle. This is ideal for developers because this fits their culture of work, which is reinforced with new asynchronous tools and processes, enabling them to be more effective and collaborative across teams. Of course, these new DevOps processes and related tools haven’t yet made their way to other teams in organizations yet; security teams, for example, don’t work within the same new culture, tools or processes.

This challenge is especially true for organizations that have been running applications securely on premises for decades. As an extreme example: When everything was on-prem, if there was a security breach, IT could physically isolate affected systems if need be. More likely they would log on to specific systems (firewalls, switches, proxies, anti-malware or the hosts themselves) and make changes to minimize blast radius and eliminate threats. It’s more than just disconnecting networking cables, but it still is work done on physical systems, exposed via interfaces purpose built for security teams.

However, in a modern breach, the paradigm is different. Everything is “ephemeral” and can be replaced in seconds. Systems are connected via software-based rules, and graphical interfaces are fewer and farther between. It’s a significant paradigm shift, and it’s understandable that security teams would be uncomfortable with the idea at first. However, as security and compliance teams learn more about cloud native technologies and security tools, we will begin to see a shift in mindset. With this shift, security teams can move to near-instant remediation, patching and threat isolation/elimination, the same way that developers update feature code. With multiple code pushes per day and short-lived services, the attack surface may grow, but the threat window shrinks dramatically, improving overall security posture. The benefits are very real, but like everything, the switch just takes time.

Security Teams Should Start Embracing Microservices

There are a few steps that compliance and security folks can take to help them on their microservices journey. And, like most things in the cloud native space, a community approach is best. They’ll need vendors, regulatory players, analysts, cloud providers and end users/developers to help:

• Lean in to the existing support systems. The cloud vendors have done a good job of learning best practices from the countless deployments running on their platforms. Many of them have high-touch services, where they will work directly with teams to ensure that the architecture, deployment and security is set up to be successful from the outset. They also have tons of guides, presentations, blogs and more to help security architects make the right choices to meet particular, and varied, needs. Take advantage of the knowledge out there from the people and teams who have already gone through it.
• Ask existing compliance vendors to provide frameworks for the cloud. Good compliance vendors, and the right kind of auditors, will have experience with best practices and even public frameworks like MITRE, CIS Benchmarks and others — which they will have already mapped to cloud and software-defined infrastructure. Push for help from them, and if they don’t have answers, look for ones that do. Compliance consultants should be able to provide proven recommendations for how to implement cloud native technologies securely, at least as a baseline — to make deployment clearer and ease subsequent audits down the road.
• Look to the open source community. Open source and security haven’t always been part of the same conversation, but today they go hand in hand. Find the Slack communities, Discord boards, and even meetups to attend where the most innovative and experienced cloud developers are presenting best practices — typically these will be centered around key open source projects and their communities. Envoy, Falco, SPIFFE/Spire and Open Policy Agent all have thriving communities with proven security implementations under their belts.
• Push analysts for more. The analyst community has been a huge part of helping to select and deploy security for decades — but not every firm has yet had a strong focus on cloud native and microservices-based security research. Reach out to see what exists now, but don’t be shy about asking for more in some cases. Analysts can unlock real value, but only if their clients drive them to areas that need insights — and we are only at the beginning of the vast amount of research that will be provided on cloud migration. Push to find the right folks, with the right experience within trusted firms. They’re in there, and need support and inquiries to justify their research.

Perhaps more than any other huge application technology shift of the past, this next evolution to microservices-based architecture is one that’s based on community. The good news is that the developer and open source teams have paved the way, and established a good foundation of culture and process — always the most important part of any business shift. The best practices are well proven, the benefits are clear, and the pioneers have already made the shift. Now all that is needed is to allow a little time to learn, trust and implement a new way of security applications.

List of Keywords users find our article on Google: