Azure Security 101
- Databases/SQL Servers
- Blockchain
- Kubernetes Services
- VM Deployment/Dedicated Host
- Containers
- Developer tools like Visual Studio
- Git Repositories for projects
- AI and IOT management services
- Iaas – Infrastructure as a Service
- SaaS – Software as a service
- Paas – Platform as a Service
Azure Security 101
- Databases/SQL Servers
- Blockchain
- Kubernetes Services
- VM Deployment/Dedicated Host
- Containers
- Developer tools like Visual Studio
- Git Repositories for projects
- AI and IOT management services
- Iaas – Infrastructure as a Service
- SaaS – Software as a service
- Paas – Platform as a Service
Importance of Azure Security and Penetration Testing Guidelines
As of June 15, 2017, Microsoft no longer requires pre-approval to conduct a penetration test against Azure resources. However, the following activities are prohibited:
- Scanning or testing assets belonging to any other Microsoft Cloud customers.
- Gaining access to any data that is not wholly your own.
- Performing any kind of denial of service testing.
- Performing network intensive fuzzing against any asset except your Azure Virtual Machine.
- Performing automated testing of services that generates significant amounts of traffic.
- Deliberately accessing any other customer’s data.
- Moving beyond “proof of concept” repro steps for infrastructure execution issues (i.e. proving that you have sysadmin access with SQLi is acceptable, running xp_cmdshell is not).
- Attempting phishing or other social engineering attacks against Microsoft employees.
Scoping a PT with a cloud component is significantly more important. Since the central concept of cloud assessment is resource sharing, applications and resources might share IP addresses with other companies and organizations even government entities. Therefore, it is suggested that a more open approach be used in a cloud assessment with the following information provided:
- Target Subscription Identifier(s)
- IPs and hostnames of the services you are to target
- List of service types in the subscription and to which IPs they map
- The goals and desired outcome of the engagement
Importance of Azure Security and Penetration Testing Guidelines
As of June 15, 2017, Microsoft no longer requires pre-approval to conduct a penetration test against Azure resources. However, the following activities are prohibited:
- Scanning or testing assets belonging to any other Microsoft Cloud customers.
- Gaining access to any data that is not wholly your own.
- Performing any kind of denial of service testing.
- Performing network intensive fuzzing against any asset except your Azure Virtual Machine.
- Performing automated testing of services that generates significant amounts of traffic.
- Deliberately accessing any other customer’s data.
- Moving beyond “proof of concept” repro steps for infrastructure execution issues (i.e. proving that you have sysadmin access with SQLi is acceptable, running xp_cmdshell is not).
- Attempting phishing or other social engineering attacks against Microsoft employees.
- Target Subscription Identifier(s)
- IPs and hostnames of the services you are to target
- List of service types in the subscription and to which IPs they map
- The goals and desired outcome of the engagement
Azure Attacks
- Credential theft and elevation of privileges (admin or developer)
- Installing code to enable backdoors
- Gaining access to data and data resources (cloud resources)
- Azure subscription owners (top-level administration)
- Pivot attacks from on-premises to the public cloud
- Cloud resource compromises by hijacking or other exploitation
- Privilege elevation to move between subscriptions
- Public storage secret credential keys (GitHub)
- Misconfiguration of credential keys
- Imperva “man-in-the-cloud” token synchronized
- Side-channel code enablement
- Ransomware on cloud resources
SAS URI, can control what data to expose, and what permissions to put on those objects (SignedPermission), and for how long the SAS URI is valid (SignedExpiry).
Attackers are on the lookout for these keys which are accidentally leaked on GitHub.
Below are a few misconfigurations in access control that can leave a resource vulnerable:
- Failing to enable RBAC (Role based access control) and MFA for users
- Failing to enable encryption for data at rest
- Failing to monitor activity logs
- Exposing resources to the public Internet
- Not restricting access to Azure portal
- Failing to use NSGs (Network Security Group) properly
- Failing to update security patches in deployed resources
- Management certificates can be misused by an attacker if leaked online to authenticate to Azure Resources
Azure Attacks
- Credential theft and elevation of privileges (admin or developer)
- Installing code to enable backdoors
- Gaining access to data and data resources (cloud resources)
- Azure subscription owners (top-level administration)
- Pivot attacks from on-premises to the public cloud
- Cloud resource compromises by hijacking or other exploitation
- Privilege elevation to move between subscriptions
- Public storage secret credential keys (GitHub)
- Misconfiguration of credential keys
- Imperva “man-in-the-cloud” token synchronized
- Side-channel code enablement
- Ransomware on cloud resources
Once access is gained, attackers elevate privileges to gain administrator access and deploy ransomwares to encrypt critical files. You can always deploy Microsoft Defender with ATP on all virtual machines or computing resources deployed. Defender is also now supported on Linux operating systems.
Storage Account containers can contain config files, VHD (Virtual Hard Drives) files, PII can be exposed on the Internet by setting Public Access Level to Container Anonymous Read Access for containers and blobs.
An Azure storage account uses credentials containing an account name and a key. The key is auto-generated when the storage account is created and serves as a password to connect to Azure Storage. The Storage Access keys, by default, has all permissions and is similar to the root password of the storage account. Additionally, Azure provides Shared Access Signature (SAS) URI for granting fine-grained access to storage objects.
SAS URI, can control what data to expose, and what permissions to put on those objects (SignedPermission), and for how long the SAS URI is valid (SignedExpiry).
Attackers are on the lookout for these keys which are accidentally leaked on GitHub.
Below are a few misconfigurations in access control that can leave a resource vulnerable:
- Failing to enable RBAC (Role based access control) and MFA for users
- Failing to enable encryption for data at rest
- Failing to monitor activity logs
- Exposing resources to the public Internet
- Not restricting access to Azure portal
- Failing to use NSGs (Network Security Group) properly
- Failing to update security patches in deployed resources
- Management certificates can be misused by an attacker if leaked online to authenticate to Azure Resources
Azure Security Hardening
- Azure Resource Manager
- Require MFA for console users with API and command line access
- Azure Active Directory
- RBAC – Role Based Access Control
- Azure B2B
- Conditional Access / Risk Based Authentication
- AD Connect
- Application Management
- Security Monitoring, Alerts, and Machine Learning-based reports
- Consumer Identity and Access Management (CIAM)
- Privileged Identity Management (PIM)
- Cybersecurity Threat Monitoring and Analytics using Sentinel
- SOAR – Security Orchestration and Automated Response using Azure Apps
UDR – User Defined Routing on Azure Networks provides the ability to create pseudo network segments which enforces traffic to traverse the firewall even between servers on the same network.
- Control VM Access (Bastion Host – Jump Server)
- Secure Privileged Access using PIM or PWA
- Use Anti Malware Solution with Defender ATP
- Integrate Anti Malware Solution (Defender ATP) with Security Center
- Ensure current security updates are installed using SCCM
- Enable Encryption on VMs and enable VM Workload Protection
- Use just-in-time access to resources
- Network security groups on the subnet level should be enabled
- Internet-facing virtual machines should be protected with Network Security Groups and NGFWs
- Publish web services can be secured through a reverse proxy – Azure WAF or a commercial WAF
- Adaptive Network Hardening recommendations should be applied on Internet facing virtual machines
- Secure keys and passwords to secure PaaS deployment (secrets management)
- Authenticate through Azure Active Directory for App Services
- Use RBAC to assign permissions to user and groups in App Services
- Restrict incoming source IP addresses
- User secure key storage
- Use strong authentication and authorization platforms
- Enable Azure Monitor and Sentinel for Threat Monitoring
- Enable Azure adaptive network hardening
- Role-Based Access Control should be used to restrict access to a Kubernetes Service Cluster
- The Kubernetes Service should be upgraded to the latest Kubernetes version
- Deploy Azure Confidential Computing for Kubernetes
- Access to a Kubernetes service management API should be limited by authorizing specific IP ranges only
- Ensure SQL database is always encrypted using TDE
- Integration network and security cloud infrastructure into Sentinel
- Discover and control use of Shadow IT – integrate CASB with Sentinel
- Configure user risk policies for corporate and privileged users
- Integrate ATA with Sentinel for advance threat monitoring against Domain Controllers
- Configure sign-in risk policy for all users with MFA
- Integrate Security Center alerts with Sentinel SIEM solution
- Configure Windows Azure Diagnostic Agent on the VMs to push logs to Sentinel
- Collect OS security events, Application Audit Events and IIS logs to Sentinel
- Perform Threat Modeling
- Use the built-in rules for MITRE ATT&CK model
- Integrate Endpoint Security Logs (Defender)
- Integrate Azure DDoS protection sensor with Sentinel
DTS Solution can help you secure your Azure Cloud Deployment.
Get in touch to discuss with our Cloud Security Experts.
Azure Security Hardening
- Azure Resource Manager
- Require MFA for console users with API and command line access
- Azure Active Directory
- RBAC – Role Based Access Control
- Azure B2B
- Conditional Access / Risk Based Authentication
- AD Connect
- Application Management
- Security Monitoring, Alerts, and Machine Learning-based reports
- Consumer Identity and Access Management (CIAM)
- Privileged Identity Management (PIM)
- Cybersecurity Threat Monitoring and Analytics using Sentinel
- SOAR – Security Orchestration and Automated Response using Azure Apps
- Control VM Access (Bastion Host – Jump Server)
- Secure Privileged Access using PIM or PWA
- Use Anti Malware Solution with Defender ATP
- Integrate Anti Malware Solution (Defender ATP) with Security Center
- Ensure current security updates are installed using SCCM
- Enable Encryption on VMs and enable VM Workload Protection
- Use just-in-time access to resources
- Network security groups on the subnet level should be enabled
- Internet-facing virtual machines should be protected with Network Security Groups and NGFWs
- Publish web services can be secured through a reverse proxy – Azure WAF or a commercial WAF
- Adaptive Network Hardening recommendations should be applied on Internet facing virtual machines
- Secure keys and passwords to secure PaaS deployment (secrets management)
- Authenticate through Azure Active Directory for App Services
- Use RBAC to assign permissions to user and groups in App Services
- Restrict incoming source IP addresses
- User secure key storage
- Use strong authentication and authorization platforms
- Enable Azure Monitor and Sentinel for Threat Monitoring
- Enable Azure adaptive network hardening
- Role-Based Access Control should be used to restrict access to a Kubernetes Service Cluster
- The Kubernetes Service should be upgraded to the latest Kubernetes version
- Deploy Azure Confidential Computing for Kubernetes
- Access to a Kubernetes service management API should be limited by authorizing specific IP ranges only
- Ensure SQL database is always encrypted using TDE
- Integration network and security cloud infrastructure into Sentinel
- Discover and control use of Shadow IT – integrate CASB with Sentinel
- Configure user risk policies for corporate and privileged users
- Integrate ATA with Sentinel for advance threat monitoring against Domain Controllers
- Configure sign-in risk policy for all users with MFA
- Integrate Security Center alerts with Sentinel SIEM solution
- Configure Windows Azure Diagnostic Agent on the VMs to push logs to Sentinel
- Collect OS security events, Application Audit Events and IIS logs to Sentinel
- Perform Threat Modeling
- Use the built-in rules for MITRE ATT&CK model
- Integrate Endpoint Security Logs (Defender)
- Integrate Azure DDoS protection sensor with Sentinel
DTS Solution can help you secure your Azure Cloud Deployment.
Get in touch to discuss with our Cloud Security Experts.
See also: