Breaches and the value of a defense-in-depth model

Peter Cockshott
| 11/5/2021
Breaches and the value of a defense-in-depth model

Breaches happen, even to the most secure organizations. A defense-in-depth model can help strengthen security postures.

Cybersecurity is incredibly difficult because of the enormous number of considerations that must be made from a defensive and operational standpoint. Even when organizations believe they have shored up their defenses, it takes only a few control failures to allow an adversary to access their data or environment. 

Many reputable companies have experienced network or data breaches, including Google, Apple, and Amazon. Organizations of all types and sizes can learn valuable lessons from others’ experiences and incorporate critical insights into their information security programs. Exploring several recent events offers an opportunity to reflect on why a defense-in-depth model can help protect organizations from cyberattacks.

Sign up to receive the latest cybersecurity insights on identifying threats, managing risk, and strengthening your organization’s security posture.

What is a defense-in-depth model?

Defense in depth is an information security strategy of applying multiple layers of physical, technical, or administrative security controls to address the security of a network, system, or application. The purpose of layering is to provide a complementary set of controls to minimize the possibility that any individual control can act as a single point of failure. When multiple controls are in place, an adversary must bypass them in their attack chain in order to compromise a system or data, thus increasing the resources and skill set needed to be successful. 

Many organizations already apply layered controls to a degree by imposing firewalls and network segmentation, implementing intrusion detection and prevention systems, developing data loss prevention strategies, and enforcing rigorous patch management life cycles. As with all information security strategies, the defense-in-depth model is not foolproof, and it can require a significant amount of work to put into practice and sustain over extended periods of time. However, when implemented correctly, it can significantly reduce the likelihood of a successful attack or otherwise minimize the potential impact of a breach. 

Colonial Pipeline and the importance of user access reviews

On May 7, 2021, a ransomware note appeared on the screen of a computer at Colonial Pipeline, triggering a series of response actions that included a precautionary shutdown of the largest refined oil pipeline in the United States. In the weeks following, gas prices surged across the southeast, fueled by fears of gas shortages and panic buying. The criminal group known as DarkSide gained access to the Colonial Pipeline corporate infrastructure to perform the attack, and the company chose to pay the ransom

How did the perpetrators successfully breach Colonial Pipeline? The answer is (unfortunately) simple: DarkSide obtained credentials to an unused virtual private network (VPN) account that was not configured to use multifactor authentication (MFA). Exactly how DarkSide managed to obtain that account’s credentials was never fully determined, though it has been noted that the account’s password was found in a publicly accessible data leak repository. It’s possible that the attackers were able to correlate that password’s associated username to discover the Colonial Pipeline account username. 

However the attack was made possible, the question that remains is how could it have been prevented? 

Enter the mundane but critical practice of conducting user access reviews. A user access review is a process of examining all active accounts on a system, correlating them to a user, examining the frequency of their use, and determining whether the account is no longer needed. 

As a best practice, reducing the number of active accounts on a system reduces the number of viable accounts that an attacker can target. Additionally, organizations can use the review exercise as an opportunity to validate that MFA has been appropriately applied to all accounts with remote access to the environment, further increasing the complexity of conducting a successful attack. 

JBS: Disaster recovery and incident response

Like Colonial Pipeline, in May 2021, JBS Foods, the leading beef producer in the world, experienced a ransomware attack. Similar to the Colonial Pipeline attack, the adversary was believed to be a Russia-affiliated ransomware gang, in this case one known as “REvil.” The compromise was first detected on May 30, and it affected servers in the company’s North American and Australian facilities. 

The disruption caused JBS to halt operations for one day while the organization isolated affected systems and contained the incident. As JBS produces nearly a quarter of all meat for the United States, beef prices temporarily rose and concerns emerged about long-term supply shortages if the attack continued for an extended period of time. In order to quickly resolve the situation, JBS negotiated with the ransomware operators and paid $11 million (of the initially requested $22 million) in bitcoin to recover its systems and data. 

It’s unclear how the attackers were able to initially gain a foothold in JBS’ environment, but some valuable lessons can be learned from the company’s response to the scenario. First, JBS was able to restore operations in about a day and a half because its backup servers were unaffected by the ransomware. In order to be best prepared to respond to a ransomware attack, it is crucial to maintain redundant backups that have been logically segmented from the rest of the network so that any affected servers can be restored with minimal impact to operations. 

Additionally, given that JBS was able to quickly coordinate with digital forensic specialists and law enforcement agencies, it could make more informed decisions on what to do next. JBS was ready to respond because of the work it had done in advance on incident response, business continuity, and disaster recovery. Established plans included detailed contact information for internal personnel and external agencies or service providers who could assist in such a scenario. 

Finally, JBS decided to pay the ransom in order to restore data elements that it presumed were not recoverable from its backups. Paying ransom to cybercriminals is an incredibly difficult decision to make, and it’s one that should be discussed as part of incident response tabletop exercises. Before an attack occurs, organizations of all types should discuss cybersecurity insurance needs and the level of coverage necessary to protect the business. Cybersecurity insurance shouldn’t be used as a primary control, but when all else fails, it can alleviate some of the financial pain that accompanies paying a ransom, rebuilding infrastructure, or providing fraud coverage for affected customers. 

How a defense-in-depth model helped the MTA

In April 2021, the New York Metropolitan Transportation Authority (MTA), North America’s largest transit system, discovered that adversaries had exploited a zero-day vulnerability (a flaw undetected by security reviewers) in its VPN appliance to gain remote access to its network. The MTA oversees operations of other New York transportation agencies such as MTA New York City Transit, MTA Bus, Long Island Rail Road, Metro-North Railroad, and MTA Bridges and Tunnels. 

While none of the attackers gained access to the operational systems for these agencies or were able to exfiltrate information (such as customer information), they were able to compromise three of the MTA’s 18 systems. It’s unclear what services those three systems support or what the motives of the attackers were in targeting these systems. 

The MTA addressed its response to the attack in a statement, explaining that it had “quickly and aggressively responded to this attack.” The MTA brought in a cybersecurity firm “whose forensic audit found no evidence operational systems were impacted, no employee or customer information breached, no data loss and no changes to our vital systems.” Most critically for the MTA, its “multilayered security systems worked as designed, preventing spread of the attack.” As a consequence of the attack, the MTA required about 5% of its employees and contractors, or 3,700 users, to change their passwords and also migrated away from the VPN appliance to another solution. 

What lessons can we learn from a zero-day attack? While organizations cannot prevent zero-day attacks, the MTA case reinforces the value of common best practices that cybersecurity professionals regularly encourage, such as the defense-in-depth model. Given the network segmentation that the MTA had in place, attackers were not able to easily move around the MTA’s networks or to compromise operational systems that could have been used to disrupt millions of U.S. transportation networks. Having a defense-in-depth model in place also appears to have prevented the adversaries from stealing sensitive customer information, such as credit card information, names, addresses, transaction histories, and other valuable information that could be used in more targeted phishing attacks. 

Lastly, as JBS had done when it was attacked, the MTA quickly coordinated with state and federal agencies. It also consulted cybersecurity specialists to determine the scope and impact of the attack in order to take the necessary responsive actions. While being able to respond quickly is especially important if an organization plays a role in critical infrastructure, it’s also a valuable exercise for all organizations to establish relationships with local law enforcement agencies and specialist information security firms that can perform the necessary digital forensic investigations in order to determine how adversaries gained access to the environment, what data they accessed and exfiltrated, and whether they established persistence and are likely to strike again. 

Why defense in depth matters

To summarize the lessons learned from these breaches, a defense-in-depth model can be implemented to help reduce the probability of a successful attack and increase the speed with which organizations can respond to attacks. Some examples of layered controls include:

  • Logical security controls. IT teams should implement MFA for all remote access accounts across the board, conduct regular account reviews, and remove accounts that have unnecessary privileges or that are not actively being used. They should also implement a just-in-time access methodology, in which elevated permissions are granted on a limited, as-needed basis, and encourage the use of longer passphrases rather than passwords.
  • Logging and monitoring. Organizations should make sure that robust logging and monitoring controls have been enabled throughout the environment, verify that these logs are being ingested by a centralized logging server and retained for a specified period of time (for post-incident investigative purposes), and confirm that heuristics or detection logic are in place to alert IT or security personnel when indicators of compromise are identified. Finally, they should test these capabilities via penetration assessments to verify that they are operating as intended.
  • Configuration management. Golden images should be appropriately hardened prior to any system’s deployment. IT teams should conduct regular audits of those images to determine if any unauthorized or insecure configuration changes have been made, and they should limit system functionality wherever possible so that attackers have fewer avenues for lateral movement and privilege escalation if they compromise one of those systems.
  • Vulnerability management. While conducting regular vulnerability scans of external and internal assets won’t prevent zero-day attacks, such scans can reveal known vulnerabilities present on an organization’s systems. Implementing a process to track vulnerabilities from discovery to remediation and evaluating trends of vulnerable systems over time so that frequently vulnerable systems can be segmented as much as possible is a good idea.
  • Incident response. Organizations should identify key stakeholders from IT and the lines of business and form an incident response team. That team then should develop an incident response plan and conduct regular tabletop exercises. The tabletop exercises could identify gaps in coverage or a lack of awareness on the incident response team. Additionally, the incident response team should coordinate with external stakeholders such as law enforcement and forensic specialists prior to any incident to avoid delay in bringing these personnel on board when an attack takes place.
  • Business continuity and disaster recovery. Without information technology or the necessary data, businesses cannot continue to function. Therefore, organizations must identify their critical business processes, determine what their core technology dependencies are, and ensure that the recovery objectives needed for those technologies are achievable. Extensively testing these backup and recovery processes to verify that they are repeatable is crucial in minimizing system downtime and data loss due to ransomware or other denial-of-service attacks.
  • Network architecture. A well-considered network architecture, with appropriately segmented internal zones, also plays a pivotal role in implementing defense-in-depth models appropriately. While every organization tends to focus on boundary points, many small organizations tend to overlook the importance of robust internal network controls. If the internal network is flat, critical infrastructure components likely are exposed to a wide variety of systems and thus have a higher likelihood of being compromised. Network segmentation acts as the foundation for other controls that can help detect or prevent lateral movement, intelligence gathering tactics, malware propagation, and some privilege escalation techniques.

Applying lessons learned

Exploring how organizations have dealt with incidents that have taken place can teach valuable lessons. Every organization is in jeopardy of being compromised and having to deal with similar circumstances. Each of the organizations discussed here took steps to disclose these breaches, attempted to remediate the issues that caused the compromise, and likely will make additional efforts to improve their overall security postures moving forward.

As a defender, it takes only a few missteps to allow an attacker to succeed, but by incorporating some of these lessons learned from past breaches, organizations can be better prepared when the inevitable incident occurs.


Is there a topic you’d like to read about?

Let us know.