It’s October and, as we're sure you've been inundated about so far, that brings an important topic to the forefront this month: Cybersecurity. We have no doubt that you’ll be inundated by vendors, product owners, and service providers creating tons of posts and articles detailing the finer points of cybersecurity. You’ll probably see topics such as “10 things you should be doing (but aren’t)”, “Why your product stack isn’t as good as XYZ”, and “This technology will disrupt the cyber space as we know it”. Sound familiar?
While these topics have their audience and certainly deserve their place in the ecosystem, it can sometimes be overwhelming to sift through posts and find what’s truly relevant. As cybersecurity professionals, we absolutely agree with the intention of these posts, but sometimes the delivery can do more harm than good. That’s why we’ve come up with a list of quick wins to help secure a platform you’re most likely using: Microsoft 365 and Azure.
While the irony isn’t lost on us that we’ve come up with a “list of things you should be doing (but aren’t)”, we also understand security is a journey and not just a switch that needs to be flipped. It evolves with time and needs to be consistently reviewed to ensure deployments aren’t plagued by misconfigurations. We also wanted to provide some of the easiest configurations that have the biggest impact along with instructions (and locations) on how to make those changes.
The List
A point of note before we start: Microsoft is constantly changing licenses to move certain security features behind paywalls of license “bolt-ons”. This is mostly done to prevent vendors and service providers from cherry-picking licenses and push towards adopting their most expensive license, M365 E5 (Enterprise). The E5 license does have its place and will always contain every security feature that Microsoft provides but isn’t always an easy operating cost for organisations to swallow. If you’re unsure of what licenses your environment has, you can always check them out here, Navigate to Billing and click on Licenses. When in doubt, turning Microsoft’s Security Defaults is always a good move if you don’t have all the bolt-ons.
So, without further ado, here are some simple changes you can make to your O365 & Azure environment that will have a big impact on reducing your surface area of attack.
Enforce MFA for all users in your environment.
This one is an easy win for your organization as it will stop the vast majority of attacks – up to 99%, according to Microsoft. However, they also stated that only 24% of companies have adopted it, regardless of how impactful this control is to securing an environment. It’s worth pointing out that the following items should be addressed and planned before flipping the switch to prevent interruptions to users:
What method is going to be used to deliver the MFA prompts? Email, text/call, authenticator app, or security key?
Each of these have their merits in moving the scale of security vs. convenience one way or the other, but it’s paramount to outline this before moving forward. For instance, if you want all users to utilize the Authenticator app, are you providing phones to the users? If it’s a BYOD environment, how are you as an organization dictating what is required to be installed on a personal device?
Are Trusted Locations going to be used?
Trusted Locations are a method of defining what are known “safe locations” within your organization (usually by IP range or subnet) to help prevent MFA fatigue and assist in tipping the scales of Security vs. Convenience. This is great to use if the users from an office location are always going to use the same public IP address or remote users are dropped into the same VPN VLAN. It’s worth asking, however: what happens if an account is compromised within these Trusted Locations? Those users won’t be prompted for MFA unless they meet specific conditions because the activity is sourced to a trusted location.
Point of Note: This is where defense in depth would come into play, allowing multiple controls like EDR, Network Access Controls, PIM/PAM, etc., to hopefully be configured and alert before this is the single point of failure.
Define your lockout policies.
This is less of a question, and more of something you’ll want to define before deploying. Outlining the thresholds for number of failed attempts, password reset requests, and MFA prompts allowed in quick succession will help reduce noise and also eliminate the effectiveness of password-based attacks (like stuffing and spraying).
Configure Conditional Access policies.
MFA configuration is a great segue into the use of Conditional Access policies. These polices represent a series of “If this, then that” scenarios that perform actions based individual activities, whether they be initiated by a user or a device. For example, a Conditional Access policy could be (and should be) created that states “If a user account with administrator privileges signs in (If this), regardless of where they are signing in from, require MFA (Then that)”.
These policies act as a backbone for Microsoft’s newer way of applying controls based on risk levels instead of blanketing the approach to all users. The only downside is most organizations haven’t mapped out which specific scenarios should be accounted for, allowing for some misconfigurations. Conditional Access policies have several variables that can be defined within, and allow for a lot of flexibility, as seen below:
Similar to the last point, planning for Conditional Access deployment should be reviewed carefully to prevent lockouts, or worse, allow for misconfigurations to be abused by attackers. Great posts have been created by other security firms, such as our friends over at Soteria discussing how Azure AD can be accessed by unprivileged users.
In our experience, here are several Conditional Access policies that should be applied to all tenants to provide a solid baseline of protections (in no specific order):
- Require MFA for all administrators, regardless of location.
- Require MFA for all users outside of trusted locations.
- Require app protection policies for mobile devices, including all platforms, for all corporate-required applications.
- Disable legacy authentication.
- Restrict access to AAD for non-administrators.
- Disable access for non-domain joined devices, including all platforms, for all cloud apps.
- Block registration for MFA and security protections from originating outside of Trusted Locations.
- Block sign-ins meeting certain risk levels.
Implementing the above Conditional Access policies will give a solid foundation for securing sign-ins and interactions with corporate resources. You’ll still need to plan accordingly and ensure coverage exists where it should as each company is different. These represent a great starting point but may not be exhaustive of all Conditional Access policies your organization may need. For instance, if you’re using third-party apps with SSO, you’re going to want to ensure you have additional policies to secure it appropriately.
Enable email protections
Lastly, we get to the topic that gets spoken about the most in our experience. Email is the most common way for malware, ransomware, and social engineering to get into your network, and presents a struggle for all organizations. Before moving into what controls should be configured, it’s worth pointing out that regardless of the size of the castle walls, how deep the moat may be, or if you have sharks with frickin’ laser beams on their heads (thanks, Dr. Evil), if someone leaves a gate down, all of that is for naught. End User Awareness training is a must and shouldn’t be skimped out on in the slightest.
Email protection is a large topic and includes more controls than this post could go into and keep its brevity. For Office 365 users, a lot of the guesswork can be taken out by applying Microsoft’s Security Defaults. If you’re not going to use Conditional Access policies (we’re not judging), enabling Security Defaults, at the very least, will give you more coverage than the average tenant.
For specific controls with regard to email, we’ve found the following to be some of the easiest ones to provide protections:
Enable SPF, DKIM, and DMARC
These controls verify that emails originating from your domain are legitimate, verified, and not spoofed. A quick overview can be found below and a more in-depth review can be found in TrustedSec’s post:
- SPF acts as the bouncer that determines if mail is allowed to be sent on behalf of your organization based on where it originated. Keep in mind that if you’re using something like Mailchimp or Hubspot for marketing emails, you’ll want to include their domain and IP in your record. If not, the email messages will be flagged and may be delivered to spam or quarantine. A simple example of an SPF record may look like:
- “v=spf1 +ip4:1.2.3.4 -ip4:5.6.7.8 include:yourdomain.com -all”
- DKIM essential is the driver’s license you hand to the bouncer to verify the message is legitimate and can be verified by the recipient.
- DMARC (in layman’s terms) is the action the bouncer takes when it finds a fake driver’s license. Actions can be defined to deliver the message anyways; deliver it but send to quarantine, spam, or junk boxes; or bounce the message and reject it. DMARC by default reports actions taken on messages to the administrator of the tenant, so it’s worth defining who should receive these messages to review when email abuse may be taking place.
Use Office 365 Exchange Online Protection (EOP)
This includes things like Safe Links, Safe Attachments, Anti-Spam, Anti-Phishing, and Anti-Malware. These policies are built-in but should be reviewed to ensure that the specific settings are defined for your organization. Microsoft has outlined their recommended settings, but keep in mind these are recommendations. For instance, the Advanced Spam Filter recommended settings has everything turned off.
One setting increases spam score for an SPF hard fail; as we just pointed out, this may be a false positive, but has been an increased attack method for phishing emails taking advantage of the From and Return Address fields. Spend some time reviewing the EOP policies as they’re an easy way to make some impactful changes to email security for your organization.
Junk is Junk.
This follows closely with the point earlier about End User Awareness training being a must. Educating your users that mail delivered to Junk, Spam, or Quarantine was delivered there for a reason and should be treated as such. While its inevitable that mail will be misdelivered to these locations, this should be treated as the exception, not the rule. Ensuring that an administrator has access to review any discrepancies is a must, along with defining what to do with self-releasing these emails. Sure, this reduces the amount of time it takes from an admin to consistently release emails, but it also removes a control layer and relies on how strongly educated your users are into determining a malicious email.
Closing Thoughts
And there you have it, some easy wins to beef up the security within your O365 & Azure environment. Please keep in mind this isn’t an exhaustive list, but merely one that can serve as a starting point to bring the topic of security front and center. Cybersecurity (and security as a whole) isn’t a switch that can be flipped or a “simple answer” – it’s a journey and one that is constantly changing. No matter how your organization feels about its cybersecurity posture, review and testing is never a bad thing. Feel free to reference this post as much as possible and if you have any questions, feel free to reach out for a more purpose-driven discussion by emailing us at info@emberlake.ky.
