Nonstandard Applications in an Identity-First World

This articles was originally published by Cerby. You can read the article here.

Nearly every web application (app) today requires us to verify who we are by signing in with a username and password or “Login with Google” (or some other single sign-on service). Simply put, the apps that support single sign-on (SSO) are considered “federated” or “standards-based” applications. In contrast, all other apps are “nonfederated” or “nonstandard” because they do not support identity standards.

Regardless of their support today, identity standards have been, and will continue to be, an important investment for securing how work gets done. However, the explosion of SaaS and its business value has made it impossible for IT and security personnel to be the gatekeepers of technology purchases as they traditionally have been. So how do IT and security teams tackle this daunting sea of decentralized apps, disconnected from central access request workflows and incident response plans?

What started as shadow IT has become strategic technology purchases by non-IT leaders to drive operational efficiency and revenue.

What are nonstandard applications?

The phrase “nonstandard applications” is a catch-all term to describe the applications that don’t support identity standards like SAML, OIDC, and SCIM. Without this support, these apps are disconnected from identity providers (IDP), like Okta, Microsoft Entra ID, and Ping Identity, because they don’t support SSO and centralized user provisioning.

Most innovative SaaS solutions that business operations teams buy today are nonstandard applications. Legacy applications that have been homegrown or built on-premises would also fit into this category.

Nonstandard applications are typically accessed through a username and password. The user identity created in nonstandard applications remains siloed from established IT, security, and compliance processes that verify the right to access the data that flows into the nonstandard applications.

How are applications managed today?

At the most basic level, organizations will decide how to manage applications based on the level of risk they present to the company. Crown jewel applications are often centralized in management, purchasing, and ownership to protect the business. Other applications are owned, purchased, and managed by someone in an operations arm of each functional department, whether in marketing, sales, finance, or a line of business.

Crown jewel applications

IT, security, and identity teams usually focus on protecting the crown jewel applications because they present the most risk to the business if they are compromised. These applications may contain sensitive data, like customer data, company financial data, or intellectual property. Other crown jewel apps might be vital to power the customer experience and would damage revenue if the systems went down. We’ve all heard stories of employees accidentally taking down production AWS resources, which impacted company revenue and customer trust downstream. 
IT, security, and identity teams use technical capabilities like single sign-on (SSO) and user lifecycle management to build a security perimeter around the identity of their workforce team member.

Business applications

Did you know that 80% of CXOs outside of IT believe digital leadership to be part of their jobs? In other words, non-IT leaders know they need technology to achieve their business goals, and according to Gartner, these leaders dedicate, on average, 21% of their staff to implementing, building, or managing technology.

When the technology landscape looks like the following for marketing, sales, finance, and industrial teams, it makes sense that each group has a technology operations arm to deliver business outcomes.

How are nonstandard applications addressed today?

Business units often own the purchase cycles of their applications, sometimes with support from IT or security as prescribed by their organization. Inevitably, the business unit owns the administration and use of the application, which includes provisioning and deprovisioning user access, determining proper roles and permissions, and enforcing security policy with MFA.

Organizations may implement an enterprise password manager (EPM) as the secure vault for usernames, passwords, or secrets. However, EPMs are merely a stopgap solution.

EPMs don’t mitigate the risk of someone being given or keeping access and elevated privileges when they shouldn’t. This is where IT and security leaders can transition from being the gatekeepers to being advisors on what “good” app management looks like because they have already implemented processes driven by compliance requirements.

IT and security leaders have:

• codified data sensitivity levels within their organization,
• outlined policies to manage risk to the business,
• built processes with HR to ensure the right people have the right level of access at the right time,
• prepared a crisis response plan to handle security incidents, and
• developed access request and review workflows to authorize access to tech.

Now, it’s time to extend that knowledge to business leaders and their operations teams.

How do we secure nonstandard apps in an identity-first world?

When a business unit assumes responsibility for purchasing and managing an application to provide business value, they also take responsibility for its security, privacy, and compliance. Business leaders often de-risk a purchase by including IT and security leaders in the buying cycle, but this doesn’t substitute securing the day-to-day use of the application.

IT and security leaders need to take the time to understand the business objectives that business leaders are targeting with their technology purchases. Then IT and security leaders can share what they’ve learned about managing applications and managing risk across their entire organization.

Business leaders need to have their operations teams partner with IT and security to align how to use technology to achieve business outcomes securely. Then business admins can leverage processes that are already in place with IT and security.

By understanding business objectives and sharing “good” app management practices, IT and security leaders equip business leaders and admins to share the responsibility of security and risk management.

We built Cerby recognizing this natural tension between the productivity gains of using best-in-class tools and securing the data that resides in those tools. By integrating Cerby into the identity and access management (IAM) architecture, IAM, IT, and security teams now have a tool for marketing, sales, and finance admins to centralize and adopt “good” app management practices.