Microsoft

Recently on the OWASP DevSlop Show, Teri Radichel and I performed a security assessment of the Azure implementation for DevSlop.co. We did it based on my previous blog post, Pentesting Azure — Thoughts on Security in Cloud Computing. You may want to read that article before you continue.

You can watch the video of the security assessment here. Subscribe to the DevSlop YouTube Channel for more awesome content like this!

“Because you can’t always blame Canada” — Teri and I causing trouble at a karaoke bar in Seattle

The first step to any PenTest is setting your Scope, Goals and Rules of Engagement for yourself and your client. You would restate this in your findings report, and you should always have a signed agreement from the client before you test anything.

 

Below is the scope of the testing and assessment that we did on the DevSlop show.

Scope: https://DevSlop.co, the DevSlopPatty Resource Group, the TANYA Azure Subscription (my subscription ID would be included in the doc). Nothing more.

Rules of engagement: Do not attack other tenants, or the Azure Service Fabric (that’s Microsoft’s underlying infrastructure that makes Azure). Some manual testing, some scanning, but mostly using Azure Security Center. Also: dates and times for testing.

Goals: Lock down DevSlop.co and my entire subscription.

Inform: We informed Azure that we were going to be performing security testing activities, and received acknowledgement before starting. **

 

** It is not mandatory that you inform Microsoft in advance of a PenTest, but for most other cloud providers you must ask permission. Informing Azure in advance of your testing takes 2 minutes, and may simplify your testing. Definitely worth doing.**

I’ve greatly improved my score since the test.

Executive summary:

Turn on all the security features in Azure Security Center (app whitelisting, file integrity monitoring), select a network security model and apply it (use network security groups), fix your VM security misconfigurations and keep patching it, address the 2 database VA (Vulnerability Assessment scan) findings, and consider getting a WAF (Web Application Firewall).

 

Risk Summary:

This Azure implementation (application + network + infrastructure) is very secure from an outsider-threat, as the application has had regular security testing and is using only known-to-be-secure and up to date components and frameworks. The subscription itself is also very secure from outside threats, thanks to the usage of Azure Security Center, a security policy, and the tight controls over subscription Access (MFA+ Difficult password + excellent password hygiene).

 

This system is not very safe from an insider-threat, assuming the malicious actor could gain access to the subscription. As only this subscription, not the “top level subscription”, was in scope, this was not investigated.

 

If the application was compromised it appears that the threat protection could potentially stop some types of attacks (SQL Server or Storage attacks only), and report on the damage after, however the protections against malicious attacks is not as substantial as it could be; multiple tools would be better.

Ifyou want to learn about about what we did to get these results, read the previous article: Pentesting Azure — Thoughts on Security in Cloud Computing. If you prefer to see what we did and follow along with us, watch the video. Better yet: do both.

 

PenTest Report — The Findings

A “+” indicates a pass, while a “X” indicates a fail of the test. Multiple “+” were used when a defense offers protection in multiple ways.

 

  1. Azure Security Centre (ASC) is turned on, with the default security policy.++
  2. MFA (Multi-Factor Authentication) is enabled for subscription access, use of a 64-bit random character that is saved into a password manager is one of the factors, the other is Microsoft’s Authenticator app, which requires not only physical access to and unlocking of a second device, it also requires a finger print. It could be argued that 3 factor auth is being used. +++
  3. ASC has 100% coverage of all subscriptions that were in scope of this assessment. +
  4. TANYA subscription was *not* compliant with the Azure Policy, earning a secure score of 340/580. (points are removed for each item below)
  5. JIT was enabled on the one VM in the subscription, properly configured +
  6. Threat Protection was enabled on all possible resources, properly configured. +
  7. Regularly VAs are enabled and schedule for the one database (+), however the database is not in compliance with VA results (X).
  8. There is no network security plan or model in place. X
  9. There are no Network Security Groups (NSGs). X
  10. Adaptive Application Controls (Application Whitelisting) is not enabled. X
  11. File Integrity Monitoring is not enabled. X
  12. DevSlop.co is not protected by a WAF (web app fire wall). X
  13. DevSlop.co forces HTTPS only on the app service. +
  14. There are no other security tools installed, such as IPS/IDS (intrusion prevention and detection systems), SIEM, or any other products or tools. X

Score: 10/17

No one outside of the DevSlop project team has permission to do testing on our site, DevSlop.co. If you want to test it, you must reach out to us and *ask permission*.

Database Specific Findings:

  1. Firewall rules not restrictive enough/non-existant X
  2. Using DB Owner privilege for an app that definitely does not require it (apply least privilege) X
  3. Sensitive data columns are not labelled properly X
  4. Regular VAs configured +
  5. Threat Protection & Detection Enabled +
  6. JIT enabled +
  7. Auditing and logging enabled +
  8. Database not internet accessible. +

5/8

 

Compute-Specific Findings (on one single VM):

  1. Missing disc encryption on server X
  2. 66 Critical security misconfigurations X
  3. 28 Warning security misconfigurations X
  4. JIT Configured +

1/4 (note: it does not list all the things we did correctly in this section)


You may think from this report that the security of the DevSlop.co Azure implementation (network + app + infrastructure) is not very good, but it’s actually not that bad at all. This report is aiming for perfection, and we are actually doing “okay”, especially considering our app doesn’t carry any real-world value. This is definitely something that would require an in-depth discussion on risk to explain further; perhaps a future blog post.

 

If you want to know more about Teri Radichel and cloud security you should read her blog, or hire her. You can also see her on the conference circuit at events such as B-Sides Vancouver in March, 2019 (I  will be there too!).


Please follow me on Twitter, on LinkedIn, and subscribe to this blog, watch the DevSlop show on Mixer, Twitch or subscribe and watch the reruns on YouTube. Thanks for reading!

 

** Special thanks to @sigje and Teri for helping with this post. They both have great blogs that you should definitely follow. I do.

1 Comment
New Contributor

I am currently required to enhance the security posture of two client in the Azure cloud space while developing their DevOps business project plan. I appreciate the article but had one question. Outside of pen testing, security essentials and security settings in the Azure and Office 365 blade, do you feel there are any other useful report mechanism to show the client their current security posture?

 

Thank you