I wanted to share some data points in regard to what controls our organization found to be the most effective. The results are based on actual attacks and incidents.
Below is a list for both the detection and prevention of threats. There are obviously some caveats due to the industry I work in, controls we have implemented, and the size of our organization. Take these data points and compare them to your own. The bottom of the page contains an explanation and description for each.
Preventative
- Employee Training
- File Type Blocking
- Baselines and hardening
- URL Filtering
- Patching
- Multi-Factor Authentication
Employee Training - Probably one of the cheapest controls you can implement. Employees tend to be the last layer of defense. Implementing a training program that educates employees on current and applicable threats is imperative. Not only should employees understand how to spot malicious content, but they should also understand how to report it.
File Type Blocking - This control can be implemented for both web and email traffic. Set a default policy similar to a firewall where only a small amount of file types are allowed then add exceptions based on an individual’s role. HR does not need to have the ability to download executables (most of the time) and javascript, ISO's and executables should not be delivered over email. This simple control can stop many attack chains because the initial stage was unable to be downloaded.
Baselines and Hardening - Having a baseline configuration applied to assets with hardening techniques built-in will go a long way in preventing initial access and lateral movement. Mistakes and misconfigurations are two of the top causes of compromises. If you can document a checklist and have the ability to verify that it was implemented correctly, mistakes can easily be reduced. A few examples of configurations that should be included in this are OS firewall config, file type execution (forcing .js to open in notepad), administrative/root access, SELinux, etc. Take a look at the CIS control list.
URL Filtering - Basic URL and domain filtering has stopped initial and multi-staged payloads. Implement a simple policy that blocks file/script sharing websites (Pastebin, GitHub), advertisement domains, new/rare domains and suspicious TLD's. Combine this with your file-type blocking and you have a solid web-based security control. For TLD blocking I recommend either allow listing the top 5 TLD's being used in your organization or blocking the top 20 most abused TLD's. This does come along with false positives so put some effort into testing.
Patching - Know what vulnerabilities exist in your environment and have a patching policy in place to address them. I recommend prioritizing based on risk to your organization and the attack vectors required for exploitation. This will help alleviate patching fatigue. Subscribe to free vulnerability databases like the cool project over at OpenCVE to easily track new and updated vulnerabilities. All practices should align with your risk management policy.
Multi-Factor Authentication - MFA really shines with cloud-based and internet facing applications and appliances. MFA solutions that get installed on desktop machines tend to only protect the GUI based utilities like RDP. You can freely run command-based attacks against remote machines without the requirement of MFA. Web and cloud-based applications on the other-hand are the most exposed. Having a solid MFA solution that relies on a time-based token (hardware or software), can help thwart credential stealing and phishing attacks. If one of your employees fell for a credential phishing attack, you have time to address this incident without worrying too much about those credentials being used against the VPN or cloud applications.
You will notice that I did not mention anti-virus (AV). While AV is great layer, most of the controls listed above were able to stop an attack before it got to the point where AV could take action.
Detection
- SIEM
- Intrusion Detection System (IDS)
- EDR
- Network Analyzer (Zeek)
- System Event Logs (Windows/Linux)
- SELinux
SIEM - Manipulating detection data is near impossible without a central logging solution that allows for the creation of rules and reporting of data. This is where a SIEM comes in. It is the primary building block for your detection architecture. If you were to provide me with the budget to purchase one solution for a new environment, it would be a SIEM.
The five other detection controls that I have listed above rely on a SIEM to succeed, which is why I placed it as number one on our list. For more information on how we utilize our SIEM for compliance, watch the talk Russell Mosley and I gave at BSides Charm in 2018: https://www.youtube.com/watch?v=g2KnSOGHqdA&t=9s
Intrusion Detection System - This is a relatively simple control. Most of the detections that we utilize come from the ETPro ruleset. We heavily rely on our IDS to tip us off on either initial access or post exploitation and C2 behavior. It is key that you place IDS sensors on every segment of your network and that HTTPS decryption is being used. The SecurityOnion project is a great all-in-one solution.
EDR - Probably one of the most popular solutions today. EDR allows for the monitoring of endpoint behavior. Besides using this control to identify malicious activity, it also provides us with the ability to investigate alerts that are triggered by our network-based controls. One important note is to ensure that an EDR solution allows for the creation of custom rules. This will expand its capability within your environment. We rely on custom rules to detect data leaks and suspicious network connection behavior. I recommend checking out the MITRE ATT&CK evaluations and plugging holes that were identified for your provisioned product.
Network Analyzer - While an IDS is great at detecting network-based threats, we find that there are limitations because these systems rely on rules. Similarly, to how anti-virus relies on signatures. On the other hand, a network analyzer allows us to take a packet and transform it into text that a SIEM can ingest. This allows you to create anomaly-based rules and investigate a breach without needing to dump packet captures from your network tap. Two examples of custom detections are the identification of DNS C2 channels and the identification of suspicious data transfers based on total connection sizes.
System Events - These tend to provide a large amount of data that can make your eyes glaze over. Our team tends to manipulate the logs related to authentication (Windows/Linux), PowerShell, scheduled tasks/cron creation, and firewall. While many these data points are also recorded by an EDR solution, raw system logs tend to serve as a backup since most threat actors attempt to bypass or disable EDR and anti-virus solutions once initial access is gained.
SELinux - Managing an SELinux deployment in protect mode can take a large amount of time and resources. One of the better options is to have it configured in detect mode and have the logs forwarded to a SIEM. In my experience, SELinux does a great job of alerting on web shells.
In closing, it’s important to understand the philosophy of defense-in-depth. You will notice that I did not list just one control under each category. We rely on a multitude of different controls to protect our environment.
