Cloud providers have amazing security protection and controls. Microsoft recently offered $300,000 for hackers to ‘do your worst’. (https://devclass.com/2019/08/06/microsoft-waves-300000-at-hackers-says-do-your-worst-to-azure-security-lab/). They are putting their money where their mouth is.
Google rewarded 3.4 million in 2018 for security bug reporting. (https://9to5google.com/2019/02/08/google-vulnerability-reward-program-2018/)
At this time it doesn’t appear Amazon Web Services offers a bug bounty program. Oddly enough, the platform probably has the most reported data exploits. Is there a correlation? No.
This leads to my point.
Most data exploits from cloud service providers have been due to lack of configuration, or misconfiguration.
So in this article, I recommend six cloud security settings to manually review on a regular basis.
1. Verify Azure blobs are set to ‘private’.
Blobs are an Azure storage resource for unstructured data. They are grouped into ‘containers’ (and these are different than application containers). Review the security setting of the blogs on a regular basis to ensure they are set to private do not allow anonymous read access.
Instead of me walking through the settings and location here is a great article by Microsoft:
https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources
2. Verify AWS S3 buckets are set to ‘private’.
This has been the crux of many data exposure reports in recent history. Amazon has been doing a lot to educate on to apply the correct permissions and go further with defense-in-depth settings for protecting s3 buckets.
Again, here is an excellent step by step article by Amazon:
3. Google Cloud Platform – Remove ‘allUsers’ Group READ permissions.
All the major cloud providers have different security settings and policies. But one thing is consistent, there is a setting that allows anonymous access to data stored int eh cloud. This is the precious gem you’re looking for to protect your data from being accessible to everyone on the Internet.
GCP handles this through ‘Scopes which deals with user permissions.
Here is an article from Google that walks through the configuration settings.
https://cloud.google.com/storage/docs/authentication
Summary
By adding a task to your calendar, or governance schedule, to review the access permissions for anonymous or public users you can greatly reduce the risk of your sensitive and confidently data being leaked on the cloud.
I’m not one to point out failures, because I’ve made enough of my own. But a quick search will reveal the top ten to twenty cloud data exposures. Most of the data exposures can be tied back to misconfigurations in cloud security settings.
“The most unfortunate part is that the issue occurred due to human error and not a malicious attack. It seems like every few days there is yet another data breach, ransomware threat or a new security flaw and companies or organizations must do more to be proactive in how they store sensitive data online.”
https://www.tripwire.com/state-of-security/latest-security-news/australian-broadcasting-corporation-leaked-data-through-aws-s3-buckets/
Recent Comments