Multi-Cloud Cyber Defense: How DNS Security Can Stop Threats Before They Strike

Well, hello and welcome to another KuppingerCole webinar. Our topic for today is Multi-Cloud Cyber Defense, how DNS security can stop threats before they strike. My name is Alexei Balaganski, I'm Lead Analyst and CTO at KuppingerCole and my guests for today are Steve Salo and Sebastian Hein of Infoblox. Welcome guys. Thank you. Before we dive into the webinar, just a few housekeeping rules. All the attendees are muted centrally, so you don't have to worry about the microphones. We actually are not planning any polls for today's webinar, but we will have a Q&A session at the end.

At any time, even now, you can use the chat or the dedicated questions part of this app to submit your questions. I will read them aloud later and we will discuss them. We are recording all this and video recording along with all the slide decks will be published on our website and everyone will receive a link. The agenda is as usual in three parts.

I will start with my neutral analyst view of the whole multi-cloud cybersecurity challenges and issues thing and then after that I will give the stage to Steve to dive into the technical details of DNS security solutions and finally Sebastian will do an interactive demo. And as I mentioned in the end, we will return with a Q&A session. So without further ado, let's dive into the first slide.

And if you have attended our webinars before, you've probably seen this slide or a similar one because, well, this is the world we are living in, the world of digital enterprises, of clouds, of mobile devices, of software as a service platforms, a world which is unfortunately profoundly insecure. And these are all the challenges we have to deal with because, well, cloud or multi-cloud is the new normal. There is absolutely no way you can succeed in the digital business world if you try to stick to the old-fashioned on-prem, primitive-based technologies and security solutions.

Of course, when we have adopted the cloud or even the clouds, we've gained a huge amount of innovative solutions, technologies, stacks and infrastructures which allow us to do things impossible before, but unfortunately with great power comes great responsibility and a lot of issues we now have to deal with which we have never had before. And by the way, I asked the Cambrian explosion in the cloud and this is what it came up with. But basically, yes, now we have to deal with ephemeral workloads, things which pop up into existence for a few seconds and then disappear without any trace, often.

And now things happen at a huge scale. You have thousands, tens of thousands, even hundreds of thousands of ephemeral workloads, be it containers or serverless functions or just any other entity in the cloud of yours or multiple clouds. And for all those entities, all those clouds, you have to manage access, you have to juggle identities, you have to audit the lifecycle of those objects.

But most of all those issues, you have to have people and a lot of people, skilled experts, to manage all those infrastructures, to manage all those proprietary interfaces which are of course different for every cloud. And in the end, you have, as I said, a huge Cambrian explosion of complexity. And with that comes absolute loss of usability and governance and this is where we are at in the moment, unfortunately.

We all know what are the major concerns for business people because they never think about containers, they think about compliance, they think about data breaching, they think about business continuity issues. And on this slide, I've just listed three of those major concerns.

Again, they are not technical in their nature, we just have to somehow make sure that our business continues to function. Business continuity is of course an issue. We have to make sure that we stay compliant with all the regulations and there are more and more popping up around the world every year. And finally, last but not least, we want our sensitive data to stay protected all the time. It's not just about compliance anymore, it's not just PII, it also can be your valuable quote-unquote crown jewels, your intellectual property, your financial data.

Well, anything digital is now at stake. And of course, as soon as you go multi-cloud, as soon as you understand, and that actually happens to an absolute majority of all the businesses, one cloud is not enough. You have to multiply your efforts, you have to multiply your risks, and with that comes an additional layer of complexity. Now you have not just a silo but thousands, hundreds, thousands of silos. Or you have multiple issues related to inter-cloud data exchanges, for example, which of course leads to cloud data leaks as well.

You have inconsistent and disjoint tools, and again, all those tools are usually proprietary for each cloud. And you have different teams, colleagues, or departments which, with everyone basically involved in their specific issues, and rarely being able to collaborate and work together solving all those issues as a large single team. And of course, all those complexity challenges turn into security risks.

Again, we don't have to go deep into each one of those, but we do know that if you are running cloud stuff for years, you probably have tons of different accounts, you have tons of different resources and assets which you don't even know why you still have them. And sometimes you just even no longer have any records. They are completely orphaned, they are no longer monitored and accounted for. Not only you are continuing to pay for them, they are actually a huge security risk because they're probably unpaged or unprotected, just unmonitored.

You have multiple privileged accounts and other types of identity in the cloud. It's not just human accounts, it's service accounts and application tokens and API keys and whatnot. You have probably tons of complicated security policies, but again, they are inconsistent and disjointed and you never know whether they actually provide full and consistent coverage. You have networking issues which, again, not only lead to cost but can cause significant security challenges.

And finally, you simply don't have enough time or skill or just enough people to respond to all those issues, compliance, security, whatnot. At some time we believed AI would come to help, but well, it remains to be seen whether it will work as expected. So what do we want? Of course we somehow want to be able to unify all those disjointed tools to make sure that all the proprietary interfaces are somehow standardized, that all the manual workflows are somehow automated, that everything is visible and auditable and properly governed. That's an idea, that's a wish, if you will.

The question is how to achieve all this? And we actually don't have to look too far outside of the cloud landscape. Let's just take Kubernetes as an example. Everyone knows that Kubernetes is a platform for running workloads and it's basically the de facto winner of the cloud native workload race. It's the most popular platform across all the clouds and on-prem.

It does not do all the stuff a cloud native platform can do, but it is somehow naturally multi-cloud because it offers you a highly standardized set of interfaces and it's ubiquitous and it's automated by design, but more importantly you only have to learn it once and then to be able to use it everywhere in a true multi-cloud or hybrid environment. So of course in cybersecurity we are dealing with a slightly different situation. We have a real nightmare of disjointed security tools which are usually created to solve a specific kind of hammer and nail problem.

And in the end we have this alphabet soup of acronyms. EDRs, XDRs, CSPMs, CNAPs. Well you probably know some of them, but I'm sure there are new ones popping up every day which you still don't know about. The question is how do you make all those tools work together? Well there are multiple approaches to that. One way is the old proven defense in depth approach. I mean this thing was invented centuries ago before computers, before the cloud.

The military has taught us that you have to build more than one wall, you have to dig more than one ditch, you have to install multiple layers of protection to actually keep your crown jewels, your multi-cloud crown jewels in the center of this diagram safe. And I've just listed a few of solutions you're probably either already using or have to use if you want to make sure that your multi-cloud infrastructure is safe.

You have to start with data, you have to secure the application layer, you have to know that your endpoints are safe, you have to monitor and secure your network level, you have to be able to deal with your attack surface management. Basically you're looking at your infrastructure from the outside perspective. You have to be able to identify and respond to all those issues quickly and of course you have to have policy controls and compliance controls in place to make sure that everything works as expected.

This is the traditional way and of course it still doesn't answer the question how to make it simpler, how to reduce the complexity. Well what if I told you that there is such a thing and this is exactly what we are talking about today. If you have worked in the industry for more than a few years you've probably heard this haiku.

A lot of people think it's a joke, it's always DNS, but again if you are in the industry for at least a decade you know it is indeed always DNS and if you want to make sure that your multi-cloud highly distributed and sophisticated application, whatever architecture doesn't break, you have to think about DNS as well. But again DNS security is not just an additional layer in the diagram you've seen before. It actually helps to reduce the overall complexity and this is why.

So if you start thinking about DNS as an additional very low, very underlying layer of your overall defense in depth architecture you actually get a lot of very interesting benefits and I've listed just some of them on this slide. I hope Steve will give you much more detail view into this, but basically I would argue the DNS for cloud networking is what Kubernetes is for cloud applications.

It's a ubiquitous, universal, very thin, very standardized layer of security capabilities, not only security but for our purposes security capabilities which would not just provide you with more protection but it will actually make other layers work more efficiently and again I've listed just a few of those things. For example if you utilize DNS security for intercepting phishing mails you probably receive fewer of those on your endpoints which means that you don't need to deal with as many endpoint security events.

You don't have to investigate every phishing attempt hoping and praying that this was not actually the beginning of a ransomware attack. The same applies to the network level. It's very easy to just isolate or block an entire C and C domain which is probably orchestrating a DDoS attack against the infrastructure or you just kind of isolate an unruly user if you know that something's not going on as expected and so on. And again DNS is obviously multi-cloud and hybrid by nature because DNS is ubiquitous. It just underlines the entire TCP IP basically networking.

And thus we actually come to a realization that yes multi-cloud and hybrid architectures are extremely complicated and we have to do something to reduce this complexity if we want to win in the ever-ongoing battle against bad people out there. And we have to look for solutions which are ubiquitous and universal and DNS security is one of those. You have to make it a material part of your defense. You have to make sure that that solution actually allows for intelligent automation and orchestration. And finally, avoid the alphabet soup. Do not look for another fancy acronym.

Take a step back, understand which capabilities you actually require and have a look and look out for solutions which offer you this integrated and unified solution. And Steve, I think you are going to present exactly that kind of a solution. The stage is yours.

Thank you, Alexi. Yeah, so let's talk about unified proactive security for the cloud and more on how DNS can play a role there and does play a role there in addition with some of the other security challenges in multi-cloud. And Alexi touched on a number of these but I'll give a little bit more of an info box focus in how we can help alleviate some of these challenges and the role DNS can play in all that as So there's things like ineffective incident response.

So if you think about public cloud, hybrid cloud, you have all these different environments, different siloed environments, possibly different DNS platforms running in these different environments, different sources of truth for data that leads to challenges with incident response and really impacts the mean time to resolve or mean time to mediate some of the potential issues. There's challenges with stale DNS records, things like dangling C names and other resource records that can be potentially compromised and lead to other exploits if proper hygiene isn't maintained from a DNS perspective.

Also there's traditionally there's more of a reactive type of approach to security in general but specifically with DNS and it's also fragmented. So again kind of touched on some of them more on some of the different environments across the different clouds and the advantages of having a single unified security policy and the DNS security policy for all of that. Another risk or another challenge in the cloud are around credential key and theft. We can talk a little bit about that and some of the techniques that are used for potentially exfiltration and different things. And then zombie assets.

Alexei was talking a little bit about this with the informal state of infrastructure in the cloud things are being provisioned quickly and and deprovisioned as well but sometimes they're not and those resources are left out there and they can be impactful from a cost perspective but also from a security perspective because they're key targets for potential cyber attacks. So traditional security, traditional cloud security like I mentioned is somewhat usually reactive.

So instead of having kind of proactive defense and mitigating it against some of the the risks you know using AI or different technologies before things happen before the threat actors strike. Traditionally the approach is okay we know there's an indicator of compromise associated with a particular campaign or some sort of a signature and we start blocking that in the infrastructure.

And that's usually pretty good but if your patient's zero or if there's some you know threat that hasn't been identified yet and you're exposed to it or it's already gotten into your infrastructure then it's already too late in this case. Contributing to that challenge too is the separate and consistent DNS platforms and DNS security across those platforms. So in a hybrid cloud or a multi-cloud environment you could have you know four or five different DNS platforms out there.

You could have some open source platforms, you could have some Microsoft DNS platforms across the three clouds, you could have AWS round 53, Azure DNS, Google DNS, all these different parts of the infrastructure using those different DNS egress points with either no enforcement from a security perspective or separate enforcement and no ability to really have a consistent approach and coverage there. So stepping back on the challenges a little graphic here to talk about a scenario typical in a siloed environment for incident response.

So let's say there's a security event that takes place and we know that the SOC knows that we know what the source IP address is that was involved in this event 192.18.197.61. All right so the SOC person asks NetOps in this case you know what is this IP address because I don't know I need to know. So NetOps checks in their spreadsheet wherever they have this data some time goes by they respond yeah the 192.18.18.16 this is in AWS so go check with the cloud team on what that might be because that's all I have.

So the SEC ops person goes and asks you know again the same question but this time to the cloud team you know what is this IP address what has that and the cloud team after some time gets back and responds okay yeah this is a a VM running for a DevOps application go ahead and check with the apps team for more details if you need more information on that. And here's some additional context you know the web server and applications and details on that.

So again the SEC ops has to go to another team and ask okay you know who created this web server who's responsible for it some time goes by they respond back yeah it's owned by by Robert Lim he's he's the one responsible for it so okay now SEC ops finally has enough information they can you know kind of move on with the containment remediation of this problem. But some time has gone by so it's you know it's it's not trivial to get some of this information if you don't have comprehensive visibility and unified data points or data roll up for all of this.

And if if you're paying attention in the graphic here as well you may have noticed there's a discrepancy in in some of the network addressing. So the IP the address that was asked for was a 192.18 the response that came back was a 198.18 slash 16.

So that's something that can happen in the real world as well if these environments are siloed there's no automation between the two there's manual interaction exchanges on hey who has this address or where is this subnet and if all that isn't consistent then you can get those types of errors so you could be chasing down the wrong network or the wrong IP address in the end leading to further delays in containment and remediation. So what can you what can you do about that?

So again related to the challenge of improving the incident response with a platform like what Infobox can provide with for example our universal DDI. DDI is the acronym for DNS DHP and IP address management that kind of ties all that together. We can provide all the contextual information related to an IP address.

So if a device makes a query to a known malicious domain name and that's part of the incidents that's being responded we can provide the context on what was being queried, who was querying that, what was the source address, what was the device, what was the MAC address, a lot of additional contextual information across all of these environments. So whether it be originating out of a public cloud environment or on-prem kind of unifying all that and really kind of speeding up the sec ops in the meantime to remediate. Another one of the challenges was around stale DNS records.

So there's been a number of attacks and techniques over the years that exploit these. Some of them use dangling C names which if a threat actor can then kind of compromise what the end destination is of a particular record then they can basically provide some sort of adversarial service or content on a address that appears to be owned by a legitimate domain name because that record originated in your domain name or one of your legitimate zones.

There's a number of examples of different things like this where attackers can kind of compromise some of those domains and create records because they're stale, they're not being monitored and cleaned up by the organization that owns them. A real world example of that was actually a medical company that was alerted that a record in one of their authoritative internet public DNS zones was pointing to an Indonesian gambling site. So the threat actor was able to compromise that because basically the record originally had pointed to a AWS S3 bucket.

The bucket was decommissioned, the record was still out there. There's some techniques that can be leveraged to basically take over that existing IP address and then they were essentially able to direct traffic to that particular DNS record to this other site. So the medical supply company suffered some reputational damage there because of this and some other things but it initiated more of a full audit into all the records and looking at compliance and control over that.

So there's kind of brings to the DNS hygiene and keeping all the records clean in the infrastructure so that they can't be compromised. So things like automated discovery of all the DNS records and maintenance of all those DNS records and information that's out there is a key part of a comprehensive security plan when you think about DNS and DNS security and eliminating some of those stale DNS records.

If you're looking at the graphic here there's another example where lame delegation from a DNS can be abused as well and lame delegations I'm not going to go into the detail about that at this point in time but basically if there's a lame delegation in your authoritative zone which is basically an NS record or a name server record pointing to a DNS server that does not acknowledge or does not have those particular zones loaded in there again kind of stale DNS information then the threat actor can potentially kind of compromise those records via the registrar take over that particular name server those particular records and then use it for similar attacks whether it be phishing or other compromise where they can basically appear to own or own part of an Another real world example of a hijacking type of attack with stale DNS records is the IP use after free attacks so if you think back a couple of slides where that S3 bucket was basically retired and then the address that pointed at that was compromised there's attacks that can be run to basically cycle through addresses quickly in the cloud environment until you get the IP the public IP assigned that you want to use and if it's one one one of the IPs that was previously used for some other valid resource in a different domain if you can take over that IP address now you have it you can put whatever threat infrastructure you want whatever adversarial malware whatever you want to host on that you can you can do that until you're you're caught effectively but now it appears to be associated with a legitimate domain so threat actors can take advantage of that particular compromise so moving on talking a little bit about we talked or actually talked about kind of the power of DNS as well from a ubiquitous approach and providing protection against DNS malicious DNS queries kind of across the different infrastructure so the native cloud resolvers don't provide either any protection or much protection from this perspective so it starts to break things down so if you already have some DNS protection in place from an on-premises perspective then you may not have that in the cloud you may not have the same platform providing some of those protections across the different environments so providing a single DNS protective DNS solution or detection and response type of solution from a DNS perspective that can be run out of a cloud infrastructure can provide the same security the same policy the same platform if you will across all of the infrastructure so whether it be traffic or DNS traffic inquiries that are generating from a public cloud from on-premises from different branches it can be all kind of centrally managed consistent policy and then you can provide the protective approach from a DNS perspective again going back to what Alexis was talking about the different layers of DNS security so protecting things from a DNS perspective is one of those layers that can be more comprehensive because DNS is everywhere everything uses it providing critical security and enforcement there against mitigation of queries to malicious domain names or things like command and control or even data exfiltration over DNS can be easily implemented and controlled from a consistent policy perspective I spoke a little bit about proactive versus reactive so one of the things that Infobox is doing that's a little bit unique in the industry is we're not just focusing on the malware but more of the malware infrastructure if you think about it from kind of generic security perspective so we're not focusing on okay we know this is bad because it's part of you know this particular threat actor campaign or this particular operation sure we can you know have those indicators we do have those indicators and we can mitigate against queries that that go to those particular domains and block those or redirect those but we're also doing a lot of research on the threat actor infrastructure and understanding and discovering the infrastructure that they're using the domain names that they're potentially registering and sitting dormant or using for other activities for a number of of months or maybe even longer so they gain some reputation and can slip past you know some of the other security controls but with the research and the intelligence that we have we're able to identify some of these threat actor domains their infrastructure and provide proactive mitigation before campaign or attribution even happens with some of the domains and on average we're able to detect and block some of these things 62 or 63 days ahead of when other tools were able to actually detect and block these because the campaign became live and active so we're providing kind of real kind of cutting-edge mitigation against a number of these threats by using the dns protocol and dns technology in this case so reducing credential and access key theft this is another critical risk when you think about public cloud infrastructure you really want to secure those access keys because cyber criminals really want to target those because of the the amount of control and privilege and different things that they can have with that how are we going to protect that with with dns well we're not going to mitigate that threat directly with with dns but one of the ways of getting information out of an infrastructure that's pretty trivial to do once once you're in once you have the data that you want to exfiltrate essentially is via dns you can simply take the information put it into what appears to be a relatively normal dns query other than the label may look a little strange send those through a dns resolver that will just send that those queries out to the internet just like any other dns query uh where the threat actor can then collect that data on the other side reassemble it and then they have all of the access keys all of the intellectual property whatever information they may want to may want to retrieve there so leveraging again with the info box dns detection and response we can mitigate against those queries whether they're up to no malicious domain names or using artificial intelligence and behavioral analytics we can detect exfiltration and c2 and those types of communications over dns on the fly to provide mitigation there as well and lastly we mentioned a little bit about zombie assets so these are something that can be exploited if they're beyond the infrastructure in the public cloud so we want to have you know visibility into the instances that are out there that are potential zombies or the other assets that are out there in the cloud that are potential zombies as well with a universal platform like info box that can provide visibility into all of these cloud environments and we can detect things that we believe are zombie assets giving you visibility into that and be able to allow you to decommission or remediate or resolve some of those potential issues to mitigate the risk of the the cyber criminals identifying some of those records or resources maybe via some of the dangling or stale dns records as well and then potentially compromising those because they haven't been secured or patched and then launching further campaigns uh and threats against your infrastructure or or others as well uh so kind of recapping a little bit here on the info box security so some of the challenges that we can help from a data security perspective and from a security perspective are again identifying some of these threats sooner and blocking uh much earlier in the the cyber kill chain if you will or even be pre-cyber kill chain because of some of the the proactive and suspicious domain monitoring and mitigation that we're doing so stopping attacks faster protecting every systems everywhere so against or across all the different clouds across the on-prem infrastructure as well blocking some emerging threats things like lookalike domains to the brand we can mitigate against those automating and plugging in this into existing cloud tools and other secop tools and operations and then really kind of streamlining operations and using more resources so in a minute we'll go into a demonstration of some of the platform where my colleague here Sebastian will will show some of the security from a dns perspective and some of the enforcement that can be provided along with some of the asset discovery and zombie assets and different things that we can provide but just want to mention too if anyone's interested we do offer a comprehensive security workshop focusing on dns and all the different exploits and activities and different techniques and tools that threat actors are leveraging uh things that you should think about and how you kind of protect and secure your infrastructure from a dns perspective so there's usually some eye-opening conversations that come out of that and then we can also provide a security assessment by looking at the actual dns traffic in an infrastructure and then pointing out the visibility and the potential threats and the different things that are going on in that infrastructure by looking at at the outbound dns traffic either out of a cloud or on-prem or wherever it may be for a 30-day perspective on that all right so with that let me turn it over to Sebastian who will actually take you into our platform to look at some of the threat defense security and universal dvi or dns and dhp and ip address management contextual information that can be provided with the infobox platform thank you steve um also welcome from my side we didn't hear each other so far so um long story short steve provided a lot of information about uh the different techniques on dns what has it to do with with micro with multi-cloud how is it running on um or how does it look like in the different environments why is it important and so on and so on um just having a look at and or let me start different having a look at all those things if customers are running multi-cloud environments aws and and google cloud and azure and even on-prem dns whatever the biggest issue everyone has running those different environments is visibility because you can assume each of those solution having their own let's say graphic user interfaces their own interfaces their own way how to configure things whatever so the biggest problem we typically have is visibility and that comes then with issues on compliancy with having the right overview and so on and so on so key fact and key problem is or the first thing we need to solve is is the visibility part because that gives you the overview to be let's say able to make decisions to see if something is secure or not and so on and so on what you see here is our cloud solution the first part of it which provides a visibility into the public cloud environment from a ddi perspective so dns dhcp ip address management and also for let's say on-prem when it comes it was mentioned on the slides already if you're running bind servers or even in the future microsoft servers or running our on-prem ddi solution already maybe some of you know it whatever that's a graphical let's say a graphical overview about how could let's say an interconnect with with such solutions look like and what which result can I get in a to get a very quick overview so what you can see here is the solution does nothing else than connecting to the public clouds azure aws google cloud and even one and then is able to to pull out the information and let's say logically combines the information to let's say things that make sense and figure out what is going on in the environment so you see some things on the top here let's say saying zombie assets what's what's a zombie asset going to the right hand side it can be something that is uncategorized so something we cannot figure out what it what it maybe is it can be something infrastructure related so it can be a whatever thing running in in in public cloud somebody spun spun the device up which we which we which is network infrastructure related virtual switch something like that or we have gateways provisioned or we have something with linux operating system provisioned or we have firewalls provisioned in the public cloud whatever and it gives you the full overview about the different cloud areas telling you what's going on when is the device being a zombie asset different criteria for that i'm not going too much into detail but one of the things is is it using dns is it being are the dns request the dns records of those devices being being resolved or not is it being used or not those are let's say small indicators of marking a device as being a zombie asset why are those devices let's say important to know on the one hand side of course it's money no public cloud provider lets you spin something up without paying money for it that's one thing and the other thing is it's security as steve already mentioned is a problem if you have stuff running in public cloud for example and then the device is doing nothing being out of control not being patched not being updated not on the not being under the the updated security controls things like that so we want to get known to such kind of things we were talking a lot about dns and stale dns records and all those kind of things so the nice thing is we're not only taking out of the out of the cloud information those are the assets those are the appearances of the assets so those are the whatever networks where they are in are they resolved or not things like that what we also do is we pull out the whole dns part from the public clouds and put it into into our system and we only we not only can read it we also can take the the management control over those systems so we can use our system to centrally configure the different public cloud dns solutions on azure for azure dns on route 53 things like that and what you see is if you have this information what can we do is we again logically can check this information and figure out okay what's going on we have a few assets but maybe we have 158 assets which have no dns pointer records and we have a few other assets 145 where the dns forward record maybe is missing is it always the case that this is a hundred percent a problem could be that it has been done on purpose but if then i want to to get rid of the ones which are where it has not been done of purpose or on purpose so i want to know if there are things missing is my configuration consistent over my different public cloud environments if you spin up let's say an application service running over multiple clouds for redundancy and resiliency so the stuff needs to be consistent in any way so how to make sure that it is consistent at all points of time and then of course confidential confidential confidentiality levels on our confidence levels on the different assets how high do we think is is it or is the percentage that those assets have an issue and then of course we can dig into details so for example for the zombie assets i want to know those just stick into the details get the detailed views and you see okay i have something running on aws here it's running in the us east two region and which classification does it have so maybe it has something to do with compliance compliancy also we do some sort of compliancy checks on the devices or on the assets we find like are the the dns records correct maybe it can be a storage volume being publicly let's say addressable things like that and we can categorize them as zombies and then i can dig into the details and figure out okay what is it where is it lying when have have i seen it the last time the first time that's a demo environment so don't care about the first scene here or just a zombie here what's going last scene at this point of time first scene at another point of time compliancy things down there is it a zombie that's a detached storage volume for example it's not used for anything it's just sitting around we see that customers especially the bigger the environment scat and the more public cloud is being used that such things can happen and if such things happen happen we want to know it immediately the reason why it happens can be multiple it can be because of automation is running or the automation is breaking somewhere or things being done manually we all know the we have in it because of too much workload too less time too high complexity whatever the reason is at the end but it can happen the bigger and the more complex the environments get so that's the the overview thing so taking the information from the public cloud pulling it into one system and then let's say creating uh kind of an uh let's say a central database for the what is asset related and then what can we figure out there and where is the stuff residing that's also important the bigger the environments get and the more widespread they get to have a single centralized overview about what is where why when and in which in which way uh that was quickly information i just wanted to to quickly show it because we do not have too much time but what do we pull from the different public clouds which visibility do we get in and what can we can we see of course it's i already mentioned that it's ipam data so from public clouds from the different ones we get the ip information the networks the dns records all those kind of things and just showing it as an example on dms how it looks like so i have one dns overview and i get all the different zones here or the different dns views for the different zones whatever and we mark it and show where the information comes from so this information or that one for example those are let's say info blocks universal ddi related information something we configured in our system this is coming from and residing on a microsoft server on the microsoft ad uh this is information residing on an info blocks uh on-prem solution and we pull the information in here and let me pull down a bit that's also an ios we also would mark it for for aws and then you see an aws sign in front of it or a cloud sign in front of it or uh depends what you want to see there um different ways of showing it in the environment um and uh so you get the generalized overview nice thing is one-stop shop for all dns related information and same on the ip side or on dhcp and all those kind of things good that is the the part of the let's say dns part when it comes to internal dns how to to to do the dns hygiene how to get the overview about what is running in my environments where is it uh zombie asset stuff um when it comes to protective dns or dns security just a quick one um no sorry i need to go to monitor here and this dashboard what does dns security care about it also is dns but it is not your internal dns so which dns records do you have or which internal laptop is reaching out to an internal dns record because an internal application has been used dns security cares about all dns let's say requests and the replies coming back leaving your environment so everything going external it can be going external from your public cloud environment it can go external from your um from your private cloud from your from your on-prem environment so as soon as you reach out to something external dns record dns requests being done and replies coming back and it can be legit or it can be malicious and this is the tricky part this is what we want to figure out and again what is the most important thing because this part very often is kind of a black hole for a lot of customers what we do is we take all the the dns requests and then of course the replies but um first of all the requests and pass them pass them through our cloud environment what we do there is we just pass them through we're sitting in line or we can sit in line not only and we analyze them how is it built how does it look like where it is going to is it already known malicious or is it just uh looking strange is it related to a threat actor environment which is known or even not known or suspicious looking whatever or something you never reached out to we also can can get away of such things and we create the visibility and that's again key we cannot secure anything if you don't know it so the first thing we need to do is create visibility that's always the first step and then doing the analysis and then figuring out what to do with it and then you see we do categorizations like data exfiltration where or something going to something we call a suspicious domain can be related to a threat actor environment internet infrastructure those are duty and duh things um dns over hdbs or dns over tls uh policy related malware commodity control things whatever so everything related on the dns side and then again on the um on the dashboard here quick overview um what can we can we say what's happening environment top request a domain so where is my environment reaching out most to or top blocked web destinations what are the most the most um address or most blocked destinations from my environment um top devices by dns activity when we do tests and custom environments are running pucs or this kind of visibility sometimes customers are surprised what are their top dns talkers in their dns environment externally facing it's sometimes really really interesting but what shows up there most customers don't know it um on that side or threat feeds what are the most hit threat feeds in your environment of course those are things you typically do not want to see in the best case you do not see any most hit threat feed because it means you have something bad in your environment but if it shows up from a security point of view for for a sock for a threat analyst whatever it is crucial to get the let's say overview on what to focus first so where do we want to focus first the most bad the baddest and the worst things in our environment so we need to get the visibility first knowing what is going on there and then getting the let's say priorities in there and figure out okay this is going on this is going strange this is going bad and in best case in the most detailed way so those are just graphs and state status information but if you look in like we have here which is called insights an insight is nothing else than let's say a sock way of showing what is going on in the environment and what we do here is we create those insights by criticality so the most critical first then a type of it what is it it's zero day dns it is emergent domain or emergent threats the last time we've seen it how long is it active in my environment and then i can investigate it immediately and see okay the active period started here it stopped there okay yeah it started here stopped there and then going on into areas like how many assets from my environment are impacted by it which ones i have once in here another one i want to sit there at this point of time for here and then even here the capability of i just want to see which ones what's going on there whatever and then i can figure on go on here and go into the details that's a windows system windows elves windows 11 system here with three address behind it for whatever reason maybe three interfaces or whatever first time last time observed and then also being able to go into the details and then going for the indicators because one threat can have multiple indicators different things coming to one so here we see the indicators and then going into the events so here we go from criticality to asset to indicator to the multiple events and then digging into the detail because typically it's the other way around you have a huge amount of events and then we go into the we want to narrow it down and we automatically can do that on the dns site here quite easy automatically in our system that's it mainly so on the one hand side we need to care about especially with with widespread environments we are running on different technologies on the visibility and centralized control over our let's call it internal dns hygiene administration configuration those kind of things this is universal ddi as an overlay and on the other hand side we need to take a look at who's talking outside on the dns layer and getting the visibility there and the control and protection mechanisms to figure out okay if something went wrong for whatever reason someone clicking a phishing link or you already got a ransomware inside a malware inside however that happened but then it starts talking outside maybe a dns or a command and control traffic happening something like that then we need to figure out what is going on there and then getting all the details in a very easy way and in best case of course there's never a hundred percent security but having a high chance of figuring out what is going on there and then blocking the stuff away and this is what we do on the blocks on threat defense part for the let's say recursive resolving part on the dns side that's it mainly on the demo i think i was already talking a little bit too long but that's it from my side if you want to get more details you always can reach out to thank you all right well thank you very much steve and sebastian uh much appreciated i think uh personally like i've been dealing with dns uh as a quote-unquote expert for almost 30 years now and still i've learned quite a few new things today so thanks a lot for that great uh we still have uh a few minutes left for questions and we actually do have uh two questions already asked earlier one was about the level of feasibility that your solution can provide and the master i think you've answered that perfectly with the demo uh the second one uh for the benefit of our viewers who won't be able to read the text part steve can you please maybe go through it uh quickly again so the question was how is uh the aws native dns firewall not better or not why is your method sure yeah good question so it's the aws native dns firewall is a is a good start it's something you can add on to route 53 to basically provide some protection of the dns queries that go outbound uh but again there's some limitations there because it's only in aws so if you want to have consistent policies across aws and azure or on-premises as well then you can't with the route 53 firewall um it's also effectively any dns filtering is only effectively as good as the threat intelligence that you provide there so you can bring your own intelligence and kind of plug that into the into the aws route 53 uh dns firewall and we do recommend our customers if if they want to leverage that and they have info box platform they can use our intelligence and kind of feed it into that but there's some other limiting factors there to around cost so like with anything in cloud nothing is free so there's costs for leveraging the route 53 resolvers there's costs for leveraging the dns firewall function and depending on the volume of traffic and activities and different things like that it can become very expensive to have kind of a point solution that's only protecting a single part of your infrastructure right well thanks a lot uh the next question i think you even or i mean if you go back to that uh imaginary conversation between different teams you've demonstrated in your slides earlier well how basically doing this or incident response and analytics manually is extremely slow how would you go about making it faster within your solution like is it automated or is it guided better so where is the time saving yeah yeah there's there's a number of ways of time saving one is using the tool and getting all the information in there but really the ultimate way is is leveraging our api integrations to be able to extract all that information so if if you're using a sock platform or a sim platform that's getting kind of the aggregate of the threats and the incidents that can plug directly into our platform to extract that data to understand yeah who owns that ip address and where is it and what what else is associated with it from a dns perspective looking at you know maybe what other things that device or ip has been querying so be able to get all that contextual information out of our platform but using the api as an automation integration that's where it can really speed up that whole time to remediation and simplify things right right uh since we only have one minute left uh and no actually no questions from the audience so far i may ask uh my own one sure so like what if i i mean what if you have a persona in the company potential customer who are actually not dns experts themselves can they still benefit from this solution can they just kind of let them do its thing and feed or the intelligence the insights to other teams so yes absolutely that's part of the i guess the the one of the missions of info box is kind of the this pursuit of simplicity making everything easier to manage and easier to integrate and not having to understand dns on a deep technological basis you know leave that leave that to us to kind of you know help solve that so yeah it can be easily implemented and leveraged and you can take advantage of all of the the features and functionality okay well awesome and we are actually exactly on the top of the hour so our allocated time is unfortunately over uh thanks a lot again steve and sebastian uh thanks a lot to all of our live attendees and of course to everyone who will be watching the recording of this later i hope to see you all at some later at another webinar or maybe even a live conference thank you very much again and have a nice day thank you alexa