The Virsec Security Platform (VSP) focuses on the code running on the workload and not threat actor techniques. It is immune to any shenanigans that even the most sophisticated threat actor can throw. VSP ensures only trusted code is allowed to run and stops everything else and is worthy of being called a true Zero Trust security solution. If VSP cannot trust the code’s provenance, integrity, and authorization, it will prevent such code from executing even one instruction, resulting in zero dwell time. Read more to learn how to implement a security control that ensures threat actor-provided or influenced code does not execute.
Zero Trust Runtime Defense
Code Makes The World Go Round: Marc Andreessen famously said, “Software Is Eating the World.” Code truly shapes the workload’s personality. While the enterprise wants to run trusted and authorized code with the least possible privileges, the threat actor’s objectives are the opposite. The latter seeks to execute code that will escalate privileges so that they can access the most confidential data. Threat actors also seek to execute file and fileless malware that will perform harmful actions such as encrypting the disk.
Initial Access Brokers (IABs): A few years ago, the count of RCE (Remote Code Execution) vulnerabilities was minimal, making it challenging for threat actors to infiltrate organizations through this vector. Consequently, stolen credentials became the primary means of infiltration, giving rise to a class of threat actors known as Initial Access Brokers (IAB). Other threat actors had to collaborate with IABs to gain a foothold in their target enterprises. Once a threat actor acquired compromised but functional credentials, victims had limited options to impede their progress.
Early Version of Zero Trust: The initial iteration of Zero Trust aimed to tackle these issues by emphasizing:
- Authentication of end-users on each access to infrastructure resources.
- Consideration of the security posture of the end-user device before granting access to requested resources
Additionally, leading networking vendors recommended deploying micro-segmentation to hinder unfettered lateral movement by threat actors. The belief was that implementing these three measures would vastly enhance an enterprise’s cybersecurity posture.
The Plan Didn’t Deliver: The original version of Zero Trust failed to deliver defense from cyberattacks. Some of the reasons included:
- Stolen credentials continued to be effective across downstream resources, given the prevalent use of Directory Servers for user authentication.
- Threat actors also used devices with sound security postures.
- For micro-segmentation to be effective, the enterprise must have prior knowledge of the application’s networking needs and be able to prevent the attacker from tunneling their stolen data through the permitted ports.
- RCE Vulnerabilities started arriving in the thousands. A threat actor can use any RCE vulnerability to infiltrate a victim enterprise. In that respect, an RCE is functionally equivalent to stolen credentials. The threat actor no longer needs stolen credentials and is not at the mercy of IABs.
Additional Pillars In Zero Trust: The Department of Defense (DoD) laid out the following seven pillars for Zero Trust:
- User: Enforcing identity and access management for privileged functions.
- Device: Real-time authentication, assessment, and patching of devices accessing data.
- Network and environment: Logical and physical isolation of networks with access-based policy management
- Application and workload: Filter traffic and manage application configuration for all services on a given workload. Use application delivery proxies to filter traffic. DevSecOps will vet source code and third-party libraries to ensure compliance with best practices.
- Automation and orchestration: Enhance security and response times through SIEM and SOAR automation.
- Visibility and analytics: Utilize contextual details for improved performance, behavior, and activity baseline.
- Data: Enterprises must validate and categorize data, develop schemas for their DaaS apps, and run controls such as DRM, DLP, etc.
Threat Actors and DoD’s Seven Zero Trust Pillars: Fighting sophisticated threat actors is an asymmetric battle. The adversary does not follow any rules of engagement and is not afraid to circumvent every recommendation of the seven pillars of the Zero Trust Framework as described below:
- Users: A trusted user can go rogue, and instead of executing benign code, they could execute malicious code.
- Device: A device with a suitable security posture is as effective as any other device.
- Networking: With the ability to execute arbitrary code on the workload, a threat actor can easily change the workload’s firewall settings and manipulate any micro-segmentation policy.
- Application and Workload: Despite leveraging the most sophisticated configuration management tools, a vulnerability in an application continues to be a weak link, which helps the threat actor gain control of the workload.
- Automation and Orchestration: If legitimate code can generate telemetry, malicious code can manipulate and subdue such telemetry in more ways than one.
- Visibility and Analytics: As SIEM and SOAR capabilities increase, so does the sophistication of attack vectors. Getting context-specific end-to-end telemetry that captures the full extent of changing threat actor actions is challenging.
- Data: High-value data in a database can be accessed via a SQL Injection vulnerability or by code emulating a SQL Client.
It is clear that if threat actor-provided or influenced code gets to execute, any benefit from the seven pillars of Zero Trust will dissipate in a matter of nanoseconds. Trying to detect when a threat actor has injected and run foreign code is like looking for needles in haystacks. This context falls into the blind spot of the existing detect-and-respond class of security tools.
In Code We Trust: To ensure threat actor-provided or influenced code does not execute, a security control must prevent the execution of:
- Code of Dubious Provenance or Code that originates from unauthorized sources. Such code could easily be malicious and trigger untold harm, including turning the workload into a brick.
- Non-Essential code that the enterprise never intended to run on the workload. An example comprises non-essential but otherwise legal software such as an email server app. Non-essential applications increase the workload’s attackable surface and help threat actors further their agenda without first creating additional work of installing such code.
- Code with Poor Integrity or when code gets altered between the original software vendor from where the enterprise-sourced pristine code should have come and the actual code on the workload is simply a disaster waiting to happen.
- New Threads and Processes that execute code provided or influenced by threat actors.
What is Zero Trust Runtime Defense? A security control that promises to deliver Zero Trust must be able to deliver on the four facets of trust described above.
Detect and Response Technology Does NOT Ensure Trust in Code. Detect and Respond class of security controls leverage an operating principle described as default-allow-block-on-threat. Such security controls fail to perform the trust-in-code checks described above. Instead, they train their AI models with past threats to detect future threats that the threat actor will come up with. AI models are notorious when presented with the unexpected. Remember how Lee Sedol, playing the highly trained AI model AlphaGo in Game 4, played Move 78, which had a 1 in 10,000 chance of being played? Known as “God’s Touch,” this move was unlikely and inventive and helped Sedol win the game. The surprise element in the threat actor’s arsenal routinely trips the AI in the Detect and Respond class of security controls.
VSP Implements True Zero Trust in Code-on-Disk and Code-at-Runtime. The Virsec Security Platform (VSP) operates on the principle of default-deny-allow-on-trust. This principle means if VSP cannot trust the code’s provenance, integrity, and authorization, it will prevent such code from executing even one instruction. This results in zero dwell time for threat actors. Thanks to the deep context VSP collects, it can quickly determine if the code about to be executed came from the application or a threat actor, a binary decision not open to interpretation. Since VSP focuses on the code running on the workload and not on threat actor techniques, it is immune to any shenanigans that even the most sophisticated threat actor can throw. VSP, therefore, implements all the considerations of the trusted code described above and is worthy of being called a true Zero Trust security solution.
For more detailed information on Zero Trust Runtime Defense and how we protect vulnerable legacy workloads, visit www.virsec.com.
Don't miss our security insights, and subscribe to our blog now.
