By now, everyone involved in some aspect of IT has heard of the recent SUNBURST (also known as Solorigate) malware associated with the SolarWinds Orion application. This breach brings the topic of least privilege into focus. Many IT professionals think of least privilege as applying just enough rights to a user or service account needed to accomplish its intended function; however, this concept should be extended to an application.
One aspect of least privilege that many System Administrators ignore is outbound firewall rules. While most are diligent about protecting the "front door,” or inbound traffic, by implementing firewall rules which allow only web traffic (e.g. TCP/80, 443) from the public, your customer base, your remote employees, etc., rarely is much thought put into protecting the "back door" by limiting egress traffic. Frequently, an "allow all" rule is in place.
As is the case with most malware, an infected host attempts to reach a command and control (C2) server for instructions and/or exfiltration of data. If egress traffic restrictions are put in place (e.g. no public Internet access), the C2 channel cannot be established and the malware impact is mitigated. In the case of the SolarWinds breach, the attackers masqueraded their communication as the Orion Improvement Protocol (OIP) within HTTP traffic that is normally exchanged between the application and SolarWinds (e.g. solarwinds.com) and, instead, directed it at attacker‐ controlled domains.
To protect your application, audit host‐based firewalls, web application firewalls, security groups and Network Access Control Lists (NACLs) to eliminate "any," "0.0.0.0/0," "::/0" or otherwise unnecessarily permissive egress rules and restrict outbound traffic to only ports, protocols, and hosts needed.
