Premiers pas avec le Zero Trust

Netskope

En tant que technologues, nombre d'entre nous adore manipuler des outils, en particulier quand nous découvrons une fonctionnalité intéressante dans tel ou tel produit. Nous recherchons immédiatement des cas d'utilisation, puis nous tentons de persuader nos dirigeants d'acheter ce nouvel outil afin de pouvoir l'installer et nous en servir. Si cette façon de fonctionner permet souvent d'améliorer les contrôles et les programmes de sécurité, elle engendre aussi de la complexité et une dette technologique considérable au fil des ans. 

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.