Select Page

The recent SolarWinds supply chain cyberattacks serve to underscore an age-old cybersecurity tenant, and the reason we need to continue beating the drum as cybersecurity professionals: Use a layered approach to OT security.

This incident highlights a rare, specific use case of a nation state threat actor, an Advanced Persistent Threat (APT). In this particular case, layers provided somewhat limited value, but helped keep the less skilled attackers – about 99% of those on the playing field – at bay.

Technology boundaries can be used to lessen the impact of (but unfortunately not prevent) nation state APTs. They not only offer additional protection, they may also help expose the presence of APTs in your network. Let’s examine how they would have helped in the case of APTs like the Sunburst malware that infected SolarWinds Orion software and was downloaded by 18,000 organizations.


Each technology boundary put in front of the attacker serves as an opportunity to better defend your network. Best of all, they can be used to limit an incident’s blast radius, containing the scope of the attack.

How Technology Barriers Can Protect Your OT/IoT Network

Technology can be used to create more layers, even layers within layers, without additional infrastructure. When attackers hit a technological boundary, they need to adjust their tactics accordingly. In addition to serving as hurdles for attackers to overcome, boundaries provide for ‘choke-points’ where monitoring and signaling can occur. Each technology boundary put in front of the attacker serves as an opportunity to better defend your network. Best of all, they can be used to limit an incident’s blast radius, containing the scope of the attack.

Use More Than One OS

Let’s start with a hypothetical manufacturing company using the SolarWinds product (or similar solution), putting aside the revealed hack for a moment. In this example, the organization runs mostly Microsoft Windows infrastructure. If SolarWinds is a key part of its cybersecurity, asset inventory, monitoring and patching infrastructure, it would be susceptible to an attack targeting Windows systems, because it uses the same OS as other monitored assets.

Say a virus or worm runs rampant on the organization’s Windows network. If the system used to control the company’s environment is also running a vulnerable OS, it may become infected and unavailable during the forensic investigation or recovery processes. A major tool that’s typically used in the recovery efforts would also need its own recovery, at the worst possible time… when trying to recover a production network.

If the manufacturer had used a technological boundary, for example running SolarWinds on Linux instead of Windows, they would find recovery much easier to perform. The worm or virus would have run its course across Windows systems, but be stopped in its tracks when it hit the Linux system.

On Linux, SolarWinds could have operated safely within the sea of infected Windows machines, and provided a secure foundation from which to operate. The opposite also applies. If the environment was full of compromised Linux machines, the investigative and recovery efforts could be handled from a different platform, like Windows or Unix. It’s important to re-state that the SolarWinds Orion attack should be distinguished from this example.

Use Different Technology Platforms

Another great technology barrier example involves remote access. If your environment contains only one operating system, you may want the remote access and VPN technologies to exist on different technological platforms. This can go beyond just operating systems to include functions as well.

Creating a barrier around remote access includes ensuring that connection monitoring is done independently of access management. If Vendor 1 provides remote access, Vendor 2 should monitor it. It would be dangerous to have the same solution granting access and monitoring its own ability to do this securely. There should always be a technology barrier between remote access and monitoring, so that if an incident occurs on one or the other platform, the blast radius is limited to a single business function. Hopefully, one product picks up on the failure of another.

“Thanks to the COVID-19 pandemic, organizations shifted to remote working models. Post-pandemic, working from home will continue at high levels, and securing remote access will remain a critical area of risk management. Security teams should ensure that remote connection monitoring is done by a different technology than access management. Separate, layered technologies are the best way to achieve defense in depth.”

Andrea Carcano, Co-founder and CPO, Nozomi Networks

We see this barrier tactic used frequently in operational technology (OT) environments involving high risk or dangerous processes, such as mixing toxic or explosive chemicals, or where human lives are at stake. In situations where an incident could cause widespread disruption or potentially impact an entire city, safety is paramount. In facilities like these, Safety Instrumented Systems (SIS) are used to reduce the risk. In many cases, separate technologies are also used to monitor and take action if certain conditions are met.

For example, a facility may run Vendor X in their production environment, but they’ll use Vendor Y or Vendor Z for the SIS system. If, for example, a sensor in the Vendor X system fails, and dangerous conditions occur, the technology barrier created by a separate, independent system doing its own monitoring and control comes in to play. It steps in with its own readings, identifies the dangerous conditions, and creates an alarm or provides the insight needed for security teams to act accordingly.

Imagine a plant that runs with a single Vendor X getting hit by an APT attack. This could create a worst-case scenario where not only do production systems go offline, safety shut-off systems become unavailable as well. To prevent this, it’s common practice to create boundaries using separate technology, teams, and processes in the SIS environments.


One layer of security requires only a one-digit combination. Each new layer of security adds another digit to the combination.

Each Layer of Security Adds Another Digit to Your Combination Lock

Technological barriers are an effective way to make it more difficult for APT threat actors to move laterally, undetected. I like to think of it as an attacker attempting to crack a safe to gain access to the contents… your valuables. The only thing preventing the attacker from breaching your security perimeter is the combination. One layer of security requires only a one-digit combination. Each new layer of security adds another digit to the combination.

An attacker using a nation state APT has access to various zero-day vulnerabilities, and enough funding to purchase others. What are the odds than an attacker has a zero-day for your system? Let’s say there’s a 25% chance. Now, let’s say you add another layer of security, using a different vendor. Using the same odds, there’s a 25% chance the APT can break through that layer too. However, both layers need to be broken simultaneously during the course of the campaign. In the same way two numbers need to be correctly aligned on a combination lock… both zero-days need to be positioned simultaneously to break into your networks. (Chance of opening combo 1 * Chance of opening combo 2 = Probability of access. So, 25% * 25% = 6.25%)

If you add a third and fourth technology to the mix, you will see major gains in protection, and achieve a .01% and .003% chance of the attacker gaining access (again, just using hypothetical numbers).

Technology Boundaries Also Provide Opportunities for Threat Discovery

In addition to serving as technological boundaries, these hurdles create opportunities for discovery. When an attacker attempts to bypass multiple challenges, it makes it difficult to mount an end-to-end attack. During execution, the attacker will invariably conduct reconnaissance activities, and probe the boundaries they’re confined within.

Let’s say the attacker is leveraging an unknown weakness in Vendor X (i.e. Microsoft, Linux or Apple) that allows them to scan all day without being noticed. When those packets hit a machine from Vendor Y (i.e. Checkpoint, Palo Alto Networks or Unix) that isn’t vulnerable to the covert scanning tactic, a discovery opportunity arises. Each technology barrier is another chokepoint and opportunity to assess the situation using different tools, providing a different perspective.

The more protocols a product can interpret, the richer the protection mechanism. For example, if the attacker is using protocols present in Vendor X, but you’re also using Vendor Z (i.e. Nozomi Networks), which understands protocols from a wide range of vendors (Vendor X, Vendor Y, Microsoft, Linux, Rockwell, Siemens, ABB, etc.), we have several opportunities to observe the attackers as they operate within the confines of each technological barrier.

The Best Defense is Defense in Depth

In summary, the best defense against nation state APTs is to incorporate layers, using several technology barriers within each layer. Employ independent and highly secure monitoring tools that aren’t vulnerable to the same cyberthreats and your critical OT systems will be much more secure.

If you’re concerned that your network has been infiltrated as part of the SolarWinds attacks, our Threat Intelligence service detects IoCs (Indicators of Compromise) related to that breach as well as the use of FireEye Red Team tools leaked during the overall malware campaign.

If you’d like to learn how the Nozomi Networks Threat Intelligence service can help you detect and respond to vulnerabilities and emerging threats faster, please contact us.

Related Content


OT/IoT Security Report

Rising IoT Botnets and Shifting Ransomware Escalate Enterprise Risk
2020 1H

Find out about:

  • The OT/IoT threat landscape:
    • IoT malware
    • Ransomware
    • COVID-19-themed malware
  • The tactics and techniques of the most important threat actors
  • The top 2020 ICS vulnerabilities and their ongoing impact on risk
  • Recommendations for securing OT/IoT networks