Do All the Things

IT folks face a grand challenge. They’re being pushed more than ever to secure more services faster, with fewer resources. Applications are now more critical than ever. And apps now need to be available 24×7 everywhere. On top of that, they need to be more responsive to changes, faster, and able to share and collaborate with others. Throughout all this, they must still maintain resiliency and security. It’s a tough challenge.

Two new ways IT shops are tackling these big changes include:

1. Switching development processes to more agile and flexible processes like DevSecOps, and
2. Transitioning away from large monolithic applications to smaller, adaptable microservices.

On top of all this, the cybersecurity team needs to ensure that security and compliance requirements are upheld. So how do they do this? Let’s dig in.

What is DevSecOps?

DevSecOps is a software development methodology with coders, cybersecurity personnel, and sys admins (ops) all working together on the same project. The approach can be seen as a faster, cheaper, and more effective way to produce secure software. Traditionally, these processes were separate, run by different teams, and often under different management silos. In DevSecOps, the participants all work together; either on the same team or by combining team members. By closing the gaps, the organization can deploy applications and services faster with more stability and better security.

DevSecOps Advantages

DevSecOps splits up large security processes into smaller, defined steps on nearly every step of the development path. This makes automation of smaller, repetitive tasks easier and more efficient. The “Ops” refers to the always-moving assembly line from the programmers to live applications. Instead of the security team bouncing insecure code back to the developers at the end, security problems are addressed earlier in the process; closer to when the issues originated. This improves education (and prevention of future problems). With security truly part of everyone’s job, there is hopefully a lot less finger pointing. As they say, many hands make light work.

Security and Compliance Challenges of DevSecOps

DevSecOps is powerful, but it also means new skills (and training), new processes (and tools), and a new level of collaboration. One of the big challenges is orchestrating all of this securely. How do you protect the development pipeline to make sure the code changes have been properly tested and the right version moves towards the finish line? There’s also the challenge of assigning and tracking access privileges among a lot of people. These same people have the ability to run code where confidential data and critical transactions reside. The DevSecOps process has to have enforcement tools to ensure only properly tested changes are posted to production systems.

Breaking Applications into Microservices

Even more challenging is the growing use of microservices for application delivery. Traditionally, applications were giant blocks of code, sometimes called monolithic apps. Microservices look more like a swarm of smaller services, which become the “app.” What used to be a library of subfunctions within a large app’s codebase is now a separate stand-alone service, usually accessed via an API. An online shopping web application in microservices is a collection of microservices for shopping carts, pricing information, inventory, customer chat, customer reviews, graphics, payment processing, sales tax, analytics, and sending tickets to the shipping warehouse. If you needed a new app for online video delivery, for example, you could grab some of those previously used microservices and add streaming servers and a video library.

Advantages of Microservices

One powerful tool in the microservice arsenal is the ability to silently replace a monolithic app running in place. The new microservice app acts as a new front end for the users, and any legacy services that haven’t been replaced yet are called via proxy from the old app. Meanwhile, the user is unaware of which system they are interacting with, as their experience is the same as the old system. It’s akin to rebuilding an airplane while in mid-flight. It’s called the “strangler pattern” because the microservices’ deployment slowly strangles the old app.

Another advantage of microservices is that applications can be built in a hybrid manner, integrating external services. For example, an internally developed vehicle-tracking microservice can pull in weather data from an external SaaS. Conversely, services can be pushed out externally. At the same time, you could offer that vehicle tracking service to other organizations or departments.

Security and Compliance Challenges of Microservices

One big problem with microservices is visibility. As applications exist as a business flow defined by services connected by APIs, they are fluid and abstract. All that communications overhead can also create a lot of wide attack surface and latency, adding to the noise and opaqueness of the system. This makes it hard to see the big picture, which can create gaps and blind spots in the security and stability of the system.

Defenders should also remember that even though microservices are smaller than traditional applications, they can still have security vulnerabilities. All the API connectivity also means that authentication and authorization need to be as tight as possible. Given the prevalence of API leaks, misconfigurations of access control settings should be a large concern for security teams. Each type of microservice should have its own unique lockdown rule to match its intended functional role within the system.

Dual Challenge of Microservices and DevSecOps

We’ve got two big, new, and complex methods to reimagine traditional IT processes, and to complicate matters, DevSecOps and microservices are often implemented together since they complement each other. With all these different users and app services requiring varying levels of access to different things, there are a lot of moving parts to track and secure. It’s enough to make IT folks want to throw in the towel and return to COBOL on the mainframe. But don’t lose hope. The integration of these monster methodologies can be done, and it can be done well.

A Zero Trust Approach

F5 Labs interviewed Nicolas Chaillan, the chief software officer for the United States Air Force. He shared with us how his IT team managed an enormous DevSecOps system within the USAF. The simplified version: use a “Zero Trust” approach for both the users and microservices, leveraging as much automation as possible. What’s the longer version? Read on.

Zero Trust Concepts

Zero Trust, or the Beyond Corp model, is a strategy for security that’s been around for a while—especially for remote user access. The basic concept is that for any given service, access is denied by default. Zero Trust is simply that: don’t trust anyone, no matter their log-in location, inside the network or out. It means before you give them access, you need to:

1. Verify their identity,
2. Apply least privilege, and
3. Keep an eye on them the whole time.

But Zero Trust can apply to more than just remote users. The concept can be used with service-to-service interaction as well as software object communications. It’s the opposite way many traditional local area networks and device groupings function, which is usually default open-access to everything locally. Zero Trust says lock it all down, even your so-called friends and neighbors. It forces the IT folks to be explicit and intentional with how they define access between entities. It’s a little more work and a little more discipline, but it provides a lot more security and clarity.

Zero Trust for Microservices and DevSecOps

“DevSecOps has two pillars,” says Chaillan. “One is the pipeline and the other is continuous monitoring with behavior detection and zero trust enforcement. No one should be able to bypass pipeline and deploy to production.” This means the same level of zero-trust enforcement for DevSecOps across services, containers, and deployment tools.

Good access control is the base for Zero Trust. This means strong authentication, which can include security-scanning the originating endpoint. All access should be under tight access control, using granular rights as much as possible with automation. Chaillan also leverages automation tools like service mesh and application sidecar containers to proxy traffic in a secure manner.

Service Mesh and Zero Trust

In older monolithic applications, each internal code function has direct access to every other code function. This is how a remote code compromise of any component of a monolithic app entails compromise of the entire app. Root shell the web server, and now you have access to the file system, local user databases, and database connections. But with microservices, you can segregate all those services within a service mesh. Just like applying Zero Trust to users, Chaillan also applies it to internal services. Service mesh can enforce that with granular access provisioning by service. In addition, each service can be required to provide identification information to the service mesh control plane, adding a level of security into an application that was never possible before.

API Security in Microservices

There are also power API authentication standards like OAuth and OpenID Connect that can be used here. Limiting the allowed API methods is a good way to use least privilege and prevent leaks and unauthorized command injections. Within the microservices’ architecture, segmentation (sometimes called micro-segregation) is a way to add another layer of security. Chaillan also includes DevSecOps vulnerability and code scans in the pipeline as packages are handed off.

“We know about a vulnerability before anyone deploys it,” he says. “Even if a developer makes a mistake, which they will, we have gates in place to detect it.”

By tracking the service connections, the system can ensure that the connection’s validity over time remains important. API gateways and JWT tokens can be used to do this. Service mesh access controls limit lateral movement. Program integrity is enforced with drift checking. This refers to rescanning application instances for deviations from the configured builds. These “drifts,” when found, are rapidly terminated and rebuilt from known and trusted configurations.

Since Zero Trust requires that connections be verified and authenticated, all API container connections are wrapped in encryption with a mutual TLS tunnel. The TLS connection adds certificate authentication and ensures confidentiality and integrity in transport, regardless of whether the connection is internal or external. Also, pre-approved allow lists of network addresses should be used instead of deny lists.

Conclusion

The transition to faster, more flexible patterns like DevSecOps and microservices can be challenging for cybersecurity teams. Zero Trust offers a powerful method to manage the security of the constantly moving river of changes and access control handoffs.

“I think if DevSecOps is enforced properly, it would be very difficult to cheat the system and deploy things that bypass the pipeline like we’ve seen with the SolarWinds breach,” says Chaillan. “The security is baked into the process.”