Let's start from a real world hack which happened and infected many users!!!!! Yoohahahahahaaaaa 😈😈😈😈
The hack that Marriott disclosed is currently one of the largest in history, jumping directly to number two in the top three.
At the end of November 2018, the hotel conglomerate Marriott disclosed a massive terrific hack that impacted over 500 million customers who made a reservation at one of the Starwood hotels. The bulk of those people had sensitive data such as name, passport number, date of birth and even credit card information stolen.
Marriott acquired the Starwood hotels in the fall of 2016, operating under brands such as Sheraton, Westin and the W hotels. The intrusion already happened two years earlier in 2014. Given the time that attackers had, the breach likely makes the breach much worse than it could have been.
You’re running valuable resources and data on Microsoft Azure and might be wondering and asking yourself why am I telling you this story and “what can I learn from this hack?” and “how can I protect my environment?”.
As it turns out, there are a couple of things you can starting doing today already.
On place three of the hacking list, in the Equifax hack that happened early 2017, hackers grabbed just under 150 million records with personal identifiable data, exploiting an Apache vulnerability.
However, the number one spot is still strongly in the hands of Yahoo, who had every of their 3 billion accounts hacked in the summer of 2013.
Marriott’s security tooling flagged suspicious access to its guest reservation database on September 8 of 2018. However, while doing their first analysis, they found that the breach had occurred already four years earlier and that hackers would have had lots of time to learn about systems holding valuable data and exfiltrate that data out.
“Four years is an eternity when it comes to breaches.” — David Kennedy, TRUSTEDSEC
You’ve been hearing this time and time again: you need to assume that your environment has already been hacked. And while this might be actually true or not, the Marriott hack certainly underlines that we need to adopt the “assume breach” mindset.
What does this mindset mean? (Click here for more info)
Well, don’t just defend the outer perimeters of your environment. Make security a fundamental part of everything your deploy and manage. Don’t just rely on network appliances or external measures, protect the valuable asset itself.
And yes, with today’s adoption of Cloud and shift to DevOps and many companies adopting new infrastructure mechanisms such as CI/CD pipelines, this might be hard — but we need to spend time and money on securing our valuable resources and data. If you’re using Azure DevOps, Microsoft will help your with your effort to get to a state of DevSecOps, for instance by providing out of the box integrations.
Understand if your industry is a focus target for hackers. Understand what attack surfaces they might want to compromise. And understand how they think and work, so that you can go Threat Hunting.
Actually , the 3 key players—Azure, AWS, and Google Cloud—are making big strides very fast in order to bring new and exciting things to customers the world over. Then there are the not so huge players, trying to keep up with the primary cloud providers all while finding some way to remain innovative. All in all, it’s a very interesting time to work in IT.
With all of these players and all of this technology, we the consumer must spend time considering what security might look like today, and what we want it to look like in the next few months.
Please Note: This is by no means an exhaustive list of all things security and some of the features and things discussed may be in preview. They are included for exposure and to get you thinking about what might be coming and how you can leverage it in your Azure environment.
Azure Security Center
Microsoft has done a lot of great work in the security sector to make all of its products more secure and increased the trust, but one of the favorite security features I’ve seen recently (since its preview release over the past year or so) is it's Security Center.
This service is built into the Azure platform—the basic tier of the service is free and starts the collection of data about your Azure environment as soon as you start it up (all Azure subscriptions can collect information in the free tier).
What maked the Security Center so awesome in my mind comes in two areas:
1.The Security Advisor, which will provide users recommendations for correcting and improving things found in your Azure environment;
2.Second is an upgrade to the standard tier of Security Center, which allows you to configure agents on any virtual machines you have running, both in Azure and elsewhere, and collect data about the security posture of your environment as a whole.
When you access Recommendations from Security Center, a list based on mitigation priority will be displayed to help you understand what’s needed and in many cases offer a fix at the click of a button.
Pricing for the standard tier:
*preview pricing for these resources – subject to change when the service goes GA
There are additional charges for data storage over the included 500Mb daily limits as well, and more info can be found on the Azure Security Center Pricing page.
Security in Azure Storage
We’ve looked at general and login security, but what about data storage? You need somewhere to keep the data you’ll be working with, and that data might be the next big thing, so security isn’t something that only applies to processing resources.
Shared Access Signatures (SAS) help keep information safe and accessible, without having to use the Administrative credentials. Utilizing Shared Access Signatures, it’s possible to control access to data stored in Azure storage accounts, and easily ensure access expires when it’s no longer needed.
Let's see another example. I’m an admin storing documents in Azure Storage, and I need to share a document with a vendor, but only for a limited period of time.
Using Shared Access Signature allows delegation of access to the data with expiration built in. When I create an access signature, a URL is created and can be shared with whoever needs access. Each storage type—blob, table, and files—is configured for the shared access signature independently, but more than one type can be assigned to each URL.
With this configuration, I can create an access endpoint that allows me to share both blob and files for as much time as necessary, allowing a few days for the data to be collected. Then, the URL expires and the data becomes inaccessible.
While this may not seem like a security feature, it can certainly help keep your stored data both secure and available to others when needed. In addition, there is no requirement for a third party service to share files, so any data storage and sharing is only being done within your Azure environment.
You can learn more about Shared Access Signatures for Azure Storage here.
Enforcing Multi-Factor Authentication for Administrator Accounts
This is more a policy or practice than a feature of Azure—sure it supports the use of Multi-Factor Authentication, but there may be users who have read-only privileges to a subset of resources that may not require MFA to be enabled all the time.
For any admin accounts, requiring MFA is definitely a security practice worth implementing. Consider for a moment the following:
You are the administrator at AwesomeStuff, a company that makes awesome stuff and uses Azure for the majority of its IT services. As the administrator you can configure settings in Office 365, create and destroy virtual machines, and use pretty much any service you need to (within reason and budget). While you’re on vacation with your family, your administrator account for Azure has been used to log in and create three or four huge virtual machines, and costs are spiraling out of control.
When you return to the office you see these new machines and their costs. Asking around, no one knows what they are used for and is under the assumption that since they were created using your account, they must be needed for something. Further investigation into the logs shows that when these machines were created, the sign in came from IP address that traced back to a European country; not your office in the US, not your home office, and not anywhere near the lake house you rented for vacation.
Without enabling MFA on your admin accounts, they can be used from anywhere. In the event that they are compromised, the person who has gained access to your account is able to create resources for any purpose they choose, and even steal both money and intellectual property from your organization.
If you have been enabled MFA on your account in the above example, the owner of the account would have been prompted to respond when the login occurred. Because you were on vacation (and definitely not creating virtual machines or other resources in Azure), you could immediately recognize the log in as suspicious, denied the second-factor authentication, and taken five minutes to change your password. This simple configuration might have prevented the account compromise.
You can find more information on Azure MFA here.
Keep your environment and data safe in the cloud
Cloud Security, like all of the other resources available in Azure, is something that should be looked upon as a first-class citizen. Taking your environment, and possibly your customers, for granted is not something that’s easy to bounce back from. Using the available resources in Azure and the Microsoft Documentation will help you better understand how to keep things safe in the fast-paced, constantly evolving world of the cloud.
The Azure cloud is not a “set it and forget it” environment, and the care and feeding needed are different in some ways from the practices used on-premises. Many of these will translate well, but you will need to continually review the services, features, and use cases for many of the resources you leverage in Azure.
The product team behind Microsoft Azure is moving just as quick (In some cases even faster (One-Step-Ahead Mindset) 😁 as their customer organizations in some areas, so the way security works today may not be the way security works tomorrow.
Please ask us your questions if you have any right bellow in comments!
TRADEMARK LEGAL NOTICE
All product names, logos, and brands are the property of their respective owners in Austria or other countries. All company, product and service names used on this website are for identification purposes only. Pheniix is not affiliated with or an official partner of Cisco, CompTIA,Dimension Data, VMware, Amazon, Microsoft, Certified Ethical Hacker, (ISC)², Juniper, Wireshark, Offensive Security,Google, GNS3, F5, Python, Linux, Java, OpenStack, Vagrant, Ansible, Docker, GIT, , Blockchain or other companies. Use of these names, logos, and brands does not imply endorsement. The opinions expressed on pheniix are personal perspectives and not those of Cisco, Dimension Data or any other company. Pheniix runs as an independent blog.