Which Connection Should I Use for Playbooks?

Give out permissions with the right balance of security and manageability.

With the release of the managed identity option for Microsoft Sentinel playbooks, there are now 3 viable options for connecting playbooks to an identity that has the needed permissions. Information about these connection types is difficult to find in Microsoft documentation, so deciding which connection to choose can sometimes be a challenge for security engineers.

In this blog, we show the different playbook connections and discuss what the difference between them is. We will also discuss practical considerations for implementing each type of playbook connection.

Connect with a Sign-In

The default and most convenient option is signing in with a Microsoft Sentinel AD account, which will have the playbook act on the behalf of that identity. This does not require any additional configurations, but it gives the playbook way more permissions than it needs to do its job.

This option should only be chosen by organizations requiring lower maintenance overhead, especially when developing and testing playbooks. Most organizations that are concerned with security use the “principal of least privilege” which is a useful security practice that this option does not fully follow.

Connect with a Service Principal

A service principal is a mechanism used to give an application an identity within Microsoft Sentinel. By creating a service principal for playbooks only, the required permissions can be given out to the service principal. Service principals can also be shared across playbooks if the playbooks need the same permissions.

This option should be chosen for organizations that want a mix of security and efficiency. Service principals that are configured correctly follow the principal of least privilege, and they can share identities. For an example of service principals that are used across logic apps see the example image below that has some of our legacy service principals.

Connect with a Managed Identity

Managed identities allow security engineers to manage the permissions of the logic app individually by giving the logic app its own AAD identity. This option allows for very precise tracking of what logic apps are doing because each logic app has their own separate identity.

This option should be chosen for organizations that want to maximize their security because this option is able to monitor the logic apps individually. If a playbook causes a serious issue in a subscription, it will be easier to track it down because managed identities are not shared between playbooks as is the case with service principals.

We will continue to share best practices and lessons learned in future posts on using playbooks in customer environments. We are constantly adding and evaluating playbook features so we will have a lot to say about playbook configuration updates as they come out.

In closing, consider these three questions when using playbook connections in your organization:

1. Are we currently using the default sign-in option without considering the consequences of that decision?
2. Would we rather have the convenience of consolidated service principals or the accounting of managed identities?
3. Should we create standards for playbooks to ensure that the right connection is being used for new playbooks?