The Cloud Threat Intelligence Engine is one of five detection engines that work together to identify and block runtime threats that affect cloud workloads in this fourth installment of our Detection Engine blog series. ( The series ‘ first, second, and third posts, respectively, cover the topics of application control engines, behavioral artificial intelligence ( AI), and static AI. )
Threat Intelligence Engine 101 for the Cloud
The SentinelOne Cloud Threat Intelligence Engine is a rules-based reputation engine that uses signatures to detect known malware, in contrast to the Static and Behavioral AI Engines, which use AI. It is crucial to remember that SentinelOne’s CWPP solution does not rely solely on signatures. Any solution that only relies on signatures is woefully unprepared to fight against cloud workload protection.
Even though sophisticated threat actors can easily avoid signatures, not every threat actor is sophisticated, and well-known malware is still frequently used. Therefore, even though advanced threats ( such as zero-day exploits, fileless attacks, polymorphic ransomware, etc. ) still exist, signatures are still useful for identifying known malware. still need a more cutting-edge, AI-powered arsenal.
How Does It Operate?
Every time a file is created, altered, copied, or executed, the Cloud Threat Intelligence Engine runs locally on the agent. The engine creates a local blocklist of well-known malicious hashes using signatures from various reputational sources. Nearly 100 % of the time, the engine is successful in finding known malware because it compares a file hash to those on the local blocklist.
A threat detection is triggered by the agent if a match is made. The Cloud Threat Intelligence Engine and the Static AI Engine are both consulted for each file that is scanned.
On a periodic and adjustable cadence, the CWPP agent has its first blocklist built-in and is regularly updated from the SentinelOne SaaS management console. The SentinelOne Cloud, which compiles threat intelligence from a variety of sources, including VirusTotal, ReversingLabs, the research team at Sentenlone, and other agents within your tenant, is where the S1 management console gathers its hashes. The management console updates the blocklist on all other agents that you have deployed when you flag a hash as an impending threat elsewhere in your environment.
SentinelOne keeps a close eye on numerous reputation feeds. Hashes from various sources are used to update the SentinelOne Cloud, which also continuously updates the agent fleet. The engine calls out to the management console to check if a new hash has been added to SentinelOne Cloud in the event that one is not listed on the local blocklist. It is added to the local blocklist if it discovers a new hash. A response is provided by the system in a split second. The two update cycles that will take the longest will send the hash upstream to the SentinelOne Cloud for review and receive the update for the local blocklist.
Additionally, SentinelOne will notify the fleet if the decision regarding a file that was previously questioned last week changes. Consider the fact that there is no reputation hash for a file that was questioned, for instance. The reputation feeds are then updated two days later, revealing that the maliciousness of this file has been discovered. This information is added to the SentinelOne Cloud, and all customer consoles that inquire about this particular file will receive a blocklist update. Additionally, keep in mind that the AI-powered engines in the SentinelOne CWPP agent, a component of Singularity Cloud Workload Security, are still operational, protecting your cloud workloads.
The Cloud Threat Intelligence Engine’s Benefits
Local autonomy is the main benefit. The agent, with all of its local engines, continues to operate independently if cloud connectivity to the management console is disrupted for any reason. The agent’s ability to carry out its duties is independent of cloud connectivity or access to distant databases.
Another benefit is that the blocklist is updated almost constantly. The Cloud Threat Intelligence Engine will only be updated once connectivity to the SentinelOne management console is restored in the event that it misses a regularly scheduled update due to network disruption.
The effectiveness of computation is a third benefit. Not every battle necessitates the use of Special Forces to accomplish the goal. A reputational lookup can be the best tool for the job of detecting known malware. According to Occam’s Razor, the simplest explanation is preferred to a more complicated one. There is no need to re-prove malware if it has already been identified as such. Simply identify, quarantine, and proceed.
As an illustration: Shellshock Detection
The following screenshot of the SentinelOne management console provides a good illustration of how to detect known malware. On Amazon Linux 2023, we have an Amazon EC2 instance running a containerized workload. Under the tabs” DOCKER CONTAINER” and “CLOUD,” respectively, an analyst could learn more about the container and cloud service provider ( CSP).
SentinelOne Cloud, the engine that is responsible for the detection, added the hash to the local blocklist. The file has the highest level of AI confidence, or MALICIOUS, and is categorized as malware. The security analyst can access VirusTotal, the source of this malicious file’s reputation, to find out more information by simply clicking the SHA1 value displayed.
The agent policy is set to” Protect,” meaning that as soon as the agent was discovered, they immediately took the mitigation measures specified in the policy. Process kill and file quarantine are the mitigation measures used in this instance. As a result, the Threat Status ( see the green shield ) is indicated as MITIGATED.
We can find useful information about our integration with Snyk on the right pane under the “XDR” tab. Numerous source code flaws in the workload have been found by Snyk, one of which, according to the Originating Process,” curl,” probably but not necessarily allowed the threat actor to download malware. There could have been a variety of underlying factors that contributed to this attack, but they are too complex to be adequately described in terms of reputation-based threat detection. The security analyst can open a ticket and give the application owner these source code vulnerability details from Snyk even though the immediate threat has passed. This promotes developer and security collaboration and improves cloud security results.
Conclusion
The Cloud Threat Intelligence Engine, one of five detection engines in SentinelOne’s real-time CWPP solution, is a reputation engine that uses local blocklists to effectively and efficiently detect known malware. Additionally, it does not depend on network connectivity to carry out its function.
Visit the solution homepage to learn more about the benefits of real-time, AI-powered CWPP in your cloud security stack, or take a 2-minute guided walk-through to see how Singularity Cloud Workload Security functions. Of course, you can arrange a personalized demo with one of our cloud security experts whenever you’re ready.