>> Announcer: From downtown San Francisco, it's The Cube, covering RSA North America 2018. >> Welcome back, Jeff Frick with The Cube. We're at RSAC, the RSA Conference North American in San Francisco, 2018. 40,000 people, it's an amazingly huge and growing conference, 'cause security is obviously at the forefront of everything, especially as everything moves to devices and services and cloud, we can't forget security and we're excited to have somebody who's kind of got to a third-party validation kind of point of view on the marketplace to get their perspective. It's Jason Brvenik and he is the Chief Technology Officer for NSS Labs. So, Jason, great to meet you. >> Great to meet you. >> So for people that aren't familiar with NSS Labs, give us kind of the overview of what you guys are all about. >> We work with enterprises to understand their needs in security, and then, build and create test environments that create real-world conditions to assess whether or not a product is a good fit. We create comparable environments, so that we can understand fundamentally whether or not the products are delivering on their claims. >> Right, and recently you've done some work around the data center intrusion prevention systems group test. >> Mm-hmm. >> It's a mouthful. What is that all about? >> Well, that's all about the recognition that data centers are the keys to access for most organizations and appropriately protecting them is not as easy as deploying a firewall. You need to have much greater inspections on the interactions with systems, whether or not security's being provided within the application layers, being properly secured, and so, latency and performance and effectiveness against attacks are all measured and then presented in a set of group test reports. >> Right. So, must be getting increasingly complex, 'cause there's all these different components now that build up a solution. Right? It's not just one set of applications, that you're pulling maybe public data sources, you've got a bring-your-own-devices, you've got this huge string of things that are all pulled together. How do you incorporate that into your testing? How do you figure out how these things work together? 'cause ultimately, that increases your attack surface area, vulnerabilities, I would imagine. >> Certainly, and we create an environment, an architecture that we propose, that based on our interactions with the enterprises, it's fairly representative of what an enterprise would have, and then we create or simulate the types of interactions you would have with the different systems, generate attacks against them, and measure whether or not the products are able to sustain a concerted attack from an adversary. All the way into creating evasive techniques, so that an attack that is known to be blocked by a technology, we would apply different techniques to make it evasive and see if we can evade the security controls and to measure those. >> So how accurate are people, not to call anybody up, but how accurate are people in assessing the effectiveness of their own products and solutions? >> That's an interesting mixed bag. >> I'm sure it must run the gamut, right? >> It does, it does. >> Well, we don't want to call out any, beat anybody up, but I would imagine there are some that are just, Are they just looking at the wrong thing? Or how do you sort that all out? >> It's interesting to see the different perspectives that exist in the security space. Everything from just make the pain stop, where they want to do simple signature blocking to, we really want to understand what's happening and dig deep into the protocols and interactions and understand what's an appropriate interaction beyond whether or not there's an attack there. The fundamental premise we have in our space is there's an absolute shortage of talent in the security space that understands that just because the standard says something should be, doesn't mean that an attacker has to adhere to it. And so there's a ton of breaks in that. >> Dang. And what are some of the things that people just miss as the attack surfaces change? And I just think of the fully automated systems like we've seen in ad tech and advanced financial trading systems that are now moving more and more into an increasing group of applications that are going to be IoT-enabled, they're all going to be connected with 5G moving very quickly, so the potential for problems becomes pretty significant if there's a bad actor that gets inserted into that process. >> Certainly and it's interesting that the attackers seem to have automation down pretty well. They can get in and move laterally pretty quickly. >> Right. >> And ferreting out attacker behavior from just bad user behavior can be very difficult. The presumptions that a lot of technologies because the standard says something should be, it will be, create these situations where people aren't effectively looking for the ambiguities and standards, and those are abused all the time. When you look at embedded devices, they get deployed and they stay for 10 years. >> Jeff: Right. >> That's 10 years of technical data that's just deployed and waiting to be exercised and exploited, and having a good general hygiene on an operational environments to understand where these rifts are is probably the biggest gap in the Enterprise world. On the security side, the reliance on standards and the reliance on assumptions of what should be tend to continue, come back, and bite vendors, all right? >> It's funny. So you say just general hygiene and we talked about that in one of the prior interviews where often we'll hear, say, there's a Amazon breach or something and you get to the second paragraph and it's because somebody forgot to set a configuration in the right way, so it's not necessarily the technology or the infrastructure or the safeguards that are put up, it's just somebody forgot to turn the switch on. >> It is. >> So, why these things, general hygiene is still such a problem, is it just because it's so complex, things are moving so fast, people are just too busy? Is it a symptom of dev ops? >> We're human, we're human. >> There we go. >> There's a 1000 things demanding our attention all the time, and without solid processes and procedures, it's easy to miss something. And it's easy in the moment when you've got a big project that needs to launch to say that can wait until next week and then the next big project comes along and next week is here and it waits until the week after. Next thing you know, it's forgotten and you've got an old piece of architecture, infrastructure or security out there that just isn't being maintained anymore. >> Right. >> It's one of the reasons we created an environment that strives to do what we call continuous security validation. So even if you had the best security technologies in the world, it's indistinguishable from no security at all until a breach occurs, right? And so, continuous security validation allows us to look at live attacks that you're usually going to face, measure whether or not your security is deployed, is delivering all protections against them, and highlights there's a gap, simply because you're human. The best technology in the world isn't going to work if you're not managing it well. >> Right. So, are you creating kind of like a digital twin of the key components of my environment back in your lab? Or are you putting things in my system so that you can do this kind of continual monitoring? >> We create, effectively, a virtual remote office and then deploy your security controls and then we attack that remote office for you. And measure whether or not your security controls are being effective and whether or not your people with those controls are able to respond effectively. >> So what's been the impact of public cloud? Of the rise of public cloud? Both obviously, for those applications that are sitting in the public cloud from the Enterprise perspective, but now it's creating this kind of hybrid situation where they've still got stuff in the data center, they've got stuff in the public cloud, there's probably some stuff that's migrating in between, maybe it's tested to have in the public cloud and it gets deployed internally, or maybe they're trying to do a lift-and-shift out of the data center, so how has the rise of public cloud and with the hybrid cloud and multi-cloud environments impacted your guys' world? >> Oh, the biggest shift there, I think, is in the proliferation of what otherwise would have been well-controlled development environments into production environments. It's so easy to move what evolved in developing a technology into a production world without going in and paying attention whether or not all of the right elements are in play. So it used to be you developed it, then you moved it into QA and then from QA, it got moved into production. Now you go right from Dev to Production and QA kind of happens in the background. >> Right, right. And we talked in an earlier conversation, too, which is before then this security would be layered on after the test dev, once it was moving in production. Well, let's slap some security on it, but now it's got to be incorporated in from day one, so another huge opportunity, I guess, to miss that, as you roll that into production. >> It seems like nobody ever thinks about security first. It just isn't the function. No developer ever wakes up in the morning and thinks, I need to do security and then develop features. Their life is all around delivering the value that the customers are looking for and security prevents them creating the feature velocity they want to deliver. There's always a push-and-pull there to get the right balance and it's easy when you're not under sustained attack to believe that security isn't important. >> So how do people adjust kind of their thinking around security? Or is it just below the surface, or it's presumed? How does it become more of an ongoing part of the conversation and a feature that's always baked in during the development versus kind of an afterthought or, oh my gosh, my neighbor just got hacked or there's a big story in the Wall Street Journal? >> I think what we're seeing now in the evolution of software and development is the supply chain involved. It used to be you created systems from scratch and you built it from scratch and you had the opportunity to layer security in as you were going. You would find a weakness, you would design around it, you would overcome it. Now it's more of an assemblage of components to produce an outcome, and the security wasn't built in when the component was built, you've pretty much lost that opportunity and it's hard to go retrofit that. I think we're going to soon see the next phase where these components are start building security assumptions in up front, but it's going to be a long time, much like IoT where things are deployed forever, where we start seeing that supply chain evolve on its own and you can assemble secure software from the start. >> Yeah, it's amazing that's it's still kind of an afterthought when these things are in the newspaper every day and it's almost an assumption maybe we're getting a little numb to the thing that you're going to be breached and you're going to have an issue and how do you react to it? How quickly can you find it? How do you limit the damage? Because it seems like everybody's getting breached every day. >> Especially, when you consider we have decades of technical data. There are companies that still run their businesses on mainframes that haven't been produced in 20 years. >> I didn't even think of that part of it. All right, last question before I let you go, Jason. Big, big week this week at RSA. What are you looking forward to? >> Ah, I'm looking forward to really the evolution of advanced end point technologies, the delivery of visibility to the enterprise, that can do new response actions based on new knowledge. I'm looking forward to the growth of automation. Automation as it relates to security elements, so we can reduce the human element. >> Jeff: Right. >> And the mistakes that are made. >> Yeah, 'cause we certainly need it, 'cause it is easy to make mistakes when you've got a 1000 little tasks, right? >> It is. >> All right, Jason. Well, thank you for taking a few minutes of your day and stopping by. >> Thanks for having me. >> All right. He's Jason, I'm Jeff. You're watching The Cube. We're at RSAC 2018 North America in San Francisco. Thanks for watching. (exciting music)

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