One of the most difficult challenges in third party risk management (TPRM) is how to effectively manage application sprawl.
It’s possible, but painful to allowlist apps at the operating system level using execution control tools. It’s possible, but painful to allowlist browser extensions using managed or isolated browsers.
It’s also painful to manage the ability of users to authorise third party applications to access data in sanctioned SaaS platforms, such as Microsoft 365 or Google Workspace.
For many years, the default configuration in productivity platforms was to allow users to provide their consent to allow third party apps to access data in their account using OAuth consent grants.
This was empowering for individual (consumer) users, and facilitated strong growth in these platform ecosystems. It wasn’t so rosy for the enterprise, however, which now had to contend with users sharing unbridled access to corporate-owned resources. The risks were exacerbated because the tools to manage OAuth content grants were gated by premium licenses.
As a result, legitimate OAuth apps have become a prime target for attackers and rogue OAuth apps have become a useful tool for phishing enterprise users.
In an OAuth Consent Phishing attack, social engineers create a pretext that convinces users to allow a third-party application to access data in their account.
Public examples of these attacks have impersonated trusted entities such as:
Email filtering software (e.g. “Please update your email security extension”)
Google Developer Support (e.g. “Your item is at risk of being removed from the Chrome web store. Please accept our policies to continue publishing your products”)
An internal HR team (e.g. a shared file with the words “July bonus” in the filename)
You can’t blame the user for these attacks. In these examples, developers of browser extensions and even security experts at the SANS Institute (yes, the guys that train cybersecurity professionals) were duped into allowing rogue apps to raid their inboxes, wikis and calendars. This is an attack that can trick just about anybody.
The risk is exacerbated in environments where an administrative user performs their administrative tasks and their general productivity work using the same account: one erroneous consent and they can easily give away the keys to the kingdom.
A few months ago, concerns over OAuth consent grants resurfaced after Patrick Opet, Chief Information Security Officer at JP Morgan, wrote an open letter to third-party suppliers expressing his anxiety about the erosion of traditional enterprise boundaries.
His primary concern was integration patterns that enable users to create direct, often unchecked interactions between third-party services and firms’ sensitive internal resources.
We’ve had to tackle this internally at Okta. Our team has blocked thousands of attempts by corporate users to provide consent to OAuth applications to access data in their Google Workspace accounts.
The vast majority of these requests were for app scripts developed by Okta staff who wanted to extend the functionality of Google Sheets or Google Calendar. Okta is an organization that prides itself on employees being “builders and owners” with the technical skills to automate their way out of problems. So the key to a good security program is to find safe ways for them to experiment.
Okta Security tackled this problem internally by:
configuring our Workspace environment to deny user consent to add new applications by default,
making it as easy as possible for legitimate apps to be allowlisted, and
assigning ownership and monitoring activity in allowlisted applications.
If a user attempts to consent to an unsanctioned application, the request is denied (see image below). The user is presented with instructions on how to file a ticket to have the application reviewed by Okta’s Third Party Risk Management (TPRM) team. The process requires the user to provide a business justification for adding the application.
The TPRM team assesses the business case, whether the application was developed by an approved vendor, and if so, whether the scope of the integration is appropriate for the use case.
Often applications are only allowlisted after the scope of the integration is appropriately minimized, and a service account is configured to manage the integration.
If you need to tackle a backlog of integrated apps, Google Workspace includes administrative tools that allow administrators to filter app integrations according to whether they are verified, which users or groups can access them and the allowed scopes for the app.
Okta Security was only able to manage what data stored in Google Workspace could be shared with other third party apps because Google built the required administrative controls and Okta was licensed to use them.
What about all the other apps? The average enterprise has 247 apps integrated in Okta, according to Okta’s Businesses at Work report. It’s naive to expect that all of those SaaS companies have the capability and resources to develop bespoke management capabilities to the degree Google can, or that enterprise CSOs have the resources to configure cross-app sharing in 200+ different consoles!
So ultimately, if we want to solve the problem of cross-app data sharing a scale, we believe these cross-application authorization flows need to be managed centrally by the CISO, using a centralized Identity solution, rather than within each individual application.
With this in mind, Okta recently proposed Cross-App Access, a method of securing agent-to-app and app-to-app access.
To learn more about securing app-to-app access, you can register to join our upcoming seminar.
Lana Grechko is a Director of Business Technology Security at Okta. Lana leads a high-impact team focused on securing corporate infrastructure and driving key security initiatives across Identity and Access Management (IAM), Infrastructure Security, and Federal Compliance. Partnering closely with engineering, security, and BT teams, she designs and implements strategies that align security with business goals. Prior to Okta, Lana led the design and implementation of the KYC and AML Programs at Bank of West/BNP Paribas. Outside of work, she is San Francisco-based and enjoys playing tennis, pickleball, and reading.
Mike Hennessey is an Enterprise Security Architect at Okta. He is a passionate advocate for modern cybersecurity paradigms and specializes in building resilient and intelligent security frameworks that go beyond traditional perimeters and focuses on enabling secure access and protecting critical data in today's dynamic threat landscape. Mike has spearheaded multiple initiatives in Zero Trust network architecture, refining identity access management, implementing contextual access controls, and fortifying data protection strategies. His expertise lies in translating complex security challenges into practical, scalable solutions. When not dissecting network packets or architecting secure systems, Mike is navigating the joyful chaos of being a father to three energetic kids, often finding real-world parallels to the importance of strong boundaries and adaptive strategies.
Mat Clinton is a Senior Engineering Manager at Okta. He has a background in software development working on internal tools, infrastructure, and security focussed automation at some of the most well-known companies in the industry. Mat and his team’s contributions at Okta push forward the company’s OSIC goals, in pursuit of being the most secure company in the world, while also balancing the needs of productivity enablement for our internal teams. Mat’s recent focus has been related to safe AI usage at Okta through his work on the internal AI Governance board where they evaluate a constant stream of new AI features being released by SAAS providers. Outside of work, Mat likes to spend time at the beach surfing, playing golf with friends, and automating things around the house.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。