Why is Post-Attack Mitigation flawed?
- Post-exploit Mitigation works by killing the suspicious process in response to an alert indicating malicious intent.
- Quoting Grsecurity, “post-exploitation detection/mitigation is at the mercy of an exploit writer putting little to no effort into avoiding tripping these detection mechanisms.” [reference]
- Post-Exploit Mitigation provides false sense of security.
Post Exploit Mitigation is a bad strategy for the following reasons
- Attacker already has gained grounds
- Attacker can disable defenses before the mitigation can kick in
- Review this blog from grsecurity instantiating what can happen
- Reducing the attack surface is the best policy
AccuKnox Zero Trust Security: Multi-layered Defense with Proactive Prevention from Zero Day Attacks
An essential aspect of Zero Trust security is to have multi-layered defense to make it impossible to penetrate in the event of a breach
At Run-time, it’s imperative that the enforcement approach should be proactive and not reactive i.e. to mitigate attack vectors when it’s executed not “after” it has executed.
At AccuKnox we believe in in-line mitigation is true security and are second to none with our ability to prevent Zero-Day attacks!!
Unique and Differentiated approach at Runtime Security to protect mission critical workloads
- Observe and Auto-detect Application Behavior
- Generate Granular policies to Whitelist (allow specific and deny all) based on App Behavior
- Files accessed by the app
- Process executed by the app
- Process that are making network connections by the app
AccuKnox Runtime Security Comparison (vs) Others
AccuKnox Runtime Security (vs) Others
Open Source
Enterprise
|
Brand X | Brand Y | Brand Z | |
|---|---|---|---|---|
| Design Approach | Zero Trust Enforcement + Observability | Observability + Add-on Enforcement | Observability + Add-on Enforcement | Observability + Add-on Enforcement |
| Enforcement Method | Inline Mitigation Any LSM | Post-execution Stop container | Post-execution Kill Proc from user space | Post-execution Kill Proc from kernel space |
| Reliability | Stable. Only stops malicious actions. App keeps working. | ⚠️ Potential service impact | ⚠️ Potential service impact | ⚠️ Potential service impact |
| Policy Creation | Auto-discovered policies | Auto-discovered policies | ? | manual rules |
Conclusion
- Proactively reduces attack surface
- Implements least permissive security posture by design rather than an after thought
- Using discovery-engine for workload behaviors analysis
- Inline mitigation: KubeArmor Policy enforcement using LSMs
- High Stability: KubeArmor uses safe, granular policy actions such that service is not impacted
- Automated Security Policy Updates:
- Ensuring that security posture is inline with application updates
- Shift left mode where changes in runtime security posture is determined in dev/staging environment
Furthermore it is based on robust, proven opensource technologies like eBPF, LSM (Linux Security Modules) and does not rely on proprietary modification to runC libraries, inefficient use of Iptables, etc.
In summary, AccuKnox and its companion OpenSource project, KubeArmor delivers in-line mitigation and consequently Zero Trust run-time Security by design a opposed to “best efforts” run-time security. Since run-time security is the last line of defense it is imperative that it is effective and efficient and not “good enough”.