Getting Started with Zero Trust

As technologists, many of us like to play with tools; especially when we discover a cool new feature of some product. We immediately look for a use case, then try to persuade our leaders to buy it so we can implement it. While this has often helped advance security programs or controls, it is also how we created a massive technology debt and complexity over the years. 

In many conversations with CIOs and CISOs, operations managers, architects, and engineers, the number of redundant technologies within their given ecosystem climbed to over 50%. Can you imagine the wasted money organizations spent due to poor planning, architecting, and implementation? What about the complete lack of value to the organization?

Before we begin architecting anything, we need to start with the business in mind first. Let’s start with the following two questions:

• What is the business outcome?
• What are we trying to solve? 

Think Big, Start Small

In order to get started with a Zero Trust based program, we need to examine the answer to the two questions previously stated. In our case, the business outcome will be, “Creating a future proof business enabler and reducing technology complexity while providing gap free protection.” 

Here are some considerations to think about prior getting into the weeds:

• Understand your  existing processes and deficiencies 
• Understand the risk and potential threats of what needs to be protected
• Understand your current technology stack
• Understand required capabilities, data and transaction flows  
• Understand the end user impact and their requirements

In my experience, the last bullet point is the least considered topic in the architecture discussion and it can completely destroy the success of implementing Zero Trust. Assuming this implementation effort is structured and architected well, adoption will succeed if there is transparency and ease of use for all users.

When talking to organizations about architecture and solutions, I always focus on fundamentals. 

Architects need to stop thinking about the vendor or a tool, and instead focus on:

• Holistic approaches, not just solving one problem (think about your program, not a tactical solution)
• Simplification of their ecosystem
• What capabilities exist and what is required, same for processes
• Principles and patterns (they must be documented)
• Defining your protection surface
• Design with openness in mind, assuming that intranet and internet are the same
• Consequences of success or potential failure

In this cloud era, it is imperative to understand that the objective of any security program is pretty much the same, but the tools and tactics must change (if the business is transforming digitally, so too must the security team). Think about how to take advantage in creating a more effective and efficient program, utilizing current trends and technologies, especially if they are cloud-native.