Prevent the Next Solar Winds Hack with Cybersecurity Fundamentals
Ask the right questions to prevent future data breaches
One of my stories on SolarWinds Breach and Data Breaches.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
Looking for an overview of the SolarWinds hack? Read these three stories first: SolarWinds Hack Retrospective: The big picture for executives, What caused the breach and what does the malware do?, and What could we do to stop similar breaches in the future?
The specific details of the breach can be further distilled to fundamental cybersecurity concepts such as those I cover in my book, Cybersecurity For Executives in the Age of Cloud. The fundamentals don’t change — whether you are in the cloud or on-premises. They apply to most lapses in cybersecurity and cybersecurity attack vectors. Understanding the fundamentals can help prevent future data breaches — and that is the sole objective and purpose of the book.
Center For Internet Security Top 20 Controls
In 2014, I wrote a paper about how the implementation of the 20 Critical Controls (now called the CIS Top 20 Controls) may have prevented the Target Breach. These controls are often cited as the most important things an organization should do to prevent data breaches. The Target breach white paper walks through the attack, step by step, and considers which control if applied, might have prevented or at least identified the breach.
Over time, my perspective on data breach prevention has shifted. The 20 critical controls are foundational to preventing or mitigating a cybersecurity attack, but some of the controls themselves won’t prevent the breach. For example, the top two controls are an inventory of hardware and software assets. Your organization may have a perfect inventory of hardware and software assets but that will not, in and of itself, prevent a data breach. Controls for an individual asset may not consider the risk a vulnerability poses to an organization as a whole.
What matters most to prevent a breach is the state of the assets, security operations, and your security architecture. Those aspects of your cybersecurity posture will determine whether an attack can occur in the first place, whether it will be identified quickly, and how much damage it may cause. This new perspective, focusing on what causes data breaches and common attack vectors, led to the 20 questions in my book that executives can ask security teams to assess their level of cyber risk and prevent cybersecurity attacks.
What if we apply the 20 questions in my book to the Solar Winds Hack?
I wrote my cybersecurity book to help organizations prevent data breaches. As an alternative to the 20 critical controls, consider how the 20 cybersecurity questions in the chapters in my book may have helped executives, developers, security professionals prevent an attack like the SolarWinds hack.
Chapter 1: Why Executives Should Care More about Cybersecurity
The first chapter covers how lapses in security at the executive level can affect not only financial matters at an individual organization but national security. SolarWinds failing to carefully implement a secure deployment system not only affected their organization’s financial status but caused information leaks at top US government institutions.
Chapter 3: Cybersecurity strategy — Ask the right questions
As mentioned above, executives need to be asking the right questions to solve the right problems to improve cybersecurity posture.
Chapter 4: CVEs: Security Bugs that bite
In this chapter, I explain common vulnerabilities and exposures (CVEs) and zero-day malware. The SolarWinds malware was not a known vulnerability until FireEye discovered it and alerted others to its existence. It was a vulnerability in the SolarWinds software and became a CVE after identification. This chapter explains the malware development and security research process.
SolarWinds CVEs:
Chapter 5: Exponential increases in cyber risk due to Internet exposure
Future blog posts here may cover in more detail how Internet exposure of the SolarWinds system allowed them to communicate with a C2 server (a term also explained in the book) hosted in AWS.
Chapter 6: High-risk ports: The chink in your network armor
Remote access to administrative functionality is dangerous. In the aspect of the attack I wrote about previously, it does not appear the hackers used traditional administrative ports to a large degree. However, many cloud providers provide customers the ability to limit. sensitive administrative actions via cloud APIs and consoles to specific IP addresses.
Chapter 7: Data Access: Protect your Gold
Although this chapter seems to apply, it doesn’t because the attackers had access to create new application permissions in Azure accounts as explained in my prior blog posts. Those credentials could take any action, including decrypting data in cloud storage systems. The fact that the attackers could access high-level credentials in Azure was the real problem, coupled with no segregation of duties when creating new all-powerful credentials.
Chapter 8: Trust is Overrated
This chapter of the book has information not published online to explain the concept of trust and why it is so important in cybersecurity. It impacts interactions between people in organizations. It also impacts technical implementations. This chapter explains the concept of Zero-Trust in terms of networking and system access. Strict implementation of networking and access rules is one of the key factors that may have helped prevent the breached systems from accessing the C2 server in AWS.
Chapter 9: The aftermath of stolen credentials
One of the most important takeaways in any environment exists in this chapter. Attackers use stolen credentials from compromised systems to do their dirty work. Limiting credential permissions would have prevented the attackers from obtaining complete control in Azure cloud. I explain some specifics related to limiting highly privileged access in Azure in this post on What could be done better to prevent the SolarWinds hack.
Chapter 10: The password problem
It appears that attackers may have been able to leverage credentials without multi-factor authentication (MFA). If this was the case, organizations should ensure all administrative credentials require MFA. Organizations can also design processes, systems, and cloud account permission structures to require two people to perform sensitive actions.
Chapters 11 & 12 on encryption at rest and encryption in transit
These chapters are also not that applicable because once someone has an all-powerful account that can decrypt your data, encryption is a moot point. You should still encrypt your data properly as outlined in these two chapters.
Chapters 13: The right cybersecurity training
For whatever reason, it took a high-end security company to discover this breach. The malware existed for months in other organizations handling highly-sensitive data. Perhaps we need to take a new approach to how to think about cybersecurity and obtain the right cybersecurity training.
Chapters 14. Testing your cybersecurity
A penetration test or security assessment cannot guarantee to find every security gap but can help find problems before an attacker does. When I undertake security assessments for customers I always check two things in particular: the amount of access that individuals and systems have within a cloud account and the network architecture which could be exposing systems unnecessarily to the Internet or Internet-connected systems. Almost every data breach involves stolen credentials and C2 servers. You’ll want to make sure your testing is effective and that you are getting value from your penetration tests and security assessments.
Chapters 15. Preparing for cybersecurity disasters
Were organizations affected by this breach able to quickly restore systems to a secure and operational state? I wasn’t involved but this chapter may help organizations considering how to quickly recover from a security incident.
Chapters 16 & 17 on Security policies and Exceptions
Perhaps the security teams at affected organizations tried to implement stricter security policies that were not enforced or ignored. Some companies may not have security policies at all. These two chapters outline some considerations and some new points of view on handling these two important aspects of any cybersecurity program.
Chapter 18: Deployment systems — danger or defense
Weak deployment system security is often overlooked as I explain in the book, and that is the attack vector that enabled the SolarWinds breach from the start. This attack vector has already been used before. It is not new and yet, to maintain speed, companies make excuses based on the need for business profitability and innovation to create a proper deployment system. I’ve assessed startups that have completely automated DevOps pipelines and have personally architected a secure, automated cloud deployment system that was implemented by my three-person DevOps team at a mid-sized business with zero-trust networking and executable verification. Yes, it is possible. It takes executive commitment and investment.
Chapter 19: How well do you know your vendors?
Customers presumed SolarWinds was taking appropriate measures to secure product development and software updates. It’s easy to say “I told you so” in this chapter, but I realize vendor assessments are a challenging and difficult task. This chapter provides some insights as I worked at a security vendor and participated in audits that involved vendor assessment processes.
Chapter 20: Efficacy of security products
I’m sure every company affected by the SolarWinds Hack has one or more security products in place designed to protect them from data breaches like this. Why didn’t they work? This chapter covers considerations when purchasing security products. I’ve also written about Copy Cat Security — the propensity to want to use the solution everyone else is using instead of looking for a solution that solves a specific problem — and Security Product Evaluations.
Chapter 21: The attackers are in your network — now what?
This chapter is certainly applicable to the SolarWinds Hack, but I cannot speak to how the incident was handled at organizations because I was not directly involved. Any organization impacted by this breach that was not immediately prepared to deal with it may want to review this chapter and the related resources.
Chapter 22: Security automation: do more with less
This bonus chapter explains how automation is a powerful security tool if used correctly. However, attackers leveraged automation without proper validation or multi-factor authentication in both the Target Breach and the SolarWinds hack. Automation implemented with proper permission boundaries and a well-designed security architecture can help organizations ensure that stolen credentials cause limited damage. A well-thought-out automation strategy can trigger rules to block suspicious activities and auto-remediation to revert non-compliant changes.
Chapter 23: Is the likelihood of a data breach going up or down?
In this chapter, also not published online, I explain how to tie together the concepts in the other chapter to get a more comprehensive view of cybersecurity risk. As I explain at one point in the book, measuring risk effectively requires understanding which aspects of your cloud and system configurations pose the most risk. Leveraging the data in your organization that tracks potential attack vectors in an automated manner can help organizations better prevent and prepare for cybersecurity attacks.
Chapter 24: Change is constant
Although the technical details vary from attack to attack, certain aspects of cybersecurity attacks remain constant, starting from the first malware ever written. Understanding these fundamentals will help organizations better formulate strategies to prevent data breaches like the SolarWinds hack.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2021
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
