Microsoft’s Azure App Service is a fully managed platform as a service for developers that provides features and frameworks to quickly and easily build apps for any platform and any device. Despite the ease of using Azure, developers need to keep security in mind because Azure will not take care of every aspect of security. In our first post on this topic, we learned how to configure custom domain names and certificates for web applications developed using Azure. In our second post, we learned how to enforce HTTPS for web applications developed using Azure. In our third post, we examined application settings in Azure that can increase the security and availability of a web application. In our fourth post, we learned how to configure logging and monitor the application traffic from within the Azure portal.
This is the final post of this series. Today, we will see how to run penetration testing of applications built using Azure.
Security in the Azure cloud is the collective responsibility of Microsoft and the application owner. Microsoft takes care of the operating system and infrastructure security, but application security lies with the application owner. Penetration testing is a great way to evaluate the security of an application in real time because the approach is similar to the one followed by an attacker.
Penetration testing requires approval
Before conducting any penetration test, prior approval is required from Microsoft. Fill in this form: https://security-forms.azure.com/penetration-testing
Penetration testing approval requests take some time to process; we recommend you submit a request at least seven days in advance.
Completing the form
Let’s fill in the penetration testing form. An example follows.
- Azure portal login email: The address used to create the Azure account.
- Azure Subscription ID: Your Azure ID.
- Contact name, email address, and phone number: Point of contact from your organization.
- Is test being performed by third party: In the majority of the cases this will be true.
If the testing is done by an internal team and not by third party, skip the following section. The following details will not be asked:
- Name of third party
- Contact name, phone number, and email address
Next we take the following steps:
- Requested start date: Penetration test start date.
- Requested end date: Penetration test end date. An extension of the end date is allowed but is subject to a new authorization from Microsoft.
- Detailed description of test: You can enter tools used and tests performed. If testing is done by a third party, include their methodology and tools. These might be present in the rules of engagement.
- Listing of IP addresses and DNS names from where the tests will originate: If testing is done by a third party, then list all the IP addresses the third party will use. If an internal team does the testing, provide all your IP addresses. If testing is done from any IP not listed here, Microsoft will block that IP, so it is necessary to ensure all testing IPs are listed.
- Tested Resources: List each resource that you want to test:
- — Resource type: “website” in this case.
- — Azure DNS name of resource: Make sure you provide the Azure DNS name and not your website DNS name. It will be something like <app-name>.azurewebsites.net.
- — Description of test performed on resource: Enter a brief test summary, for example, “OWASP top 10, fuzz testing on my resource, port scanning on my resource.”
- — Tooling or utilities to be used on resource: List all major tools used during testing. If testing is done by a third party, get their list.
Things to not do:
- Denial of service (DoS) attack; Do not initiate a DoS attack, or perform related tests that might determine, demonstrate, or simulate any type of DoS attack. To avoid a DoS attack, do not run your scanner beyond your subscribed bandwidth. If a third party is doing the testing, make them aware of your subscribed bandwidth and plan. Throttle down the number of threads to just a few when performing automated scanning.
- Test only the resource for which authorization is granted. No other resource should be tested.
Read all the penetration testing terms and conditions before submitting your penetration testing request.
If during the course of testing, you discover a potential security flaw related to Azure or any other Microsoft service, report it to Microsoft within 24 hours by following the instructions. Do not disclose this information publicly or to any third party for at least 90 days. Reporting the security flaw may qualify for the Bug Bounty; refer to the Bug Bounty Terms.
The post Security Best Practices for Azure App Service Web Apps, Part 5 appeared first on McAfee.