No Such Thing as “slightly” Compromised

References to Solarwinds

SolarWinds Blames Intern for Weak Password That Led to Biggest Attack in 2020

New Evidence Suggests SolarWinds’ Codebase Was Hacked to Inject Backdoor

Amazon’s Lack of Public Disclosure on SolarWinds Hack Angers Lawmakers

Where is the risk?

When you are faced with a compromise of credentials that connect to your system, there is no “slightly” compromised. A system that has had it’s remote access credentials compromised must be considered “completely” compromised.

Recent developments in the Solarwinds hack have executives pointing fingers at an Intern who shared the password “solarwinds123” on a public facing github account. This password was online for over a year and apparently provided access to a Solarwinds development server.

In short discussion today, we review a hypothetical situation where a SCADA server on an OT (Operational Technology or Industrial) network has it’s remote access credentials made public. If you are logging and monitoring all access and all activity on the SCADA workstation, than you can detect if those credentials are used. HOWEVER, if you are sharing a username and password and are unable to differentiate between valid, authorized users and anonymous users–you must consider the system and OT network as compromised.

Defense In Depth – What Applies?

Referencing the Defense in Depth strategy from the ISA 62443 Cybersecurity best practices:

  1. Access Control – Know who has access to the system with discrete username and password combinations
  2. Policies & Procedures – Do all employees and contractors know your password policy, how it affects them, what they must abide by and what the consequences are if they fail to comply?

What can you do?

  1. If you must use remote access, ensure that it is well documented, is equipped with monitored logs and that everyone has a discrete username and password combination.
  2. If you think that your system has been compromised, schedule a recovery of the affected systems.
  3. Develop, test and verify your Disaster Recovery plan. If you don’t have a DR… now is the time to start one!

For Previous Discussions on Cybersecurity, see the links below!