Back at it again with part 2!
This week we’re continuing our journey through the CIS 20 Critical Controls and if this security framework is new to you, go check out part 1.
Today we’re transitioning from “basic” to “fundamental” controls.
Time is fleeting, so let’s not waste it with intro fluff. 😉
Control 5 (basic) – Secure Configuration
Misconfigurations are a constant thorn in the side of every defender. Sadly, misconfigurations have been on the OWASP top ten from the beginning of time.
Whenever you set up a piece of hardware or software there’s always some configuration needed for it to function, but the function is only half of the puzzle. Most of us only focus on getting something up and running, without considering how secure it is. This short-sighted approach has caused some serious damage.
DivvyCloud researchers estimated cloud misconfiguration breaches cost companies upwards of $5 trillion over 2018 and 2019. Trillion with a “T”… That’s Doctor Evil-level money!
This type of mistake can happen anywhere, some recent examples are Facebook (twice), Capital One, DoorDash, Burger King, Georgia Tech, Adobe, and EasyJet. I’m sure all of these companies have pretty solid security, so if it can happen to them and can happen to anyone.
With that context out of the way, let’s take a look at the sub-controls.
As you can see the main focus of this section is creating a secure configuration once, then making it easy to copy over to other hardware and software.
Let’s focus on three.
- Secure Configs: First things first! Every time we deploy a brand new piece of software or hardware, it’s important we spend a little extra time upfront to ensure our configurations are secure. This upfront time should include dynamic/static analysis, vulnerability scanning, and eventually packaging this config into a secure baseline.
- Secure Images: Once we have a secure configuration we should turn it into a template or image, so next time we’re deploying a similar piece of software or hardware it’s quick and easy. A way to picture this is through cookies… Instead of shaping every single cookie like a star by hand (custom secure configs) for Christmas, we use star-shaped cookie cutters (secure images) instead.
- Automate Config Management: For the last subcontrol, we’ll invest in a Config Management Tool that automates the entire deployment process. Meaning, anytime a similar piece of software or hardware is deployed on the network it is automagically securely configured to meet our original baseline image. To take our cookie-cutter analogy to the next level we’re going to buy a cookie-cutting machine, automating the entire cookie-cutting process.
Control 6 (basic) – Loving Logs
Logs are the best and worst thing that’s ever happened to the world of InfoSec.
Every security analyst has faced the dreaded “Alert Fatigue”, being completely overwhelmed by the number of alerts. This alert fatigue causes their senses to slowly become more tolerant of the number of alerts flooding into the SOC, so eventually, they begin to ignore them.
This scenario is very similar to a childhood story we’re familiar with – The boy who cried wolf. The more our alerting and logging systems lie to us (e.g. false positives), the more we learn to ignore.
Based on a Cisco survey, organizations only investigate 56% of security alerts.
A common example used in the world of InfoSec is Target. Target security products detected a breach, but due to the high volume of alerts and false positives, the company’s IT security team did not take action, costing the company $252 million and the resignation of their CIO and CEO.
The flood of logs and alerts not only causes obvious damage to companies but can cause a massive delay between a network breach and detection. In 2018 Ponemon Institute discovered that it takes an average of 197 days for a company to detect a breach. That’s plenty of time for an attacker to get familiar with most companies’ internal architecture, system configurations, etc.
Let’s see what subcontrols CIS has in mind.
Here are three that stand out to me…
- Timing is everything: The problem of solving timezones is a difficult one, especially when you have systems being logged from all around the world. Each log eventually lands in a central location where it’s matched up against others, so all the time zones need to line up. Ensuring that you have a minimum of three-time synchronization servers sitting around your network is critical and if you don’t have these your logs are useless.
- Active logging: Even though I ranted about alert fatigue, logging should be a generous activity where you’re logging from every device/system on your network. Don’t be greedy about who logs and who doesn’t, every device should be actively logged.
- Storage Space: With all of these logs we’ll need to store them somewhere… Storage is always a major consideration whenever you’re standing up a security function within a network. Tradeoffs are part of life and logging is no different. Logs come in different flavors (Pcap, Netflow, meta, etc.) and each flavor takes up a specific amount of space, so when deciding on storage space, it’s always good to consider which devices should have detailed logs and how long those logs should be stored until it’s time to make room for new logs.
- SIEMs = best friend: A SIEM is a single dashboard where all of your logs will be presented, most companies use Splunk, Qradar, or ELK Stack. Without a SIEM correlating and analyzing your logs turns into an impossible task.
Control 7 (fundamental) – Email & Browsers
There is an endless number of ways an attacker can enter your network, but two of the most popular are via web browsers (e.g. Chrome, Edge, Firefox, etc.) and email clients (e.g. Outlook, Gmail, etc.). There’s a simple reason why these two channels are their favorite… Humans.
We, humans, spend the majority of our time either browsing the web or responding to emails, so this is where attackers spend their time due to humans being easily tricked.
Apparently, around 94% of all malware in 2019 was delivered via email, and 1 in 13 web requests lead to malware infections.
From these two statistics, I think we can both agree that our browser and email are useful, but extremely evil tools.
So how does CIS recommend we protect ourselves?
This subcontrol list is longer than most, so we’ll limit our attention to four I found interesting.
- Picking your poison: We all need to access the internet and send emails, so it’s important to choose an email client and browser that are fully supported. This means that we’re using the latest version and it’s constantly being updated.
- URL & DNS filtering: I’ve bundled these two subcontrols together because they’re doing similar tasks. Any time an employee attempts to access a known malicious domain or URL you should block it. An extreme approach to this is whitelisting the websites needed for each job function, then blacklisting the rest, but this is close to impossible, so I’d steer away from this approach.
- Blocking unnecessary file types: Last we’re going to focus on file types. Whenever an email flows through your network’s email gateway it should only have file types your security policy accepts (pdf, doc, etc.). If there’s a funky file type trying to get in, you should block it by default, then have the employee explain why it’s needed.
Control 8 (fundamental) – Dirty Malware
Defending against malware is why InfoSec exists.
Below are the CIS subcontrols for protecting against the known bad via high castle walls, but remember protecting from the outside is not enough.
Here are the three that jumped out to me…
- Central Management of Anti-malware: Every device (servers/workstations) on your network should have anti-malware installed on it, which means plenty of alerts/logs. Similar to general logging, it’s important to centralize all of these anti-malware alerts and logs in a single location. This will most likely be a SIEM.
- Updated Signatures: Discovering known bad things is mainly done through anti-malware signatures, which is basically a fingerprint of bad guys/girls. When an attack happens to someone with similar anti-malware installed this knowledge of the attack will be bundled into a signature and copied over to your installation of the anti-malware, so in the future, you’re prepared. These signatures should be constantly updated by the anti-malware provider, with no exceptions.
- No Autorun: Most operating systems prefer convenience over security, so all friction-filled experiences disappear, but this is something we’ll avoid for removable media (e.g. USB or CD). When plugging in removable media it shouldn’t autorun, this convenient feature is useful for malware, so a little friction to ask the user if they want it to run or not is always a plus.
That’s two parts down and three more to go!
I’ll see you next week my fellow humans.