Microsoft Azure, a popular cloud service used by businesses for their products and services, has come under the brunt of an increasing number of cyberattacks, especially in today’s scenario of significant dependence on digitization. Therefore, Azure penetration tests are crucial and are recommended by Microsoft itself to stay a step ahead of hackers.
Called the ‘Assume Breach’ stand, users are recommended to form red and blue teams for testing the security resilience of the cloud infrastructure, systems, and other assets. Pentesting the Azure cloud services allows the duplication of the production environment for more efficient testing. This also ensures that firms utilizing Azure services are able to detect and resolve security vulnerabilities before they lead to cyberattacks.
What should you keep in mind for an Azure penetration test?
Microsoft has certain rules of engagement that limits aspects such as the types of penetration testing procedures, assets under testing, etc within the Azure environment. Here are some of them:
Types of pentesting procedures
Microsoft Azure has a list of allowed pentesting procedures for Azure assets. Some of these are testing for the vulnerabilities mentioned in the OWASP Top Ten Vulnerabilities in applications , endpoint port scanning that looks for unnecessary or loopholes in open ports, and endpoint fuzz testing that tests inputs from the saas application to detect security risks or coding flaws.
The Assume Breach methodology
This methodology includes methods and security measures tried and tested by the Azure team and are recommended to the users as well. These security steps focus on possible attacks, detecting intrusions, recovery periods after attacks, system response to hacks, and prevention of future compromising situations. The main goal of the entire procedure is to reduce the mean time to detection (MTTD) and mean time to recovery (MTTR).
Red and Blue teams
As the colours may suggest, the red team of ethical hackers takes up the offensive while the blue team responds to these attacks with the help of the IT team of the organization. The red team keeps launching attacks against the cloud-based assets and services, focusing exclusively on these and not on the data of endpoint customers. The blue team builds barriers against these attacks with innovative practices and tools, keeping on alert 24/7 to respond against unanticipated attacks.
The responsibilities of the blue team in these activities also include the collection of data indicating compromised systems, prioritize alerts according to criticality, prepare plans for mitigation, notify respective authorities, and protect affected systems.
After the end of the attack, the red and blue teams come together to analyze the attack and evaluate the response strength. This will include crucial details such as where and how the attack happened, the compromised systems and assets, the extent of successful threat eradication, and recovery.
Prohibited activities
The defined rules of engagement clearly demarcate the aspects of the Azure environment and the tools for testing:
- Conducting tests that show fake increases in traffic for an application, such as Denial of Service (DoS) or brute force attacks
- Breaching the personal assets of other customers on the Microsoft Azure cloud
- Acting on the results from the proof of concept (POC) stage of pentesting, such as gaining the root access to a system but not being able to execute any commands
- Forced access to foreign data that’s not a part of your business
- Any kind of testing that require large amounts of network bandwidth except on your own virtual machines (VMs)
- Attacks targeting Microsoft employees such as phishing or social engineering
- Failure to adhere to the ‘Acceptable Use’ policy
Allowed Activities
Here are the permitted rules of engagement according to Microsoft Azure:
- Checking application load through traffic generation expected from a typical business process such as surge tests
- Finding loopholes in Azure service containers such as Azure Functions – if successfully breached, this should be reported to Microsoft and access rights gained from this should not be utilized
- Using test accounts or tenants to check access and data transfer between two parties
- Running vulnerability scanning for your own Azure VMs
- Checking security monitoring capabilities through the generation of suspicious activities on the log
- Testing available restrictions in Mobile Application Management (MAM) and other policies that provide conditional access
Like all penetration testing procedures, Azure penetration tests also help firms to remain ahead of hackers and detect vulnerabilities for their quick remediation. The ‘Assume Breach’ methodology is successful in this sense as it encourages Azure users to predict attacks by using teams of ethical hackers for attacking and protecting the systems. There are a number of tools available to assist in the process such as PowerZure and Stormspotter that help in collecting information about the system and initiating specialized attacks to know the system better.
In this manner, it’s always better to go prepared in terms of what to expect from an Azure penetration procedure for optimal results and protection.