Parameters to identify high risk app registrations

Enterprise Applications High Risk
1

I’m currently working on an exercise to identify risky app registrations within my tenant and would appreciate some insights. Here are the metrics I’m considering:

  1. The API to which the app is connected.
  2. Type of permission:
  • Is it read or write?
  • However, using read/write permissions alone to assess risk isn’t foolproof, as context matters. For example, reading group members versus reading a user’s mailbox involves different levels of risk.
  1. The lifetime and number of secrets/certificates.
  2. Certificates versus secrets.
  3. The number of owners.

Does anyone have additional suggestions or insights on how to more accurately identify risky app registrations?

2

Hi Louis,

I believe context is key, when analysing SaaS risks.

There are multiple aspects that add risk to apps integrated with Entra ID:

  • The combination of permissions and/or roles assigned
    Some permissions and roles can lead to business email compromise (BEC) and/or privilege escalation to the level of Global Admin within Entra. We see these highly-privileged permissions and roles being labeled within the Entra portal. Single permisions and roles are easy to spot, but combinations of permissiones is harder (see next point), or when multiple apps are compromised with a potentially highly-priviledged combination of permissions and roles.
    From a compromise perspective, I agree that there are difference between read and write permissions. However, from a reconnisance and data leak perspective, there is no difference. Data that can be read can typically be siphoned off.
  • Creation and/or change following a known tactic from known adversaries
    Adversaries can typically avoid detection and gain persistence when they assign combinations of permissions and/or roles that are each perceived as low-privileged (but the combination is highly-privileged) to an app or assign the low-privileged permissions and/or roles to multiple apps.
  • An app impersonating a legitimate app (not for app registrations, but for enterprise apps)
    Another way adversaries could consent phish privileges is by impersonating a benign app or group of benign apps that each provide a part of the combination of privileges and roles that are highly-privileged.

Then, as you list them in your post, there are indicators of a lack of security sense (or the positive side: a thorough understanding of integrating SaaS apps in Entra) from admins and vendors:

  • Using secrets vs. certificates
    Microsoft recommends using certificates to have apps authenticate, but for non-production use, a secret suffices. When a secret is used for a long time, than it can be compromized by analysing the sheer amount of packages exchanged between the app and Entra ID on the transport level. Additionally, the way certificates are used for authenticating is certificate-based in terminology, but not all certificate processes are enforced when using certificates to authenticate. The lifetime is enforced, but it can be a self-signed certificate if you, your admins or your vendors would have a preference for those. Likewise, the 13-month validity period for certificates is also not enforced.
  • Owners
    Owners offer a delegated way per application to assign the equivalent of application administrator privileges to a person that does not (need to) have that role. To me, owners indicate a high SaaS governance level and an understanding of SaaS integration with Entra ID.