Background
If you work in Information Security, Technology, or even if you are just a person who stays up to date with recent news headlines, you probably already know about the “Sunburst” hacking fiasco that came to light at the end of December 2020. I use the term “fiasco” intentionally, because this wasn’t just a routine headline security breach – it was a monumental catastrophe of unprecedented scale, and the all-too-fitting endcap for a notoriously unpleasant year. It was the kind of event that will likely serve (for decades to come) as a cautionary tale, a sobering reminder, and a wake-up call to business and technical professionals alike.
For any that have been living under a rock (and given the year we had, I wouldn’t blame you), the short version is that a group of cyber criminals gained access to a very pervasive IT service provider (SolarWinds) and then used that access to push an “update” to their IT management solution (Orion), which actually consisted of a Remote Access Trojan (RAT) backdoor, now being referred to as “Sunburst”. There has been no public release to indicate the exact number of organizations impacted, but recent SEC filings from SolarWinds stated that the compromised version of Orion was installed by “less than 1,800” organizations[1]. Regardless of the exact number, it is apparent that the scale of this is unlike anything we have seen before.
Back to the Fundamentals
So, what new lessons does the Sunburst hack teach us? The honest answer is… not a single one. Instead, these events should serve to reinforce the existing lessons that security evangelists have been preaching for years. They should be a harsh reminder of the need for basic security hygiene and the importance of squaring away the fundamentals.
FireEye, who initially discovered Sunburst, released a detailed write-up of the attack. The write-up suggests that the campaign was highly sophisticated, but all of the TTPs (Tactics, Techniques, and Procedures) used by the threat actors are still neatly classified within the pre-defined techniques described by the existing MITRE ATT&CK Framework. While the execution of these techniques was advanced, they still were not anything new (supply chain compromise for initial access, use of Windows Services for persistence, code-signing for evasion, web protocols for C2 communications, etc.).
Admittedly, in this case, there was very little that the impacted organizations could have done to prevent the attack. Unfortunately, the nature of supply-chain compromise attacks makes them inherently difficult to prevent, since the attack originates from an otherwise trusted source. Nonetheless, adherence to some core fundamental security principles could have significantly minimized the impact and the time to detection.
These fundamental security principles include:
Principle of Assumed Compromise
One of the most dangerous assumptions you can make is to buy into the “unhackable fallacy” – i.e. the notion that any system is so well-architected that it cannot possibly be broken or hacked. Don’t believe me? Just ask Todd Davis, the former CEO of LifeLock. In the early years of the company, Davis prominently advertised his social security number in a now infamous marketing campaign, which implied that the protection provided was so effective that he could not possibly become a victim of identity theft. According to journalist reports, in the years that followed (between 2007 and 2008), he was a victim of identity theft — and not just once, but 13 times[2].
The obvious take-away? Don’t be Todd Davis. A better approach is to operate at the opposite end of the spectrum and assume that your system, network, or organization has or inevitably will be compromised.
The victims of the Sunburst hacks could have done very little (if anything) to prevent the initial breach. And that is exactly the point. There are many scenarios where, even if you are doing all the right things, it is still nearly impossible to prevent the initial compromise (zero-day exploits, malicious insider, supply-chain malware, etc.). That is why you implement multiple layers of controls and architect your network with the worst-case scenario in mind…operating under the assumption that it could, and very likely will, happen.
In addition to the thoughtful architecture of your controls and network (which we will expand on even more as we discuss the next two principles), organizations should also manage their operational readiness with the same assumption in mind — by constantly refining and updating response capabilities through table-top and red-team exercises. And finally, organizations should have ongoing threat-hunting operations, rather than waiting for something to go wrong before actively looking for IOCs (Indicators of Compromise) or IOAs (Indicators of Attack).
Limited Access
When assuming a security breach is likely, one of the most important things you can do is minimize the impact by limiting access to the greatest extent possible, from any given point of entry. This can be achieved through adherence to three similar but separate principles.
- Least Privilege – Implement user permissions in such a way that any given user only has as much access as is necessary to complete their required job functions. To implement least privilege effectively (as managing individual user permissions becomes unmanageable at scale for large organizations), assign permissions based on job functions with a RBAC (Role-Based Access Control) model. And use the tools that you have available. Fortunately, most organizations already have the tools to apply RBAC, as Microsoft AD (Active Directory) natively includes one of the best and most widely used RBAC implementations. But having AD isn’t enough… you actually have to implement the role based restrictions through user and security group mappings. Finally, build an IAM (Identity and Access Management) program that centrally manages identity and requires access reviews and routine recertification of access to manage user permissions. Most importantly, limit any privileged or administrator permissions as much as possible. Giving everyone in your IT department (or worse yet, your entire organization) administrator rights is how you ensure that a small security incident will quickly escalate into a catastrophic data breach.
- Compartmentalization – Isolate critical functions from other mundane day-to-day operations. This can be done on the network through segmentation. Create dedicated security enclaves for sensitive network operations and limit the traffic that can go across the associated boundaries based on operational necessity. A simple example that should be applied to any enterprise network is the isolation of management services. There is no reason somebody working in Finance needs access to terminal services (SSH, RDP, etc.) on servers in the datacenter. Additionally, servers on the network should never have unfettered access to the Internet. Internet connections from servers should be explicitly whitelisted (using a default-deny approach) and any servers that do need to make any calls to the Internet should be isolated. Compartmentalization should also be applied based on operational functions. Separation of duties has been historically used as a means to minimize the risk of fraud associated with critical operations, but it also significantly increases the level-of-effort required by an attacker to exploit those operations. Finally, you should never grant standard user accounts administrative rights of any kind (local admin, network admin, etc.). Browsing the Internet and accessing email are inherently high-risk activities and should always be done using a non-privileged user account. Users that need administrative access should have a separate and dedicated administrator account for this purpose.
- Minimization – All systems should be hardened and minimized to only run the software, protocols, and services that are necessary to perform its designated function. For example, network devices managed with SSH (Secure Shell) should have other management services (such as HTTP and Telnet) disabled, and a database server should not have Microsoft Outlook installed on it. Apply this principle to all standard baseline builds and ensure that any deviations from that baseline are necessary, approved, documented, and tracked. Universal application of this principle can help organizations to avoid any unnecessary exposure.
Defense in Depth
Another important principle for minimizing the impact of a security incident is applying multiple layers of security, also commonly referred to as “Defense in Depth”. Security controls are going to fail. In acknowledgement of this, the best way to prepare for failures is to ensure that there are other layers of security to operate as a safety net. When implementing a defense-in-depth strategy, consider the following:
- Ensure that you have controls to assist in detecting, preventing, and responding to threat activity
- Implement security at all layers (network edge, network segment, endpoint, application, user, etc.)
- Implement controls to address TTPs (Tactics, Techniques, and Procedures) throughout all steps of the kill-chain to include Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command & Control, and Exfiltration.
The MITRE ATT&CK Framework is an excellent and free resource that can be used to rationalize and optimize your control stack across the enterprise.
Summing it up
While the Sunburst attack was unprecedented in scale, the types of techniques used by the threat actors was nothing new. These events should be a wake-up call to remind us of the importance of basic security hygiene. There is no silver bullet, controls are going to fail, and security incidents are inevitable. But by accepting that inevitability and architecting networks, systems, and controls accordingly, organizations can significantly minimize impact and improve their detection and response capabilities.
[1] https://www.zdnet.com/article/sec-filings-solarwinds-says-18000-customers-are-impacted-by-recent-hack/
[2] https://www.wired.com/2010/05/lifelock-identity-theft/
***
This blog was written by Justin Hutchens, Consulting Services Practice Lead at Set Solutions.