In a previous blog, I discussed securing AWS management configurations by combating 6 common threats with a focus on using both the Center for Internet Security Amazon Web Services Foundations benchmark policy along with general security best practices.
Now I’d like to do the same thing for Microsoft Azure, but unfortunately as of this writing, CIS hasn’t published a benchmark policy for Azure. Fortunately, many of the cloud security fundamentals we discussed also apply to Microsoft Azure. Now we’re going to use that best practice cloud security knowledge we learned from the last blog and apply it to Microsoft Azure.
Like before, it’s crucial that multi-factor futhentication is being used wherever possible in order to combat attacks from phishing and lost or compromised credentials. At a minimum, any Azure Active Directory User with an administrative role or the ability to create and alter resources should have multi-factor enabled. Enable password policy settings to ensure complex passwords.
It’s easy to lose track of which permissions exist within custom roles. Audit any custom role definitions to ensure that none contain unnecessary administrative permissions that could be instead assigned via default roles.
Ensure that no unneeded guest users are created in the Azure Active Directory. For any that are necessary, ensure that the user setting for limiting guest permissions is set as well as the setting to not allow guests to invite additional users.
If you are using Active Directory Federation Services in order to allow a user to sign into Azure-AD based services with their on-premises password, it is critical that you are also auditing your on-premises Active Directory for security and compliance with vulnerability assessment and monitoring tools.
The Security Center
A number of security features are available within the Microsoft Azure Security Center for us to take advantage of, and Microsoft has automated the discovery and implementation of a good deal of it.
It is important to enable virtual machine security data collection by default via the automatic provisioning of monitoring agent function. Once the monitoring agent is enabled, you should ensure that all recommendation settings in the security policy are enabled. These recommendations cover a myriad of security settings, such as when operating system patches are required or when encryption has not been enabled.
You should make a habit of reviewing the Recommendations tab within the Security Center blade in order to ensure no active security tasks exist and that any recommendations have been considered and implemented where possible.
Ensure that a current security contact email and phone number have been set in the Security Center Policy. This ensures that Microsoft has an accurate contact within your organization for any security related incidents.
Lastly, consider upgrading from the Free Azure security tier to the Standard tier for enhanced security options. This does come at a cost, but it allows threat detection on virtual machines and databases.
It’s critical to limit exposure to brute force attacks by limiting access to ssh and rdp in your Network Security Groups. This advice is the same no matter the platform; don’t open ports 22 or 3389 to the open internet.
If you are running Microsoft SQL Server, there is a separate SQL Server Firewall mechanism that exists outside of the Network Security Groups function. You should audit the SQL Server Firewall to ensure that you have not allowed access to the open internet or to network blocks that do not require access.
It still makes sense to make use of operating system firewalls within virtual machines to provide defense in depth in case of accidental Network Security Group misconfiguration or a platform error.
It is also a good idea to perform vulnerability scans against your infrastructure. These can be done without notifying Microsoft as long as they follow the Pentest Rules of Engagement. You can assess your Azure infrastructure for network- and host-based vulnerabilities with a vulnerability management product like Tripwire IP360.
There are multiple Logging capabilities within Microsoft Azure, and it is important to utilize them for security auditing and compliance.
Ensure that you have enabled Activity Log storage, which we will further use to create monitoring alerts for various behaviors. (See below.)
Additionally, each Network Security Group should have flow logging enabled, and each SQL Server Database should have database auditing enabled.
Each of these logging capabilities utilizes a storage account. For each logging function, you should create a storage account that is encrypted at rest via the “Storage Service Encryption” setting and in transit via the “Secure Transfer Required” setting.
It also recommended that you enable log storage retention for greater than 90 days or set retention to unlimited if possible for each logging case.
The Activity Log enables us to perform monitoring for a variety of security relevant events. Alerts allow us to ensure that the appropriate parties are notified of behavior that could be suspicious if it has not been approved, such as the changing of security settings.
Activity Log Alerts should be created for the following events:
- Create Policy Assignment
- Create or Update Network Security Group
- Delete Network Security Group
- Create or Update Network Security Group Rule
- Delete Network Security Group Rule
- Create or Update SQL Server Firewall Rule
- Delete SQL Server Firewall Rule
- Create or Update Security Solution
- Delete Security Solution
- Update Security Policy
We previously mentioned ensuring that logs are stored in storage accounts with SSL and Disk Encryption. Where possible, you should configure every storage account to use blob encryption, file encryption, and secure transfer.
Storage Account keys should be periodically regenerated to mitigate the risk of compromised access keys.
Shared Access Signatures should be used only with secure transfer and should have expiration times of 8 hours or less so that access is not granted indefinitely.
Any public access of Blob or File containers should be carefully audited to ensure it is only used in cases such as public web sites.
One unique facet of Azure virtual machine security is the virtual machine agent that gathers security data as mentioned above. Keeping the agent running ensures a proper overview of your assets.
However most importantly, securing virtual machines in the cloud works much the same as on the premises and has been discussed at length. Ensure you have the latest operating system and software patches and are running endpoint protection. Ensure you are using disk encryption to encrypt files at rest in case of storage compromise.
Microsoft SQL Server
Finally, one of the main selling points of Azure is the integration with Microsoft SQL Server. At a minimum, it is important to set your SQL Server Firewall with the tightest policy possible and to enable audit logs for insight into security breaches or possible misuse of information.
The Microsoft SQL Server threat detection capability within Azure can detect SQL injection, SQL injection vulnerabilities, and other anomalies. This is a paid feature, but it can enable further defense in depth and should be enabled if possible. Ensure that you are sending alerts to a security contact and service owners if you do enable threat detection.
This best practice advice is a baseline that applies to any project implemented within Microsoft Azure and can be expanded on and tailored to individual installations.
Tripwire has recently released version 2.0 of the Cloud Management Assessor, an integration for Tripwire Enterprise which helps you determine the security state of your Microsoft Azure or Amazon Web Services deployments by collecting and analyzing Azure configuration data. You can monitor your AWS or Azure Resource Manager for configuration changes right alongside the security monitoring of cloud and on-premises assets.