What is Zero Trust Security?

Zero Trust is a security model based on maintaining strict access controls and not trusting anyone by default. Corporate IT has the affinity to trust every session originating from within the organization while denying anything coming outside of the organization. The problem is once somebody is inside the network, there is no way to stop them. If a hacker could phish an inexperienced employee to give up their SSO credential, why would they play hide and seek with the intrusion detection system in place?

Therefore, organizations are moving towards a zero-trust system for security verifications on their network, servers, services, and other resources. The idea is “always verify, never trust”. If you’re a developer pulling commit on their code at the end of the day, zero trust means it won’t go through to your Jenkins instance to become a part of the CI/CD pipeline unless you verify your identity as a developer on the project. Continuous integration does save the development and operations team from “integration hell” and the consternation of “merge day”. However, automation in DevOps processes shouldn’t come at the expense of security. DevOps teams should collaborate with the application security (AppSec) team to build security checks throughout the CI/CD pipeline. Again secure DevOps or DevSecOps only matters when it is a part of your culture. Even then what is stopping that rogue developer in your team to bypass the security check by disguising their identity.

The rise of cloud and containers has made software development make huge strides in the direction of productivity, agility, and scalability. Organizations are increasingly adopting modern DevOps practices to accelerate their software delivery pipelines. DevOps is allowing them to ditch their traditional monolithic applications and move to a microservice architecture in a cloud-native and containerized world.

DevSecOps or Secure DevOps, a natural evolution of DevOps, brings security to standard DevOps processes and practices without slowing down the development pipeline. Development pipelines are critical to the functioning of a DevOps process, which dictates terms like continuous integration, continuous delivery, and continuous deployment. The end game is to automate the entire production pipeline from code generation to deployment to shrink development cycles.

DevOps, DevSecOps, and a transition to ZTS

For developers, DevSecOps introduces an unnecessary hindrance since DevSecOps is a team with shared responsibility. The idea is to shift left on the delivery pipeline.

Before DevOps came, security teams would enter the picture once a year right around the deadline, run their scanners, and certify the release. For larger projects, security analysis would take weeks, even months. In DevOps world, things happen hourly and daily, not weekly and monthly.

It was simple: traditional security analysis methods won’t work with DevOps. DevSecOps was introduced for this very reason: to make security an integral part of DevOps, not an afterthought.

Small security teams can’t run their scanners on every build, multiple times a day. So the responsibility fell on developers, who did not appreciate it. They already had a lot on their plate. They now not just have to write code but secure code while keeping in mind the best practices. They had to test their code at every change before throwing it into the pipeline, which is now automated.

Developers did not appreciate the new situation they were thrown into in the name of DevOps and DevSecOps while their sysops and security colleagues were relaxing after adding a couple of checkpoints to the otherwise automated pipeline. Security in DevOps means, you’re asking the developer to take responsibility for something they hate the most—security. As I said, DevOps is more about building a culture around speed-with-security. Building a new culture takes time. Even then culture and best practices are not lines drawn on a stone they can be mended or skipped altogether.

So what happens when a developer skipped his security responsibility to accelerate a build cycle. It may not look so much of a big deal if you have a large team with shared responsibilities. But, you’re probably pulling the application into a security nightmare down the line.

Organizations are aware of the risks of trusting their developers and, thus, moving to a Zero Trust Security model which dictates—”never trust, always verify”.

What is Zero Trust Security :

Zero Trust Security is a “never trust, always verify,” approach to secure IT systems.

Let’s take a concrete example. Consider you are securing your  private network.

In this case, the Zero Trust Security strategy for users requesting access to your organization’s private network will be as follows:

Unlike firewall-based security systems that work on a set of predefined rules to allow or disallow a connection request, the Zero Trust Security system denies each connection request by default. It doesn’t matter whether the request is coming from inside the network or outside it. For a connection request to gain access to the network, the ZTS system will block their request and do the following:

1. Verify their identity
2. Apply least privilege
3. Monitor them for the time they are on the network

You can apply the Zero Trust Security model to any sort of connection request to your organization’s network be it service-to-service interaction or software object communications. ZTS has overcome the limitations concomitant with traditional security models introduce such as allowing unsolicited access to any request originating within the organization. Zero Trust Security may lockdown to your even teammates at first; the tiny work and modest discipline will come around as better security and finer clarity. Also, the system forces corporate IT to be explicit and intentional in how they define access between entities.

How to achieve ZTS in DevSecOps?

DevSecOps has two pillars: the pipeline and continuous monitoring. With behavior detection and zero trust enforcements, nobody, including your developers, can bypass the CI/CD pipeline and deploy it to production. With Zero trust enforcement, you can bring the same level of security to your services, containers, K8s, and deployment tools.

Zero Trust is all about fine access controls and robust authentication for security-scanning the originating endpoint. ZTS dictates all access to the network shouldn’t be under tenuous access control. You should be using granular rights wherever possible with automation.

Moreover, you may use automation tools like application sidecar and service mesh containers to securely tunnel the traffic

CI/CD pipelines with ZTS

Enterprise network security is based on stringent firewall rules that hinder the flow of an automated DevOps pipeline around CI/ CD workflows.

Cloud instances/services such as EC2 and EKS have security groups and container service meshes to automate deployments over CI/CD pipelines. These provisions might work for simpler applications but fall on the ground as we go about multiple regions, clouds, or technology stacks. Good luck finding interoperability between vendors’ security groups or Kubernetesclusters.

Therefore, software development firms are increasingly shifting their security efforts to zero trust when it comes to their pipelines.

Use software-defined security

Software-defined security is commonly used in situations where hardware-based security is low or non-existent, such as cloud computing and virtualization infrastructures. It’s a model in which the security of the hardware is managed using the software. Firewalling, intrusion detection, access controls, and network segmentation are all features of network security devices that are abstracted from hardware to a software layer. If you use cloud computing services, you already know that everything should be managed as code, including security, which should be wrapped within your architecture. Infrastructure as code is then prolonged to the security layer while also being vendor agnostic.

Identity-centric security

To build a ZTS strategy, the organization must grants security teams the control overall policies to align them to enterprise rules and translates them into equivalent access control settings.

We’d like to take the example of AWS here. When you create a service in AWS, say an EC2 instance, it is in reality not accessible by any user unless you create the right user, with the right identity, and policies ..etc Every call in AWS is authenticated and authorized by AWS Identity and Access Management (IAM), just as your calls to AWS services are. Strong identity-centric controls form the basis of the security model between AWS services. The way AWS is built and is run is a good example of leveraging IAM to establish a powerful ZTS.

Secure your services and how they interact.

Zero trust means zero trust. Securing the network is good, securing sessions and networks is better. By applying security directly to a session, secure tunnels are created between services to enforce security on each individual connection. This makes it easy to change, test and scale. When your services need to call each other, they should rely on the same security mechanisms that you use as a customer.

By services, we don’t only mean production services, but your entire IT services including CI/CD pipelines and every resource your DevOps team is using to build, test, and deploy.

Use a CI/CD solution that keeps your pipelines safe

As CI/CD is one of the pillars of DevOps, thinking of the security of your DevOps pipelines should be also considered part of your Zero Trust Security strategy. This is what every serious company should do.

This will not work for you if you think it’s about “adding” a new security layer across your application, the goal is to consider the dynamic nature of artifacts and infrastructure and embed security into these.

Wildcard CI/CD solution takes a security-first approach in handling development, delivery, and deployment.

Wildcard is a NoCode platform that provides a solution to help organizations, and developers, even those without DevOps experience or coding knowledge, to successfully implement and manage versioned infrastructure using NoCode CI/CD pipelines. It enables collaboration, auditing, and automation. You can use Wildcard to build, deploy, and manage applications without writing a single line of code.

Start for free by singing using Github or GitLab.