Third-Party Access Risks Explained

In honor of Cybersecurity month, we wanted to take a look at one of the most confusing, if not successful, threat actors who have been on everyone’s minds this year. 

In looking back at some of the biggest hacks of the past year, one theme appeared to come up over and over again, becoming a disturbing trend.

Attackers are going after third-party contractors, using their legitimate access to the targets and exploiting security gaps to break in and make off with their ill-gotten goods. 

Okta, Uber, and others have found themselves breached after a contractor was compromised, leading to the malicious actors gaining super admin access within their targeted environments. 

What is it about the way that organizations manage and interact with contractors that makes these third-party players such a risk? 

Contractor Security Challenges Explored

Supply chain security has been a hot topic the past few years, especially since the SolarWinds attack. But not as much focus has been directed at those workers contracting with your organization, accessing your assets and sometimes opening the door for attackers. 

Some of these issues include:

Lower Security Standards, Familiarity, and Protections

These workers, whether working for a vendor or as independent contractors, may be doing much of the same tasks as your employees. But unfortunately, they are probably not receiving the same level of protection and management. 

For starters, contractors also might not have access to the same support systems or know how those support systems are supposed to work. This includes some of the basics of how the organization manages security. 

A prime example of this is the recent Uber hack where the contractor reportedly received a WhatsApp message “from IT” telling them to approve the MFA prompt. An employee may have known that IT is not going to send them a message over WhatsApp but rather a channel that they manage, if at all.

Secondly, many of these workers are likely not using an endpoint (laptop) that is owned by your organization. This means that you do not control the security standards, configurations, security monitoring tools, or have other important risk management controls that can help to bring up the level of security to a more desirable starting point.  

More than likely in our day of remote work, these contractors are logging into the organization’s cloud apps and services using identities and credentials that may or may not be under the organization’s management. 

Lack of Comprehensive Visibility 

Security teams struggle to achieve effective visibility over what their own employees are able to access. Third-parties cause all kinds of difficulties when it comes to understanding who has access to what. 

There are two main issues that impact their visibility. 

How Access is Managed

The first pertains to how the contractors received their access. This provisioning usually happens in one of three ways. 

• Access is managed in the company’s Identity Provider (IdP) as an additional user
• Provisioned ad-hoc local accounts in apps. An example here might be a third-party developer receiving an invite to access the organization’s GitHub repository. This method is not considered best practice since it is harder to manage securely.
• The big vendors that can share accounts from other tenants (Microsoft and Google) make it easy to allow access to external organizations that are using the same IdP vendor. Okta does not support this so you have to set it up separately. 

If the third-party vendor controls their own identities and you are just granting them access, then you will always have some limitations on your visibility and control. This is especially true once they end their engagement with your organization and you want to offboard them. 

How can you be sure that they no longer have access to your assets? This leads us to our second visibility challenge.

IdP Visibility is Limited 

Even if you are running access correctly through your IdP, you are only going to see what your IdP is capable of showing you — which is essentially what access you have provisioned through it.

And that is not enough. You need visibility from the asset side as well to get the fullest picture of your access state. 

Maybe a contractor has that access to parts of your development pipeline like repositories or even a production environment via a direct invite. That access, and definitely any of their access privilege activity, will not be visible through the IdP. 

Only by having granular visibility into all of the environments along the access path between the identity and the asset can you really understand and secure that access, and thereby the identity’s privileges for the asset.

Again, this is a serious concern for off-boarding and maintaining Least Privilege in general because a contractor could hold onto access for years if their access privilege activity is not being monitored. For example, a contractor could receive access privileges for a project but not have those access privileges revoked when the job is done. The same issue holds true for employees, but we consider contractors to potentially have a higher level of risk.

Stale access privileges, like the one that was used in the Colonial Pipeline with the unused VPN account, can be used by attackers to breach the organization. 

3 Tips for Mitigating Third-Party Access Risks

While issues like hardware and training may be harder to find a quick fix, there are a couple of steps that can be taken today to make it harder for your contractors to be exploited by attackers.

1. Achieve and Maintain Least Privilege with a Usage-based Approach 

Removing unused access should be a top priority. Doing so requires having continuous visibility over access privilege activity across all your clouds. 

Authomize connects to every environment in your cloud and homegrown apps, providing you granular visibility into who is using which access privileges and how. This end-to-end visibility runs from your IdP all the way to the specific file, repo, or whatever the asset is, regardless of how many environments, groups, or roles it crosses through on its way. 

Having visibility over not just who has access to (what you see in the IdP), but what is being accessed by who (what you see from looking at the assets as well), can be critical to having a real understanding of your actual access.

Collecting access privilege usage data allows you to make data-driven decisions about which ones to keep or revoke. 

For example, if an access privilege has not been used in say 30 or 60 days, then that employee or contractor probably does not need it anymore to do their job effectively. Revoke it.

Another case could be that a contractor has ended their relationship with the organization but still holds onto their access to the repositories, creating a partial offboarding situation. By understanding their effective access with our insights from the source control tools, we can quickly remove their access.

2. Configure Your IdP with Expressions for Managing External Identities

Another practice for more secure contractor management would be to assign specific names to them when they sign in from their IdP.

Create an expression for their IdP username that will keep them separated from your employees. For example, build an expression so that every time [email protected] signs in from her IdP,  you will rename it to [email protected].

This way Jane will not be able to impersonate sensitive accounts like [email protected].

As an added point, if you are using Okta, make sure that the checkbox stating “Only allow usernames that match defined RegEx Pattern” is marked since it defaults to unchecked. From this screen you can set the regex that will fit your requirements.

3. Continuously Monitor for Changes and Indicators of Compromise

Once you have achieved a state of Least Privilege, removing risky access privileges, you need to maintain a secure state.

Our continuous monitoring enables you to set policies and receive alerts when there is an identity or access risk violation or threat detected.

Threats can include: 

• An inactive identity that performs an activity. This could be a suspended account that suddenly springs to life and could have been taken over by a malicious actor.
• A SAML configuration is changed. We might see someone changing a property or the URL being passed to a third-party app in the SAML authentication process, indicating a possible compromise.
• The user property has changed (at least twice) in the last 24 hours. This could indicate that someone is attempting to hide their tracks after having carried out some dirt. 

By detecting these issues, security teams can perform targeted investigations and remediations as necessary, securing their organization from possible threats and exploitation.

Expanding Capacity, Reducing Threat Surface

Working with third-party vendors is a given in our increasingly interconnected ecosystem. Contractors and other extra hands provide value in allowing us to scale up and do more while maintaining flexibility. 

These advantages should not come at the expense of our security. 

By removing risky access privileges, adopting safer configurations, and continuously detecting threats, we can reduce our overall threat surface. To learn more about Authomize’s Cloud Identity and Access Security Platform, contact us for a demo today.

The post Third-Party Access Risks Explained appeared first on Authomize.

*** This is a Security Bloggers Network syndicated blog from Authomize authored by Gabriel Avner. Read the original post at: https://www.authomize.com/blog/third-party-access-risks-explained/