Como profissionais de tecnologia, muitos de nós gostam de brincar com ferramentas; especialmente quando descobrimos um novo recurso interessante de algum produto. Procuramos imediatamente um caso de uso, depois tentamos persuadir nossos líderes a comprá-lo para que possamos implementá-lo. Embora isso muitas vezes tenha ajudado programas ou controles de segurança a avançar, também é como criamos uma dívida tecnológica maciça e complexidade ao longo dos anos.
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.
