Incident response consultants are often contacted by clients who are in complete shock that their systems or networks have been compromised. Many times, these clients are hoping our analysis will ultimately prove that the incident was just a “flesh wound” to their systems and that they didn’t experience an actual data breach. It’s quite common for organizations to assume that data breaches won’t happen to them, and consequently, they typically don’t have an incident response plan.

Not only do organizations need an incident response plan, but they also need to test it via incident response tabletop exercises. In this podcast, LBMC Information Security’s Bill Dean shares five key reasons why organizations don’t detect cyber breaches, as well as some helpful tips for being prepared in the event of a cyber-attack.

Listen to Podcast

Listen, and discover these key takeaways:

  • Reasons why organizations need to plan for a data breach and test the plan
  • Understanding why it’s important for organizations to know where its sensitive data lives
  • The importance of enlisting the assistance of skilled information security professionals
  • The case in support of quality penetration testing

Subscribe to the Cybersecurity Sense Podcast on iTunes.

To learn more about LBMC Information Security or to speak to one of our trusted professionals about our services, including incident response and penetration testing, contact us today!

Five Reasons Why Organizations Don’t Detect a Cyber Breach

This podcast is inspired by an article from technologyrecord.com before the holiday season. The article starts out by explaining how we, as incident response consultants, are often contacted by clients who are in complete shock that their systems or networks have been compromised. Many times, they are hoping our analysis will ultimately prove as just a “flesh wound,” and that they didn’t experience a data breach.

Reason #1: It’s common that organizations assume it won’t happen to them and consequently they don’t have a plan. Their assumption is that they aren’t interesting enough, their data isn’t interesting enough, there are bigger and better targets, or, worst of all, they have security solutions in place, which means they are bulletproof.

Many organizations pay incident response-planning lip service. They download a vanilla incident response plan from the internet, update it a bit, file it in a folder, and feel good that they are compliant with the latest or greatest cybersecurity framework.

Assuming a compromise will not happen is not a good plan, especially if you are targeted by a talented attacker group with a focused objective. Not only do you need a plan, you need to test it via incident response tabletop sessions.

Reason #2: The second reason in the article is that organizations don’t fully know where their data is. It is common for an organization to focus on where they think the data is, protecting this with security controls and processes. However, they are frequently unaware where data has leaked to within a network or cloud services.

Organizations that don’t know where all their data is located will struggle to defend it. They will struggle to detect attacks that target it, and they will be unable to respond when incidents occur. For an organization to be able to detect and respond to a cyber-attack, they must have a full and complete picture of where their sensitive data resides in advance.

Reason #3: Organizations expect that technology alone will detect a breach. I put IDS/IPS and SIEM into this category. Many organizations make the investment in these technologies but do not ensure they are properly tuned and located at the right locations and receiving the correct data sources. There have been numerous times that, through the incident, the organization realized that the correct network segments weren’t being monitored, or critical data sources were not being fed into the SIEM.

Outside of tuning, most every organization that purchases a IDS/IPS/SIEM quickly comes to the same conclusion, it takes dedicated and talented resources to monitor these technologies, if they want more than to “check the box.” Checking the box in the InfoSec world is code for “they are making the investment into compliance rather than their security posture.” Technology alone isn’t enough to detect and respond. It requires human intervention and successful processes to act on alerts and to undertake a counter-action when faced with a possible breach of network or systems. And—as with the Target beach—all too often, critical alerts are ignored.

Reason #4: The organization has never done any assurance on their detection. The article described that many years ago, when firewalls were first deployed, organizations trusted that they were secure and assumed that they wouldn’t be breached. Over months and years, mature organizations recognized that they should probably test the security of the firewalls to ensure that they were doing the filtering in the way that they expected. Through firewall audits and external penetration tests, some organizations gained assurance that their firewalls were delivering the value they expected. You now need much more.

In some instances, clients are also inadvertently testing their MSS providers, but that is about as far as it goes for the majority of companies. We all know that the endpoints and users are what are now being
targeted, and much of the InfoSec budgets are being spent there. However, most organizations are still performing conventional “penetration tests” but not emulating what today’s attackers are doing and how to detect them.

Organizations need to understand the threat landscape and conduct applicable threat modelling to understand the likely attack paths and the relevant tools, techniques, and practices that threats have been seen to display. Detection and response assessments should then be conducted to
simulate these threats and determine an organization’s detection capability.

Last year, I was introduced to MITRE’s ATT&CK Methodology and Matrix and have been very impressed with how valuable this resource is in emulating known attacker groups and testing the controls. The framework even has IOCs in the STIX format for searching the environment for these types of indicators.

Based on this awesome work, we are currently developing new tabletop session approaches and augmenting our penetration testing methodology with this framework. I’ll have more on this in a future podcast, but here’s a link to some additional info.

Reason #5: Organizations assume that the threat will look like it’s from an external source. Many organizations monitor the external infrastructure effectively but have poor detection capability internally. The expectation is that the threat is external and will look like malicious traffic.

The reality today is that many threat actors target people, your employees, and your colleagues. They compromise their machines through phishing techniques and then move laterally across the network abusing the inherent trust controls that you have built into your systems, your services, and your processes. More and more attacks don’t look like external threats. They look like internal users, accessing systems and services in an abnormal manner. If you are not monitoring the internal networks, and you have no ability to detect normal from abnormal user behavior, then it will be really hard to detect many of the more common current threats.

Takeaways

  • System and network compromises will happen to your organization. You need to plan for it. Once you have planned for it, test the plan.
  • You must know where your sensitive data is, I can’t say this enough.
  • Technology alone will not stop the compromises; you must have skilled people and tested
    processes.
  • In your penetration tests and audits, test your security technologies with how today’s attacks occur. Match the test to your security maturity level when emulating current attacks.
  • Don’t always assume you know what an attack will look like. Again, this is demonstrated in
    quality penetration testing attacks.

Bill Dean is a Senior Manager at LBMC Information Security. While involved in various aspects of
LBMC’s security services, he is also the practice lead for the organization’s incident response,
forensics, and litigation support practice.

References: