|
|
In this the fourth installment of our Detection Engine blog series, we examine the Cloud Threat Intelligence Engine and its role as one of five detection engines which work together as part of our cloud workload protection platform (CWPP) to detect and block runtime threats impacting cloud workloads. (The first, second, and third posts in the series discuss the Static AI, Behavioral AI, and Application Control Engines, respectively.)
- Static AI Engine
- Behavioral AI Engine
- Application Control Engine
- Cloud Intelligence Engine
- STAR Rules Engine
Cloud Threat Intelligence Engine 101
Unlike the Static and Behavioral AI Engines, which use AI, the SentinelOne Cloud Threat Intelligence Engine is a rules-based reputation engine which uses signatures to detect known malware. It is important to note that SentinelOne’s CWPP solution does not rely solely upon signatures. Any solution that relies solely upon signatures is woefully underprepared for cloud workload protection warfare.
Even though signatures are easily evaded by sophisticated threat actors, not every threat actor is sophisticated, and known malware is still often used. And so, the use of signatures still has a place in detecting known malware, while advanced threats (e.g., zero-day exploits, fileless attacks, polymorphic ransomware, etc.) still require a more modern, AI-powered arsenal.
How Does It Work?
The Cloud Threat Intelligence Engine runs locally on the agent anytime a file is written, modified, copied, or executed. The engine consolidates signatures from multiple reputation sources into a local blocklist of known malicious hashes. The engine uses a reputation lookup, comparing a file hash to those on the local blocklist, and is nearly 100% effective in detecting known malware.
If a match is made, the agent triggers a threat detection. Every file scanned consults both the Cloud Threat Intelligence Engine and the Static AI Engine.
The CWPP agent has its first blocklist built-in and is regularly updated from the SentinelOne SaaS management console on a periodic and adjustable cadence. The S1 management console collects hashes from the SentinelOne Cloud, which aggregates threat intelligence from a number of sources including VirusTotal, ReversingLabs, SentinelOne’s research team, and other agents within your tenant. When you mark a hash as a threat elsewhere in your environment, the management console updates the blocklist on all other agents which you have deployed.
SentinelOne continuously monitors multiple reputation feeds. The SentinelOne Cloud is updated with hashes from various sources and updates the agent fleet in real time. If a hash is not found in the local blocklist, the engine calls out to the management console to see if a new hash has been added to the SentinelOne Cloud. If it finds a new hash, it is added to the local blocklist. The system delivers a response within a second. The longest round trip will be 2 update cycles: one to send the hash upstream to the SentinelOne Cloud for inspection, and another to receive the update to the local blocklist.
In addition, SentinelOne will update the fleet if the verdict changes for a file which was previously queried within the last week. For example, consider that there is no reputation hash for a file that was queried. Then, 2 days later, the reputation feeds are updated, revealing that this file is now known to be malicious. The SentinelOne Cloud is updated with this information, SentinelOne will push a blocklist update to all customer consoles that asked about this specific file. And remember – the SentinelOne CWPP agent, part of Singularity Cloud Workload Security, still has the AI-powered engines active, keeping your cloud workloads protected in the interim.
Advantages of the Cloud Threat Intelligence Engine
The primary advantage is local autonomy. If cloud connectivity to the management console is disrupted for any reason, the agent, with all its local engines, continues to operate autonomously. The agent does not rely upon cloud connectivity or access to remote databases to perform its duty.
Another advantage is that the blocklist is nearly continuously updated. In the event that the Cloud Threat Intelligence Engine happens to miss a regularly scheduled update due to a network disruption, it will simply be updated when connectivity to the SentinelOne management console is restored.
A third advantage is computational efficiency. Not every battle requires Special Forces to achieve the objective. For detecting known malware, a reputational lookup can be the right tool for the job. Occam’s Razor states that the simplest explanation is preferred to one which is more complex. If it is already known malware, there is no need to re-prove it as such. Simply detect, quarantine, and move on.
Example: Shellshock Detection
A good example of a detection of known malware is shown in the following screenshot of the SentinelOne management console. Here, we have an Amazon EC2 instance running a containerized workload on Amazon Linux 2023. An analyst could find more details about the container and cloud service provider (CSP) under the tabs “DOCKER CONTAINER” and “CLOUD,” respectively.
The engine to which the detection is attributed is “SentinelOne Cloud,” meaning that SentinelOne added the hash to the local blocklist. The file is classified as malware with AI Confidence Level of MALICIOUS, the highest confidence level. With a simple click on the SHA1 value shown, the security analyst can visit VirusTotal, the reputation source for this malicious file, to find even more details.
The agent policy is set to “Protect,” such that upon detection, the agent immediately took mitigation actions defined in the policy. In this example, the mitigation actions taken are process kill and file quarantine. Therefore, the Threat Status is shown to be MITIGATED (see the green shield).
On the right pane under the “XDR” tab, we see helpful details from our integration with Snyk. Snyk has identified numerous vulnerabilities in the workload’s source code, one of which presumably, but not necessarily, allowed the threat actor to download malware (see the Originating Process, “curl”). There could have been any number of root causes of this attack, which, while interesting, are beyond the scope of describing a threat detection by reputation. Even though the immediate danger is gone, the security analyst can open a ticket and share these source code vulnerability details from Snyk with the application owner. This helps to foster collaboration between security and developers, and create better cloud security outcomes.
Conclusion
One of five detection engines in SentinelOne’s real-time CWPP solution, the Cloud Threat Intelligence Engine is a reputation engine using local blocklists to efficiently and effectively detect known malware. Moreover, it does not rely upon network connectivity to perform its job.
To learn more about the value of real-time, AI-powered CWPP in your cloud security stack, head over to the solution homepage, or see how Singularity Cloud Workload Security works with a 2-minute guided walk-through here. And of course, whenever you are ready, you may connect with one of our cloud security experts for a personalized demo.
