Why you should view the SolarWinds news as an opportunity to improve your security by moving away from ADFS to cloud-based authentication.
The SolarWinds breach (also known as Solarigate or Solorigate) that made headlines in December 2020 opened many eyes to the issues of indirect attacks.
My aim here is not to go through the actual attack in great detail – more than enough has been written about that to keep people reading for hours.
Instead, my aim is to get you to examine whether this style of attack is something that you can discover and react to. I’ll also offer advice on what you can do to remove as much risk as possible from your environment by addressing how you authenticate.
As we now know, the attackers gained access to the SolarWinds source code and injected malicious code directly into it. This code was then included in the distributed code from March 2020 until it was detected.
This breach is a particular cause for concern as SolarWinds are a leading IT infrastructure supplier, spanning network, systems, database, applications, and security management. This means that their systems are deeply ingrained across thousands of organisations.
Typically, organisations are encouraged to patch servers regularly and keep them up to date. With SolarWinds, this became the dispersal method for the attack. As the core software is updated, the malware is installed and starts to send details out to the attackers.
This was not a quick, smash and grab breach but a long-term, planned, patient attack. The timeline is extensive and has been traced back as far as September 2019.
Examining the attack shows a very careful approach that involves deliberate delays before the real breach began.
Since the initial disclosure, MimeCast, Malwarebytes, Palo Alto Networks, Qualys, and Fidelis have all reported that they were targeted following the breach. Quite a prominent set of organisations.
When this attack was being investigated, it showed that there was an opportunity for the attacker to access the federation services on-premises and use these to attack other services that used the federation for authentication.
In the past, federated authentication has been used to provide security and single sign-on to external services and was recommended by organisations like the NCSC. I’ll come back to this in a moment.
Just because a third-party provides a security function doesn’t mean that you can take them at face value. As with other attacks, the communications from the malware to its host can be monitored and reported on.
When management software is installed, it should communicate internally, collating data from servers and systems to do its job. It may contact an external server, perhaps to validate a license or check for updates, but these external access points should be documented and provided as part of an allow list.
“One of the issues with the SolarWinds attack was the potential for an on-premises ADFS service to be broken.”
However, if the system starts to reach out to other services – ones that have not been disclosed by the vendor – then an alert should be raised, and the communications blocked. This monitoring and reporting should be put in place as soon as possible to ensure that any services you add are not communicating with outside systems that they shouldn’t be.
So, why did I mention federation earlier? Well, one of the issues with the SolarWinds attack was the potential for an on-premises ADFS service to be broken. This break may allow the attacker to spoof the identity of any individual and access a third-party service.
Once in that service, they could add in their own IDP, create additional accounts or anything else that a system administrator might do.
Discover how to protect your key cloud-based assets by applying cloud-native authentication to your on-premises infrastructure. Watch this webinar to learn:
In my previous blog on ADFS, I talked about moving from ADFS to cloud-based authentication using password hash synchronisation (PHS) or pass-through authentication (PTA) with a strong recommendation to use PHS.
This is now much more important. If a third-party service can authenticate against Azure AD rather than ADFS, the ability for an attacker to spoof the identity is reduced. Even with full administration access to the internal directory services, an attacker can’t gain access to the certificates needed to spoof an identity.
It is worth remembering at this point that the on-premises administration accounts should NOT have any form of administration access to the cloud services. One thing we don’t want is to lose the administration to both cloud and on-premises through a single account being compromised.
You should ensure that the cloud administration accounts are cloud-only and do not have any presence on-premises.
Moving from ADFS (or another federation provider) is not the scary prospect that it was a few years ago. A staged migration, allowing you to migrate some users and test how they work in real life, means that you can be confident in the migration going well.
Moving any relying parties from ADFS to Azure should be performed one service at a time, as that provides the option of a simple roll-back should that be required. Since Azure AD supports “seamless single sign-on” from domain-joined devices without using ADFS, the user experience can be enhanced.
While the Solarigate (or Solorigate) event has brought working with third-party software into focus, it’s not something you should be panicking about. Instead, use it as an opportunity to consider the potential risks of software being used within your network and its communications with outside services.
It should also provide a catalyst to make the move from ADFS authentication to Azure-based authentication with the options for single sign-on to third-party services.
This can ensure that authentication is secure (supporting multi-factor authentication using an app, FIDO 2 or OATH tokens) and much harder to co-opt for nefarious purposes.
The integration of the seamless SSO functionality for domain-joined devices ensures that the user experience is maintained or enhanced through direct authentication.
We'd love to hear from you! Our friendly team can be reached Monday through Friday, from 9am to 5pm.Contact Us
Eight-time winner of the Microsoft Partner of the Year Award for Identity Management, Enterprise Mobility, and Security and Compliance.
You are seeing this because you are using a browser that is not supported. The ThirdSpace website is built using modern technology and standards. We recommend upgrading your browser with one of the following to properly view our website:Windows
Please note that this is not an exhaustive list of browsers. We also do not intend to recommend a particular manufacturer's browser over another's; only to suggest upgrading to a browser version that is compliant with current standards to give you the best and most secure browsing experience.