How to Implement Zero Trust Security in your Applications: A Tutorial

Modern security threats require modern security approaches. Traditional security approaches presume that attackers will come from outside an organization’s internal network and so seek to authenticate access to the network. But at the application layer, once a user is inside the network, applications which assume they are trustworthy are at risk. Attackers take advantage of these assumptions to compromise applications. Modern security approaches combat this risk at the network level by adopting a zero trust security model. 

In this post, we’re going to talk about the concrete steps that you need to take to bring zero trust security to your applications. As with any tech initiative, there is no silver bullet. You’ll have to figure out how to plan your zero trust security rollout so that it fits your organization. But there are some steps every organization will need to go through, and we’ll touch on each of those. 

What Is Zero Trust Security?

Zero trust security is exactly what it sounds like: a security approach that authenticates and authorizes a user on every request that they make. Traditionally this is done at the network boundary, but with today’s boundryless cloud-native application architectures, the key concepts of  zero trust security must now be applied at the application level. Instead of assuming a user (human or software) is trustworthy, the application limits every user’s access and authorization to the minimum required by their role. It also combines authentication and authorization with additional metadata about user requests, such as geographic location and local time of request. It uses this metadata to identify suspicious patterns of requests. When these patterns are detected, a human or an AI evaluates whether a user should in fact have access, instead of just assuming that because they’re authenticated, it’s acceptable. 

Step One: Take Inventory

As is so often the case in security initiatives, step one is figuring out what you have to work with. This doesn’t just mean users, accounts, servers, and network switches. It also means things like what sensitive pieces of information are stored in your application. It means figuring out who has access to which systems and which pieces of data. You’ll likely need to develop a system to classify the data in your application traffic (see an example from Carnegie Mellon). 

By the end of this process, you should know what data flows through  which applications and application components in your network. You should have an exhaustive list of the users, applications, and application components running in your application landscape. This process takes some time, and it’s likely the application landscape will change while you’re cataloguing it. You still need to get this part as right as possible in order to succeed with the project.  Application discovery tools can help here.

Step Two: Beef Up Authentication

This will be the first step of the process that looks like “improving security” to non-technical individuals. It’s also one of the most painful. Improving authentication for an organization means looking at each of the three factors of authentication and determining which work for your organization. Often, this will look like adopting a two-factor authentication app or even a hardware security token. 

By improving authentication protocols in your applications, you gain more trust that people are who they say they are. When someone signs into your application, your security system has a greater degree of confidence that they’re an authenticated user, not someone impersonating that user. One of the key tenets of zero trust security is that we re-authenticate the user on each request. This is often done through a hardware or software security key that applications pass along with the user request. It doesn’t mean typing in the user’s password on every request; most users would riot before they’d put up with that kind of interruption. 

Step Three: Limit Authorization

Many companies make it through steps one and two only to stall out on step three. Much like climbing a mountain, the going gets tougher the further up the hill you push. Limiting authorization means ensuring users only have access to the data, applications, and systems they need to do their job. Often, this step requires doing an audit of the primary and secondary job responsibilities for each user of your application. It also requires making some difficult and unpopular judgement calls about what access is truly necessary. It’s easy to say that someone needs access to an application that serves their primary job function which they perform once per week. But what if it’s a secondary job function once a month? Or once a quarter? 

When possible, your response shouldn’t be to eliminate user capabilities, but rather to limit them to only the capabilities they need to perform their job. This has dual benefits for the organization. If the user accidentally takes an action they shouldn’t, the scope of their mistake will be limited. Additionally, if a malicious user compromises an account, they’ll only be able to take actions that the compromised account is authorized to take. 

In my experience, this is the most common place for zero trust security initiatives to meet resistance. People don’t like losing access to systems or data they were previously able to utilize. It’s common to need to explain the need for stricter authorization measures to departments, and again to individual managers, and then to their teams, and then again to the individually affected team members. At each step of the way, it’s common to experience pushback on your decisions and a desire to litigate them to a higher authority. 

Step Four: Monitor Actions

Once you’ve identified all of the sensitive components of your applications, effectively authenticated your users, and ensured that they’re correctly authorized, it’s time to start tuning your policies. Your goal as a security team is to ensure that employees have all of the access that they need to do their jobs and none that they don’t. You want to minimize interruptions to workflows for things like authentication windows, but you want to make sure that if an unauthorized user takes over an account, they’re locked out as quickly as possible. 

This is where effective monitoring comes in. Smart security monitoring will build context about how users use the applications. Meaning they’ll monitor things like where they access the applications from and when. Then, when a user takes actions that are outside their normal flows, security operations knows right away. They can then quickly decide whether that action is appropriate or should be blocked. In the best cases, this decision-making can be built right into software and integrated straight into the authorization flow. 

Getting Zero Trust Security Right is Key

As mentioned in the beginning, malicious users are more sophisticated than ever. They identify paths into your applications and use your implicit trust to gain access to data and systems you never thought would leak. Adopting zero trust security means limiting or completely eliminating those risks. That doesn’t mean that zero trust security is easy to implement, nor does it come for free. It’s a lot of hard work, but digital security needs to constantly evolve with the threats businesses face. And let’s not over sell it: Adopting a zero trust security model doesn’t mean that you’ll never experience a breach. But it is designed to limit the damage a malicious actor can cause if they do breach your application. 

Traceable identifies all of your APIs, and evaluates your API risk posture, stops API attacks that lead to incidents such as data exfiltration, and provides analytics for threat hunting and forensic research. With the Traceable solution, you can confidently discover, manage and secure all of your APIs, quickly deploy, and easily scale to meet the ongoing needs of your organization.

Depending on your role and the needs at your organization, there are multiple options to get started with observability and API security:

• If you’re a CISO or DevSecOps security leader and want to evaluate your API security risks, try the API Security Posture Assessment. 
• To start your journey, sign up to learn all about your APIs — internal, external, third-party, and even the shadow or rogue APIs you may not even be aware of.
• If you want to compare different API security solutions in the market, check out an API Security Tools comparison guide.

You can also view a demo or book a meeting to learn more and ask your questions on how Traceable AI can meet your API catalog, observability, and security requirements.

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.