Shadow IT Security Risks: Web Applications run by Shadow IT

A quiet proliferation of web applications and infrastructure with web-based interfaces is taking place throughout your organization. Known as “Shadow IT,” many web applications and platforms are often licensed by business, financial, and technical users, independent of central IT management. Sometimes these groups even build their own technology solutions. Security and operations folks who are tasked with safeguarding your entire IT environment are likely unaware of the breadth of applications in use or their impact on security risk.

Shadow IT increases security risk for many reasons. Web applications may have bugs or flaws that attackers can exploit. They may not receive recommended patches and updates. Shadow IT applications aren’t included in audits, which may lead to compliance problems and also increase security risk.

And, of course, Shadow IT web applications and platforms aren’t included in central Privileged Access Management policies.

Securing these potential infiltration points is critical. Attacks on web applications more than doubled in 2019, and web applications were involved in 43% of breaches. If sensitive data is accessible via web applications and platforms, it could be exposed or stolen.

Consider that a former employee or contractor typically retains access to numerous SaaS or web applications much longer than they should

Shadow IT security risk is acute when you consider that an employee or contractor typically retains access to numerous SaaS or web applications much longer than they should.

Shadow IT means that when someone leaves your organization, it’s unlikely that there is a record of all the SaaS, web applications, and infrastructure they had access to. Therefore, they may be able to view and manipulate sensitive systems and data long after they leave. Did they create additional accounts? For whom? Where are they? No one knows.

How many cloud services do you think the average enterprise uses? 10, 100, 1,000? Most IT organizations believe that number is around 30. The truth is there was an average of 1,935 cloud services in use in 2019, representing a year-over-year increase of 15% from 2018. About 70% of these are business applications, such as Office 365, Salesforce.com, HubSpot, project management tools, help desk software, online notebooks, accounting software, and collaboration, and social media platforms.

How many of those are Shadow IT in your company?

Shadow IT makes access management inconsistent and inadequate

The problem with Shadow IT isn’t only that systems are purchased and maintained outside of the IT mainstream. It’s also that the security practices in place to control user privileges and permissions aren’t implemented. Business users may have access to sensitive, protected information. They may also have unprecedented power to represent your organization’s brand, such as through social media applications.

Many organizations make an investment in securely storing and managing passwords and establishing role-based access control aligned with the least privilege model to protect privileged accounts.

Without central Privileged Access Management, credentials for Shadow IT tools may not be set up, rotated, or monitored appropriately.

End result: a Shadow IT organization supporting privileged user behavior, administered by non-IT professionals

Via Shadow IT, users may create their own accounts, outsource services to a third party, or share credentials because of limited RBAC or reduce the cost. End result: a Shadow IT organization supporting privileged user behavior, administered by non-IT professionals.

The underlying problem of Shadow IT is compounded because humans have so many credentials for browser-based applications that they may store credentials in their web browsers, spreadsheets, and consumer-grade password vaults to remember them. These practices open the door to credential theft.

Worse, people often use the same credentials and passwords for multiple tools and rarely, if ever, change them. And that problem only gets worse when they use shared credentials to access Shadow IT applications. Cyber criminals love this practice because it increases the attack surface and makes it easier to infiltrate multiple applications.

Mismatch of user credentials and permissions

SaaS and web-based service providers are focused on the security of the applications they build. But a SaaS application’s access and permissions models may not mesh with your organization’s protocols. When custom applications are built, they rarely consider integration with modern security controls.

Legacy applications run on code that developers don’t want to work with — that’s if they even have access to the code. Network and security applications come with their own built-in RBAC, but SecOps and NetOps teams can’t follow the least privilege or zero trust model because the available controls are often inconsistent.

Every application has different ways of configuring authentication, access, and policy controls. Third-party apps are built to support many customers, so they’re naturally limited in the level of customization they’re able to provide for your organization. As a result, the definition of roles and role types may be less precise than you would like and likely won’t match how your organization defines them.

For example, organizations that build compute in AWS can define privileged roles in a way that makes the most sense to them, and it will likely be different than how you define privileged roles for other enterprise tools your organization uses.

With each vendor making different choices, your organization is faced with reconciling and managing hundreds of different definitions. Remember, that’s 1,935 different applications, on average, to be managed. More mature apps may offer more control, while newer applications may have limited options.

Why is it difficult to secure SaaS and web apps?

Let’s say you do find out about Shadow IT and you want to bring third-party or custom applications and platforms under a central PAM umbrella. There are a number of challenges inherent to managing SaaS and web systems using the same tools you use for user identities, access, and permissions.

• Many enterprises rely on Active Directory (or a similar, centralized system), to manage identities and access across their workforce. Yet, many SaaS applications lack the ability to integrate with AD. This means that members, groups, and permission structures need to be managed separately in each application.

• Lack of integration between enterprise and SaaS user management means that you’re limited only to each application’s internal reporting and auditing capabilities. You don’t have central access to event logging, event alerts, event notifications, and critical activity reporting. Most SaaS and web applications lack the ability to report on user activity, which results in no central visibility, no monitoring, and a limited audit trail.

• Most SaaS offerings only offer limited additional security layers. While many offer multi-factor authentication (MFA) as an option, few if any provide geofencing or geoproximity. Thus, if MFA is compromised, there is rarely an additional layer of security in place to deter the intrusion.

What are your options to reduce risk?

Many organizations have challenges applying consistent access security policies across all applications, so users are often left to make decisions on their own. You likely have many questions to help you make the right choice. The ones listed below are the most common questions we hear.

Should I allow users to choose and maintain their own passwords for SaaS and web apps?

No, you shouldn’t.

Unfortunately, users are notoriously bad at coming up with strong passwords, and even worse at regularly rotating them. Some web apps enforce password complexity and rotation rules; many do not. (Use Delinea's tool to create strong passwords.)

Left to their own devices, users are likely to store passwords for web apps in their browsers. Unfortunately, hackers have become adept at extracting browser-stored passwords. Browsers weren’t built to be password managers. Browser-stored passwords may make it faster and easier to log in to resources, but are again, notoriously easy to steal.

• Browsers typically don’t use strong encryption for passwords.
• Inspector tools make it easy to reveal browser-stored passwords and require zero programming knowledge.
• Password recovery tools can easily find these passwords.
• Users rarely monitor or change passwords once they store them in their browser.

If the same password is used for many applications, the danger can spread. If users have local admin rights on their computers, a stolen password can provide the keys to your entire network.

What if I try and manage each app’s access control individually?

It’s going to be difficult and time-consuming.

To keep track of user accounts and establish a standard approach, some organizations will pass along the responsibility of maintaining each app’s access control separately. In practice, this means IT operations teams must either manually or programmatically create user roles and permissions inside of each application. Then, your organization has multiple user identities, usernames, and passwords tied to each individual for IT to track outside of Active Directory. This approach is resource-intensive, error-prone, and very difficult to keep in sync.

Single Sign-On (SSO) should work for web applications, right?

Well, maybe.

SSO platforms exist to serve as a bridge between apps and environments. For those SaaS and web applications that provide integration points for SSO platforms, SSO can streamline and simplify the process of maintaining user identities and managing permissions across many environments and third-party sites.

There are downsides to this approach, though.

• SSO must be configured uniquely for every SaaS web app. It is both time-consuming, and, as mentioned above, IT teams aren’t even aware of all the sites used by employees. This is especially true of custom, legacy, social media applications, and services.
• There are many enterprise-grade SSO providers and solutions, such as Directory Services, Okta, and Ping Identity, but not all third-party apps work with all major providers. The providers are usually competitors seeking to lock customers into the provider’s own ecosystem, so they are often purposely not interoperable with each other. If your organization has standardized on one SSO platform, you may not be able to integrate with all platforms, SaaS, or web apps. This is especially true of custom, legacy, social media applications, and services.

Should I create shared accounts and groups that can be used to access an app?

Perhaps.

If you’re using SSO, rather than managing unique account credentials for each user, you could assign each user an account, associated with a shared role, then the shared role would have a login that users would never need to see. By using the autologin, users will never know the username and password for the site. This also limits the number of accounts on the app, while providing the ability to implement password complexity and rotation, SSO, MFA, session recording, auditing, and reporting for all users.

While this reduces the burden on IT to manage each user individually, it’s important to note that this approach could run afoul of the web app’s user licensing policies, especially those that follow a named-user licensing model.

Modern PAM gives you central control for cloud access

Compared with the options you’ve had to date, PAM solutions that are built for the new world of SaaS and web applications provide a more robust approach to user permissions and access control. When you use a centralized PAM solution for web apps, you get all the benefits of PAM, including enforcement of best practices and good security hygiene; enhanced visibility, auditing, and oversight; and reduced risk to privileged accounts.

PAM solutions also allow you to apply consistent authentication, authorization, and auditing across all applications and websites without the need to deploy any additional software, agents, or infrastructure.

Secret Server for all types of privileged users

Secret Server, Delinea's core Privileged Access Management solution, can be extended to integrate with SaaS and web applications, while also protecting privileged accounts and credentials for tools that aren’t web-based. This option may be preferred by teams that prefer hands-on control and customization, and is purpose-built to address the access and permissions issues related to cloud. Some advantages of this type of Privileged Access Management solution are:

• Ability to manage centrally: One of the main challenges of managing cloud access is that each one requires its own account management, with separate users, roles, permissions, and authentication schemes. Secret Server enables you to centralize management functions and unify roles for multiple cloud platforms with consistent PAM policies and practices, so they can be managed in a single hub.
  
  
• Easy deployment: Asking users to install additional software so they can access third-party apps can hinder productivity. Generally, users value ease of use and ease of access over increased security. With Delinea, there are no agents to install, no additional infrastructure or VPN is required. It requires minimal effort from users both to get started and to use, so it’s easy to get going and easy to keep using it.
  
  
• Control contractor access: With Secret Server, you can connect to third-party and custom-built web apps and manage credentials with custom password changers. You can manage their access without setting them up in your Active Directory and give them an email address with Remote Access Service (RAS). 
  
  
• Standardized cloud platform integrations: Secret Server has built-in integrations for cloud platforms like AWS.

• Easy to deploy: You can choose between SaaS or on-premise deployment. Either way, you’ll have access to a complete solution quickly.
  
  
• More extensive MFA: Secret Server provides additional authentication to strengthen your approach, including biometrics, geolocation, and geofencing, in addition to traditional credentials and passwords.
  
  
• Increase awareness of user behaviors: Privileged Behavior Analytics (PBA) can quickly detect anomalous behavior and instantly alert your security team to a cyberattack or insider threat before a breach catastrophe happens.

Next steps in applying for a unified and consistent access management program

Least privilege and zero trust mandates are the reality of today’s IT environment. Implementing a comprehensive approach to tracking, maintaining, and monitoring their use is now a must-have for Privileged Access Management. That starts with providing a minimally intrusive approach for users to access the applications they choose, an approach that also provides controls needed for an IT team to increase oversight and accountability.