Check APIs published in Azure API management is using Defender for APIs

[BenjaminEngeset]

Existing rule

No response

Suggested rule

APIs published in Azure API Management can be secured by Defender for APIs. All tiers of APIM supports Defender for APIs.

It offers full lifecycle protection, detection, and response coverage for APIs.

Defender for APIs can be onboarded in the Defender for Cloud portal, or within the API Management instance in the Azure portal.

With infrastructure as code this is done by creating an sub-resource Microsoft.Security/apiCollections under Microsoft.ApiManagement/service. The collection (Defender for APIs resource) must have the same name as the API published in Azure API Management. This will initiate an diagnostics setting on the API as well.

Defender for APIs is currently in preview.

Defender for APIs currently doesn't onboard APIs that are exposed using the API Management self-hosted gateway, or managed using API Management workspaces.

Currently Defender for APIs only discovers and analyzes REST APIs.

Pillar

Security

Additional context

https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-apis-introduction
https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-apis-prepare
https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-apis-deploy
https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-apis-posture
https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-apis-manage
https://learn.microsoft.com/en-us/azure/templates/microsoft.security/apicollections

[BenjaminEngeset]

@BernieWhite Could you brainstorm a bit on this one with me?

1. Check that APIM instances have minimum one collection attached and detail rule docs.

2. Check that APIM instances with API sub-resource of the type REST and compare that the amount of these are the same as same amount of collections. Detail rule docs.

We are also not able to test APIs that are deployed standalone.

Both proposed designs will not be bulletproof and have trade-offs and rule the rule doc will be important.

[BenjaminEngeset]

@BernieWhite Bump, when you have the time.

[BernieWhite]

@BenjaminEngeset For each API that is a REST API it should have matching a Microsoft.Security/apiCollections with the same name as the API. We should target Microsoft.ApiManagement/service.

APIs that are not REST, have a properties.type value set to something other then http, however the property is not required so if the property does not exist it should be treated as http.

For example:

{
  "id": "/subscriptions/nn/resourceGroups/nn/providers/Microsoft.ApiManagement/service/nn/apis/graph",
  "name": "graph",
  "properties": {
    "apiRevision": "1",
    "authenticationSettings": {
      "oAuth2": null,
      "oAuth2AuthenticationSettings": [],
      "openid": null,
      "openidAuthenticationSettings": []
    },
    "description": "",
    "displayName": "Graph",
    "isCurrent": true,
    "path": "graph",
    "protocols": [
      "http",
      "https"
    ],
    "serviceUrl": null,
    "subscriptionKeyParameterNames": {
      "header": "Ocp-Apim-Subscription-Key",
      "query": "subscription-key"
    },
    "subscriptionRequired": true,
    "type": "graphql"
  },
  "type": "Microsoft.ApiManagement/service/apis"
}

I'm not sure how we determine if the API is only self hosted. There is a mapping for APIs that are self hosted (https://learn.microsoft.com/en-us/azure/templates/microsoft.apimanagement/service/gateways/apis?pivots=deployment-language-bicep), but these also could be deployed to the managed gateway as well, and I can see anything that flags it is only self-hosted.

[BenjaminEngeset]

@BernieWhite Thanks for the input. Yes, it's unfortunate that we might not be able to catch explicitly self hosted APIs.

Do you agree on that the best we have right now is to point out this in the documentation, so it's clear that it's not supported and that the rule can emit false results under these circumstances?

[BernieWhite]

@BenjaminEngeset Yes, let's do that. It's preview so, hopefully we can refine it further with feedback.