Security operations center (SOC) teams experience challenges when integrating Microsoft Sentinel with Azure DevOps. The process involves many steps and the setup can take days with constant repetition. You can automate this part of the development.
Cloud modernization means engineers must constantly learn new skills and techniques for securing and protecting vital business assets. Engineers must build robust and scalable solutions that keep pace with the ever-changing security landscape and business needs. The security solution must be flexible, agile, and carefully planned from the earliest stages of development, known as shift-left.
You can even expand the solution to cover complex organizations that have multiple entities, subscriptions, and various operating models. Some of the operating models supported by this solution include local SOC, global SOC, cloud service provider (CSP), and managed security service provider (MSS)
Potential use cases
The following are the typical use cases for this architecture:
Rapid prototyping and proof of concept - This solution is ideal for security organizations and SOC teams who want to improve cloud threat coverage or modernize their SIEM infrastructure with infrastructure as code (IaC) and Microsoft Sentinel.
Microsoft Sentinel as a service - This development framework integrates service lifecycle management principles. These principles suit simple or complex teams like MSSPs who run repeatable, standardized actions across multiple customer tenants while combining the power of Azure DevOps and Azure Lighthouse. For example, a team that needs to publish Microsoft Sentinel use cases for a new threat actor or ongoing campaign could use this solution.
Building SOC use cases for threat detection - Many groups and threat intelligence platforms rely on MITRE Att&ck content and taxonomy to analyze their security posture against advanced tradecraft or techniques and tactics procedures. The solution defines a structured approach for developing threat detection engineering practices, by incorporating MITRE Att&ck terminology within Microsoft Sentinel artifacts development.
Architecture
Diagram of the Architecture for automating a Microsoft Sentinel Infra as code pipeline.
Components
This architecture makes use of the following components:
Azure Active Directory is a multi-tenant, cloud-based service to manage your identity and access controls.
Azure DevOps is a cloud service to collaborate on code, build and deploy apps, or plan and track your work.
Azure Key Vault is a cloud service for securely storing and accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, certificates, or cryptographic keys.
Azure Policy is a service to create, assign, and manage policy definitions in your Azure environment.
Microsoft Sentinel is a scalable, cloud-native, SIEM and security orchestration, automation, and response (SOAR) solution.
Azure Automation is a service for simplifying cloud management through process automation. Use Azure Automation to automate long-running, manual, error-prone, and frequently repeated tasks. Automation helps improve reliability, efficiency, and time to value for your company.
Considerations
With security, in general terms, automation increases operations efficiency while saving time for more complex use cases, such as threat detection engineering, threat intelligence, SOC, and SOAR use cases. DevOps teams need to know where they can use IaC securely in the context of Microsoft Sentinel CI/CD. This process introduces the use of specific identities that are used by non-human accounts in Azure AD called service principals and managed identities.
The following table summarizes security considerations for service principals and the main use cases that are covered by Microsoft Sentinel and Azure DevOps release pipelines.
Privileged access model
Privileged access should be the top security priority at every company. Any compromise of these identities creates highly negative impacts. Privileged identities have access to business-critical assets, which nearly always causes major impacts when attackers compromise these accounts.
Security of privileged access is critically important because it's foundational to all other security assurances. An attacker in control of your privileged accounts can undermine all other security assurances.
For that reason, we recommend logically spreading the service principals into different levels or tiers by following a minimum privilege principle. The following illustration shows how to classify the service principals, depending on the type of access and where the access is required.
Diagram of the layered architecture for a privileged access model in a pipeline.
DevOps
Microsoft Sentinel solutions are composed of three blocks, which ensure complete and successful operations.
The first block is the environment definition, which makes up the essential architectural elements. Your main concern with this block is to consider the number of production and non-production environments to be deployed, and then ensure the setup is homogeneous in all cases.
The second block is the Microsoft Sentinel connector deployment, where you consider the kind of connectors that are required by your team and the security requirements to enable them.
The third block is the Microsoft Sentinel artifacts lifecycle management, which covers coding, deployment, and use or destruction of the components. For example, this block contains the analytic rules, playbooks, workbooks, threat hunting, and so on.
Consider these dependencies between artifacts:
Automation rules that are defined in an analytics rule
Workbooks or analytics that require a new data source or connector
Managing the updates of existing components
How to version your artifacts
How to identify, test, and deploy an updated or entirely new analytics rule
Orchestration and automation of release processes
You can set up the deployment process with Azure DevOps or GitHub. Azure DevOps supports using a YAML pipeline or a release pipeline. For more information on using a YAML pipeline in Azure DevOps.
Azure DevOps
You can do the following deployment activities in an Azure DevOps deployment.
Use a YAML pipeline to automatically trigger PR approvals or run on demand.
Manage service connections for different environments by using Azure DevOps groups.
On your critical environments, set up deployment approvals by using the service connection feature and Azure DevOps groups to assign specific user permissions in your team.
GitHub
You can do the following deployment activities in a GitHub deployment.
Use GitHub to create PRs or deployment activities.
Manage service principal credentials by using GitHub Secrets.
Integrate deployment approval through the workflow that's associated with GitHub.
Automatic deployment with Microsoft Sentinel infrastructure
You can deploy one or more Microsoft Sentinel environments, depending on your enterprise architecture:
Organizations that need multiple instances on their production environment can set up different subscriptions on the same tenant for each geographical location.
A centralized instance on the production environment provides access to one or more organizations on the same tenant.
Groups that need multiple environments like production, preproduction, integration, and so on can create and destroy them as needed.
Pricing
The cost of the solution depends on the following factors:
The volume of data that your company feeds into the Microsoft Sentinel Log Analytics workspace monthly
The commitment tier or billing method that you choose, like pay as you go (PAYG)
The retention rate of the data policies at a table or global level
To calculate pricing, see the Microsoft Sentinel pricing calculator. For more information on the advanced pricing considerations and examples, see Plan costs for Microsoft Sentinel..
You can incur additional costs if you extend your solution with the following components:
Playbooks - runtimes for Azure Logic Apps and Azure Functions. For more information, see Pricing details.
Exporting to external storage like Azure Data Explorer, Event Hubs, or an Azure Storage account.
A machine learning workspace and the compute that a Jupyter Notebook component uses.