Zero Boundaries for Zero Trust

To combat the increasing occurrence of bad actors misusing data, the security community has developed some basic principles, which John Kindervag had branded “Zero Trust,” that have reshaped how we think about data security and access.

Zero Trust has become a movement to change the general mindset from a perimeter-focused security posture to one of continuous authentication and continuous validation across the technology landscape. Instead of only having to pass an identity check at the castle entry, all the guards posted inside the castle now ask you to prove you belong there as you move from room to room. Now, think of security meshes and webs narrowly focused on systems and applications rather than the expansive perimeters, edges, and boundaries that made sense a short while ago.

Data security principles are fundamental to the success of an organization. Loss of classified or proprietary data, loss of privacy data (PII), and the risk of direct loss of money, as in a ransomware attack, can all severely set back progress if it does not bring the entire business to a screeching halt. Zero Trust has many different flavors tailored to the different topographies to which it is applied. Most Zero Trust principles are spelled out to be most broadly applied. The core sentiments come down to the following:

Never Trust, Always Verify – avoid using a security check that happened earlier. Do your own security check now.
Implement Least Privilege – add privileges from a zero base minimally and only when needed.
Assume Breach – develop security processes with the same vigor as if a breach had happened yesterday.

In a parallel path, the applications and systems in the Zero Trust security web have developed their own methodologies for increasing security. Application development was a simpler prospect when the application ran on a local end user’s machine or was deployed to bare metal servers.

As the need for more consistency, dependability, and scalability rose, automation became a part of development and deployment, giving rise to DevOps – the people, hardware, and applications that support the speed and repeatability of the new automated processes. However, those bad actors were always there to exploit vulnerabilities, so a renewed focus on integrating security morphed DevOps into DevSecOps, and then even more refined by some (read: “shifted left”) to SecDevOps, a security-first mindset for application development.

With two mature security frameworks topping tech headlines and blog articles, it is hard to miss the influences, dependencies, and synergies between them. DevSecOps (the wider default term) automated repeatable processes to provide fast iteration and agile capability to development teams. This automation comprises applications and systems that provide source code management, project management, pipeline management (covering CI and CD), and various other functions.

Each of these systems needs to be thought of as a node in the organization’s security mesh to which the Zero Trust mindset must be applied. Adhering to the Zero Trust principles, such as Always Verify and Implement Least Privilege, changes the nature of development at its core. New languages and supporting frameworks will arise to provide the tools to build applications that interface with authentication protocols being used to enforce the Zero Trust principles.

Zero Trust is rapidly becoming a permeating principle in the technology security industry. With the next generation of automation and new technologies coming quickly, those of us in the information security community should apply the principles of Zero Trust wherever possible and in innovative ways.