Microsoft Defender ATP API updates released. A rich and complete set of APIs geared to fulfill the needs of security operations teams, enabling interoperability with enterprise security applications and automation.These capabilities enable customers to integrate and orchestrate defenses across their solution stack and management systems to orchestrate Microsoft Defender ATP; enabling security teams to effectively respond to modern threats.
What’s new in Microsoft Defender ATP APIs
Microsoft Defender ATP offers a layered API model exposing data and capabilities in a structured, clear and easy to use model, exposed through a standard AAD based authentication and authorization model allowing access in context of users or SaaS applications.
Microsoft Defender ATP API Model
The API model was designed to expose entities and capabilities in a consistent form, once you try out one or two examples, the pattern of using other capabilities or entities will be similar.
The API exposes the richness of Microsoft Defender ATP data – exposing calculated or ‘profiled’ entities (for example, machine, user, and file) and discrete events (for example, process creation and file creation) which typically describes a behavior related to an entity, enabling access to data via investigation interfaces allowing a query-based access to data. Soon, Microsoft Defender ATP will also expose an event streaming interface allowing customers to flow event data to an external storage, correlate with additional data sources, perform custom analytics and others.
Additionally, the API exposes the ability to take actions in the service and on devices, enabling customers to ingest indicators, manage settings, alert status, as well as take response actions on devices programmatically such as isolate machines from the network, quarantine files, and others.
Authentication and Authorization
Accessing Microsoft Defender ATP APIs is granted in accordance with the service users and permissions model. For users, Single Sign On (SSO) and RBAC rules apply, and for services – permissions management. Using an AAD Applications model solves them all. A user’s API calls use the delegated permissions model. It means that the user context is used when calling the API, leveraging SSO capabilities. Since the user identity is used, the same RBAC rules applied for interactive user, applied also for API user. For services, the AAD application model is applied where the AAD Global Admin grants the permissions to the application. Any change of the application “manifested” permissions will require Global Admin Consent. Full control. Full transparency.