(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)