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 breaches, 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. 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, 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. But sometimes you just 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 unpatched, 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 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, it's well, 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.
EDR, XDR, CSPM, Synapse, or 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 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 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 a 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 just seen before. It actually helps to reduce 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, he'll help you into this. But basically, I would argue that DNS for cloud networking is what Kubernetes is for cloud applications. It's 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 would 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's just underlying 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 you 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 an integral part of your defense. You have to make sure that that solution actually allows for intelligent automation of orchestration. And finally, well, 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, Alexei. Yeah, so let's talk about, yeah, 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 Alexei touched on a number of these, but I'll give a little bit more of an infobox focus in how we can help alleviate some of these challenges and the role DNS can play in all that as well. 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 meantime to resolve or meantime to remediate some of the potential issues. There's challenges with scale 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, touched more on some of the different environments across the different clouds, and the advantages of having a single unified security policy and a 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, you know, with the ephemeral state of infrastructure in the cloud, things are being provisioned quickly 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 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 you're patient 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 inconsistent 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 Route 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 the siloed environment for incident response.
So let's say there's a security event that takes place and we know that the SOC knows, you 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.197.1.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 SecOps 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 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 there's some additional context, you know, the web server and applications and details on that.
So again, the SecOps 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 Robert Lim, he's the one responsible for it. So, okay, now SecOps finally has enough information, they can, you know, kind of move on with the containment and mediation of this problem. But some time has gone by, so it's, you know, 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 you're paying attention in the graphic here as well, you may have noticed there's a discrepancy in some of the network addressing. So the IP 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's the 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, you know, 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, there 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 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 point of the DNS hygiene and keeping all of 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 scaled 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 on 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 a 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 authoritative domain of a customer infrastructure.
Another real-world example of a hijacking type of attack with scaled 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 public IP assigned that you want to use, and if it's 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 do that until 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 Alexei talked about kind of the power of DNS as well from a ubiquitous approach and providing protection against 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 a non-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 and queries 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 Alexei was talking about, the different layers of DNS security, so protecting things from a DNS perspective is one of those layers that can be, you know, more comprehensive because DNS is everywhere, everything uses it, providing, you know, 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 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 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 a 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 amount of control and privilege and different things that they can have with that. How are we going to protect that with DNS?
Well, we're not going to mitigate that threat directly with DNS, but one of the ways of getting information out of an infrastructure that's pretty trivial to do 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 those queries out to the internet, just like any other DNS query, 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 retrieve there.
So leveraging, again, with the InfoBox DNS detection and response, we can mitigate against those queries, whether they're up to known 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 on 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 InfoBox that can provide visibility into all of these cloud environments, and we can detect things that we believe are zombie assets, give 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 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 and threats against your infrastructure or others as well.
So kind of recapping a little bit here on the InfoBox security. So some of the challenges that we can help from a DNS security perspective and from a security perspective are, again, identifying some of these threats sooner and blocking much earlier in the cyber kill chain, if you will, or even pre-cyber kill chain because of some of the proactive and suspicious domain monitoring and mitigation that we're doing.
So stopping attacks faster, protecting systems everywhere, so against or across all the different clouds, across the on-prem infrastructure as well, blocking some of the 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 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, things that you should think about and how you can 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 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 DDI or DNS and DHCP and IP address management contextual information that can be provided with the Infobox platform. Thank you, Steve.
Also, welcome from my site. We didn't hear each other so far. So long story short, Steve provided a lot of information about the different techniques on DNS, what has it to do with multi-cloud, how is it running on, or how does it look like in the different environments, why is it important, and so on and so on. Just having a look at, or let me say different, having a look at all those things.
If customers are running multi-cloud environments, AWS 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 solutions having their own, let's say, graphical 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 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 the 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 such solutions look like and which result can I get 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 on-prem, and then is able 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 a zombie asset? Going to the right-hand side, it can be something that is uncategorized, so something we cannot figure out what it maybe is.
It can be something infrastructure-related, so it can be whatever thing running in public cloud. Somebody spun the device up, 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 a 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? Are the DNS records of those devices 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, it 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 being under the updated security controls, things like that.
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. The nice thing is, we're not only taking out of the cloud information, like those are the assets, those are the IP addresses 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 our system.
And we not only can read it, we also can take the management control over those systems, so we can use our system to centrally configure the different public cloud DNS solutions 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 100% a problem?
Could be that it has been done on purpose, but if, then I want to get rid of the ones which are, where it has not been done 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's consistent at all points of time.
And then, of course, confidentiality levels or confidence levels on the different assets. How high do we think 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 2 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 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 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 seen at this point of time, first seen 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's gap and the more public cloud is being used, that such things can happen. And if such things 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 problems 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 overview thing. So taking the information from the public cloud, pulling it into one system, and then, let's say, creating kind of a, let's say, a central database for the whole overview about what is DNS related, what is ACID 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 way. That was quickly information. I just wanted 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 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 DNS, how it looks like. So I have one DNS overview, and I get all the different zones here, all 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, Infoblox universal DDI related information, something we configured in our system.
This is coming from and residing on a Microsoft server, on a Microsoft AD. This is information residing on an Infoblox 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 AWS, and then you see an AWS sign in front of it, or a Google Cloud sign in front of it, or depends what you want to see there, different ways of showing it in the environment, and we highlight it. So you get the generalized overview.
Nice thing is one-stop shop for all the NS related information, same on the IP side, or on DHCP, and all those kind of things. Good. That is the part of the, let's say, DNS part when it comes to internal DNS, how to do the DNS hygiene, how to get the overview about what is running in my environments, where is it running, and some of the asset stuff. When it comes to protective DNS or DNS security, just a quick one.
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 is being 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 private cloud, from your on-prem environment.
So as soon as you reach out to something external, 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 you 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 DNS requests and then, of course, the replies, but first of all, the requests, and pass them through our cloud environment. What we do there is we just pass them through. They'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 is it going to? Is it already known malicious, or is it just 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 get aware 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, or something going to something we call a suspicious domain, can be related to a threat actor environment. Internet infrastructure, those are DUT and DOH things, DNS over HTTPS, or DNS over TLS. Policy related, malware, command and control things, whatever. So everything related on the DNS side.
And then, again, on the dashboard here, a quick overview. What can we say what's happening in the environment? Top requests to domains. So where is my environment reaching out most to? Or top blocked web destinations. What are the most address, or most blocked destinations from my environment? Top devices by DNS activity. When we do tests in customer environments, or running PUCs, or the security assessment, we get this kind of visibility. Sometimes customers are surprised what are their top DNS talkers in their DNS environment externally facing.
It's sometimes really interesting what shows up there. Most customers don't know it 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 a SOC, 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 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 status information. But if you look in something like we have here, which is called insights, an insight is nothing else than, let's say, a SOC 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 related to 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 ones in here, another one I set 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 11 system here with three IP addresses 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 side here, quite easy, automatically in our system. That's it mainly.
So on the one hand side, we need to care about, especially 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 via DNS or 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 100% on 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 Proxima 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 us. Thank you. All right.
Well, thank you very much, Steve and Sebastian. Much appreciated.
I think, personally, I've been dealing with DNS 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. We still have a few minutes left for questions, and we actually do have two questions already asked earlier. One was about the level of feasibility that your solution can provide, and Sebastian, I think you've answered that perfectly with the demo. The second one, for the benefit of our viewers who won't be able to read the text part, Steve, can you maybe go through it quickly again?
So the question was, how is the AWS's native DNS firewall not better or not comparable to your solution? Why is yours better? Sure.
Yeah, good question. So it's the AWS native DNS firewall 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.
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 do that with the Route 53 firewall. 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 AWS Route 53 DNS firewall. And we do recommend our customers, if they want to leverage that, and they have an Infobox platform, they can use our intelligence and kind of feed it into that.
But there's some other limiting factors there too 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. The next question, I think you even are, I mean, if you go back to that imaginary conversation between different teams, you've demonstrated in your slides earlier, well, how basically doing this response and analytics manually is extremely slow. How would you go about making it faster within your solution? Is it automated? Or is it guided? 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 SOC 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 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 is an automation integration.
That's where it can really speed up that whole time through mediation and simplify things. Right, right. Since we only have one minute left, and no actually no questions from the audience so far, I may ask my own one. Sure.
So like, what if I mean, what if you have a persona in the company, potential customer who actually not DNS experts themselves? Can they still benefit from this solution? Can they just kind of let them do it thing and feed 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 pursuit of simplicity and making everything easier to manage and easier to integrate, and not having to understand DNS on a deep technological basis with that, that's us to kind of help solve that.
So yeah, it can be easily implemented and leveraged. And you can take advantage of all of 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. Thanks a lot again, Steve and Sebastian. 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 time at another webinar or maybe even a live conference. Thank you very much again and have a nice day.
Thank you, Alexei.
