Zero Trust is a behavioral, engineering, and security principle that exists to protect organizations' systems and sensitive data because both security threats and human error are impossible to avoid. Identity and Access Management tools are the methods by which this principle is managed in organizations.
The practice goes like this – prove the need for access to data or a system, provide only the necessary access for the necessary time, and then take the access away right after achieving the objective.
For this to be accomplished, a few things are required:
If a threat actor is able to compromise your systems or environment, what effective access do they have? Are they able to move through your systems and data from a single, seemingly unrelated compromise?
All too often the answer is yes. Part of the solution to this is Zero Trust. With the right layers of checks and balances in place, the threat actor does not automatically possess any ability to access areas outside of the compromised workload. If the threat actor tries to gain access, these same checks and balances identify and raise alarms for suspicious behavior or potential unauthorized access.
1) If you think about your product or service as a house, it’s common for teams to build it and provide access as needed or in an ad-hoc manner. Essentially, they add a door and give access when requested to complete work. Often, when the work is finished, they still have access when it’s no longer needed.
2) As a team continues to build out the product or service, other entry points might be added. A backdoor or window that is not logged, monitored, or traced.
3) As a team gets closer to production, security teams review and try to lock down access. They try to patch entry points and build a moat for protection, but oftentimes it ends up ineffective because of Wild West permissions that were granted.
1) With a Zero-Trust approach, technology teams address security from the start. In this analogy, the team would build the moat from Day 1.
2) The product or service is built with limited access that is explicit and on a by-need basis. One access point (a door) and additional security (alligators) are layered in.
3) As the product or service evolves, the team creates automated permissions that are logged and monitored by security systems (cameras) to alert if a threat is detected. One point of access to get to the house, a drawbridge, can be put down or drawn up.
It’s easy to just give everyone access to all the things and trust them. It’s hard to be disciplined enough to create the software, systems, practices, and processes that get you as close to Zero Trust as humanly possible.
Zero Trust is the idea we are always trying to move toward but can rarely achieve in its purest form – Minimum Trust is the everyday compromise.
With Zero Trust, you only have the power you need to complete the task, so there is less chance of breaking something that causes extended downtime, loss of customer trust, or money. But it requires going through everything on purpose, regularly to see if anything was missed, anything changed, or anything new was introduced.
The imperfect implementation of the “Zero Trust” practice is inevitable. It is a by-product of human inclusion in the process and leads to an increased need for automation, testing, inspection, assessment, penetration, logging, monitoring, and alerting.
Over time, it is common for one or more of these behaviors to become an afterthought, leaving you susceptible to bad actors with malicious intent. And that is getting more costly. On top of the incalculable costs like lost trust with customers and the cost of downtime, the global average cost of a security breach was $4.45 million in 2023 – an all-time high according to the IBM Cost of a Data Breach report.
When I moved to a Zero Trust environment it took so much weight off my shoulders. Personally, I want to work for an organization that empowers its teams to take all possible precautions to lock down sensitive information and protect customer data.
The practice of zero-trust is context-driven to the people, company, culture, and project. We say practicing zero trust because it is an ongoing practice.
People make decisions you don’t want, overwhelmingly as an accident, but occasionally maliciously. Limit the damage that can be done by investing in recovery processes and procedures and continuously monitor, review, and update access.
The following practices help you pursue, implement, and evolve a Zero Trust framework for your organization. They are in no specific order of importance – they all play a vital role in the Zero Trust journey.
Version Control is used to create and monitor the audit and change logs of systems and code. Without it, you can’t see who changed what or why. Bad actors could break the system or even worse, critical information could be sent out. Money could be siphoned. Even if the worst-case scenario doesn’t happen, there is no good way for peer review.
If you are doing anything with software, you need to have version control and change management processes to ensure you know who is doing what and when.
Infrastructure as Code (IaC) enables the same capabilities for infrastructure as Version Control plays for audit and change logs in software. IaC provides detailed information that allows you to see if someone made a change to an environment, who it was, and when. You have some facts of what happened to help understand the scope and scale of the incident.
Infrastructure as Code must follow the policies defined by the governance group below.
Policy as Code leaves no space for people to do the wrong thing. Engineers aren’t simply trusted to do the right setup, they are protected from the ability to do the wrong thing.
Policy as Code enforces written policies systematically.
There are a couple of different types of governance: industry and organizational. Organizational governance is a policy written and adopted by the organization that states things such as, “customer data does not exist in non-production environments” or, “engineers can’t create storage accounts that are publicly accessible.”
Organizational governance also addresses questions like:
Industry governance exists to regulate compliance standards across the industry. For example, federal agencies must adhere to NIST controls whereas the healthcare industry must adhere to HIPPA.
CI/CD enables Version Control, IaC, and Policy as Code in a way that keeps security as the focus. If you have Version Control but don’t have CI/CD, someone still needs to manually see, touch, build, and deploy code.
Instead, by automating CI/CD pipelines, code can be written to say, “When I see a change in the Version Control system, I will run these things to check against our policies and then build, bundle and deploy that code with no manual access needed.”
The benefits that are enabled through automation aren’t limited to security, organizations often see a reduced time to market and lower total cost of technology operations.
Who you trust to build out the governance, Policy as Code, Infrastructure as Code, and CI/CD pipelines necessary for Zero Trust matters. Read three examples of how Trility helped clients improve security posture.
Whether it's industry compliance standards that must be met or an organizational effort to shift security left, Trility can provide the resources to solve your organization’s high-consequence problems.
Read more articles from Trility’s team.
Read summaries about projects Trility has delivered.
