Most organizations increasingly trust third-party vendors to perform critical business functions, but it is important to realize these vendors could potentially be the ‘weakest link’ within their own organization.
The most recent attacks attributed to the Lapsus$ group confirm that
even organizations with the most well-resourced security can fall victim
to attackers through third-party dependencies.
A Quick Lapsus$ Refresher
In just a few months, Lapsus$ - also known as Dev-0537 - has expanded from launching a handful of destructive attacks to stealing and publishing source code of multiple top-tier technology companies. The Lapsus$ gang first appeared on researchers’ radars through a plethora of techniques including phone-based ‘vishing’ scams, island-hopping supply chain attacks, buying compromised credentials, offering financial incentives to employees to disclose their credentials, and targeting personal email accounts.
Most recently, Okta disclosed a breach impacting several hundred customers, thanks to the relatively new cybercrime gang.
Like most Software as a Service (SaaS) businesses, Okta uses several third-party vendors to help expand their workforce. And while this is certainly beneficial to the business, it could ultimately expose an organization to some serious incidents, which is unfortunately what happened in Okta’s case.
Sitel, a customer service provider for Okta, was the third-party responsible for the recent Okta security breach (which affected around 2.6% of Okta’s customer base). Okta’s investigation concluded that Lapsus$ gained access through a remote desktop protocol (RDP) execution of a compromised Sitel support engineer’s computer, which allows one computer to remotely connect to another computer over a network connection. This is like walking away from your computer at a Starbucks, and a stranger (in this case virtually) sits down at your computer and begins using your mouse and keyboard.
So, while Lapsus$ never truly gained access to the Okta service through account takeover, a machine logged into Okta’s management and support console was compromised and Lapsus$ was able to obtain screenshots and control the machine through RDP. While unfortunate, Lapsus$’s use of third parties as a way of being able to access larger vendors is nothing new.
And Okta’s latest incident certainly won’t be the last of this type.
Gaps in Okta’s TPRM?
While the forensic reports did not conclude how the hackers gained access to the Okta support engineer’s laptop, fingers are pointing towards negligence or potential malfeasance by the engineer (aka insider threat). The modus operandi (MO) of the Lapsus$ group is to gain initial access through purchasing credentials and multi-factor authentication click through from legitimate system users. While it was never made clear how the Sitel engineer was compromised, it seems likely there was some foul play involved based on how Lapsus$ operates.
When the term ‘insider threat’ is mentioned, most people visualize a malicious employee or an incident-prone worker. While that’s often accurate, there’s another type of insider threat that is often overlooked - third parties. Third parties have access to critical systems in business, and most organizations work with a steadily increasing number of third-party vendors.
Okta’s third-party risk management program probably did not account for the insider threat programs at their third parties, or consider how to keep data safe by centralizing how they both vet and monitor their third parties.
To help close these gaps, companies should include third-party
insider threat in tabletop scenarios, test insider threat ‘inquire and
response’ action procedures, and prepare a response plan for third-party
related incidents before they happen.
What We Can Learn (and Do) to Protect Our Data
As companies rely more and more on third-party vendors, their risk profiles continue to grow. Some of the largest data breaches to date have stemmed from third-party relationships.
Fortunately, organizations are starting to become more aware of third-party breach issues as a source of cyberattacks.
Inadvertent mistakes by your third-party vendors’ employees can easily cause just as much damage as intentional attacks (take Okta for example). While unintentional, these mistakes can still lead to data leaks, significant revenue losses, and service outages.
Below are some steps you can stay on top of your third-risk management program and incorporate insider threats:
Secure your third-party access. Properly securing third-party access is one of the best ways to protect against intentional or accidental data breaches. Assume an insider threat event will take place at a third-party and think about how to limit the damage through intentional permission limiting and good identity and access management axioms like the ‘principle of least privilege.'
Account for internal threat and human errors within your TPRM program. Your third-party risk management program needs to account for internal threats and human error. Risk assessments should go beyond the basic security questionnaires, as these can provide a false or incomplete version of the security landscape. Instead, customize them to include how the third-party evaluates their own insider threats through employee surveys, and potential employee behavioral reports.
Conduct periodic tabletop exercises around insider threat. Performing periodic tabletop exercises based on insider threat scenarios in conjunction with your critical third parties can result in refinements to your program to ensure that the inner perimeter of your defenses are less vulnerable to these types of attacks.
Regularly review third-party employee training and awareness. All organizations must conduct employee training and awareness around insider threats and social engineering. Teaching employees about third-party insider threat is a good way to help prevent it from happening. Ensure your third-parties are cognizant of this risk and they are training their work force to look out for these types of issues amongst their ranks.
Assess and monitor behavioral performance. Make sure your third-parties are identifying internal and external sources of employees’ (including third-party) behavioral issues to incorporate personal and environmental factors within threat identification, risk assessment, and response. These are tried and true methods to rooting out insider threat issues before they manifest into bigger problems.
The Bottom Line
The Okta breach demonstrates that no business organization is 100% safe from malicious attacks. The best way to mitigate risks like the Okta breach is to deploy a sophisticated third-party risk management program that includes employee insider threat and awareness.
Ultimately, anyone who is allowed access into your systems should be included in risk assessment to account for insider threat. Third parties should be managed as if they are current employees within your own four walls.
Okta’s breach is an important reminder that companies must monitor the actions of any person who can access an organization’s critical applications or systems. Whether malicious or unintentional, any vendor with access to sensitive data may be a potential insider threat.