What I learned by failing the AZ-500 Microsoft Azure Security Technologies exam

This morning I sat for, and failed, the AZ-500 Security exam.

Let me share the first thing I learned, which I learned well before this exam and over the course of nearly 15 years in Cybersecurity/IT and after roughly 20 certifications. You can't tie your self-worth up in the result of the exam. Failing sucks, no doubt about it. The hours spent studying, videos, reading, labs, practice exams and more. However, the result of the exam isn't a reflection of you as an individual or even what you bring to an organization from an employment and competence perspective. While certifications can help with resumes, applying to roles and feel good to pass, our ultimate goal of pursuing them is and should be the obtainment of knowledge related to the technology/area of expertise to make us better professionals.

Certification exams can be fickle, tedious, full of gotchas, nuanced details and downright frustrating. That is part of the territory. This one was no different. There were complex scenarios, multiple tabs, many multi-choice questions and more.

I went into this exam with a desire to expand my knowledge of Azure, after several years of deep work with AWS, holding 8 AWS certifications, all of their Associate/Professional certifications and the Security and Networking exams as well. Let me say, there is a lot of overlap with AWS and Azure and you'll see me reference it throughout this article. That said, there are also a lot of differences. AWS is still the market leader of Cloud and by quite a bit. That said, Azure is gaining market share gradually so it is nice to be diversified as a Cloud security professional and have a baseline level of competence with more than one CSP, as it is likely you will certainly encounter several CSP's in your professional activities.

Preparation was tough, through Thanksgiving/Christmas and everything else. I initially tried to take the exam from home but Pearson Vue's software "OnVue" crashed on me, so I had to reschedule and I selected in-person this time. That was a unique experience of its own, including masks, latex gloves during testing and everything else you would expect during a pandemic.

What I learned throughout the studies

IAM/Authentication

• Azure utilizes a variety of methods to support both Cloud-native and hybrid identity solutions. This includes strictly Cloud-based AD referred to as Azure Active Directory (AD), with no reach back to an on-premise IdP. There's Azure AD Connect, which you can use various options such as Azure AD Pass-through Authentication, which allows you to utilize on-premise agents and pass your users request back to the on-premise environment for authentication, which helps to enforce corporate authentication and account policies/requirements. There's also password hash synchronization which helps accomplish hybrid identity by using Azure AD Connect to synchronize a hash of the hash (yes, you read that correctly) of the users password from on-prem AD to the cloud-based Azure AD instance. Pass-through authentication is for organizations with more rigorous security requirements who do not want authentication occurring in the Cloud and/or aren't comfortable with a hash of a hash being stored in the Cloud as well. Lastly, there's Federation, which is the most robust of the options but also the most demanding, requiring the most infrastructure to support. This option also helps support unique use-cases such as smart card authentication. You can also utilize a synchronization rules editor to determine what characteristics are actually synchronized from on-prem to the Cloud. If you're looking for SSO, you can implement Azure AD SSO, which helps automatically sign users in when they are on specific devices connected to your corporate network. This streamlines authentication and user experience (but of course could be risky).
• If you're looking to eliminate the challenge of developers managing secrets/credentials between services you can utilize Azure Managed Identities, which provides an identity for the Azure resource in Azure AD, allowing it to obtain Azure AD tokens. It essentially provides Azure services with managed identities in Azure AD automatically.
• Azure Conditional Access is a very powerful tool to help add context to your users access. It utilizes signals to help makes decisions, such as allowing full access, required increased assurance, allowing limited access, or even blocking access. Signals can be things such as User and Location, Device, Application and Risk. You can allow access, require additional assurance (e.g. MFA), allow limited access to a subset of resources/applications or block access entirely.
• Azure Privileged Identity Management (PIM) is used to provide time-based/approval-based role activation to help mitigate risks of excessive, unnecessary or misused access permissions. It does this through Just-in-Time (JIT) access. This means ports aren't left open indefinitely and users don't have constant access to resources or environments. Instead connections can be allowed and time-bound with start and end dates/times. You can also require approval prior to activating roles. You can enforce MFA, and force users to provide justifications when roles are activated. You can (and should!) also perform access reviews to ensure users still need roles they're able to assume (don't let stagnant access come back to bite you later).
• Azure Identity Protection is great for automating the detection/remediation of ID based risks. You can also use it to investigate risks in the portal or export risk detection data to 3rd party utilities/tools for analysis. This helps identify risky users, sign-ins and risk detections. It categorizes risks into levels, and includes detections for items such as atypical travel, anonymous IP and more.
• Governance - Much like AWS's Organizations, OU's etc. Azure utilizes a governance construct that is hierarchical. This includes Management Groups, Subscriptions, Resource Groups and lastly, resources themselves. You can push policies at specific levels and allow flow-down/inheritance of these policies and locks etc. Think in how AWS you would utilize SCP's to set constraints such as what actions can be taken, what size/type of resources can be provisioned. You can do the same with Azure policies.

Network Security

• Azure utilizes many similar constructs to AWS in this regard. Unlike VPC's, they have Virtual Networks, or VNETs. They allow VNET peering both within and across regions, with latency impacts of course when peering across regions. You can implement Network Security Groups (much like AWS Security Groups) to restrict the flow of traffic within your subnets and VM's. They generally have default rules, such as allowing traffic among resources within the VNET, from Load Balancers and outbound to the Internet.
• You can utilize Azure Firewall, which is a managed cloud-based network security service to protection your VNET resources. It is fully stateful and has built-in high availability and scalability. This lets you centrally enforce and log app/network traffic and connectivity across subscriptions and VNETs.

• There is also firewalls for resources, such as Storage and Key Vaults. This lets you secure/control the level of access based on the type and subset of networks used. You can configure network rules to allow only apps you approve over specific sets of networks/IP's etc. access your resources.
• Azure Service Endpoints provide secure/direct connectivity to Azure services over optimized routes on the Azure backbone network. (sound familiar to AWS VPC Endpoints?)
• There's also Azure Private Endpoints that create a NIC via Private Link (think AWS Private Link) which allows you to use private IP's from your VNET, basically bringing the service into your VNET.
• Much like AWS VPN, Direct Connect etc. there's Azure VPN and Azure Express Route for connecting bespoke networks, either VPN or dedicated connections depending on your connection and security requirements.

Endpoint Protection

• There's a whole slew of endpoint protection capabilities, much of which are baked in to Azure Security Center (incredibly powerful service) to help manage things such as Antimalware, Updates and more.

Azure Resource Security

• As mentioned before, Azure resources are organized into constructs called Resource Groups, Subscriptions and even Management Groups. You can utilize Resource Locks on resources to set resources (or the constructs they reside in mentioned above) to either Read-Only, or CanNotDelete. Read-only means just that, you can't modify the resource in any way, this includes if new resources get added to a RG post-lock implementation. You can also implement a CanNotDelete, which allows the provisioning of new resources etc. but stops any deletions. These can help for legal purposes or also simply governance and mistakes.
• Azure Compliance Manager is very promising. This service lets you get visibility in how your environment and workloads align with policies you put in place. These can be Azure managed policies or policies you have created on your own. They include templates for common frameworks such as GDPR and ISO 27001:2013 and NIST 800-53. They are also working on 800-171/CMMC templates, be sure to check out their CMMC Accelerator offerings (I'm talking to you DoD Defense Industrial Base).
• Azure of course has Container and Kubernetes offerings, much like AWS's EKS/ECR there is ACR and AKS. I can't say the offerings are comparable in maturity but it is there. You can manage registry, instance and container security as well as security for AKS.

Azure Key Vault

• I can't stress the importance of this service enough. It is critical to understand for Azure when it comes to secrets and key management. You want to know how it is scoped across Resource Groups and Regions. You also want to understand how you govern access to it. This includes RBAC for Management Plane activity (think control plane activities such as modifying vaults etc.) and Data Plane access, which is governed by Access Policies (think who can access the keys and what actions they can perform with them).

Encryption

• Azure of course supports encryption of data, both at-rest and in transit. It is done via keys/certificates, all of which is supported by Azure Key Vault. There are also some neat features for Azure SQL, such as Always Encrypted which involves Column and Database Master Keys. You can encrypt disks via Azure Disk Encryption and your backups as well. Given how important it is to secure your data when using Cloud, Azure Key Vault is absolutely critical to master in this regard and manage appropriately.

Automation/IaC

• Much like AWS Cloudformation, Azure offers Azure ARM Templates and Blueprints. These are incredibly powerful IaC options that come with all of the usual IaC benefits of versioning, governance, etc.

Study Resources

• AZ 500 Study Guide (https://www.amazon.com/AZ-500-Microsoft-Azure-Security-Technologies/dp/0136788939/ref=sr_1_2?dchild=1&keywords=az+500+study+guide&qid=1609436450&sr=8-2)
• Great AZ 500 Exam Study Guide mapped to exam objectives (https://ravikirans.com/az-500-azure-exam-study-guide/)
• Two-part video that covers a lot of the key topics (https://www.youtube.com/watch?v=_EfMWEkFq9I)
• ACloudGuru AZ 500 Course
• Udemy AZ 500 Course
• WhizLabs Practice Exams

Anyways, that's enough for now. These are some of the key things at the top of my mind and that stick with me. It was a great learning experience and I certainly feel more confident in my understanding of securing workloads in Azure than I did prior to this endeavor. I can't say that I will re-take the exam again or not, but I hope this knowledge helps those who will!.

Happy New Year all!