A multi-part blog series by Edgile’s Co-founder and a leading Microsoft MVP
It’s time to transform risk into opportunity.
Authors: Dean Fantham, Partner and CTO and Sean Deuby, Senior Architect
You’re making progress securing your hybrid organization. You’ve secured access to your Office 365 apps with conditional access and MFA, and you’re using the built-in security tools such as Secure Score to fine tune the service’s security. Congratulations!
But other than email, the bulk of your organization doesn’t yet use these cloud services for their day to day work; instead, they use a constellation of apps – third party or internally developed, hosted in your data centers or consumed as a SaaS subscription – to move your business forward. And these legacy applications, which depend on network security rather than identity security, are vulnerable to modern attack methods. How do you use a cloud service to increase the security of these apps?
The Threat
Legacy applications are vulnerable to modern cyberattacks because they assume
- the network they reside in has only trusted actors, and
- anyone that holds a shared secret (userid / password) is the authorized user of that secret.
But countless cyberattacks on internal corporate networks have shown that neither of these assumptions are accurate anymore.
The term “assume breach” is a mindset that assumes adversaries are already on the network and already have some credentials. The way to protect applications in this environment is to use modern security mechanisms that don’t depend on network and password security, and thus aren’t vulnerable to these vectors.
Adding Identity Security
The core premise of identity security is ensuring that the user is really who they say they are, regardless of what network or device they’re on. Even if an attacker is on your network or on your organization’s device with a valid userid and password, risk-based authentication evaluates hundreds of attributes of a user and the user’s session. If the computed risk score is high (perhaps the user has never logged on from this location before, or they are logging on at different times of the day, or from devices not seen before), they may require additional authentication such as MFA. This is the essence of the “Zero Trust network” concept: No entity on the network is trusted until its identity has been verified.
How can this be used for your applications? When an app is integrated with Azure AD, for example, the cloud service uses this sophisticated analysis to authenticate the user’s identity to a high degree of assurance before they may access the application. This improves the risk even for legacy apps that have little to no built-in security; after integration you’ll know you have a valid user accessing the app.
It’s important to understand that this integration isn’t the same as a “lift and shift” of on-premises VMs to a cloud IaaS environment. Moving an app from one virtual environment to another may have nothing to do with the identity security of the app.
Focus on modernization
A key takeaway from our application integration experience is that modernizing apps to support claims-based authentication with Oauth2 or SAML is the most important, and time consuming, aspect of such a project. All organizations that have existed for more than a few years have many applications built on the Windows domain shared secret model. Cloud service providers support architectures to integrate on-premises legacy apps (for example Microsoft’s Application Proxy). But bridging legacy apps into a modern framework can be tricky and require extra steps such as browser plugins, network lockdown, and latency testing. Modernizing an app avoids all of these issues and adds more control over app authentication and roles.
You should push application owners to modernize with OAuth2 and SAML where possible; we’ve found that many apps support SAML but the developers didn’t implement it because they don’t understand it. Your integration team needs to have developers well-versed in modern protocols to assist application owners with the modernization process.
Executive support is critical
Executive support of this integration effort is critical and can’t be overstated. Application teams generally aren’t sitting on their hands; they have a backlog of features and upgrades already in their work queue. And even if they don’t, stability and availability are paramount: application owners don’t tend to be rewarded from the business for increasing their app’s security. Management must make the integration effort a clear priority, or app teams just will not prioritize improving authentication security over the long list of items in their backlog. You’ll be pushing a rope.
SaaS applications that only support userids and passwords and not the modern protocols of OpenID Connect / OAuth2 and SAML cannot truly be secured. You can integrate these applications with your cloud service using password vaulting and replay to provide convenience and an SSO experience for your users. But as long as users and bad actors can go directly to the SaaS app, they can sidestep any security measures you implement in your cloud service flow – which makes it only security theater.
Note that this is all about authentication and coarse grained authorization (allowing / denying access to an application). Authorization – who can do what inside the application – is the next step, and worthy of its own post. This allow / deny level of access is usually controlled by group membership or, less often, an attribute of the user object (which can be used to dynamically determine group membership)/ fine grained (RBAC + internal permissions).
Updating the applications your users work with every day to use modern IAM patterns will significantly improve your organization’s risk posture and user experience. This modernization process can be a complex task that requires significant analysis and planning. We’d love to talk to you more about our experience with this process.