Pentesting Azure — Thoughts on Security in Cloud Computing
Below I share with you these pre-book thoughts, and will compare them in a future article with the ones I will learn — or confirm — after reading Matt's book.
Original on medium
So here goes the list of thoughts on Azure security that I had before reading Matt’s book. Feel free to comment below about other things Azure users should be checking to ensure their Azure deployment is secure.
- Do not test the Azure Infrastructure. That is violation of the user agreement for Azure and will get you into hot water with Microsoft. No one wants that.
- Be extremely careful to only test things that are IN SCOPE for your client.
- Is Azure Security Center turned on? If not, turn it on. I ASC.
- Do all subscriptions/sub-subscriptions have it on? Do you have complete coverage? If not, definitely report it.
- Is there a policy set (settings that the org has chosen as “secure”, such as all storage must be encrypted at rest)? If so, what are the settings? Do they look good? Also, what level of compliance do they have? Everything that is not compliant should be reported.
- Is threat protection (storage and databases only), monitoring and auditing set up on every possible resource? If not, report it.
- Look at the network, in the same way you would look at a traditional network, is anything out of place? Also, are they doing Zoning or Zero-trust or something else? Which network security model are they using? Make sure they are compliant with their own plan. Ask them what their plan is for their network to start. If they don’t have an answer, that’s another issue altogether.
- Do they have “just in time” (JIT) set up on all ports on all servers/VMs? Or are they using a JumpBox to access VMs from outside Azure? Or is that not allowed at all? They should use JIT and Network Security Groups (NSGs)for *everything*.
- Do they have app whitelisting enabled on VMs? It’s called Adaptive Application Controls, and it’s right underneath JIT in the security center (ASC) menu, under “Advanced Cloud Defense”. They should have that turned on for *all* servers.
- Are they using a SIEM (Security incident and event management system)? Are they using it well? Are they monitoring it? What kind of coverage is it getting? Does ASC feed into it? It should.
- Are they using a WAF (Web Application Firewall)? If so, test it. If they aren’t, mark it as advice for improvement.
- Any other 3rd party security tools (IPS/IDS/HIPS/Other)? If so, are those getting complete coverage of all assets that are covered by this test? And are they configured well?
- Look in “Recommendations” tab of Azure Security Center and it will tell you all the problems (network issues, config errors, missing patches, more) that you haven’t spotted yet. Really, you could likely start here. This is a list of everything that is not compliant with your policy, in order of importance.
- If you are assessing web apps within Azure, APIs and functions (serverless), that’s a whole other topic, but all of the regular security testing rules would apply, Azure or not.
- If your org is using Azure DevOps I suggest adding several security tests to your pipeline including Azure Secure DevOps Kit. It’s strict; you likely won’t pass the first few times around, so prepare your developers for a bit of disappointment. There are a TON of great security tools in the Azure Marketplace, add a few, one is not enough.
- Turn on VA for SQL DataBases as part of the Azure Threat Protection, and kick off a scan right away to see if anything is happening. It will likely had a lot of advice for you.
- Look in the Threat Detection part of Security Centre, verify that there are no active attacks happening or recent ones, investigate accordingly.
Stay tuned for more (and likely better) advice after I read Matt Burrough’s book!