The increasing breadth and complexity of the environments we manage are nothing short of breathtaking. Understanding the security risks and applying policies across the cloud, multi-cloud, private clouds and a plethora of software technologies is a challenge faced by every enterprise.
vArmour recently announced version 5 of the vArmour Application Controller, which opens more significant access to vast amounts of information the Security Graph represents and organizes through its Security Graph and SDK. By streaming cloud, network and agent information into the Security Graph, enterprises now have a centralized understanding of application relationships across their multi-cloud infrastructure, enabling centralized risk and policy management that is simple, accurate and secure.
In this DevOps Chat, Marc Woolward, vArmour CTO and CISO, and I discuss how establishing and assessing policies becomes more manageable through expanded access to information about software infrastructure, systems, environments across the organization.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Marc Woolward, who is CTO and CSO at vArmour. We’re talking about policy and risk of cloud applications, how to manage it. Marc, welcome to DevOps Chat.
Marc Woolward: Thanks, Mitch. It’s great to be here.
Ashley: Well, thanks for flying over from across the pond, too. [Laughter] You’re in the U.S., with your U.K. accent, so thanks for being on.
Woolward: There’s quite a few of us out here in Silicon Valley. To be honest, I think it’s half British.
Ashley: There are, there are quite a few of you here. [Laughter] Would you do us a favor and just introduce yourself, tell us a little bit about you, what you do at vArmour, and just a brief on what vArmour does.
Woolward: Yeah, of course. Alright, well, hi, everybody. As Mitch said, I’m Marc Woolward, I’m chief technology officer and also, in my spare time, the CSO at vArmour. My background is, I’ve been at vArmour for five years or so and I look at kind of the strategic direction, I speak to the senior technologists and our customers to understand their challenges with cloud security, and I lead some functions such as, you know, the data science team, and handle things like CCPA and GDPR in my role as CSO.
So, my background is, before I joined vArmour, I was a technology fellow, and I was the CTO for telecommunications and networking at Goldman Sachs. I think I was there for 18 years. Did lots of things there. One of the interesting parts of the role of a tech fellow at Goldman Sachs is, you kinda get involved in all sorts of things. So, I was a member of the private cloud architecture team, you know, almost a decade ago, we built one of the first private cloud environments. And also, I had an interest in application resilience and application design patterns, despite my background keynote infrastructure. So, that kinda set me up really well for a job in a product company in Silicon Valley.
Ashley: Yeah, very much so, especially the proliferation of cloud and all of that. So, let’s jump into it. I think we’re gonna talk about an announcement that was made back in October—what was it, version 5 of the application controller from vArmour?
Woolward: Yes.
Ashley: Can you tell us a little bit about what that announcement was, and then we can get into some of the effects that you’ve seen in the market from it?
Woolward: Yeah, of course. Well, I mean, first of all, I think I probably should tell everyone a little bit about what vArmour does.
Ashley: Oh, yes. Please.
Woolward: So—yeah, no problem. I didn’t answer that in your last question. So, really, we focus on helping our customers to understand how their applications behave within cloud and multi-cloud environments. So, we have a risk and a policy engine that kind of builds a picture of your application behavior, its dependencies, and suggests the ways in which the application should be secured from a policy standpoint, and we help to make it—we make it simple for our customers to implement safe, secure, simple policies within cloud environments.
So, what version five was all about, underpinning the application controller function itself is a security graph, and affecting that is a graph that describes all of the nodes, you know, the compute instances, the Kubernetes pods, the servers within a multi-cloud environment and the relationships between them. And what we’ve been doing is enriching that graph with all sorts of information about the application, compliance requirements, information about what the application does, is it there, what ___, what realm does it run in, what region does it run in?
And really, what version 5, release five was about was opening that up and exposing more of the information within the graph so that customers can benefit from it more. So, what that means is the ability to plug more and more information into the graph to gain more value out of it. Things like information that reside in CMDBs, information from systems that handle vulnerability management, information from control planes, things like Kubernetes so that that information within the graph becomes richer and richer and more valuable. And it can be used for all sorts of use cases, and it also allows companies to build the policies based upon their view of risk and their view of their applications, whether that’s compliance driven or risk driven or business unit driven.
Ashley: Now, can you kinda dig down and open up the hood a little bit more for us? Talk about how all this information gets into vArmour addition the application controller. Are you taking it from logs, configurations, active applications? What are some of the sources for this?
Woolward: Yeah, and—great question. And what I do, I’ll start out by answering that by saying, in the cloud, we do not have a deficiency of data. So, if you’re running a reasonable sized cloud environment, you have tremendous volumes of logs—you know, cloud trail logs, flow logs, all sorts of event based information. And that’s—well, event based data. And that’s data.
The problem with that is data—it’s unstructured, and it’s in huge volumes and it’s very difficult to kind of glean too much value from it. And what the application controller does is, it takes the data and it transforms it into knowledge. So, it provides you with insight into your application, which makes it a lot easier to make good security decisions.
Ashley: Mm-hmm.
Woolward: So, I’ll kinda come back to that in a minute. But the way that we do it is, we have a distributed telemetry pipeline where we use edge compute functions distributed out to the cloud environments that consume the logs and also consume events off of event buses and APIs. So, when a compute instance is deployed, we pull all of the metadata associated with it.
The edge compute function we call message bus summarizes that data, enriches it, and then distributes it into the centralized graph where we effectively are transforming that data from being the individual flow log information into adding information into an edge within a graph, which represents the relationship. So, all the time, we’re enriching and summarizing, and that enrichment provides context, which makes it a lot easier to understand what your application is all about.
Ashley: Well, and given the dynamic nature of our applications—cloud native, all of that, whether it’s Kubernetes clusters instances, microservices, just knowing what you have is half the battle, more or less what’s this information telling you? So, that’s got to be a value, too.
Woolward: For sure. And, you know, Kubernetes is a fantastic example. Because if you’re capturing that information at the wrong level, if you’re looking at the IP address level or even the pod level, there’s a tremendous amount of noise in there and it’s very temporal and it doesn’t make any sense. If you can consume that at the abstraction, that makes sense to the application, so that would be at the deployment or at the service level and you ingest that into the graph you can build a picture of your application over time.
And then when the, kind of the instantiation that’s just been deployed now varies from that model, you can see it very quickly. So, what we’re trying to do is summarize the information and represent it as—I say represent it as knowledge while continuing to process kind of the very dynamic and very high volume data and look for the anomalies and look for places where it varies.
Ashley: That sounds, too, like a perfect application for a graphing technology to be able to visualize, explore, dig in deeper, back out, look at it at different levels.
Woolward: Yeah. For sure, and you know, like I said, my background of working at Goldman and working in financial services, graph technology is fantastic for describing relationships, and that relates to risk. So, if you look at financial risk modeling, that has been almost the archetype application for graph technology for over a decade. I really would take that same approach and that same principle to cyber risk and cloud security risk.
Ashley: Very good. Now, I know also that you’ve introduced an SDK with this. What are some of the applications where customers might want to use the SDK?
Woolward: The whole point of the SDK—so, we integrate with all of the common cloud environments and we integrate with SDNs and the other product is designed to integrate into these different environments, just as part of the product out of the box.
Ashley: Mm-hmm.
Woolward: But what we’ve been finding with our customers is, they have different repositories for this context that would enrich an understanding of risk. So, if you have a vulnerability scanner, you have a tremendous wealth of information about the posture of the individual systems running in your environment. By plugging that into the graph, and by using the SDK, it’s very easy to do that for whatever system you’re using, you can begin to ask questions like, “Well, for my application, do I have any dependencies on systems with, let’s say, a CB severity of seven or above.” So, the SDK is a way of pulling in the vulnerability information, pulling the specific fields that are of value to you from your CMDB from, say, your service now, effectively plugging in that context that kind of illuminates your whole kind of understanding of your application and your risks.
So, really, it’s about allowing our customers to integrate the data sources that matter to them into this graph that plugs into their cloud.
Ashley: Mm-hmm. So, both in kind of an in and out application—bring in more data, also be able to pull it out for other uses reporting.
Woolward: Yeah. That’s a superb point. I missed that. Another application that customers use the graph for is, embedded within the app controller, we have classification engines. So, what we do is, we will classify systems based upon our understanding of their behavior, based upon the relationships they have and the systems they have relationships with, we’ll classify them.
So, one great use of the SDK is to compare the results of our systems classification with the information within a CMDB. So, you know, does your intent, which is in the CMDB match what’s actually happening in the cloud environment?
Ashley: Mm-hmm.
Woolward: And by doing that, what you can do is, you can validate that your inventory information is correct, is accurate, continues to be so—which, again, improves your security posture because, you know, one of the fundamental pillars of security is understanding what you have, and having an accurate understanding of the systems that you want to secure, so yes, for sure.
Ashley: Absolutely.
Woolward: But, you know, it’s a two-way thing, the SDK.
Ashley: Well, and you’ve got a little bit of time under your belt with GDPR and we have the California Consumer Privacy Act coming up here. How does this kinda technology help satisfy, meet, report compliance—what are the various ways that you could leverage vArmour and the application controller to help you with those challenges to meeting regulatory requirements?
Woolward: For sure. Yes, so, I mean, there were different regulatory frameworks that are more or less specific about the security controls required. So, if you take something like PCI, it’s very specific and it’s very directed in terms of the way in which you structure your controls. So, the app controller can allow you to scope your in scope infrastructure around your card holder data environment and build the layers of controls around the tiers of systems, according to the PCI DSS. So, it’s very good at doing that.
If you look at something more abstract, which talks more about the outcome rather than the means of getting to the outcome—so, if you say it’s something like GDPR where you’re looking at protecting personal information relating to data subjects in Europe or CCPA where it’s more around protecting the personal information around California based consumers, that really comes down to managing risk and ensuring that the control—suitable sets of controls are placed around the systems that either store or process this information. And the first step to do that is to understand the scope of the problem and the scope of the relationships of the systems that are processing this personal information.
So, the app controller, first and foremost, can allow you to understand, you know, the scope of these environments and begin to put controls and reporting around their behavior and access to those systems. So, it all starts from scoping and understanding your environments and ensuring that you can put the controls around the—you know, place the controls around the edge of them, and you continue to monitor that those controls are effective and that, effectively, in the cloud is what the app controller does.
Ashley: Mm-hmm. Very good. Well, I certainly don’t profess to be an expert on either of those two regulatory frameworks. [Laughter] I’m really curious, we’re about a month, month and a half in since you’ve released version 5. As a former product creator myself, it’s always interesting to see what people do with new technology, new versions. But also, what you didn’t expect them to do with it. Have you seen kinda instances of both, you know—yep, we thought we’d help customers this way, it’s worked out that, and then we’ve also seen some interesting ways they’re using it they didn’t think they would.
Woolward: Yeah. So, I’ll start with kind of what we expected and kind of the, if you like, the continued illustration of the value that we designed the product to offer. One of the things that we never—well, I never fail to be amazed by is, you deploy our system within a cloud environment and it begins consuming the telemetry. And within an hour or so, the graph is already beginning to hydrate and you’re finding hundreds or thousands of workloads.
And all of a sudden, the extent of the interrelationship and often the external dependencies, the relationships outside of the VPC or outside of the VNET kind of are visualized. And almost every time, as we sit there for the first few hours with the customer, we’ll get into the same discussion about, “What’s that relationship? Oh, I have a dependency on something in GCP.”
So, generally, that kind of uncovering the unknown and unsuspected dependencies opens up a whole kind of, you know, can of worms for understanding what’s going on here and ensuring that the correct policies are in place and ensuring that everybody understands the extent of the attack surface and the blast radius. So, that, we always see, and that’s just accelerated with version 5.
In terms of what was less expected, that’s the beauty of the SDK. So, the SDK allows the customer to plug in the information and the metadata that’s important and pertinent to them. An area where I didn’t really expect it was actually the application not just to your traditional cyber risk and your attack surface and your blast radius, but asking some interesting operational questions.
So, this use case came up about two weeks ago where a customer was taking kind of an operational term for their applications and plugging it into the graph, and asking the question around, for my critical tier applications, my systemically critical applications, if one of their dependencies, one of the applications that they depend upon for, I don’t know, reference data or for other types of communication, like communications gateways failed, what would be my recovery time?
And all of a sudden, what you can do is, you can draw within the graph the relationship between your application and the dependencies and plug in that recovery time objective, and all of a sudden, I understand that if application A, B or C failed, I might be waiting eight hours for recovery, whereas my system has a recovery time requirement of one hour.
Ashley: Mm-hmm.
Woolward: So, they’re beginning to ask these questions that you would not expect from, necessarily, a cyber tool around operational risk. So, I think that’s the beauty and the power of the graph—it allows the customer to think about, what does risk mean to them, and they can plug the information or plug the data in that they require and then they can ask these questions that lead them to knowledge.
Ashley: Excellent, yeah. It sounds like both information, operational information, but also behaviors of what’s happening between applications and greater insight into it.
Woolward: Absolutely, yeah. Yeah, for sure. And I think the other thing, I mean, the final thing I’d say is, if you look at most of these data breaches over the last year or two, it kinda comes down to, if you look at cloud and you understand the way that security works, it’s this shared responsibility model. So, the cloud service providers provide a tremendous array of tools—you know, micro-segmentation, identity access management policy enforcement. There’s a tremendous suite of security capability there.
The problem is always that the lack of knowledge about the application means that the policies that are written and the permissions that are provided by the customer, because that’s their side of the, kinda the shared responsibility model have been deficient. And what the application controller allows you to do is to build the policy in a simple fashion that’s secure and meets your business requirements, and then that’s allowing our customers to meet their part of the shared responsibility model for cloud security.
Ashley: Mm-hmm. Wow. Well, I feel like we’ve barely scratched the surface and we’re already out of time. Hopefully, we can get you back and we can explore this some more as we get closer to the CCPA coming into effect in January.
Woolward: Yeah, and as the CSO of a California based company, I’m obviously spending a bit of time on that as well, so.
Ashley: I’m sure you are.
Woolward: That’d be fun.
Ashley: Yeah, exactly. Well, Marc, thank you so much for being on DevOps Chat with us.
Woolward: Yeah, it’s been a real pleasure, Mitch. Thank you—thank you for inviting me.
Ashley: Absolutely. The pleasure has been ours. I’d like to thank my guest, Marc Woolward, CTO and CSO with vArmour and of course, thank you, our listeners, for taking your time to join us and listen to this podcast episode. This is Mitch Ashley with devopsy.kinsta.cloud. Have a great day, and be careful out there.
— Mitchell Ashley
Testim will continue to provide access to its platform via a graphical user interface, but with the edition of the SDK, Rubin said his company expects to see an increase in the number of DevOps teams that will incorporate Testim within the context of continuous development/continuous deployment (CI/CD). Once that occurs, the number of tests those teams will be willing to run against software before it’s deployed in a production environment should also increase, especially as more developers leverage APIs to create their own tests, Rubin said. That doesn’t eliminate the need for another set of eyes to test an application, but it should reduce the number of common errors made before any piece of code is tested by someone else on the DevOps team.
