At Wiz, we value the importance of a defense-in-depth strategy, and so do our customers. So what does this mean? Defense in depth is a multi-layered approach to protecting cloud environments, deploying multiple defensive measures at various levels to ensure attacks are proactively avoided or detected quickly to minimize business impact. We’ve recently released new features that give our users another layer of defense: custom runtime rules and runtime response policies. 

Custom runtime rules provide another critical detection layer 

This flexible framework allows users to create threat detection rules evaluated by the Wiz runtime sensor. Runtime detections benefit security teams by providing: 

• Additional real-time protection: Runtime threat detection offers real-time monitoring and protection, ensuring that any malicious activity is identified and addressed immediately, reducing the potential for damage. 

• Increased visibility: Runtime detection offers visibility into the behaviors and activities occurring within cloud workloads. This allows security teams to understand what is happening in their environment in real time. 

• Compliance and regulatory requirements: Many regulatory frameworks and security standards require continuous monitoring and real-time threat detection. Implementing runtime detection of process-related events helps organizations meet these compliance requirements and demonstrate their commitment to security. 

• Integration with automated response: Runtime threat detection can be integrated with automated response policies to take immediate action when a threat is detected. Automation ensures swift and effective responses, minimizing the potential business impact of an attack. 

To ensure the best detection coverage, rules should be tailored for your organization’s processes, files, and network. We allow for the creation of hundreds of rules by default that have a negligible impact on the sensor's resource consumption. Each rule can be applied across all sensors, scoped by projects, and assigned a severity. 

Runtime rules need to be flexible for any environment 

Runtime detections focus on processes, their behaviors, and the actors behind them. Even the most complex rules can be created with Boolean operators, string operators, and regular expressions. 

• Process execution: A process begins the execution of another. 

• Network connection: A process establishes an outbound connection. 

• DNS query: A process initiates DNS lookup activity. 

• Network listen: A process initiates network port listening activity. 

• Actor: The entity responsible for initiating the event. 

Any matches to these detection rules can be used to generate issues, create findings added to the Wiz security graph, used with our cloud response playbooks, or serve as inputs for runtime response policies. 

Automated blocking improves security outcomes and reduces manual effort 

The Enterprise Security Group surveyed 393 IT and cybersecurity professionals and found that "nearly one-third (31%) believe that security operations are more difficult than they were two years ago due to factors like the inability to automate, a growing attack surface, and monitoring gaps." 

Response policies allow users to automate the response actions (blocking) for high-certainty threats at runtime, which provides multiple benefits to security teams including: 

• Immediate threat mitigation: Automated blocking enables instant response to detected threats, stopping malicious activities before they can cause significant damage. 

• Reduced manual intervention/operational cost: By automating the blocking of malicious activities, security teams can focus on more strategic tasks rather than constantly monitoring and manually responding to threats. This reduces the workload on security teams and helps address the cybersecurity skills shortage. 

• Scalability: Automated blocking solutions can easily scale to accommodate growing cloud environments. As your infrastructure expands, automated systems can handle the increased volume of threats without the need for additional manual resources. 

Several triggers can initiate a response policy: 

• Match from a custom runtime rule. 

• Broad threat categories, such as malware, malicious IOCs, etc. 

Since these response policies focus on high-confidence threats, the resulting actions can be to simulate (allowing users to test the outcome of a rule) or block (to immediately terminate the malicious process). 

Conclusion 

We prioritize a defense-in-depth strategy, deploying multiple defensive measures to ensure robust protection against threats. Our custom runtime rules and runtime response policies add critical layers to our security framework. They provide real-time protection, enhanced visibility, and integration with automated response — all of which allow for precise, environment-specific threat detection.