Hi, my name is Garrett Weber. I'm with Akamai and I'm going to give you a demo today on the Akamai Guardicore Segmentation platform. Now the first thing you're going to see when you look at the Akamai Guardicore Segmentation platform is we give really rich visibility into what's going on within your environment in your infrastructure.
So as we look here, we see a map. We refer to this as Reveal, and you can easily zoom in and take a look at what's happening within your infrastructure. First place we'll look here is inside the production environment, and we can see here a collection of different applications and how they communicate within the organization.
We can look specifically at the accounting application and see how the different components of the accounting application communicate with each other. More specifically, we can take another step down and look inside the different pieces of the accounting application and look at how the database servers communicate within that application.
And we can go all the way down, look at an individual database server and look at the actual processes that are communicating for that system. You can take a look into these processes and see exactly the process name, the path, the hash, the user that executed the process, as well as the command line that was executed to run that process.
This gives organizations a really rich understanding of how their applications are communicating, how users are using those applications, and sets us up for success when we start building policy and when we do investigations into the traffic. These maps are fully customizable.
So here we looked at a view starting at the environment level first. Well, we use a concept of tags to actually organize and look at, here we go, different levels within an application. So you can see here we've already labeled this system as being an Ubuntu server.
It's part of the accounting application, it's a database server and it's part of the production environment. We can use these labels to create different views. So now let's look at this from a view of the platform first. So now we understand which platform these systems are actually deployed on.
We can look at what's deployed on the Akamai cloud computing platform. We can look at what's deployed within a Kubernetes cluster, and we can look at what's deployed within an on-prem environment as well. You can fully filter to include or exclude any type of attribute you would like to look into deeper in these maps, and you can also have them time-based.
So here we're looking at the daily map from yesterday. You can also view back up to 60 days worth of the traffic within your environment.
Now let's talk about labels. Labels are really critical because they allow us to abstract the assets and create rules that are not based on IP addresses, but are based on the actual assets themselves. Labels can be created in several different ways within the platform.
The first way is we can create them on our own using maybe criteria such as if every server includes the word prod in it, we can add it to a label called production. We can also pull them from your CMDB, such as a ServiceNow. We can pull them from tags you've created within a cloud provider like AWS or Azure.
Or we actually have a way of introducing labeling using an AI tool where we look at what's occurred within your environment and give you recommendations of labels you can apply to collections of assets based on traffic profile, such as the processes, the ports they're communicating on and how we see users and systems interacting with these applications.
You'll see here we have a recommendation to add the App: MySQL label to six systems within your environment. If you want to take a deeper look into this recommendation, you can review our suggestions, understand which six systems have been identified as possibly having this label applied to them, and if you click on one, you can get a recommendation and all the evidence tied to it that shows you exactly why we are recommending you apply the App: MySQL label to this system, giving you a confidence level that as you apply these labels, they are accurate and they are relevant for the systems within your environment.
Now let's move to policy building. The first way organizations build policy within the platform is they use what we call Essential Policies.
Essential Policies are a collection of recommended policies that we see as relevant for all customers and all enterprises to reduce risk and eliminate the opportunity to move laterally for an attacker throughout the environment. You can see here some of these examples of the Essential Policies.
The first one we see are common binaries that are unnecessary and leverage high-risk ports to allow an attacker to move laterally through the environment. You see the recommended rules, any binaries or processes associated with them, the fact that the rule is enabled, it's currently in an alert mode, and how many of the systems are actually enforcing the rules to date.
You'll also see that we believe this rule is ready to move to block at this point in time. So not only are you getting a full set of recommended rules, you're also getting a recommended flow for when to move the rules from draft to alert to block, making it really simple for your organization to leverage these essential policies to reduce risk within the environment.
Some of the other policies that we recommend here are around controlling high-risk ports that should not be accessed from the internet. Tools like Windows Remote Management, RDP, SSH that are commonly used by attackers to move laterally, and high-risk ports that are oftentimes should just not be available to and from the internet.
And giving you another layer of ensuring that these ports and services are not accessible to attackers that may be trying to access them from external to your environment. Now, once you've reduced risk using essential policies, you can start building rules based on other use cases for segmentation.
We make this really simple for you by using these policy templates that show first, types of applications that can be used as templates for the environment, such as Active Directory or DHCP. These are well-known applications that are documented, and we have templates that recommend the appropriate ruleset for those applications.
We also have rulesets for ransomware, both for prevention and response. In the case that you may want to ensure you are not vulnerable to allowing an attacker to move laterally in the case of a ransomware attack, or if the attack is in progress, you can quickly isolate parts of the environment.
Then you'll see an additional list of templates here. And these are really focused around different types of segmentation use cases. So maybe I want to control privilege access from jump boxes into different parts of my environment, or I want to only allow outbound flows for a specific application.
Or most commonly, organizations want to ringfence applications within their environment controlling access to and from that application. We click this tile, and then we get a really simple wizard to walk through creating policy for this application. So in this case, we're going to continue looking at the accounting application.
We're going to look at it inside of all of our worksites, and we're going to secure it within the production environment. You could do this also in development or QA environments if you have pre-prod versions of this application as well. And we're going to choose an additional option to secure it all the way down to the process level.
So now when a user clicks next, you get a full recommendation of all the rules that would be necessary to lock down this application, as well as a visual view of how these rules impact that traffic flow.
What you'll notice about these rules is we recommend them all the way down to the actual process that is included in the connection so that you can secure all these systems down to only the necessary communication ports and services that should be open and available.
You see we have our source and destination outlined with the labels we've created, the ports, the protocols, and the processes all in one place, making it really simple for you to build rules to protect these applications. When organizations begin to push rules, they first start pushing them in alert mode.
This allows you to ease into creating segmentation policy without potentially impacting business processes. After about a week or two, we'll probably be in a position where we're ready to move these rules to block and we really have simple workflows to get you from draft to alert to block, and then publishing these rules out to the agents, security groups, switches, and other enforcement points within the environment.
Another way that organizations use the Akamai Guardicore Segmentation platform is for querying for potentially vulnerable systems — systems that may be subject to supply chain or zero-day attacks. To quickly identify which systems are vulnerable and put policy in place to mitigate that risk temporarily until you can patch or upgrade or take the necessary actions to bring those systems back to business as usual.
The way we do this is using Guardicore Insight. Guardicore Insight allows us to use SQL queries to ask questions of anything within the environment on the systems that our agent is installed on. So in this case we're going to use a SQL query looking for systems that are vulnerable to the XZ Utils vulnerability that was a major issue for many organizations a few months ago, with the biggest deal being how do I locate which systems are vulnerable and how do I put a control in place to limit the impact temporarily.
I enter my SQL query, I press run, and you'll see automatically we go out and we start querying all the systems within the environment to identify if they are vulnerable based on the requirements within the SQL query. Once we get a list of vulnerable systems returned, we can easily apply a label to these systems, something like Quarantine XZUtils.
Apply that label, and then move to our policy building screen, and build rules to limit access to these vulnerable systems. You'll see here we still have a rule in place allowing our incident response team to access from their endpoints these vulnerable systems over SSH or RDP.
This allows these teams to still patch these systems and take the necessary mitigation actions while using these block rules to reduce the risk associated with the XZ Utils vulnerability. Making sure that no one else can access these systems aside from the incident response team.
This is a really quick and easy way for organizations to address zero-day and supply chain attacks in one tool without having to first run vulnerability scans. Take that data, compare it to the segmentation solution, and then write those rules.
This is all done in one location for you.
Next, we'll take a look at another part of the Akamai Guardicore Segmentation platform that we call Akamai Hunt. Akamai Hunt is a service offered by Akamai that allows you to leverage your segmentation deployment to do a few things, one being threat hunting and looking for threats that may be within the environment that other tooling has not identified for you.
Another thing we use the Akamai Hunt for is identifying areas in the environment where we can improve your security posture by recommending rules that help lock down systems within the environment a bit tighter than you may have them today. So let's look at what we see here. Some examples of what Akamai Hunt gives you is looking into misconfigurations within Active Directory.
It also gives you the ability to look at something like the XZ Utils vulnerability and recommendations of systems that may be vulnerable to that vulnerability. Here I'm going to look at this vulnerability associated with OpenSSH within the environment. When we look into the incident, we're first going to get a visual view of systems and traffic that are impacted.
Then we get a full description of the incident and the severity of the incident itself, including what vulnerable versions we've detected within the environment, the priority that you should take, the assets involved, and if any assets are at more risk than the others.
In this case, we have one vulnerable asset that's actually exposed to the internet and should be your top priority in addressing this risk. You'll also see full recommendations for how you should mitigate this risk within Guardicore and within other tooling within your environment.
You'll see a list of the affected assets, all 10 Linux servers here. And then you'll see a recommended policy. This is really the strength of Akamai Hunt in the service offering. We don't just show you the alert, we actually recommend the appropriate policy to mitigate the vulnerability within your environment.
So you'll see here we recommend two rules for this vulnerability. The bottom one here is the most important one. We're going to ensure that access from the internet to those systems over SSH is blocked to address the risk for this OpenSSH vulnerability.
But then we want to ensure that internally users can still SSH to these systems. So we're not impacting day-to-day business operations. So we also have a rule here allowing that access, but alerting us to it just in case we want to take a deeper dive and look into are these users trying to exploit this vulnerability?
This allows Akamai Hunt to fully close the loop on the alerts that we're providing and give you full value out of the solution, ensuring that you're not only understanding the risk, you also have the opportunity to mitigate and address that risk.