Why Use a Host-Based IDS in AWS
March 7, 2018
Does this image look familiar to you?
You’ve probably seen the AWS Shared Security Responsibility model over and over in conferences, tech talks, white papers, and AWS Summits, making it clear that Amazon only protects the infrastructure layer. Your data running in the application layer is your responsibility to secure. This sounds easy to implement but in the noisy security market, how do enterprises pick the right security solution to meets their needs? How do enterprises differentiate between legacy security solutions that were designed for on-prem data centers and today’s highly volatile data centers running in AWS public cloud?
The starting point is the Intrusion Detection System (IDS). Next question — Network-based IDS (NIDS) or Host-based IDS (HIDS)? The point at which information is collected is the main differentiator. Do you monitor network traffic or the host’s activity? Security of your workloads depends on how well your IDS solution can detect insider attacks that otherwise won’t be caught in the network traffic, and how well you can investigate an infected host or application based on the data that has been collected.
But wait, there’s more! Signature-based or anomaly-based detection? A question that has been debated for two decades. Attackers have access to the same resources as you and I do. In many cases, they have more budget than many enterprises to purchase firewalls, get access to threat intelligence sources and signatures that are based on those known threats. Strengthen your cloud security by using anomaly-based IDS instead of using the same signatures and rules that hackers already know about.
But I don’t want to be bombarded with alerts on every single change in my environment so what are my options?
Lacework addresses every workload behavior possible using anomaly detection algorithms and machine learning. Our coverage is 100% of anomalies on SSH, parent hierarchy, user privilege change, process communication, machine communication, data transfers both internally and externally, and more. A typical challenge with anomaly detection tools is alert fatigue. We have addressed that using behavior baselining. Instead of looking at each machine, user, or application individually, we cluster them together based on their behavior and alert you when the behavior becomes abnormal. Clustering enables us to alert you once instead of 30 times for a set of 30 machines, which are known to have the same behavior but start deviating from the norm when they contact a new app.
Lacework machine learning algorithms have saved our community of customers over 200,000 rules in the past two months!