"Identity is the New Security Perimeter" is a great tagline, but what does it really mean? Recently, a colleague and I were working with a client on a security assessment of their existing Azure implementation. They had built some data and analytics implementations along with a few web sites and wanted to check how they were doing.
We tackle these security projects in a multi-phase approach:
This client, as with many, had predominately defined their security practices based on a network perimeter approach, rather than a more cloud approach - identity based security perimeter. The Microsoft Security guidance provides a lot of great information, as does the Microsoft Cloud Adoption Framework (CAF), but consuming it and more importantly making it actionable is difficult and often overwhelming. Some of the best practices that relate to identity as a perimeter are split across multiple CAF disciplines. Identity as the security perimeter is not a new concept, but what does this really mean at a tactical level?
Let’s look at some examples:
Centralizing your identity management- this is typically Active Directory. Multi Factor Authentication (MFA) is another obvious choice and provides a great level of additional security. Combine MFA with Conditional Access Policies and now you can ease the end-user impact of MFA based on where the user is accessing from. So, these examples are ones where we are making sure the user is who we think they are.
Password strength - force users to create complex passwords. However, there are several things to consider: first even though P@ssWord1! Might meet your complexity requirements, it is a well know example. So, do you compare your users’ passwords to known lists of easy passwords to break? Do you have a tool for Risky Password detection?
But what about thinking a bit more strategically, for example, do you sync to Azure AD your domain admin accounts? We do not like this practice, we think of it as an anti-pattern, if the domain admin accounts are compromised on the cloud, the hacker now has the ability to attack your on-premises domain. This represents a lateral move threat to your environment.
Privilege Identity Management (PIM)- Are you using PIM? PIM allows users to request elevated rights, for example global admin, for a period of time and forces the user to provide a reason for the elevation. Once the request is made, other admins and the user are notified that the user has requested elevated rights. This is a huge security win as it allows other users to know when an administrative action is taking place, by whom, and it starts before there is an issue and you have to traverse the logs to find who may have done what. If the user's account has been compromised without their knowledge the email notification will provide an opportunity for this to be detected.
Unusual user activity - Another situation you need to consider for identity as the perimeter is looking for unusual user activity. This could be in the form of logging in from an unusual location, or perhaps doing unusual activities; this is especially true if you are using Office 365. For example, if a user deletes a large number of files, this could be valid user activity, or it could be an indication that the users account has been compromised. Using tools such as Cloud App Security and Sentinel can enable your security team to quickly spot these breaches.
PaaS applications- are you using Azure Key Vault to store secrets such as connection strings, usernames and passwords? By Using Key Vault, you can separate the knowledge of the username and password for a database from the administration of the database, from the developer or even the user deploying the application.
As you can see, it’s not just about making sure passwords are complex, there are many aspects to Identity as a Security Perimeter. When we engage with a customer to work through a security review, we use a spreadsheet that tracks security best practices for all aspects of the Cloud Adoption Framework, we then track the number of Azure resources that are impacted by the best practice, and the number of those resources that are compliant. Additionally, we tag the best practices with useful meta information such as NIST Controls or other industry specific controls. This helps our clients get a handle on how they are doing with compliance as well.
If remediation is required, we will either outline the process, or provide detailed steps to remediate, along with a rough estimate of our time. This enables us to provide our clients with a score card of how they are doing with security, where they need to improve, and a rough number of hours to complete. We present this score card using a Power BI dashboard. To help our clients consume the best practices in a visual way, we create a Mind Map that maps out the best practices so that they can more easily see which best practices relate to which aspects of security.
Below is an example of our Best Practices scorecard. Green denotes that the client is doing well in that aspect.
This is an example Mind Map we use for security best practices:
An alternate view structures the information based on Cloud Adoption Framework discipline.
Interested in learning more or have any questions? Contact us today!