ESP for Azure: Security for the Modern Enterprise today announced support for Microsoft Azure, which extends our cloud security and compliance monitoring to multiple cloud environments. In this blog,’s Tim Prendergast (co-founder and CEO), and Prashant Ketkar (SVP of Product) discuss Azure, cloud security, and how to develop a multicloud strategy. today announced support for Microsoft Azure, which now extends continuous insight and control provided by the Evident Security Platform (ESP®) to a single pane of glass for AWS, Microsoft, and multicloud environments. It’s a big step for our company, and an important new offering for our customers and partners.

As we see more demand from customers who use multiple clouds, we recognize that choose a cloud vendor and managing security controls according to that vendor’s security approach requires a lot of coordination. To help us understand more about Microsoft’s approach with Azure, and how security works in a multicloud environment, I talked with two key strategists who developed’s Azure plans: Tim Prendergast (co-founder and CEO), and Prashant Ketkar (SVP of Product). Their comments offer some very poignant and unadulterated views into cloud security and keeping your data and organization safe in the cloud:

Patrick Flanders: Let’s first talk about Microsoft’s approach to cloud security and how the Evident Security Platform supports it:
Tim Prendergast: Microsoft advocates is having a mentality of “harden by default”, and “assume breach”. It’s a well understood concept in the industry that basically says, “don’t assume everything is safe.” Many companies think that a perimeter defense will keep everything safe that’s inside. This philosophy that Microsoft applies presumes that hackers can get into a cloud at any point, and an organization needs to take necessary steps to protect themselves.

Prashant Ketkar: Azure customers have been very influenced by a checklist type of approach. In fact, when I was at Microsoft, many of us read and adopted the principles in Atul Gawande’s great book, The Checklist Manifesto. You’re always thinking about what could go wrong and what the different scenarios might be. You do it in a qualified manner, but as you go through the checklist, you’re making sure you don’t leave anything to chance. While most cloud providers have it in some form, it’s very prevalent in the Azure approach. The problem is, the checklist approach doesn’t scale.
That’s where the Evident Security Platform comes in. ESP automates the checklist, running all of your subscription and services configuration data through a “checklist” that will validate the settings against hardened security best practices, and then prioritizes the vulnerabilities that are found so your team knows what to work on first, second, third, and so on.

PF: What about Azure customers; what’s significant to them about a tool like ESP?
TP: Think about all the recent AWS S3 breaches we’ve seen. Then consider that Microsoft also uses a “harden by default” approach, and that’s important for customers to think about, especially in the context of how they put security around and within their environments. Customers have to build architectures and workloads, and in the Azure world, that is usually done in a way where they open up just what’s necessary for them to accomplish business goals. The alternative is to start fully open and then ratchet down from there. For customers exceptionally well-versed in security, this isn’t a problem. But for teams that have a variety of different backgrounds, especially those that don’t have a lot of expertise in security and compliance, this isn’t going to work. They are given a platform on which they have to control the infrastructure, open ports, set encryption policies, manage firewalls, and other tasks, they are likely to make errors in judgement, deploy misconfigurations, open things too broadly…and then forget to go back and fix and manage.

PK: Well, there’s also the fact that we’re now cross cloud platform. A tool is available that not only applies these philosophies of “assume breach” and “harden by default”, but it can be done in environments that are using AWS in addition to Azure. This is very important because those customers don’t want multiple security tools. They want a single pane of glass to get visibility and insights across the entirety of their cloud. That makes security understandable and fixable for Azure customers, but also for those considering Azure as a way to migrate to the cloud, or as a way to use multiple clouds.

PF: I’d love for you to talk more about supporting the needs of Azure customers. What helps them develop a rigorous security posture?
TP: Let me first address that second part of your question. Irrespective of your cloud provider, there are three mechanisms that have to be in place in order to actively control your cloud: detection, remediation, and ongoing measurement. Not incidentally, these are the three elements that ESP was built on and it formed our design of the product. ESP is essentially designed to bring “assume breach” to a programmatic infrastructure for cloud customers. So getting back to your first question, yes, the Azure infrastructure was built with “assume breach”, but customers who build architectures may not necessarily carry that mentality forward, so they need guidance.

PK: Every customer is thinking about removing risk. Many Azure customers are large, global brands that have very distributed architectures. Azure can handle that type of environment without a problem, but as the reach broadens, so too does the need for security. ESP was built to create minimum attack surface exposure. ESP guides users to open just what is needed to do business, and from there, detect settings, configurations, and changes that might leave them open to attack.

PF: We often talk about a cloud provider’s “stack” because their approach to the different layers of the stack speaks to their overall security posture. What are your thoughts on Microsoft’s stack and how security control is applied to it?
TP: Microsoft has taken a threat-driven approach to cloud security. They evaluate a lot at the host and network levels and look at data flowing into the cloud, as opposed to configuration management, security configuration, compliance, and those kinds of things. They learned a lot by being a late entrant to the cloud market. Across their existing ecosystem they could see customers who wanted to address network-faced attacks, DDoS prevention, SQL injections, application layer attacks; Microsoft began with a security approach that looked first at these things. They recognize that attacks, once they penetrate the environment, can go deeply into the infrastructure, so they clearly want to help prevent that.

PK: It’s important to remember that many Microsoft customers are moving from on-premises and legacy environments to the cloud, so they are changing the paradigm of their infrastructure. They are accustomed to layers; they’ve used a Microsoft operating system, SQL, Active Directory, and all the other components of the Microsoft universe. This makes for a very different type of customer and security team. Azure, therefore, is architected according to this stack idea, and it’s based on coexisting within a Microsoft framework, so those working with it are accustomed to locking down hosts and the OS as a way to control security.

PF: Why would companies choose to use a multicloud strategy?
PK: There are two types of ecosystems to think about: one is the large, established enterprise that has a legacy IT environment. Then there’s the younger, born-in-the-cloud company that has been with the cloud from the beginning. For companies migrating to the cloud, moving to one provider is challenging at scale, so it makes sense from an architecture standpoint to have different providers handling different workloads. That’s helpful both at the time of migration and for ongoing management. For the younger, cloud-first companies, multicloud is a strategy that provides both economic and operational leverage. In terms of costs and licenses, spreading your environment over multiple clouds gives you more control when it comes time to renew. But also remember that these born-in-the-cloud companies don’t have their own data centers, so there’s nothing to fall back on in case of data loss. So they need multiple clouds for the sake of business recovery and business continuity.

TP: There’s a lot of value to be had from this diversity proposition. Not just being able to log in to different platforms, but also things like benefiting from diversity of innovation. If you want to access modern technologies and always be able to capitalize on better ways of running your applications, you’ll need to be on the receiving end of new deployments from a variety of providers. Otherwise, your perspective and abilities become narrow. Let’s say I’m building something using serverless code functions in Lambda or Azure Cloud Functions, and I run into a software function issue that renders it non-functional. Well, I can simply use it in a different cloud and move back and forth as needed. It helps you escape issues like a human introduced bug on the backend. And ultimately, it’s a strategy of keeping your eggs spread across different baskets.

PF: I’m hoping we can continue the conversation soon. There’s a lot to learn about Azure and’s plans for the future.
TP: Absolutely. I love talking about all of this, and it’s a broad topic.

PK: Yes, I would like that. Thanks for having me.

We invite you to learn more about ESP support for Azure, and to come back to our blog in the coming days and weeks for additional insights about cloud security.