(upbeat music) >> Announcer: From downtown San Francisco, it's theCUBE. Covering RSA North America 2018. >> Welcome back everybody, Jeff Frick here, with theCUBE. We're at RSA Conference 2018 in downtown San Francisco, 40,000 plus people, it's a really busy, busy, busy conference, talking about security, enterprise security and, of course, a big, new, and growing important theme is cloud and how does public cloud work within your security structure, and your ecosystem, and your system. So we're excited to have an expert in the field, who comes from that side. He's Tim Jefferson, he's a VP Public Cloud for Barracuda Networks. Tim, great to see you. >> Yeah, thanks for having me. >> Absolutely, so you worked for Amazon for a while, for AWS, so you've seen the security from that side. Now, you're at Barracuda, and you guys are introducing an interesting concept of public cloud firewall. What does that mean exactly? >> Yeah, I think from my time at AWS, one of my roles was working with all the global ISVs, to help them re-architect their solution portfolio for public cloud, so got some interesting insight into a lot of the friction that enterprise customers had moving their datacenter security architectures into public cloud. And the great biggest friction point tend to be around the architectures that firewalls are deploying. So they ended up creating, if you think about how a firewall is architected and created, it's really designed around datacenters and tightly coupling all the traffic back into a centralized policy enforcement point that scales vertically. That ends up being a real anti-pattern in public cloud best practice, where you want to build loosely coupled architectures that scale elastically. So, just from feedback from customers, we've kind of re-architected our whole solution portfolio to embrace that, and not only that, but looking at all the native services that the public cloud IaaS platforms, you know, Amazon, Azure, and Google, provide, and integrating those solutions to give customers the benefit, all the security telemetry you can get out of the native fabric, combined with the compliance you get out of web application and next-generation firewall. >> So, it's interesting, James Hamilton, one of my favorite people at AWS, he used to have his Tuesday Nights with James Hamilton at every event, very cool. And what always impressed me every time James talked is just the massive scale that Amazon and the other public cloud vendors have at their disposal, whether it's for networking and running cables or security, et cetera. So, I mean, what is the best way for people to take advantage of that security, but then why is there still a hole, where there's a new opportunity for something like a cloud firewall? >> I think the biggest thing for customers to embrace is that there's way more security telemetry available in the APIs that the public cloud providers do than in the data plane. So most traditional network security architects consider network packets the single source of truth, and a lot of the security architecture's really built around instrumenting in visibility into the data plane so you can kind of crunch through that, but the reality is the management plane on AWS and Azure, GCP, offer tremendous amount of security telemetry. So it's really about learning what all those services are, how you can use the instrument controls, mine that telemetry out, and then combine it with control enforcement that the public cloud providers don't provide, so that kind of gives you the best of both worlds. >> It's interesting, a lot of times we'll hear about a breach and it'll be someone who's on Amazon or another public cloud provider, and then you see, well they just didn't have their settings in the right configuration, right? >> It's usually really kind of Security 101 things. But the reality is, just because it's a new sandbox, there's new rules, new services, you know, and engineers have to kind of, and the other interesting thing is that developers now own the infrastructures they're deploying on. So you don't have the traditional controls that maybe network security engineers or security professionals can build architectures to prevent that. A developer can inadvertently build an app, launch it, not really think about security vulnerabilities he put in, that's kind of what you see in the news. Those people kind of doing basic security misconfigurations that some of these tools can pick up programmatically. >> Now you guys just commissioned a survey about firewalls in the cloud. I wonder if you can share some of the high-level outcomes of that survey. What did you guys find? >> Yeah, it's similar to what we're chatting. It's just that, I think, you know, over 90% of enterprise customers acknowledge the fact that there's friction when they're deploying their datacenter security architectures, specifically network security tools, just because of the architectural friction and the fact that, it's really interesting, you know, a lot of those are really built because everything's tightly coupled into them, but in the public cloud, a lot of your policy enforcement comes from the native services. So, for instance, your segmentation policy, the route tables actually get put into the, when you're creating the networking environment. So the security tools, a network security tool, has to work in conjunction with those native services in order to build architectures that are truly compliant. >> So is firewall even the right name anymore? Should it have a different name, because really, we always think, all right, firewall was like a wall. And now it's really more like this layered risk management approach. >> There's definitely a belief, you know, among especially the cloud security evangelists, to make sure people don't think in terms of perimeter. You don't want to architect in something that's brittle in something that's meant to be truly elastic. I think there's kind of two, you know the word firewall is expanding, right, so more and more customers are now embracing web application firewalls because the applications are developing are port 80 or 443, they're public-facing web apps, and those have a unique set of protections into them. And then next-generation firewalls still provide ingress/egress policy management that the native platforms don't offer, so they're important tools for customers to use for compliance and policy enforcement. They key is just getting customers to understand thinking through specifically which controls they're trying to implement and then architect the solutions to embrace the public cloud they're playing in. So, if they're in Azure, they need to think about making sure the tools they're choosing are architected specifically for the Azure environment. If they're using AWS, the same sort of thing. Both those companies have programs where they highlight the vendors that have well-architected their solutions for those environments. So Barracuda has, you know, two security competencies, there's Amazon Web Services. We are the first security vendor for Azure, so we were their Partner of the Year. So the key is just diving in, and there's no silver bullet, just re-architecting the solutions to embrace the platforms you're deploying on. >> What's the biggest surprise to the security people at the company when they start to deploy stuff on a public cloud? There's obviously things they think about, but what do they usually get caught by surprise? >> I think it's just the depth and breadth of the services. There's just so many of them. And they overlap a little bit. And the other key thing is, especially for network security professionals, a lot of the tools are made for software developers. And they have APIs and they're tooling is really built around software development tools, so if you're not a software developer, it can be pretty intimidating to understand how to architect in the controls and especially to leverage all these native services which all tie together. So it's just bridging those two worlds, you know, software development and network security teams, and figuring out a way for them to collaborate and work together. And our advice to customers have been, we've seen comical stories for those battles between the two. Those are always fun to talk about, but I think the best practice is around getting, instead of security teams saying no, I think everybody's trying to get culturally around how do I say yes. Now the burden can be back to the software development teams. The security teams can say, here the list of controls that I need you to cover in order for this app to go live. You know, HIPAA or PCI, here are these compliance controls. You guys chose which tools and automation frameworks work as part of your CI/CD pipeline pr your development pipeline, and then I'll join your sprints and you guys can show incrementally how we're making progress to those compliance. >> And how early do they interject that data in kind of a pilot program that's on its way to a new production app? How early do the devs need to start baking that in? >> I think it has to be from day zero, because as you embrace and think through the service, and the native services you're going to use, depending on which cloud provider, each one of those has an ecosystem of other native services that can be plugged in and they all have overlapping security value, so it's kind of thinking through your security strategy. And then you can be washed away by all the services, and what they can and can't do, but if you just start from the beginning, like what policies or compliance frameworks, what's our risk management posture, and then architect back from that. You know, start from the end mine and then work back, say hey, what's the best tool or services I can instrument in. And then, it may be, starting with less cloudy tools, you know, just because you can instrument in something you know, and then as you build up more expertise, depending on which cloud platform you're on, you can sort of instrument in the native services that you get more comfortable with then. So it's kind of a journey. >> You got to start from the beginning. Bake it in from the zero >> Got to be from the zero. >> It's not a build-on anymore. All right Tim, last question. What are we looking forward to at RSA this week? >> I'm very cloud-biased, you know, so I'm always looking at the latest startups and how creative people are about rethinking how to deploy security controls and just kind of the story and the pulse around the friction with public cloud security and seeing that evolve. >> All right, well I'm sure there'll be lots of it. It never fails to fascinate me, the way that this valley keeps evolving and evolving and evolving. Whatever the next big opportunity is. All right, he's Tim Jefferson, I'm Jeff Frick, thanks for stopping by. You're watching theCUBE. We're at RSAC 2018 in San Francisco. Thanks for watching. (upbeat techno music)