5 Cybersecurity Best Practices from the Front Lines
by Chris Triolo
category Cybersecurity Analysis
tags cybersecurity best practices, cybersecurity best practices for employees, cybersecurity best practices guide, cybersecurity risk management and best practices, mitre att&ck framework, mitre att&ck framework excel, mitre att&ck framework explained, small business cybersecurity best practices
Every security professional has their war stories. Our First Responders are long-time Security Operations professionals who have built and run SOCs for some of the largest companies in the world. In their current roles, they see a large number of incidents on a daily basis and work closely with our customers to resolve them. We thought we’d share 5 best practices they have gained from real experiences working with customers over the last few months.
Be wary of lateral attacks from IoT Devices
Nothing feels more overblown then the constant stream of articles about vulnerabilities in IoT devices. However, during a recent Proof-of-Concept, we detected evidence of lateral movement from an IoT device (in this case a network of security cameras) to other systems in the environment. Lateral movement is a technique where an attacker breaks into one system and uses that as a beachhead to move on to other systems in the environment. In this case, their physical security camera systems were on the same network as systems managing critical data. We recommend monitoring all devices on the network and ensure appropriate network segmentation, so that critical systems would never be on the same network as IoT devices like security cameras, smart TVs, etc.
Tune Up Your Sensors (Be careful how you tune)
In the last few months, we detected a Zeus infection inside a customer’s network. Infected internal systems were reaching out to known malicious IPs. The customer had seen SO MANY of these alerts, they assumed they were false positives, and began disabling the intrusion detection signatures, i.e., tuning down the sensors. We immediately notified this customer to let them know these were actually real incidents and gave them the required evidence. They re-enabled the signatures and took action to clean up the infected systems.
Always Clean Infected Systems
Often, we'll identify customer systems infected with malware and are "beaconing out", i.e. communicating with attacker systems, outside the network. In some cases, the customer, who has already anticipated this type of thing, has technology controls in place that drops or blocks the traffic on its way out of the network, so the internal system can't reach out to the external system of the attackers. Some customers will think, “No problem, the traffic is blocked, I'm safe.” However, the customer STILL has a compromised or infected system inside the network that needs be cleaned. Just because the malicious traffic is blocked, doesn't mean you can ignore it. What if the system is a laptop and is taken home (out of the office) where it’s no longer protected? There's nothing to stop it from communicating with the attacker's system when on the employee’s home WIFI.
Find and Fix Misconfigurations
Another typical issue we uncover is that security sensors are often not working as expected. The Respond Analyst and our team can catch misconfigurations and ensure that security controls are working as they should.
While monitoring a customer’s URL filtering product, we noticed that the traffic volumes were unusually low—too low for normal URL traffic. There was just not enough user activity for this size of environment. We coached the customer to review the configurations on the URL Filtering software, and yes in fact, it was misconfigured. Once fixed, our product detected and alerted them to several malicious and actionable security incidents that needed incident response. Up until that point, they thought they were protected. They weren't.
Normally, we see 300+ unique IDS signatures alerts on a daily basis in a typical customer environment. On one particular day, we noticed something wrong —a customer had only 30 unique signatures alert that day. We believed it was likely that their IDS was misconfigured or over-tuned. Our suspicions were correct. The customer reviewed their configs, made updates, and we began seeing normal volumes of IDS traffic. We started catching the bad guys again, escalating new incidents once the fix had been made.
Always ensure that your sensor grid is working. Pay attention to expected traffic volumes and signature feeds and when there are anomalies, investigate.
Working with Red Teams
As a result of our automated decision monitoring, the Respond Analyst routinely catches pen-test and red team activity of a customer testing their own defenses. Interestingly enough, before customers had the Respond Analyst, customers with an MSSP or internal security teams would miss the tell-tale signs. Here's the interesting part: since this is just testing and NOT ACTUAL malicious traffic, customers often want to "whitelist" the system(s) conducting pen-tests or red teams in the Respond Analyst, as they're not real incidents. We encourage them NOT to whitelist these systems because it's a great way to prove the Respond Analyst is working, and it's good to test your security controls and your security detection capabilities regularly.
In need of smart folks who can help take your security operations to the next level? The Respond Analyst is constantly learning from the billions of security events it sees on a regular basis, and our team of First Responders are here to help you resolve the incidents that appear. To see for yourself how Respond Software can help you detect and respond to threats in your environment, click here to see the Respond Analyst in action.