Managing Security for the Multi-Cloud

On-Demand

Video Transcription

Dave Klein:
Welcome to BrightTALK today live from RSA 2019 Conference center. Today we’re talking about managed security for multicloud, but first I’m Dave Klein, Senior Director of Engineering and Architecture for Guardicore. Guardicore is a micro-segmentation provider that works across all environments. And now my panel.

Tim Woods:
Tim Woods, I’m Vice President of Technology Alliances at FireMon and we provide security visibility across your hybrid infrastructure.

Dave Klein:
Excellent, all right.

Tom McAndrew:
Dave, I’m Tom McAndrew, I’m the CEO of Coalfire. We’re a cybersecurity advisor, and in this panel I think I’ll be talking about our work mostly with cloud and some of the technical and engineering work that we do.

Dave Klein:
Excellent, excellent.

Praveen Jain:
I’m Praveen Jain, CTO at Cavirin Systems. We provide security and compliance for hybrid as well as multicloud, so very relevant talk here today, thank you.

Dave Klein:
Perfect, perfect, excellent. Now just a reminder, this is a live summit. Please put your questions in. We’re going to take them as we go and make it interactive, so make sure to get to your questions, please post them as we go.

Dave Klein:
So the first question I have is what is driving multicloud adoption? Everyone is not doing a single cloud, it’s multicloud. Is it haphazard, is it well thought out? What are the reasons?

Tim Woods:
Well, there’s a lot of reasons for it and I think they’re doing it for the right reasons, it’s to try to accelerate business, it’s to try to gain competitive advantage in the marketplace, it’s trying to take advantage of the technology that’s there. Obviously with the acceleration of DevOps, CICD, things of that nature, it’s all meant to try to make the businesses remain relative, right?

Praveen Jain:
So what I hear is on one hand you don’t want a single vendor locked in. Even when single vendor lock in, right? So for example, when you are in the private data centers, you want those two vendors to come in, and similarly here, when you go one cloud, now you’re locked in for life. If they increase the price, you’re done, right? So that is one angle where you want multicloud strategy.

Praveen Jain:
In addition, some of the cloud providers, like Google, for example, people say they’re very good in machine learning, so there’s a type of the applications which are well suited for one type of cloud versus another, that’s another reason I see driving multicloud, but I don’t see anything where a single application is just spanning across multicloud. I just wanted to clarify because sometimes people think that’s what is happening.

Praveen Jain:
It’s very difficult once you have the dataset sitting in one cloud, now you’re accessing it from another cloud. Doesn’t work that great, at least-

Tim Woods:
That’s right.

Tom McAndrew:
I guess I’d also add that the organizations are moving generally their entire infrastructure to the cloud. They’re moving components to the cloud, so over the next… The assumptions are roughly 20% of what could be moved to the cloud has been moved, and there’s still going to be some massive changes, so rather than thinking of everybody has to choose an Amazon or a Microsoft or a Google, it’s really we’re moving components to the cloud, and there’s some components that might be part of Oracle or IBM that are still around. They may have Salesforce. So everybody has to understand this isn’t a technology choice, it’s a business choice, and you also have to look at the needs of the business.

Dave Klein:
Got you. Excellent. One of the things about cloud adoption that I find really funny is they always talk about a shared responsibility model. Each cloud vendor says, “We have a shared responsibility model,” I think the caveat emptor in that is really it’s all on the enterprises.

Praveen Jain:
Yeah.

Dave Klein:
We’ll set up the VPC for you and it’s really your responsibility. In all three of your experience, are we finding that the customers are understanding that?

Tim Woods:
Not always, but I think it’s important, depending on who you choose as your cloud provider, and as it’s been seen, there are multiple, people are choosing multiple cloud providers as well, so it is very important. It is your responsibility as the client of that cloud provider that you need to understand with complete clarity about what they’re taking responsibility for and what you need to assume and what your security teams need to assume responsibility for, or your development teams, because it’s not necessarily the same across every platform.

Praveen Jain:
Let me little bit redefine the shared responsibility, because on one hand we think shared responsibility, cloud providers are taking care of all the infrastructure, so they’re taking care of that security, while applications are in your responsibility, you have to make sure that applications are protected.

Dave Klein:
Correct.

Praveen Jain:
But let me just also say, it’s also the shared responsibility in this agile world between the developers and the application.

Dave Klein:
Yes.

Praveen Jain:
Because now that boundary is going away. Now what’s happening is the quick things, you take customer data and put it into the DevDesk workload somewhere in the cloud and suddenly somebody accesses it. That’s a share responsibility too.

Dave Klein:
That is.

Praveen Jain:
So there is, I think, what I feel, is that on one hand, there are things you need to do from enterprise, you need to do from the cloud provider perspective, I think there’s a shared responsibility of training these DevOps guys. Saying that it’s not about developing the… I’m just trying to remember. Remember that there used to be software development lifecycle where you said, “Do this. Always check null point of access, always do that.” There is a new generation software development lifecycle that says, “Hey, don’t put the customer data into the open buckets. Make sure that you are not sending the passwords in the clear text.” So in other words, what I’m saying, shared responsibility’s also cloud providers, enterprise workers, also DevOps. So it’s all three combined together.

Dave Klein:
Very, very good. Very good.

Tom McAndrew:
Yeah. I’d just add I think the biggest challenge that we see is… So I just had dinner with about 20 different cloud CSOs the other night and we were talking about this. On one hand, this shared responsibility model’s been around for over a decade, and yet we still see the same problems with people moving stuff into S3 buckets and leaving them open, or not knowing what’s happening. So I think there’s really two components. I think the cloud providers have said, “Look, we’ve provided the education, we’re providing the tools, we’re transparent, and many customers just aren’t realizing what’s there, or remembering it.”

Tom McAndrew:
I think from a customer perspective, they’re saying it’s too complicated. You are the expert in your cloud, but I’ve got to work with three or four and the way that one organization does identity access management, is totally different. So that’s really kind of why we have the continued challenge. The cloud providers keep getting more technically complicated and the customers are, to be responsible you have to be responsible user of cloud, and that requires you to be a more and more technical expert. So what we’ve seen is more technical proficiency of organizations so that they’re using clouds correctly.

Tim Woods:
I think that’s why you see cloud providers now moving to some best practice or providing blue prints, they’re calling them, or foundation templates that the customers can follow, because that’s what the customers are then asking for. Exactly what Tom said, they’re looking for a best practice. Help me understand how to implement an S3 bucket. Help me understand how to implement my Hadoop big data store, and what are the best, you know other people have done this, so tell me what other people have done, what have you seen work, what’s successful, and how can I do it securely also at the same time?

Dave Klein:
Right.

Tom McAndrew:
And that’s really more of a solution versus services. The old way was, “Here’s all the stuff, you guys figure out how it works.” And we’re saying, “Well, you guys have millions of customers. What are some examples of how a bank has done, or a health organization,” and so like you said, these reference architectures, and some automations are now starting to grow.

Praveen Jain:
And that’s where the challenge also begins, right? So you are AWS, I have got the best practices for S3, now I want to deploy Google. I have gotten best practices for them. Controls are different, exporters are different. Now suddenly I have to worry about, “Oh, here it means this. Maybe here I apply the same best practices,” but they still left something open. So that’s where the multicloud security becomes so challenging at the end of the day.

Dave Klein:
Indeed it does. So another big question. What are the biggest mistakes that you see your customers doing in doing multicloud?

Tim Woods:
It’s not aligning the teams properly in the beginning. You need a prescriptive process in place. You need a way. History sometimes is the best teacher and we don’t always learn from it because we don’t go back and look at what we’ve done in the past, right? And I hear customers all the time ask me, it’s like, “God, if I could only do it again. If I could only start over.” We’ve seen people trying to take on readdressing, IP readdressing schemes because they went the wrong way and things like that.

Tim Woods:
But here people have an opportunity now where you’re talking about greenfield deployments, or even brownfield deployments sometimes as you’re going into the cloud, to take a page out of the history book and say, “What worked for us on PRIM? What did we do right, what did we do wrong? What should we be doing as we start looking at the cloud?” And I think asset management becomes a part of that as I’m deploying these applications. Who’s the business owner, what’s the business justification for that app, how are we going to tag this with metadata, how are we going to track it over time so that cloud sprawl doesn’t creep into the equation, and then how are we going to align our DevOps teams with our security teams so that we’re doing it so… You talked about the lifecycle application, but how do I get security into that lifecycle of my DevOps development teams too, right?

Dave Klein:
Yeah, excellent.

Tom McAndrew:
As we see people move into the cloud, security has been the number one reason why people have either not moved to the cloud or have been slow to move to the cloud for many, many years, and it continues to keep going that way. So I think we’ve really been trying to simplify this into, like you said, the most common things.

Tom McAndrew:
If you look it up, everyone’s got a bunch of different opinions. I think I really see three common areas for that. One is this lift and shift mentality of taking what does work, and just moving it to the cloud and assuming it’s going to be the same thing, and then from there you’re going to go and adjust it. If you’re going to move, you really have to look at the benefits and risks of what you had on PRIM and the benefits and features. So if someone’s doing a lift and shift, that’s bound to fail.

Tom McAndrew:
A second component, I think, I was talking to somebody else, and if we really did two things well, all the other stuff is kind of less important, and that’s managing access to data, and protecting the data. Those are the two things right?

Dave Klein:
Yeah.

Tom McAndrew:
I mean, that are happening. There’s other things about availability and things like that, that are important, but ultimately, people fail to understand what data they have, whether that’s sensitive information, PII, business intelligence. Organizations still don’t know what data they have, and if they don’t know what data they have, there’s no way they can get the right access into them, and that’s where they make the critical mistakes of moving sensitive data, or regulated data, and accidentally having it open to groups or public, and that’s really the biggest risk that most CSOs, or people moving to cloud are worried about. I’m going to move, it’s going to be open to public, and I’m going to be fire.

Tim Woods:
That’s right.

Tom McAndrew:
And that’s one of the biggest mistakes.

Dave Klein:
Yeah.

Praveen Jain:
Yeah, so to your original question about what mistakes people are making when they’re designing this multicloud strategy. Giving an example about naming the customer, so they decided they want to move to AWS, so they did all the work, designed everything, didn’t choose anything off the form of TerraForm or any of those things, so now they’re very locked into the APIs of this AWS now.

Praveen Jain:
Now the person who is the CIO, I was talking to him, and he says, “Suddenly the cost is a hockey stick. What I thought is a small cost, suddenly a hockey stick, and I want to explore new cloud, but there’s no way I’m moving out. It took so much time just to get onto the one cloud.” So in short, now we are starting to learn that the multicloud is important whether it’s because of cost reasons, or because of the type of the workloads you want to deploy. Thinking about the strategy where even if I’m not ready today, I’m ready five years from now. I think we need to do it in such a way that it suddenly doesn’t get into the API lock in, and security becomes even more challenging in this multicloud environment.

Praveen Jain:
So in short, I think just having a vision of five years out, saying, “Even if I’m not deploying today, I will get there one way or another.”

Tom McAndrew:
I would say maybe another thing is that there are some cases where that concentration is beneficial. Like we’re saying, the more technology you have, the more expertise you need to have, the more errors you could have. So there’s certain types of deployments, or certain applications where we see that, A, for most email systems, people aren’t distributing across multiple clouds, right? They’ve gone and consolidated that. But when it comes to back up solutions, they may have different versions. When it comes to development, or software availability. So I think the question is really to understand the organization that they have. What their technical skillsets are in their business rationales and the benefits of multicloud or few clouds.

Dave Klein:
So that brings up a great question. So there’s two things about this that are interesting. One is there’s premises, right? There’s still premises.

Tom McAndrew:
For most customers.

Dave Klein:
For most customers. There’s some people who come up, but really most customers are multicloud and their premises, and they’re probably going to be forever, and somethings will move around, but there’s also situations we talk about picking an email provider that goes into one cloud. We talk about you said generally applications stay in the particular cloud that they’re in.

Dave Klein:
But there’s things across the board. There’s visibility, for example. Visibilities huge, and the idea of being able to troubleshoot and figure things out, take advantage of the green fields and say what does my application look like over here, and go put it into the cloud, and how does it operate differently, as we talked about. So you have the visibility angle, and you have things like segmentation.

Dave Klein:
So the idea of all of these compliances are coming out. Talk about segmentation, and each vendor does it differently, right? There still premises and stuff like that. Where are the problems with the existing software that each cloud provider provides and what can fill that gap? How do we deal with situations where you have to be in the multicloud and have something that goes across all of it?

Tim Woods:
Sure.

Praveen Jain:
So I want to, at the start of this, when the Kubernetes came, we thought, “Wow, that’s a full table application I deployed.” And then everything works after that. It provides visibility and all this, but then you forgot suddenly, that’s a good job, very good step, but you’re only at an IES level, right? Application use, what database I’m consuming, what networking is… Endless things happening on top of that, right? That’s where each cloud provider provides tons of services, so just to stitch one application, either you bring your own, or use their native services, and then each of them have visibility.

Praveen Jain:
And let’s say Amazon has providers with PC logs, there’s a guard end logs are available. Now the problem again is that there’s tons of logs to consume.

Tim Woods:
That’s right.

Praveen Jain:
Tons of things to consume. So I would not say that they haven’t provided the visibility.

Dave Klein:
Correct.

Praveen Jain:
The issue is how to consume that data.

Dave Klein:
Correct.

Praveen Jain:
And once you consume in one cloud, now this is a multicloud discussion, I take my separate application to a second cloud, they have their own tons of data. So problem here right now is the summarization and the prioritization in a way that I understand these are most critical issues I need to address today. There will always be issues, what are the most critical issues? That’s what I feel like they need.

Tim Woods:
Tom touched on it earlier when he talked about complexity as all this stuff starts going out there. You do need to have better visibility around it, but we know as complexity goes up, the probability of error creeping into the equation, additional risk creeping into the equation, develops as well, so it’s not just visibility, it’s continuous visibility and we’re talking about a really dynamic environment here that can change across multiple different vectors at any given time, so how do I know when something shifts and moves and changes, and how do I know that my data controls moved along with that as well, right? Whether it’s native controls, whether it’s third party controls, whether it’s non-existing controls that are in there because it is, it’s a shifting environment that we have to stay on top of.

Tim Woods:
But visibility is definitely probably the main thing that we here from our customers as far as, even a barrier to adoption as well too.

Dave Klein:
Agreed. Mine too.

Tim Woods:
They’re very concerned about the lack of visibility it’s going to give them when they move their services there.

Tom McAndrew:
I think Dave your question earlier was what are the big challenges, I think one of the biggest challenges we have is we just call all clouds cloud as if they’re one common platform, and that’s like saying a horse, an airplane, and a car are just transportation.

Dave Klein:
Right, they’re all the same.

Tom McAndrew:
They’re all very unique, so we have a term, we talk about the cloud amigos is what we use. We use Amazon, Microsoft, IBM, Google, Oracle, as five of the common infrastructure cloud components that we see and of those folks, there’s a very broad spectrum between what do they do well? Well, it depends. Do you want someone to manage everything soup to nuts on there? Do you need a managed services with professional services on top? Some cloud offerings have that as a whole package. They’ll run everything for you, go buy it. Others of them are saying, “No. We will give you all the tools and all the training, but we’re hands off.”

Tom McAndrew:
So I wouldn’t really say that, it’s not necessarily that one is better or worse, it’s that they’re very different and people group them all in the cloud and if you have one expectation and you got another one, you have to realize you’re going to totally miss out on what you want.

Dave Klein:
Right.

Praveen Jain:
At the same time, when you’re dealing with multicloud environment, you don’t want to be a lowest common denominator where-

Dave Klein:
Correct.

Praveen Jain:
You abstract in everything and then suddenly you don’t give the capabilities of that available, so it’s a challenging problem, but you need some kind of summarization.

Tim Woods:
I think it goes back to what we talked about earlier too, understanding what you have responsibility for versus what they’re providing. If you don’t clearly understand that going into it, you’re going to hit some serious road bumps along the way.

Dave Klein:
We have some really good questions here that I think you guys are going to love, and again, please put in your questions as we go along.

Tim Woods:
Are we going to love them? I don’t know, we’ll see.

Dave Klein:
I think you’re going to love this. This one’s pretty cool. So this one here is with application code being tied to infrastructure, API calls from the cloud provider, how do you see changing the Ops landscape and the amount of time developers will have to spend supporting their applications between infraclouds, or interclouds, between clouds so the codes are intertwined? And I have some feelings on this, but I want to start with you guys.

Praveen Jain:
Yeah, so I think I would take it right from, let’s say, as I was saying earlier, Kubernetes layer, container layer, normalized data, so not a problem, right? But as I start using S3 buckets, API is this bucket, API is that all of that, right? So then I’m starting to tie up the cloud. What I have seen is that people have island soft applications. Some applications are going AWS, you’re not saying that now this application is going to move to Azure tomorrow, right? For example, one customer I was talking to, he said, “It took me so much effort taking my application,” it was a brand new application, or old one, doesn’t matter, “deploy on the cloud. Now any problem happens, I have to be able to debug it. I have to be able to respond to my business leadership saying why the application was down,” so I said I built all the processes around it. Now if you tell me and take that application and go to Azure because offhand reason, I’m not for it. I’ve already deployed it, right?

Praveen Jain:
Another island, another application, definitely you can take it there. So it’s very hard to normalize API where you build an application and completely portable. Data is another issue. So you have databases sitting in one cloud, how will you ort it to another cloud? So it’s usually you have independent pockets of applications which go to independent clouds.

Dave Klein:
Got you.

Tom McAndrew:
For that, maybe I’ll tackle the security slant that, which is where things are going in development in the cloud. So I think we’ve really gone through three different phases. The first phase, we would just train developers on security best practices, OWASP, or whatever. And then they’d have to periodically prove it. Once a year by showing-

Praveen Jain:
They don’t.

Tom McAndrew:
Something they need to have, whether it be an audit, or some code review, you find some issues and you fix it. The next phase we’re kind of getting into is something where they realize that they can’t just, what we call the they can’t just go through it and then wait 12 months and come back, they’re constantly being bombarded now, so some organizations are going through audit fatigue where they’re saying, “Look, my job is develop, but all you’re doing is asking me over again how I’m doing and how I’m doing it secure,” and they’re running into audit fatigue.

Tom McAndrew:
What we’re really seeing the kind of the automation of security in the feedback loop into the process. So when we talk about security orchestration, automation, and response, it’s making sure that you’re developing the code correctly, that you’re testing it as it’s rolling out, and when there are issues, it’s not just flagging for someone to follow-up, but it’s actually automatically responding and either segmenting those networks, or delaying that code.

Tom McAndrew:
So I think for developers to be thinking about this transition of SOAR, and how that leads into AI and machine learning, and all the stuff down the line, depending on the size of your organization, you may be getting closer to that, or you may be in the very beginning stages of the wild, wild west of, you know what? We trained them and hopefully they’re doing the right thing.

Dave Klein:
But let’s dive into that more deeper because I think that’s really kind of important. So with the APIs being separate for each vendor, one thing I see as uniform, as I’ve developers use Chef, Puppet, Ansible scripts, across everywhere, right? And back to what you’re saying about bringing them into the fold, they’re truly doing agile development today. It really is not a once a year, let’s take a look at the audit, workloads are being spun up and spun down-

Tim Woods:
It’s truly continuous, yeah.

Dave Klein:
Truly continuous. So what are some of the methodologies that we can use to keep them, and really do shift security left?

Tim Woods:
First off, you’re talking about two opposing attractions almost. You’ve got one team over here that’s compensated, or is motivated by speed, and you’ve got another team when you’re talking about security, they’re motivated by monitoring, audit, control, so it’s kind of opposing there. So some way or another, somehow it has to be more infused from a real-time capacity, so that we have to understand the DevOps culture and what drives that and anything that slows it down is probably going to get kicked off the bus fairly soon, but we also have to understand the processes that security uses in order to integrate.

Tim Woods:
So at some point or another, I mean I think for both, I think we’d all agree that we’re tilted in the wrong direction. Somehow we have to find a medium ground that’s going to work for everybody, but it’s definitely, some people are discussing it up front right now at the C-level, and some aren’t.

Tom McAndrew:
Yeah, that’s a good… The CSOs were talking about, I thought this was a great approach, this CSO said, “My goal is not to have anybody underneath me.” He’s like, “This whole idea of development and security being different or opposing forces,” like you said, there’s that natural, but he’s like, “We’ve learned that we don’t want to sprinkle security on top, we want to build it in, so why would I have a security team that’s independent from the developers?”

Tim Woods:
Right.

Tom McAndrew:
So what this CSO did is built the teams up and then purposely reorged them and pushed them back into the organization so they could work together, and I think that’s what we’re seeing more and more as developers that are feature rich, understand that they developed something great and there’s this security issue with it. That’s not good for them. The security guys realize if they just keep raising their hands and saying, “No, this isn’t good enough,” they’ll slow the pace of innovation for a business, so those two folks have to come together so that you’ve got the right risk and innovation happening with the right security.

Dave Klein:
Right.

Praveen Jain:
So with the developers, anytime when you’re moving very, very fast, there’s always a chance that you’ll make a mistake, right? So that’s with the DevOps, with the right intentions, are moving very, very fast. On the other hand, security team, in this process, is not able to catch up with them, so that’s where the automation fits in, right? So now think about it where while they’re putting the code into production you’re able to put title control and maybe a monitor that what exactly is happening. The reason somebody leaked customer’s data because they were moving very, very fast, they left it open in the Amazon bucket, it’s very easy, right? Really easy to do.

Tim Woods:
It happens.

Dave Klein:
It happens.

Praveen Jain:
So that’s where the automatic platform, or automated security stuff brings the two worlds together, right? Where you don’t slow down, but at the same time keeps your checks and balances in place otherwise things will happen.

Tom McAndrew:
But like you said, the cloud, if you’re a AWS with Macie, it used to be cloud trail and you can get some understanding of what’s happening, but now with Macie and some other tools you have, well if you make a mistake, how will it be caught? And so I think as we look at it, as we all agree, that people will make mistakes, it’ll happen, rather than going back and hitting people, look at it, say, “How quickly are we finding it,” are we catching it before the bad guys? And then are we learning from it so we’re not making the same mistake two years later, three years later, two months later, so that automation’s big, but to your point earlier, it’s challenging because the APIs are different and where we are seeing some consolidation is around logging and monitoring SIM solutions, right?

Tom McAndrew:
If you think about those folks, Splunk acquiring how Phantom works, and some of those other changes. So the cloud providers themselves are adding more features, but there’s two or three kind of common tools that we see many folks, and these cloud providers realize they have to either work with them, or else they’re going to lose the customers. The cloud providers are becoming a little bit more open to sharing that data.

Dave Klein:
Right.

Praveen Jain:
Yeah, and actually to your point, that’s how they have this Google Security Center, or AWS Security Hub and all that where other security vendors can come in and integrate. So I think from security perspective, it makes sense that having a unified tool, I mean, obviously there cannot be one unified tool for everything, but for a given set of problems, one unified tool, which is across multicloud and on-prem, which kind of takes care of it holistically, underneath, hides the APIs because ultimately that’s what you’re trying to protect.

Dave Klein:
Right. I think that’s the biggest opportunity in the next five years, is these manager managers perspective of, whether it be segmentation, visibility, or automation, is something that can work across all the cloud providers seamlessly.

Tim Woods:
I think the future is going to revolve around collaboration of the teams, right? It’s collaboration of the security teams, it’s collaboration with compliance, with the business owners, with DevOps. I mean, everybody has to have an ability to take part in the conversation and have input. Yeah, security can create the guidelines, but that security intent that we define around those application assets and resources really become the driving factor, right? It helps develop that global policy that everyone kind of aligns to.

Tim Woods:
What we right now is, I’m calling it, and some people take exception to this, but I’m calling it fragmented security-

Tom McAndrew:
Yeah, absolutely.

Tim Woods:
Or fragmented responsibility that we see forming across the cloud on who’s actually taking responsibility for the security configuration as I roll my different pieces of code out, or my applications, or I’m deploying an asset out there in the cloud, and we’re getting away from a controlling, a central security policy, that can dictate how we should… And moreover, the compliance around that too. We talked about it earlier, what are the regulatory compliance things that I have to be aware of? And a lot of these DevOps teams, they’re not getting that’s not on their radar. It’s not in their headlights, and then when we hit that, but security by design and default? Think of GDPR, think of the California Privacy Act, anything that touches personally identifiable information, right? And if you don’t align, the teeth are getting bigger from a financial responsibility, as well. If you get fined, the teeth are only going to get bigger, and if you’re found at fault that you didn’t put security in the front of the conversation, then there’s going to be bigger debt to pay.

Dave Klein:
Go ahead.

Tom McAndrew:
I was going to say, you mentioned this, but the… I mean, if you’re a security person right now who’s slowing things down, you should be fired. Because right now security needs to be about enabling the business and to be tied to differentiating the business. What we’re seeing is where security used to be an overhead or a cost, security is now becoming a differentiator because what are businesses worried about? They’re worried about innovation, they’re worried about costs, they’re worried about making sure that they can stay competitive out there and security’s a huge component of that.

Tom McAndrew:
So that’s what we’ve seen before where folks that historically looked at compliance initiatives and things like that and think of them as little, say, “Well, if your sales force can’t sell the product because companies are asking how are you HIPAA compliant, or HITRUST compliant, or how are you protecting GDPR, and your competitors have those things, it does matter.” So you know, thinking about security and privacy, we’re just now starting to get there where we, as consumers, are making conscious decisions to choose products that maybe even though they cost a little bit more, it’s really if they’ve got higher levels of assurance, of security, or privacy, we’re willing to move our data there.

Praveen Jain:
Only thing I would say is don’t fire him, retrain him.

Tom McAndrew:
I’m the CEO.

Dave Klein:
I want to definitely spend some with more on the compliance, I want to get back to that, but I want to get back to the DevOps and security people. I think we all agree that really, it’s no longer a conflict model, it has to be a case of the security person has to say, “I have to accelerate growth and competitive differentiation. I have to reduce risk at the same time, and you’re the DevOps guys, I’m your ally. We’re working together, and I’m teaching you things to continue to use those scripts to automate things, but do a Kernel check. Do a patch check when you push it out so that five years from now that application continues to evolve and be healthy versus something else,” so there’s that angle from it from a psychology perspective.

Dave Klein:
Then secondly, I think the biggest thing is the language. Is that the idea is the language of security people is totally aligned with the business and with the developers and speaking their language, understanding what’s important for them.

Tim Woods:
Yeah, it’s a common culture that has to develop within the company, right? You can’t just have the DevOps culture, and security culture, and the stake… Over time, this is going to have to evolve into a common culture for these organizations.

Dave Klein:
And evolve. So let’s talk about compliance. So for me, and in my customers and prospects, the biggest thing is compliance. The biggest adoption of security from our solution perspective is to stop compliance problems, and we have some compliance out there these days. GDPR is one. The California one, we’re in California today, is going to have the same kind of teeth, or even better teeth than GDPR, and the thing is if you sell to people in California, you are part of that standard whether you want it or not, so what are you seeing as far as adoption of better security in the clouds?

Tom McAndrew:
Well, I’ll tackle it. So we are the largest provider of compliance solutions across all cloud providers. So anybody that gets something from Amazon or Microsoft, Google, you’ll get a report where we’re doing some of the third party attestation work along with them. I think there’s a couple things that are really happening within the group. One, the infrastructure stuff has been under regulation and scrutiny for a very long time. It’s now, what we’re seeing is the next evolution’s really on the software and that stack. So the infrastructure folks, they get it. They’ve been doing this for a long time. In order to convince folks to come over they’ve had to deal with that.

Tom McAndrew:
I think there’s two real trends that we’re seeing, one, the number of services are increasing at an exponential rate. So it used to just be we are cloud provider, we provide one service, two services. Well the first thing we do when we sit down, we say, “Well, what’s the roadmap for the next three years?” And they show all these services they’re going to do. And I said, “Well, you’re struggling meeting GDPR today for this one product, what’s your answer going to be when you have 40 products?” So thinking about compliance and security as part of their evolution as they scale in service is one.

Tom McAndrew:
And the second part for a business, we say, “Well, what sort of customers are you going to be working with?” So if you are financial services and you work with GLBA, and you’ve done your SOC, and now you want to go into healthcare, you say, “Well, those customers, they’re not interested in speaking GLBA language, they’re interested in HITRUST or HIPAA,” so all those areas I think are evolving.

Tom McAndrew:
I do think there’s kind of two general areas. There’s one, you’ve seen kind of the security regulations that have been out there, but privacy and that data protection is now the next thing that’s really been happening over the last little bit where people are saying, “Well, how is privacy different than security?” And there’s a lot of nuances that make it very different.

Praveen Jain:
So with the all these things changing so fast, it’s very hard to define what compliance requires, right? Because now in the static workflow you define some policy, some technical controls, and said, “This is it, once comes in, he knows what to check on.” Whether reducing the number of services, or whether the DevOps somebody created this new code base and now that exposes something which is not in your radar, right? Because it’s just moving so fast. So I think in short, if somehow taking those static compliance specifications, but at the same time taking the dynamism and the way we are moving, somehow we need to bring those two worlds together, then we know whether you are really compliant or not. Right? That’s where-

Tom McAndrew:
Well that is exactly what’s happening now, what we call continuous monitoring, or continuous diagnostics mitigation, CDM, right? If you think of FedRAMP, which is what the initiative is for federal there’s already 76 controls that are there daily, weekly, monthly, so this idea of I have a piece of paper and I’m good for a year is going away, and like I said, it’d becoming much more software and design oriented-

Praveen Jain:
Exactly that.

Tom McAndrew:
More frequent with higher level data and higher assurance. We’ve got organizations that have over a million assets. Sampling even 100,000 provides no real value into it, so we have to assess the way that those assets are created.

Praveen Jain:
Exactly, and that’s-

Tom McAndrew:
And the way they’re monitored so that you can provide assurance across millions of assets.

Praveen Jain:
cannot figure out out of your 100,000 what is really mapping to this or that, so that’s where all this software compliance, framework, all the platforms, are helping now, right? That’s move forward.

Tim Woods:
It goes back to looking at the visibility across the infrastructure too, right? If you don’t have the visibility, we say this, it’s kind of a cliché, but it’s true, you can’t manage what you can’t see. You can’t secure what you don’t know about, right? And you pick a regulatory compliance initiative, I don’t care what it is, whether it’s HIPAA or HITRUST or FISMA or GDPR, whatever. They all ask, “Are you monitoring for change?” It’s one of the first things they always ask, “Are you monitoring for change, yes or no?” If you say no right up front, you fail. Do not pass go.

Tim Woods:
So it gets back to the common, the core conversation of visibility. How do I extend visibility across those adopted cloud platform, across my hybrid… Because I can’t take my eye off the ball in the on-prem either, but if I’m going to be compliance, if I’m going to prove compliance, I have to have visibility to those things that I’m responsible for having compliance responsibility around.

Dave Klein:
Right.

Praveen Jain:
And the good news is once you, let’s say, created this platform, and once you have this software platform which is doing a good job, these requirements do not change whether you’re in one cloud, two clouds, three clouds, or on-prem.

Tim Woods:
That’s right.

Dave Klein:
That’s correct.

Praveen Jain:
It’s the same dashboard, same view, so that’s the good news.

Tim Woods:
That’s right.

Dave Klein:
We have a question from the audience. Again, we have a lot of wonderful questions here, I can’t get to all of them, but please submit some more. We were kind of talking about this going down this line of conversation is, how are organizations, how should they adapt or align to existing security IT frameworks like ISO27001, COBIT, NIST, and this kind of plays into what you were talking about earlier is we can learn from history, learn from what we did before, and utilize it today. So the key is, what frameworks are your customers using?

Tom McAndrew:
Sure. So I’ve spent many late nights on this, so five or seven years ago when there was a small number of frameworks, we all started creating what we called these common control frameworks, so it’s here’s your FFIC, and here’s your PCI, and you get two of them. What we found is that is a losing… Nobody is doing that now. If you’re still building common controls and trying to map that out, that doesn’t really work because they’re changing so frequently.

Tom McAndrew:
Instead, what we’re seeing is people are mostly basing it around, at least in our experience, two different main controls. So they’re mostly doing kind of the NIST cybersecurity framework for their core technical controls, and then ISO for their policies, and using those as a foundation to then leverage up, because one, it adds consistency, and two, there’s so many free mapping tools and regulations that if you’re following those two, with certain overlays, these are what you can have.

Tom McAndrew:
The exception may be if you have a very purpose built application or system for a specific industry then it may make sense to build it all around HITRUST or something, but if you’re going to deal with multiple compliance areas, most folks generally get to the ISO and NIST as the foundation.

Dave Klein:
Those two as the…

Praveen Jain:
And also what is happening is apart from the frameworks, any security vulnerability is ultimately a compliance. Maps to somewhere or another compliance issue, right? Let’s say recent vulnerability of runC in Kubernetes, right? If, let’s say, I was following some frameworks, and runC vulnerability is not detected by my platform, that’s not good either, so in other words, if you’re taking the live feed. Let’s say runC vulnerability is detected, you took a live feed and said, “Oh yeah, I need to start checking this for my compliance and map it to appropriate bucket,” that would be ideal, right? So that’s where it’s not just a static. Dynamic information you pull from the feeds, and apply your knowledge of how you’re utilizing, and then presenting something to the.

Dave Klein:
Got you, excellent, perfect. Let’s see here, this is another one, another question from the audience here. How do you see implementation of disposable infrastructure aiding in multicloud deployments and operation services and resources that are rebuilt through CICD pipelines to insure pedigree?

Praveen Jain:
What did you say?

Dave Klein:
I was thinking the same thing, I got to be honest with you folks. But it’s interesting, so disposable infrastructure, aiding in multicloud deployments and operation services, and how does that work.

Tom McAndrew:
So I’ll tackle one level, when we talk about the, rack huggers is one thing we talk about. People that love physical things.

Dave Klein:
They’re rack huggers.

Tom McAndrew:
We have some organizations that say, “Look, if I don’t see the blinking light, not at the data center, I don’t trust it.”

Dave Klein:
Tap the table.

Tom McAndrew:
And I think with cloud, with had this migration that physical things don’t matter. I tell my kids that all the time, right? Things don’t matter. So this idea of if we really think of the physical assets as disposable, and you really believe that, you really start running IT the same way, that every physical thing is a liability. You don’t want a thing, you’re actually trying to get the output of that thing, and then you’re then managing those services.

Tom McAndrew:
So I think what you’re seeing is this change of, we had it before, right? Just like we had to build all the components to get our IT infrastructure, now we have to start buying services to build the infrastructure. So I think what that’s going to change is it’s less of people creating a physical device and then making it a virtual device in the cloud, instead you’re going to say services that are all coming together, and thinking that if you do it and you architect it the right way, you can move from one to another if you’re defining the services the right way. If you’re just doing the lift and shift and you just virtualized it, you’re going to be stuck in exactly that thing because you customized it so much.

Tim Woods:
Well there, look, you see applications tied specific to hardware tuning. You look at a specific piece of hardware and the application’s kind of tied to the performance of that hardware platform.

Tom McAndrew:
Right.

Tim Woods:
When you go into the cloud, the performance parameters change, right? So your applications have to conform to that as well. So you have to take that into consideration, but once you successfully bridge that gap, then you’re a lot better off.

Tom McAndrew:
I think the extreme of that is serverless enterprise.

Tim Woods:
That’s right.

Dave Klein:
Yes.

Tom McAndrew:
That’s the next thing of why virtualize a physical thing if we don’t care about it? Can we re-architect it? So that is another area where we’re seeing, not many, but we are seeing some adoption for those serverless enterprises.

Dave Klein:
Excellent, excellent. So here’s another question from the audience. Open source versus vendor products for cloud security. How should companies balance product offerings and narrow down what level of visibility and control they need?

Tom McAndrew:
Sure.

Dave Klein:
I could say to begin with, regardless if it’s a vendor or open source, applicability to multicloud and premises is important. If they have that, to me, you’re covering multiple bases, or that’s kind of my background. There are probably reasons in choosing open source versus product vendors. What are some of the reasons why you would choose those?

Tim Woods:
I-

Praveen Jain:
I think-

Tim Woods:
Go ahead.

Praveen Jain:
Go ahead.

Tim Woods:
I was going to say that I think right now, if I’m a consumer of the technology today, one of the very first things that I’m going to look at for the products that I’m selecting at the very top, is interoperability. I want to know that the vendors that I choose, whether that’s an open sourced piece of code, or whether that’s a vendor supported piece of code, I want to know that that API is well structured and well supported for the future, because whether I’m using it today or not, the ability to exchange information in between, the ability to enhance one of my other platforms from information from one of my other platforms is going to be critical, I think, into the future, and I should be able to do that somewhat seamlessly.

Tim Woods:
So if you’re selecting technology that doesn’t have a commitment to an open API, to a structured API, to a robust API, then I think you’re making a mistake from the beginning.

Praveen Jain:
I change the question a little bit because it’s not about whether it’s open source versus non open source, I think question is more about whether it’s a supported platform or not because I can have a great open source software, which I want to take, but it’s supported by the company, they have a license model-

Dave Klein:
That is critical.

Praveen Jain:
They have a commercial model. I like it, right? So I think it’s all about applicability. If suppose this product has the full support, it’s able to take the live feeds, right? It should not become that, let’s say as we were talking about compliance just now, it should not become that I picked a product who’s lagging behind three months or four months on getting me the new vulnerability check, new vulnerability which was found in the market, that is not good, right?

Dave Klein:
Yes.

Praveen Jain:
But it’s all about taking a product with a full community or full company behind it who can support me and also move at the agile speed which is required now.

Tom McAndrew:
Tim brought up earlier about the importance of the people. I think for us, the biggest part is realize your labor force. If you’ve got a labor force who’s used to Linux, and you’re going to move to AWS, that might be easier than Microsoft, but if you’ve got Microsoft developers that are doing work and now you want to shift to AWS, that may not work. So I think a key part is not so much, the failures we see are not so much the technical features of what you’re moving to, but your labor force, and then like he said, do you train them to have the right force, or do you have to end up augmenting or changing them?

Praveen Jain:
Yeah, don’t fire.

Tom McAndrew:
So yeah, I think a key component of those two things is really to understand what your labor force with the technology you’re doing.

Tim Woods:
That’s true. I think at the strategic level too, when you’re talking at the C-level, you look at their strategic initiatives, it’s always interesting to me to see what technologies are interlaced into those strategic initiatives, but right below that, and that’s whether it’s technology they already own, or technology they’re going to acquire, or technology they’re trying to aggregate, but I’m always interested in the people aspect of that.

Tom McAndrew:
That’s a huge, it’s the biggest part of it.

Tim Woods:
I had that technology, but how am I empowering my people to use that technology that I’ve selected to achieve our corporate goals?

Dave Klein:
That’s extremely important.

Praveen Jain:
Like Tim was saying earlier about the APIs, which is also very important aspect, because let’s say I picked up a product, and let’s say I don’t have a vendor ecosystem to give me a single point of SOAR, or whatever it is, so let’s say if I didn’t have an API, I will not be playing to that ecosystem, so it’s really important that once I have the APIs, I picked up a product which has full support, open APIs, integration with ecosystem partners, so hopefully I don’t have to have thousands of product for security, just few, very few where I can do the job. So it plays a very important role in that.

Dave Klein:
So one of the last questions I have, and I thought this was quite interesting in talking to a lot of my customers this year, the larger ones who have multicloud, one of the reasons for multicloud often they have partners. Partner applications, or vendors, or customers that have to tie and be inside their networks, and I’m actually seeing a trend, which I thought was really fascinating, is almost like an advisor to the smaller vendors, customers, or whatever they are, because often they find where the inherent risk is, is with the ones who are smaller who don’t have the education, and they’re becoming mentors or mentorees and that kind of thing. Is this something you’ve seen out in the field a lot?

Tom McAndrew:
Yeah, I mean, absolutely. I think there’s, I mean, when you look at these marketplaces, or these app stores that they’re all creating, again, the infrastructure piece has been there, but the majority of the revenue and the business is in the application. If you think of Salesforce, you think of SAP, you think of all those different folks that are running the application that’s there, so there’s all these smaller little folks that are there that are also playing as part of it, and people pick them, and they find out they don’t play well, or there’s an upgrade on the infrastructure and they become a legacy product, so those organizations are really becoming much closer to those partners and one, sharing what they’re doing in future releases so those partners aren’t just reacting to what’s released, but two also, I think organizations should be very careful of is that smaller vendor going to be obsolete or be replaced by something else?

Tom McAndrew:
And that’s always a hard thing of how do you differentiate, and is that really a unique differentiated asset you want to maintain, or are you willing to take the generic solution or something that may be bigger that may have some more innovation tied to it in the long run?

Dave Klein:
Got you. Excellent. I think we have time for one more question. One thing that, a big technology, 5G, has come out, and we were talking about this in the prep call before we met here today. How’s 5G going to affect things in the cloud?

Tom McAndrew:
I think, I’ll talk, I think one of the biggest parts, and someone brought this to me a couple of years ago, I was like, “How’s faster speed in my cell phone have anything to do with the cloud?” Was kind of my initial reaction. I think what people don’t realize and you’re seeing this so much in the news, it is going to fundamentally change what we’ve got. Gig speeds coming to your devices and less latency. So if you think of today I looked at my home, I had 63 things connected to the internet. You think about 10 years ago we had two or three. Those things now, we’re going to continue to grow exponentially, but now those things are all going to my home wireless router, I have some protection. In the future, they’re going to be going directly out, and that’s going to totally change the security construct.

Tom McAndrew:
So these cloud providers know about that. The telematics know this. So it’s going to further expand the problem we have of these borderless cloud things of when you’ve got physical devices or pacemakers reaching straight out to applications in the future, it’s going to change it. So I think people should be aware that these 5G concerns are going to happen and as they’re focusing so much on building cloud infrastructure and that today, if mobile users or devices are part of your environment, you need to be thinking about that because it’s going to change quite a bit in the next two or three years.

Dave Klein:
Definitely.

Praveen Jain:
So I think the conference we would have is multicloud and edge security.

Dave Klein:
Agreed, 200%.

Praveen Jain:
Right? Because with 5G, if you think about it now, the edge cloud is started in multi, right? So far we’re not able to consume multicloud, now edge cloud.

Tim Woods:
I know at our house, it’s the more you can stream, the more you will stream.

Tom McAndrew:
Absolutely.

Dave Klein:
Absolutely.

Tim Woods:
The more you can stream, the more you will stream, that’s for sure.

Dave Klein:
Excellent, excellent. Well Praveen, Tom, and Tim, thank you guys so much, this has been really a fun conversation.

Praveen Jain:
It was fun.

Dave Klein:
And for everyone out there, thank you so much. Again, this is BrightTALK, this is Dave Klein saying goodbye, take care.

Read more

Get 90% Better. See How to Get:

  • 90% EFFICIENCY GAIN by automating firewall support operations
  • 90%+ FASTER time to globally block malicious actors to a new line
  • 90% REDUCTION in FTE hours to implement firewalls

SCHEDULE A DEMO