We recommend that you download the Infection Monkey while you read this post, so you can start working with it as soon as you finish reading.
Guardicore Labs has been hard at work on adding new features to the Guardicore Infection Monkey. In this post, we will talk about the new Zero Trust features of the Infection Monkey v1.7.0, which we recently released.
What is the Infection Monkey for Zero Trust?
The Infection Monkey is a free, open-source Breach and Attack Simulation (BAS) tool that assesses the resiliency of private and public cloud environments to post-breach attacks and lateral movement. We have released a new version which enhances the Monkey’s capabilities.
It now tests your network against the Forrester ZTX (Zero Trust eXtended) framework and provides a report with actionable data and recommendations to help you make Zero Trust decisions.
To see Guardicore infection Monkey for Zero Trust in action, watch a video demo highlighting the Zero Trust features.
Why did we add Zero Trust capabilities?
Zero Trust is a top concern for cybersecurity professionals and many companies.
In recent years there has been a lot of talk around Zero Trust. When our team started looking into this, we noticed that while there was a lot of spoken and written guidance around how to implement Zero Trust, there were no actual tools enterprises could use to assess their advancement toward their Zero Trust journey.
Aligned with our commitment to give to the cybersecurity community, we decided to put talk into action and harness the Monkey to help other enterprises truly assess their Zero Trust security posture and network resiliency. After all, who’s better positioned to do this than our Infection Monkey? ????
How does it work and how can you use it?
After downloading and deploying the Monkey, it simulates an attack on your network.
In doing so, it tests the network for adherence to the principles of the Zero Trust security framework.
When the Monkey’s tests have been completed, you get a Zero Trust status report with all the information you need to improve your Zero Trust posture.
The Zero Trust Report
The Zero Trust report includes three main sections:
The Summary provides a glance at how your organization scores on each component of the Forrester’s Zero Trust model with Failed, Verify, Passed and Unexecuted verdicts. Each component is assigned one of the following verdicts:
- Failed: At least one of the tests related to this component failed. This means that the Infection Monkey detected an unmet Zero Trust requirement.
- Verify: At least one of the tests’ results related to this component requires further manual verification.
- Passed: All Tests related to this component passed. No violation of a Zero Trust guiding principle was detected.
- Unexecuted: This status means no tests were executed for this component.
In this diagram, for example, you can see three red circles which means three components – Data, Devices and Networks – have failed at least one of the tests. We also need to verify that our Visibility & Analytics is OK (Orange). To see what failed and why, let’s move on to the next part of the report: Test Results.
This section allows you to see how your network fared against each of the tests the Infection Monkey ran. The tests are ordered by Zero Trust components, so you can quickly navigate to the components you care about first.
Let’s take the Data component as an example. We see the Monkey’s scan results as it tried to find open data endpoints. It didn’t find any ElasticSearch instances, but it did find open HTTP servers. In compliance with the Zero Trust principles, data in transit must be encrypted, which makes open HTTP servers a major data security issue.
But what exactly happened? Where is the open server? Where was it accessed from? When did it happen? For this, we turn to the last section of the report, the Findings section.
This section allows you to deep-dive into the details of each test, and see the explicit events and exact timestamps in which things happened in your network. Match these findings against your SOC logs and alerts to gain deeper insight into what exactly happened during each of the tests. It also provides recommendations based on Zero Trust principles.
The results are exportable. Click Export after clicking on Events to view them in a machine-readable format, so you can use a script to cross-reference them against your databases, security solutions, etc.
Let’s see how all the sections of the report work together: In the Summary section, we recognized we had a problem with our Data component (red middle circle). In the Test Results section, we learned that we failed the data encryption test by allowing unencrypted access to HTTP servers in our network. Now, in the Findings section, we can see the specific findings of that failed test.
Click on Events to see exactly what happened during the test to gain deeper insight. Here we can see that a Monkey performed a network scan on 10.15.1.96, and found an HTTP server (with an unknown TCP signature). We can also see that this happened at 13:41:12 of Oct. 16th, 2019. We can now look at our firewall logs and see why this wasn’t blocked; we can log in to 10.15.1.96 and shut down the rogue server. Finally, we can run the Monkey again to make sure everything was fixed and the test now passes.
What tests does the Infection Monkey run?
Disclaimer: This list is updated to version 1.7.0 of the Infection Monkey. We will add more tests in the coming releases. Check out our release notes to stay up to date on the latest changes.
|Zero Trust Component||What tests does the Monkey run?|
|Networks||Segmentation: Zero trust supports the use of microsegmentation in the network. The Monkey tries to scan and find machines that it can communicate with from the machine it’s running on, that belong to different network segments. If the Monkey successfully performed cross-segment communication, we recommend checking firewall rules and logs. This is relevant to the Visibility component as well.Tunneling: The Monkey tries to tunnel traffic using other Monkeys. If it succeeds, that means that the network policies are too permissive. We recommend to restrict them in such a way that unknown tunnelling traffic will not be allowed.|
|Data||Open Data Endpoints: The Monkey scanned for unencrypted access to Data endpoints: namely, HTTP servers and ElasticSearch instances. If the Monkey successfully accesses any of these, we recommend limiting access to data by encrypting it in in-transit.|
|Workloads||(Coming soon) Cloud Privilege Escalation Opportunities: The Monkey checks if machines on the public cloud (e.g AWS) have overly permissive Identity Access Management (IAM) roles that may allow them to compromise other machines on the network, or even take over the entire cloud account. This is based on open-source research from Rhino Labs.|
|People||MAC (Mandatory Access Control) for New Users: The Monkey tries to create a new user and communicate with the internet using the new user. If the Monkey successfully caused a new user to access the network, that means the network’s policies are too permissive. We recommend restricting user network permissions using MAC.(Coming soon) Scheduled/Impersonated Execution: The Monkey is executed outside of working hours or as a user on vacation. This behaviour should be alerted on by User-Behavior Analytics security solutions.|
|Devices||Exploitable Machines: The Monkey tries to exploit machines to breach them and propagate in the network. If the Monkey has successfully exploited endpoints, we recommend checking IDS/IPS logs to see activity recognized and see which endpoints were compromised, and remedy the reasons the endpoints are vulnerable.Endpoint Security Active: The Monkey checks if there is an active endpoint security software in place. If the Monkey doesn’t find ANY active endpoint security processes, we recommend installing and activating an anti-virus software on endpoints. If the Monkey found active endpoint security processes, we recommend checking their logs to see if they recognized the Monkey as a security concern.|
|Visibility & Analytics||Malicious Activity Timeline: Zero Trust attempts to empower the analyst. The Monkey performs all sorts of malicious-looking actions, like scanning and attempting exploitation. If you have good Visibility of your network, you should be able to see all the events in your SOC logs and alerts. These events are machine-readable and are also designed l for the power analyst that want to automatically cross-reference Monkey logs with security solutions.|
|Automation & Orchestration||(Coming soon) Cloud Privilege Escalation Opportunities: The Monkey checks if machines on the public cloud (e.g AWS) have overly permissive Identity Access Management (IAM) roles that may allow them to compromise other machines on the network, or even take over the entire cloud account. This is based on open-source research from Rhino Labs.|
Test your network after every step you take toward a Zero Trust architecture
The main use case we had in mind when we developed this new Monkey version with Zero Trust capabilities is assessing progress in your Zero Trust Journey.
We understand that implementing a comprehensive Zero Trust architecture is a journey that takes time, resources – and naturally includes mistakes.
The Monkey acts like a highway sign that lets you know how much you’ve travelled and how much you still have to go.
Test your network after every step you take toward a Zero Trust architecture and see what you’ve achieved.
You should see more and more passed tests in your report the better your network performs.
Verify that your security tools meet Zero Trust requirements
To successfully implement a Zero Trust architecture in your network, you need to do more than just get the right security tools; you need to make sure they are well-configured and working as expected.
The Monkey can enable you to verify that that is the case.
Run the Monkey and see if your security tools manage to “fight it off” and that you have full visibility of the Monkey’s actions.
Let’s look at how Guardicore Centra takes on the Monkey from a Zero Trust perspective.
You can check out our demo video to get an in-depth look into this process, as well.
Let’s say you want to test the Centra’s visibility capabilities.
When the Monkey tries to attack a network with Centra deployed in it, we can immediately see all the malicious connections (highlighted red):
Using Centra’s process-level visibility, we can even see that the malicious communication lines are originated by the Monkey process itself:
From the Infection Monkey’s Zero Trust report we can export all the malicious network events generated by the Monkey and create segmentation rules that block malicious connections. See Centra’s Network log, created after Centra blocked the Monkey using a simple segmentation rule:
Now, check out the Monkey’s infection map: The first time we ran the Monkey (without activating Centra rules), it managed to propagate successfully across the network:
After activating Centra’s rules, the Monkey wasn’t able to spread:
Identify the Areas You Need to Focus On
The Zero Trust report shows you which Zero Trust components include security issues.
Combined with how easy it is to re-run the Monkey, you can focus on one component, fix all the security issues the Monkey has discovered and then move on to the next.
For example, choose to fix all the People security issues first, as recommended by Forrester’s principal analyst, Chase Cunningham.
Try it for yourself
To make your journey to zero trust security a reality with Guardicore’s Infection Monkey for Zero Trust, download the new version of the Monkey and test your network. It’s free and open-source.
We also invite you to join the conversation in our Slack channel to ask questions, suggest new features, or just talk to us.