Como tecnólogos, muchos de nosotros disfrutamos experimentando con herramientas, sobre todo cuando descubrimos una nueva función de algún producto que nos parece interesante. De inmediato buscamos un caso de uso, y luego intentamos convencer a los responsables de que la adquieran para que podamos implementarla. Aunque en ocasiones esta estrategia nos ha servido para mejorar los programas y controles de seguridad, con los años a menudo también ha creado un gasto enorme en tecnología y una mayor complejidad.
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.
