What do you do when you're handed a pile of new-to-you Azure accounts to secure?
There's some security measures rolled out to some accounts, and lots of works-in-progress. You have limited resources, and you know you should focus on things that will reduce the most risk in the least amount of time, but how do you know what that is?
Well, Scott Piper published an excellent AWS Security Maturity Roadmap, which you should check out, but (and maybe you saw this coming) that's for AWS, not Azure. With Scott's permission, I borrowed heavily from his example and translated his AWS roadmap to the security capabilities in Azure.
This is just a guide, and feel free to use it however you'd like. I'd recommend you spend some time at each step, doing the best you can to make it true for all your Azure accounts. Don't sweat it if your business needs you to skip ahead or shuffle things a little bit. But if you don't have an inventory yet and you're being asked to do purple team exercises and threat intelligence, well, maybe it's best to start at the beginning.
- Identify all Azure subscriptions and have point of contact for each.
- Organize subscriptions into Azure Management Groups.
- Security team has their own subscriptions (at least dev and prod).
- Azure Platform Logs are going to some sort of SIEM.
- Security team has access to a Security Reader Azure RBAC role.
- There’s a paved path for provisioning new accounts that includes the above capabilities (Management Group, Platform Logs, Security Reader, etc).
- One-time security scan of subscriptions to identify tactical remediations.
- Azure Security Center is enabled in all subscriptions; findings are triaged by an on-call team.
- Security teams have documentation and training for log-based incident response investigation.
- There’s periodic / continuous security scanning of environments.
- Control plane audit logs are going to some sort of SIEM (AKS, Container Registry, ...).
- Containers / host OS send run-time telemetry to some sort of SIEM.
- There’s a framework for writing detection engineering alerts, and we have some alerts written.
- Go through Azure Identity Management security best practices.
- Azure RBAC roles are scoped to jobs-to-be-done (it’s okay for one person to have access to multiple roles); access is periodically reviewed.
- Do a one-time audit of RBAC roles in production to look for opportunities to scope down to least privilege.
- Secrets access is scoped and auditable (strongly recommend Azure Key Vault).
- Resources that don’t need public IP addresses should not have them (even if they have firewalls in place): application servers, data stores, etc.
- Use Azure Policy to enforce organizational security policies.
- Harden build environment: ephemeral instances, restrict network egress, sign build artifacts, verify signatures before deploy.
- Use Infrastructure as Code.
- Create hardened base images and drive adoption.
- Consider using Azure Resource Tagging to aid ownership tracking.
- Build out detection engineering alerts further.
- Implement automatic remediation for common incidents.
- Systematize developing least privilege RBAC policies.
- Move everything you can to private networks.
- Segment network for services that don’t need to talk to each other.
- Restrict egress network traffic.
- Practice responding to incident scenarios (like compromised user accounts).
- Develop forensics for traditional VM workloads as well as orchestrated and container workloads.
Good luck! We're rooting for you.