>> From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020, Virtual. Brought to you by Red Hat, The Cloud Native Computing Foundation and Ecosystem partners. >> Welcome back, I'm Stu Miniman and this is CUBEs coverage of KubeCon CloudNativeCon 2020 in Europe, the virtual edition and of course one of the things we love when we come to these conferences is to get to the actual practitioners, understanding how they're using the various technologies especially here at the CNCF show, so many projects, lots of things changing and really excited. We're going to talk about security in a slightly different way than we often do on theCUBE so happy to welcome to the program from Sera4 I have Jeff Klink who's the Vice President of Engineering and Cloud. Jeff, thanks so much for joining us. >> Thanks too, thanks for having me. >> All right so I teed you up there, give us if you could just a quick thumbnail on Sera4, what your company does and then your role there. >> Absolutely so we're a physical hardware product addressing the telco markets, utility space, all of those so we kind of differentiate herself as a Bluetooth lock for that higher end space, the highest security market where digital encryption is really an absolute must. So we have a few products including our physical lock here, this is a physical padlock, it is where door locks and controllers that all operate over the Bluetooth protocol and that people can just use simply through their mobile phones and operate at the enterprise level. >> Yeah, I'm guessing it's a little bit more expensive than the the padlock I have on my shed which is getting a little rusty and needs a little work but it probably not quite what I'm looking for but you have Cloud, you know, in your title so give us if you could a little bit you know, what the underlying technology that you're responsible for and you know, I understand you've rolled out Kubernetes over the last couple of years, kind of set us up with what were the challenges you were facing before you started using that? >> Absolutely so Stu We've grown over the last five years really as a company like in leaps and bounds and part of that has been the scalability concern and where we go with that, you know, originally starting in the virtual machine space and, you know, original some small customers in telco as we build up the locks and eventually we knew that scalability was really a concern for us, we needed to address that pretty quickly. So as we started to build out our data center space and in this market it's a bit different than your shed locks. Bluetooth locks are kind of everywhere now, they're in logistics, they're on your home and you actually see a lot of compromises these days actually happening on those kind of locks, the home security locks, they're not built for rattling and banging and all that kind of pieces that you would expect in a telco or utility market and in the nuclear space or so you really don't want to lock that, you know, when it's dropped or bang the boat immediately begins to kind of fall apart in your hands and two you're going to expect a different type of security much like you'd see in your SSH certificates, you know, a digital key certificate that arrives there. So in our as we grew up through that piece Kubernetes became a pretty big player for us to try to deal with some of the scale and also to try to deal with some of the sovereignty pieces you don't see in your shed locks. The data sovereignty meeting in your country or as close to you as possible to try to keep that data with the telco, with the utility and kind of in country or in continent with you as well. That was a big challenge for us right off the bat. >> Yeah, you know Jeff absolutely, I have some background from the telco space obviously, there's very rigorous certifications, there's lots of environments that I need to fit into. I want to poke at a word that you mentioned, scale. So scale means lots of things to lots of different people, this year at the KubeCon CloudNativeCon show, one of the scale pieces we're talking about is edge just getting to lots of different locations as opposed to when people first thought about, you know, scale of containers and the like, it was like, do I need to be like Google? Do I have to have that much a scale? Of course, there is only one Google and there's only a handful of companies that need that kind of scale, what was it from your standpoint, is it you know, the latency of all of these devices, is it you know, just the pure number of devices, the number of locations, what was what was the scale limiting factor that you were seeing? >> It's a bit of both in two things, one it was a scale as we brought new customers on, there were extra databases, there was extra identity services, you know, the more locks we sold and the more telcos we sold too suddenly what we started finding is that we needed all these virtual machines and sources in some way to tie them together and the natural piece to those is start to build shared services like SSO and single sign on was a huge driver for us of how do we unite these spaces where they may have maintenance technicians in that space that work for two different telcos. Hey, tower one is down could you please use this padlock on this gate and then this padlock on this cabinet in order to fix it. So that kind of scale immediately showed us, we started to see email addresses or other on two different places and say, well, it might need access into this carrier site because some other carrier has a equipment on that site as well. So the scale started to pick up pretty quickly as well as the space where they started to unite together in a way that we said, well, we kind of have to scale to parts, not only the individuals databases and servers and identity and the storage of their web service data but also we had to unite them in a way that was GDPR compliant and compliant with a bunch of other regulations to say, how do we get these pieces together. So that's where we kind of started to tick the boxes to say in North America, in Latin America, South America we need centralized services but we need some central tie back mechanism as well to start to deal with scale. And the scale came when it went from Let's sell 1000 locks to, by the way, the carrier wants 8000 locks in the next coming months. That's a real scalability concern right off the bat, especially when you start to think of all the people going along with those locks in space as well. So that's the that's the kind of first piece we had to address and single sign on was the head of that for us. >> Excellent, well you know, today when we talk about how do i do container orchestration Kubernetes of course, is the first word that comes to mind, can you bring us back though, how did you end up with Kubernetes, were there other solutions you you looked at when you made your decision? What were your kind of key criteria? How did you choose what partners and vendors you ended up working with? >> So the first piece was is that we all had a lot of VM backgrounds, we had some good DevOps backgrounds as well but nobody was yet into the the container space heavily and so what we looked at originally was Docker swarm, it became our desktop, our daily, our working environment so we knew we were working towards microservices but then immediately this problem emerged that reminded me of say 10, 15 years ago, HD DVD versus Blu-ray and I thought about it as simply as that, these two are fantastic technologies, they're kind of competing in this space, Docker Compose was huge, Docker Hub was growing and growing and we kind of said you got to kind of pick a bucket and go with it and figure out who has the best backing between them, you know from a security policy, from a usage and size and scalability perspective, we knew we would scale this pretty quickly so we started to look at the DevOps and the tooling set to say, scale up by one or scale up by 10, is it doable? Infrastructure as code as well, what could I codify against the best? And as we started looking at those Kubernetes took a pretty quick change for us and actually the first piece of tooling that we looked at was Rancher, we said well there's a lot to learn the Kubernetes space and the Rancher team, they were growing like crazy and they were actually really, really good inside some of their slack channels and some of their groups but they said, reach out, we'll help you even as a free tier, you know and kind of grow our trust in you and you know, vice versa and develop that relationship and so that was our first major relationship was with Rancher and that grew our love for Kubernetes because it took away that first edge of what am i staring at here, it looks like Docker swarm, they put a UI on it, they put some lipstick on it and really helped us get through that first hurdle a couple years ago. >> Well, it's a common pattern that we see in this ecosystem that you know, open source, you try it, you get comfortable with it, you get engaged and then when it makes sense to roll it into production and really start scaling out, that's when you can really formalize those relationships so bring us through the project if you will. You know, how many applications were you starting with? What was the timeline? How many people were involved? Were there, you know, the training or organizational changes, you know, bring us through under the first bits of the project. >> Sure, absolutely. So, like anything it was a series of VMs, we had some VM that were load balanced for databases in the back and protected, we had some manual firewalls through our cloud provider as well but that was kind of the edge of it. You had your web services, your database services and another tier segregated by firewalls, we were operating at a single DCs. As we started to expand into Europe from the North America, Latin America base and as well as Africa, we said this has got to kind of stop. We have a lot of Vms, a lot of machines and so a parallel effort went underway to actually develop some of the new microservices and at first glance was our proxies, our ingresses, our gateways and then our identity service and SSL would be that unifying factor. We honestly knew that moving to Kubernetes in small steps probably wasn't going to be an easy task for us but moving the majority of services over to Kubernetes and then leaving some legacy ones in VM was definitely the right approach for us because now we're dealing with ingressing around the world. Now we're dealing with security of the main core stacks, that was kind of our hardcore focus is to say, secure the stacks up front, ingress from everywhere in the world through like an Anycast Technology and then the gateways will handle that and proxy across the globe and we'll build up from there exactly as we did today. So that was kind of the key for us is that we did develop our micro services, our identity services for SSO, our gateways and then our web services were all developed in containers to start and then we started looking at complimentary pieces like email notification mechanisms, text notification, any of those that could be containerized later, which is dealt with a single one off restful services were moved at a later date. All right. >> So Jeff, yeah absolutely. What to understand, okay, we went through all this technology, we did all these various pieces, what does this mean to your your business projects? So you talked about I need to roll out 8000 devices, is that happening faster? Is it you know, what's the actual business impact of this technology that you've rolled out? >> So here's the key part and here's a differentiator for us is we have two major areas we differentiate in and the first one is asymmetric cryptography. We do own the patents for that one so we know our communication is secure, even when we're lying over Bluetooth. So that's kind of the biggest and foremost one is that how do we communicate with the locks on how do we ensure we can all the time. Two is offline access, some of the major players don't have offline access, which means you can download your keys and assign your keys, go off site do a site to a nuclear bunker wherever it may be and we communicate directly with the lock itself. Our core technology is in the embedded controllers in the lock so that's kind of our key piece and then the lock is a housing around it, it's the mechanical mechanism to it all. So knowing that we had offline technology really nailed down allowed us to do what many called the blue-green approach, which is we're going down for four hours, heads up everybody globally we really need to make this transition but the transition was easy to make with our players, you know, these enterprise spaces and we say we're moving to Kubernetes. It's something where it's kind of a badge of honor to them and they're saying these guys, you know, they really know what they're doing. They've got Kubernetes on the back end, some we needed to explain it to but as soon as they started to hear the words Docker and Kubernetes they just said, wow, this guys are serious about enterprise, we're serious about addressing it and not only that they're forefront of other technologies. I think that's part of our security plan, we use asymmetric encryption, we don't use the Bluetooth security protocol so every time that's compromised, we're not compromised and it's a badge of honor we were much alongside the Kubernetes. >> Alright, Jeff the thing that we're hearing from a lot of companies out there is that that transition that you're going through from VMs to containerization I heard you say that you've got a DevOps practice in there, there's some skill set challenges, there's some training pieces, there's often, you know, maybe a bump or two in the road, I'm sure your project went completely smoothly but what can you share about, you know, the personnel skill sets, any lessons learned along the way that might help others? >> There was a ton. Rancher took that first edge off of us, you know, cube-cuddle, get things up, get things going, RKE in the Rancher space so the Rancher Kubernetes engine, they were kind of that first piece to say how do I get this engine up and going and then I'll work back and take away some of the UI elements and do it myself, from scheduling and making sure that nodes came up to understanding a deployment versus a DaemonSet, that first UI as we moved from like a Docker swarm environment to the the Rancher environment was really kind of key for us to say, I know what these volumes are, I know the networking and I all know these pieces but I don't know how to put core DNS in and start to get them to connect and all of those aspects and so that's where the UI part really took over. We had guys that were good on DevOps, we had guys are like, hey how do I hook it up to a back end and when you have those UI, those clicks like your pod security policy on or off, it's incredible. You turn it on fine, turn on the pod security policy and then from there, we'll either use the UI or we'll go deeper as we get the skill sets to do that so it gave us some really good assurances right off the bat. There were some technologies we really had to learn fast, we had to learn the cube-cuddle command line, we had to learn Helm, new infrastructure pieces with Terraform as well, those are kind of like our back end now. Those are our repeatability aspects that we can kind of get going with. So those are kind of our cores now is it's a Rancher every day, it's cube-cuddle from our command lines to kind of do those, Terraform to make sure we're doing the same thing but those are all practices we, you know, we cut our teeth with Rancher, we looked at the configs that are generated and said, alright, that's actually pretty good configure, you know, maybe there's a team to tolerance or a tweak we could make there but we kind of work backwards that way to have them give us some best practices and then verify those. >> So the space you're in, you have companies that rely on what you do. Security is so important, if you talk about telecommunications, you know, many of the other environments they have, you know, rigid requirements. I want to get to your understanding from you, you're using some open source tools, you've been working with startups, one of your suppliers Rancher was just acquired by SUSE, how's that relationship between you know, this ecosystem? Is that something that is there any concerns from your end user clients and what are your own comfort level with the moves and changes that are happening? >> Having gone through acquisitions myself and knowing the SUSE team pretty well, I'd say actually it's a great thing to know that the startups are funded in a great source. It's great to hear internally, externally their marketing departments are growing but you never know if a startup is growing or not. Knowing this acquisitions taking place actually gives me a lot of security. The team there was healthy, they were growing all the time but sometimes that can just be a face on a company and just talking to the internals candidly as they've always done with us, it's been amazing. So I think that's a great part knowing that there's some great open source texts, Helm Kubernetes as well that have great backers towards them, it's nice to see part of the ecosystem getting back as well in a healthy way rather than a, you know, here's $10,000 Platinum sponsorship. To see them getting the backing from an open source company, I can't say enough for. >> All right, Jeff how about what's going forward from you, what projects you're looking at or what what additions to what you've already done are you looking at doing down the road? >> Absolutely. So the big thing for us is that we've expanded pretty dramatically across the world now. As we started to expand into South Africa, we've expanded into Asia as well so managing these things remotely has been great but we've also started to begin to see some latencies where we're, you know, heading back to our etcd clusters or we're starting to see little cracks and pieces here in some of our QA environment. So part of this is actually the introduction and we started looking into the fog and the edge compute. Security is one of these games where we try to hold the security as core and as tight as you can but trying to get them the best user experience especially in South Africa and serving them from either Europe or Asia, we're trying to move into those data centers and region as well, to provide the sovereignty, to provide the security but it's about latency as well. When I opened my phone to download my digital keys I want that to be quick, I want the administrators to assign quickly but also still giving them that aspect to say I could store this in the edge, I could keep it secure and I could make sure that you still have it, that's where it's a bit different than the standard web experience to say no problem let's put a PNG as close as possible to you to give you that experience, we're putting digital certificates and keys as close as possible to people as well so that's kind of our next generation of the devices as we upgrade these pieces. >> Yeah, there was a line that stuck with me a few years ago, if you look at edge computing, if you look at IoT, the security just surface area is just expanding by orders or magnitude so that just leaves, you know, big challenges that everyone needs to deal with. >> Exactly, yep. >> All right, give us the final word if you would, you know, final lessons learned, you know, you're talking to your peers here in the hallways, virtually of the show. Now that you've gone through all of this, is there anything that you say, boy I wish I had known this it would have been this good or I might have accelerated things or which things, hey I wish I pulled these people or done something a little bit differently. >> Yep, there's a couple actually a big parts right off the bat and one, we started with databases and containers, followed the advice of everyone out there either do managed services or on standalone boxes themselves. That was something we cut our teeth on over a period of time and we really struggled with it, those databases and containers they really perform as poorly as you think they might, you can't get the constraints on those guys, that's one of them. Two we are a global company so we operate in a lot of major geographies now and ETC has been a big deal for us. We tried to pull our ETC clusters farther apart for better resiliency, no matter how much we tweak and play with that thing, keep those things in a region, keep them in separate, I guess the right word would be availability zones, keep them make redundant as possible and protect those at all costs. As we expanded we thought our best strategy would do some geographical distribution, the layout that you have in your Kubernetes cluster as you go global for hub-and-spoke versus kind of centralized clusters and pods and pieces like that, look it over with a with an expert in Kubernetes, talk to them talk about latencies and measure that stuff regularly. That is stuff that kind of tore us apart early in proof of concept and something we had to learn from very quickly, whether it'll be hub-and-spoke and centralize ETC and control planes and then workers abroad or we could spread the ETC and control planes a little more, that's a strategy that needs to be played with if you're not just in North America, South America, Europe, Asia, those are my two biggest pieces because those are our big performance killers as well as discovering PSP, Pod Security Policies early. Get those in, lock it down, get your environments out of route out of, you know, Port 80 things like that on the security space, those are just your basic housecleaning items to make sure that your latency is low, your performances are high and your security's as tight as you can make it. >> Wonderful, well, Jeff thank you so much for sharing Sera4 for story, congratulations to you and your team and wish you the best luck going forward with your initiatives. >> Absolutely, thanks so much Stu. >> All right, thank you for watching. I'm Stu Miniman and thank you for watching theCUBE. (soft music)

>> Announcer: From around the globe, it's theCUBE with digital coverage of next level network experience event, brought to you by Infoblox. >> Okay, welcome back everyone's to CUBE's coverage and co creation with Infoblox. Next Level networking event, virtual event, I'm John Furrier, your host to theCUBE. We're here with Craig Sanderson, Vice President security products at Infoblox. Talking about securing the borderless enterprise, obviously Infoblox, we had a variety of different conversations. Craig, welcome to theCUBE. >> Thank you. Thanks, it's great to be here. >> Remote CUBE, normally we're in person, but since it's COVID-19, we're doing our best to get the stories out and one of things I want to chat with you is with COVID-19, this shift to remote working is interesting and the word work is interesting you got the work forces which are people work places which are locations, which is now home, workflows and work loads all work related, right? So if you think about the enterprise, you know, just the disruption to business model around this unforeseen, almost 100% VPN usage maybe or you got all this remote action, no one could have foreseen all this coming. How is this shift change the security paradigm and posture for enterprises? >> Yeah, I think for a lot of the customers that we've talked to, a lot of them are thinking about digital transformation for some time. What COVID has really done is rapidly expanded or kind of accelerated the need for them to think about what the digital transformation plans are. And unfortunately for some organizations who may be not as far down the line as others, they've looked at their current implementation for remote access, and their traditional security models of like perimeter based and they found that you know in this current environment where suddenly you've gone from being only a partial set of your workforce or remote to now all of them being remote and their applications, their data, the users, they're all kind of spread anytime, anyplace, anywhere. Their traditional models don't really work. So what it's caused a lot of organizations to do is to really accelerate their digital transformation plans and quite often for some of those organizations, they've realized that they've had to make the move relatively quickly because their traditional architectures have just not been designed for this level of disruption the digital transformation has had on their businesses. >> Give some examples of how companies have either been flat footed or on their heels, kind of push back and saying, well, we got caught off guard to ones that are kind of in place that kind of managed the pandemic well, what's the difference? Can you just give some color commentary around, you know, the the profile who got it right or some were right, and some that have gotten it wrong, or are struggling? >> So I think the ones who got it right are the ones who were already thinking about digital transformation. They're looking at the fact that a lot of the applications that their consumers or their users are consuming are increasingly going to be in the Cloud anyway. So the traditional architecture of all the good stuffs on the inside and the bad stuff on the outside, that simply doesn't work with Cloud and those organizations who were looking at obviously Cloud deployments for their applications, SDN IoT, those organizations have had be thinking about how they can secure those devices, the applications and users in a way that is going to be ubiquitous. The fact that you can deploy the security controls wherever those applications users or devices are going to be. So those organizations are already starting to think about how they can build a networking architecture that is going to be suited for digital transformation, and by extension, they've been recognizing that the security model has to change, 'cause they were much further down the path. Really, this has been an acceleration. For those organizations that well, I'm not really interested in Cloud, are worried about the risks associated with Cloud and things like that, who tended to try and stick or cling to the old traditional model. Where they really run into trouble now, it's like this model just doesn't work. And now the decisions almost been taken out of the hands with COVID, because now their users are not on the corporate network. They can't build a rock wall around those users. They now have to provide protection for a user who's potentially not even using the device that they can control. So for those organizations who are already thinking about cloud and SDN and IoT, because of that digital transformation effect they've been starting to think about security, for those who have not thought about that or who have tried have been pushing that off, they're the ones who've been caught somewhat flat footed and now they're been forced to make a decision which maybe not they're actually feeling comfortable already ready to go off and do. >> You know, Craig, I sat with a friend the other day and we're like briefing on hey, you know, COVID-19 really, kind of, exposes almost like the tide coming out as that tsunami comes. You can see everything, all the scabs and all the problems. And then we started talking about the whole work at home situation, like this is probably the biggest use case of IoT in real life because you can really see it play out, not just a factory or sensor or device at the edge of the network, these are work, people doing work, right? So this whole IoT Edge, it's about addressability. So you know, I have to ask you, 'cause we've talked with you guys earlier in other segments around this next level networking experience, I love the word experience, but next level networking means next level. So DDI has an abstraction, DDI being DNS DHCP, and IP address management. How does the security piece fit in? Because certainly, yes, you got at home, we got a bunch of IoT people running their stuff from their home networks and so remote access, and you got also the business around, which includes everything that's connected to the network now, and literally is borderless. So I like that term. So how does DDI security fit into that? Yeah, I mean, it's part of having the experience, I mean, one of the things that's changed, I mean, I've been in security for over 20 years, probably about 10 or 15 years ago, as a security guy, you could come back and you had a veto, you'd come back and say, well, no, we're not going to roll this thing out, these applications, or these services, because it's a risk to the business. Now in a lot of the CSOs that I've talked to is that veto is going away. If this application is going to get rolled out, we're going to run this service security has to catch up. Now what you can't have is from a seamless experience point of view, is to say well, okay, you've now got wonderful application experience, but then it gets ruined by all the security controls are very invasive. So all organizations are having to do is to think about how you can build a seamless networking architecture that can also seamlessly include the security as part of that. And so you can still have the security of the organization needs without it becoming a massive disruption to the experience. And one of the good examples is, for a lot of organizations their remote access, going back to the COVID example, is based on VPN. VPNs are cumbersome and have got troubles with passwords and all these sort of like traditional issues associated with the user experience from a VPN perspective. I mean, a lot of users have the patience to deal with that, and they don't necessary follow all the necessary security controls. So people are being forced to rethink how they can build the quality application experience underpinned by a digitally transformed network, but at the same time, making sure you could layer in at foundational layer, the security functions as well. And that's where a lot of organizations who are a little bit more forward thinking understood that and start to think about like DNS, is essentially this ubiquitous platform, which is already there it can already provide the sort of security services by default. Because going back to your example about IoT, one of the jokes with one of my friends is, and for every IoT security, sorry, every IoT offering, there's a separate IoT security offering. And one of the things that was a lightbulb moment for us is, if you're trying to secure all these heterogeneous IoT devices, well, one thing they have in common, they're all going to get an IP address, so we're going to use DNS. So what people have to start to do is to try and make security seamless, it has to be built into the foundations. It can't be this extra thing that you kind of glob on the side, because it then ruins the overall experience for the users. The nice thing about DNS is its ubiquitous, and you can apply the security, regardless of what the endpoint and application is, because the common denominator they choose they get an IP address and they use DNS. >> And DNS has such a great track record over the years of having layers of abstractions on top of it to pace with the functionality and it's really been an operating model and you bring up the different security packages and postures for each thing. And you mentioned, you know, the old days security guy, oh, no we're killing that, no we're going this way. That was the operational model, but now with DevOps, you put a Cloud earlier, DevOps has proven that agility, speed scale can work, and how to security catch up? It's an operating model. So this is really kind of the key epiphany is, hey, VPNs, that's not the experience that people want. And, you know, I was just talking with someone from Amazon this morning in another interview segment and the discussion was new expectations, new solutions. So that's kind of what we're seeing right now. So how do you enable that out at speed by not screwing over the operations people, right? So 'cause they got to be, operationally, I need to be really rock solid, so you need automation, you got to have those factors and requirements built in, but you got the agility for development. your reaction> >> Yeah, absolutely. We see that especially is one of the things about 'cause DNS essentially ubiquitous. You can apply similar security controls regardless of the environment. So, right now I'm stuck at home because of the COVID virus. So again, I'm going to use DNS, I go through one of our Cloud platforms, I have DNS applying the security controls there. But within the same thing because DNS works as one ubiquitous system and it's like how the internet works with DNS is quite easily, not only can you block malicious threats for myself, but also you can push that same block mitigation to a DNS server that's running in AWS. So if your workload that may also have been compromised, trying to go to the same malicious domain, you can also be blocked by DNS. And so that ubiquity, the fact that it's built as this ubiquitous system, mean one thing is very different in the networking world standards are great. We can plug different things together, they all kind of fit together nicely. Insecurity is not normally that not only the cases, normally, you've got this jigsaw puzzle, where all the pieces don't really fit together. The nice thing with DNS is is absolutely ubiquitous. So one basic example is, if I try to go to a malicious domain, or I tried to steal data over DNS, not only would we be able to block it, but we'd also be able to dynamically share that mitigation to all of the on prem DNS servers, the DNS servers rather in your public or private Cloud, and for all the other like remote users. So the fact you've got this pre built fabric, and it's not that we're security geniuses, it's just it happens to already be there because of DNS and how DNS has been developed over the last 30 or 40 years. So I think the nice thing about it is a lot of organizations are starting to realize that you've got this foundation already there. Ostensibly, it's there for networking purposes, but the ability to repurpose all the core assets of DNS, the scalability, the flexibility, adaptability, the ubiquity, all those things are there by default. Why don't you use that as the new foundation for that next gen security architecture? >> And you know, you got me as a fan, I'll say that right away, because when we think about the simplicity of going to the low level building block in DNS, it fits for what I said earlier, the future of work, the word Work, workplace, workforce, workload, workflows, no matter what it is, it works across. So it's a consistent, primitive. I mean, it makes total sense. Why would you want to have different things. So again, this brings up the whole foundational level of DDI that's got my interest. And I want you to explain this for folks, because I think it's not obvious. Abstractions are pretty clear, people get abstraction layers, reduce complexity, and increase functionality and capability. But DDI, you guys have from a foundational security standpoint, is kind of the unique thing Infoblox has. How is that different, DDI from other offerings in the security stack? >> Yeah, I think the one thing is pretty unique, especially when it comes to DNS is the fact that it's built together as this ubiquitous system, and it's there by default. I mean, otherwise, the internet just wouldn't work. So the nice thing is, is that if you deploy a DNS system we can deploy as a grid, so whether it's the an appliance running on prem or sitting in a public Cloud, or even for roaming users who are going through one of our points of presence, it works as one big ubiquitous system, whereas you take like traditional firewalls, you're configuring these devices separately, and you have to manually stitch it together. And you take multiple different vendors and you know, it doesn't quite fit neatly together. DNS is based on the standard, you could take a DNS server for master DNS server from another company and because it's based on standards, it will work seamlessly together, in fact, that the threat mitigation mechanism where you distribute threat intelligence to tell the DNS, what is the malicious domains or IP addresses to block is based on so called response policy zones. That's been part of the DNS standard since 2010. And it works seamlessly across multiple vendors, whereas in the security world, as I said, it's kind of like a jigsaw where you get all the pieces together that you think you need and then the burden is always on the customer or the organization to then piece these things together and as a chief source it doesn't fit together. I can see that burden can cause a hell of a lot of issues for a lot of the customers. >> Yeah, I got to ask you since DNS is so foundational to element *and have all internet activities obviously, you know URLs is DNS, it's string actually. So everything's based on DNS, how it resolves. So what what about the, how would you respond if someone said, hey, you know, I don't even know DNS is still around. I know it's palm. It's underneath there somewhere, I don't even have to deal with it, it just runs things, we've been using it for years. What's the big deal? So how do you go in and say, hey, customer, hey, enterprise, you're not borderless, I get a hitch. But they have DNS. How do they modernize it? How do they assess it? How do you go in and some of the young kids don't even know what DNS might even is? I mean, like, it's a new, so like, *what do you go where, how do you approach that and what's the pitch because they got it and as an opportunity to innovate. what's the story there? >> *Is really two aspects to it. The first one is, I mean, DNS is a bit like oxygen. If it's not there, you really need to notice it. You just take when we had the Mirai botnet attack a few years back, all these organizations suddenly realized how important DNS is. And there's a reason why DNS is the number one attack vector for DDoS attacks. If I'm an adversary, I could try and take out individual applications it's going to take me forever. I take out your DNS, everything's going to stop. I mean, it's that *foundational z. But because its been >> *Hackers no problem, yeah. >> Exactly, so and for that reason, that's why it's constantly targeted. So firstly, my first pitch to customers is, you've got to take this stuff seriously, because when it goes down, everything is down. And the impact to your organization, not just from a brand reputation, but just from running your business is going to be huge. But on top of that, the way to think of DNS is, the nice thing is is you don't have to change your network architecture. If you think about a typical user who clicks on a phishing link. When they click on a phishing link, who's going to see the malicious requests first? Is it your firewall? No, your DNS server. Because you made the request, you have to resolve the malicious domain that you're going to try and connect to. You need to find out the IP address of it. So your DNS server and it's been proven multiple studies that, the vast majority of malware uses DNS as its control plane. So if you want to understand what the bad guys are doing, you know, your DNS servers got a front row seat to exactly what the bad guys are doing. And to implement security on it is you don't have to change your network architecture, because your DNS is already there by default. All you need to do is infuse it with security knowledge, whether that is machine learning, analytics or threat intelligence. But those DNS servers are ideally positioned. They're going to see the malicious activity, regardless of what the application is. So it's foundational, not just in terms of, if it's not there, it's going to cause a massive issue to your field or environment anyway. But even if you secure the DNS, the DNS is also this wonderful tool that is in all the right places and it's also deeper into the network. One of the challenges you mentioned about operations is the challenges is okay, you can block malware but if you don't know the source address of the device that is actually trying to make the request, you don't know what to go and clean up, where's your DNS server, your DHCP server knows exactly who it is because we handed out the IP address, we know the MAC address, we know the IP address, we know the user name, we have all that information that is going to be critical for security operations. And now you can see what *it's or about maybe the first report, you start to see that organizations are waking up to the fact that you have this treasure trove of security operations data that you haven't tapped largely for political reasons, because the security guys can't reach over and grab the necessary DDI network context from those DNS platforms, because typically they're owned by the networking or the server team. >> Before we get into that *force reports, I think that had some threat investigation data. What you're getting at about this DNS is that basically, it's critical infrastructure. And if you try to forget about it, 'cause it works, you lose sight of the real opportunity, which is, if it's critical infrastructure, you got to treat it like critical infrastructure, and make sure it's modernized, refreshed in the right position to manage all this, right? >> Absolutely. Absolutely, yeah. It's unfortunate With the Mirai botnet attack. A lot of organizations, as they said well, okay, we'll just outsource this, we don't have to worry about it. But when it wasn't there, and it wasn't the fact that, I mean, it was an attempt to take out like Minecraft servers. Nothing to do with most of the businesses who were impacted, but there was a lot of collateral damage. And unfortunate is like one of those things is because DNS is a victim of its own success. The fact that is reliable, it is consistent. You don't have lots of DNS outages typically. As a result of that people tend to forget about how critical it is as the role it plays in serving all of your applications and your users. >> Let's get into the *fourth report 'cause they surveyed a bunch of hundreds of security and risk management leaders, both compliance and also security pros that are using DNS, what were your key thoughts on the takeaways from that study? What should people know about it? >> It's very encouraging as up in Infoblox about five years when I first joined, the usage of DNS as a network context as a way to help with security operations is very, very low. And that causes all sorts of issues for organizations when it comes to doing security operations. I mean, a prime example is, the guys who work in security operations, that is the biggest issue for customers right now. They've bought almost too much security gear. And each of those security tools and platforms, they're generating security events. So again, security events from your firewall, or from your IPS or from your neck system, or whatever it happens to be and the burden now falls on the security operations teams. And it's been proven that there's huge amounts of open opportunities because there just, isn't enough trained security operations staff and the ones who are already in the business, are massively overworked and struggle to get through all the security events that have been firing from their security operations tools. So for what I was encouraging from the first report is that organizations are realizing that DHCP is going to help* you be able to identify the fact that these two security events seem completely separate. One of them is got a source address of 10.1, the other ones 20.1, well, you know what? This laptop moved from one side the building to the other and got a different address, it's actually the same device. But based on the traditional security events you're getting from the existing tools, you know, you're going to think it's two separate events, and they're not. Likewise, one of the things that's coming out is that people start to use DNS as an audit trail. And one of the challenges for organizations is, if you get a data breach, what's one of the first questions a journalist is going to ask you is like, well, what is the scope of the breach? What was impacted? And quite often organizations are not prepared. They come back and say, well, at this stage, we don't know. That's a great way for a CEO or CFO to get fired. So a smarter way of doing it is, if you think about you got the devices under investigation, the DNS queries that those* machines have been making is a wonderful audit trail of not just the external resources it's been accessing, but also the internal resources as well, what has been potentially exposed. So I think from the forest report, we're certainly seeing people realizing what were their biggest challenges security operations. Essentially, the DDI data is almost like the oil that's going to grease the wheels of security operations. And if you don't do that, buying more security gear, it's not going to make the problem better, it's actually going to make it worse unless you can operationalize it. >> Yeah, at the end of the day, the failures right there in the low level of critical infrastructure and building floors no one cares what happened on the 10th floor foundations. I got to get your thoughts on this because as you guys have DDI abstraction, DNS, you know, as it's growing, had its evolutions with abstractions, you know, as these things kind of flex, used to be an old expression DNS tricks, you know, you would mangle DNS, and it was a naming system. So you use it the way you use it and then new innovation layers create more upside and more, takes away complexities. How does DNS scale enable value? Because now you got Cloud, you got Cloud native, new software's being written and developers want to rely on the DNS as a critical infrastructure, but also want to be enabled to have, you know, really robust applications. >> Yeah and I think with the, given the fact that all the work has been put into DNS over the last 20 or 30 years, work has resolved in a very highly available very resilient system. And so a lot of stuff has to go wrong for DNS to fully go down. And it's easy to just take things like *Anycast, Anycast allows you to connect to the nearest DNS server, that's going to give you the resolution. So it's going to give you the best performance. This also can give you the high availability and resilience that goes along with that. And I think also from the security guys point of view, is if all the things that we've started to realize is that DNS is a great avenue by which you can detect somewhat unique threats. So one of the things that comes up quite a lot, we're starting to see old malware being re weaponized to exfiltrate data over DNS. So if you're a DevOps guy, and you're building your new application, if someone compromises your application, if I tried to extract the data over HTTP or email, you probably have a solution for that. 6But how many organizations have visibility in the billions of DNS queries that's going to come out your network in a day. Which ones are those might be actually data that has been stolen, it gets encoded and corrupted, chopped up and sent out and DNS packets. Is very difficult for traditional security appliances to understand and really differentiate between legitimate DNS requests, the malicious ones are actually the ones who are benign applications that essentially tunnel over DNS because they're trying to bypass firewalls. So increasingly, DNS is a threat vector for basic data loss. It's also important to understand is really gives you a window into what the adversary is doing. So not just when it comes to data exfiltration, but other things like domain generation algorithms that allow adversaries to maintain control of devices that they compromised. So a lot of that stuff is not just about the high availability and the ubiquity of DNS, but also making sure you can be fully on top of the potential impact of DNS being exploited as a potential backdoor out of your network. >> Critical infrastructure, but also that's where you're going to see the footprints of any kind of activity right there, it's a great observation space as well for detection and analysis, great stuff. Craig, thank you for taking the time, great insight, great conversation. DNS is critical infrastructure, get on it, and people are on it, they're going to go the next level. Getting the next level networking experience is about having that security always on high availability, and protecting the bad guys. Craig, thanks for joining me on this CUBE conversation for the Infoblox virtual event. Thank you. >> Pleasure. Thanks for having me. >> Okay, that's the CUBE coverage of Infoblox is next level networking virtual event. I'm John Furrier, your hosts of the CUBE. Thanks for watching. (upbeat music)