Cybersecurity Requires Practicing Zero Trust

Zero Trust protects technology teams from having access to do unsafe things by leveraging tools and processes to secure organizations’ systems and sensitive data.

By
Ryan Skarin
October 13, 2023
Secure identity logs into systems.

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: 

  1. A baseline principle where access is provided to no one and no system
  2. There is an evidential, provable, and requested need for access
  3. If access is granted, it is surgically explicit and temporary

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.

Ad-Hoc, On-Demand Approach to Security

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.

Zero-Trust Approach

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.

Zero Trust Requires Discipline 

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. 

Trust Has a Cost

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.
– STEVEN GATES, TRILITY SENIOR DEVSECOPS ENGINEER

Zero-Trust Practices

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 / Change Management 

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 

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 

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. 

Governance

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:

  • Where do we store data? 
  • How do we catalog it? 
  • How do we create common terms so they can be used? 
  • How do we expose our data? 
  • Who is allowed to access pieces of the data? 

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.

If You Aren’t Automating, You Aren’t Zero Trust

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. 

Enable Security Surety with Trility

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.

  1. NIST 800-171: Automated Compliance
  2. Data Storage CI/CD Pipeline Solution
  3. Phase II: Policy as Code Implementation

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.