I am a frequent traveler. In fact, I am writing this piece from the seat of an airplane, cruising at 35,000 feet over somewhere in India. And if you travel as frequently as I do, you want predictability, ease of use and economy. Take, for example, ride-hailing apps like Uber and Ola – they have made travel a lot smoother – easy-to-use, readily available cars, predictable fares, customer-friendly service and consistent experience – almost anywhere in the world. However, these very companies have also made life difficult for others – Airport Administrators, for one.
Over the past few years, Airports in India have had to re-orient traffic and parking facilities to accommodate a mushrooming number of passengers that prefer to use these services. Most Indian airports – like Bangalore and Mumbai – now have dedicated areas for pick-up and drop-off for such services – something that was not forecasted in the master plan.
The Evolution of “The App”
In this age of Digital Disruption, the “app” is the core of the company’s user experience, and a lot of times, the competitive differentiator. And running behind this app is an entire software powerhouse. Not too long ago, application architectures were “monolithic” – meaning that every development team worked on the same application, and every release of that application had to be coordinated across every team. Whenever a new feature was to be added, it involved countless edits and rewrites – an unwieldy process that required complicated coordination. Needless to say, this severely limited the ability to innovate fast, and at scale – a critical capability in this digital economy.
Today, most applications are being re-architected into smaller functional blocks that are independent of each other – called microservices. Each service can be managed and scaled independently, giving faster turn-around times and much needed agility in releasing new features and capabilities. Modern applications, therefore, have a far more distributed nature compared to traditional ones – giving rise to a different problem – how do you secure so many different components of the application, potentially running on different infrastructures?
Zero Trust, Extended
In my previous blog, I covered how we can implement Zero Trust for the Workforce – i.e. consumers of these apps. This involves 3 key steps:
1. Verify Users’ Identities
2. Gain Device Visibility and Trust
3. Enforce Access Policies for every App
Now let’s look at how we can implement Zero Trust for the Workload – i.e. the app itself. It is important to understand that this app – or even components of it – may be running across multiple different infrastructures – the Private Data Center, the Public Cloud, or a combination of the two. Zero Trust involves the ability to establish trust for every access request – regardless of where the request is coming from or is targeted towards.
Verification of Trust for Applications involves:
1. Identifying what applications are running in the Enterprise
2. Understanding what is communicating with your applications and data
3. Verifying that communications between workloads are verified and trusted
The first part is about gaining visibility – into your applications, containers and data across your multi-cloud environment, as well as workload relationships, components, communications and dependencies. This level of capability is well beyond traditional techniques such as SPAN or NetFlow and needs real-time network sensors that can gain accurate visibility into devices, processes, packets, network flows and communications within application environments. This is crucial for gaining deep insights – such as unpatched software and configuration states.
The second part is about creating an accurate, real-time model of the applications using big data analytics. This helps categorize application tiers and identify application dependencies. This, performed over a period of time, captures infrequent activities, such as monthly jobs or one per quarter accounting processes. The more accurate the application mapping, the more accurate the resulting policies will be.
Third, is about being able to apply policy to multiple elements across multiple environments. These policies are designed to minimize trust within the application ecosystem. This is also known as micro-segmentation and prescribes a whitelisting or “default-deny” approach to move the perimeter as close to the workload as possible. The ability to simulate and validate the policy and deploy it across all environments is a given.
Lastly, continuous monitoring and continuous improvement of the environment is a must – to account for changes in the application landscape, changes in the organization, changes in the attacks – zero trust needs the policies to evolve as the ecosystem does.
Now that we’ve secured our Workforce and our Workloads, we will shift our focus to the Workplace next. In the meanwhile, my flight has landed – so let me go call for my Uber…
Authors
