TEC Talk: Addressing CISA Security Warnings in Rushed Office 365 Deployments

All right. Good morning, everybody, and welcome to today's TEC Talk, Addressing CISA Security Warnings and Rushed Office 365 Deployments. Today, I'm joined by Amy Babinchak, a Microsoft MVP, consultant and business owner of Third Tier. She's also a TEC-- The Experts Conference speaker. Before I go too far, I should introduce myself. I'm Jennifer LuPiba. I'm the chair of our conference-- The Experts Conference. And so we're putting on these TEC Talks right now to deliver a lot of value straight to you where you're at. It's a very busy time and we wanted to provide pure training in the spirit of The Experts Conference. So no product pitches. The only pitch you're going to hear from me is for The Experts Conference and just the next slide. But I think that will be OK. Today's topic, specifically, is really hitting close to home for a lot of folks. Over the last several months there's been a huge rush in to Office 365. Satya Nadella in fact said that in his last earnings call that two years worth of digital transformation happened in two months. And one thing that I saw several weeks ago is that the US Department of Homeland Security Cyber Security Infrastructure, or CISA, put out an alert around Office 365 security concerns because of the deployments being rushed so quickly with these work from home orders. So Amy's going to address some of those concerns, as well as show in a very demo heavy presentation today ways to mitigate that with in Office 365 itself. For those who are attending and do need CPE credits, this is perfect. We're not pitching products, we're really talking specifically around Office 365 and what you can do in there. It's perfect for any of those CPE credits that you need. If you need an attendance receipt for that or the slides or both, please email me and my email's in the Q&A. We will save that Q&A for the end. But you can enter your questions anytime. I will publish the question, and then if-- you can like them and will address the questions in order of likes. I think that would work. So I said that I would only do one pitch today. And it's really dear to my heart and that is The Experts Conference. So today's session, what you're going to see this is the type of content that you will receive at The Experts Conference in Atlanta November 17 and 18. The Experts Conference was something that Quest did for many, many years. It went on a hiatus for several years, and we brought it back last year. It was sold out. And it's really quite a success. And we're bringing it back again with three tracks, hybrid Active Directory security, Officers 365, and migration and modernization. At The Experts Conference, we carve out a lot of time for networking and interacting with industry experts and peers. Folks like Randy Franklin Smith, Shawn Metcalf, Chris McNulty, David Kennedy from TrustedSec, you're speaker today, Amy Babinchak. And because we understand and know that these types of conferences are really great for not just the learning and all of the valuable lessons and best practices you'll take away, but it's also connecting with your peers, other people who are going through similar products or projects. And then talking to these experts and ask them your questions directly, during the session after the session. So we're really excited to be bringing this to Atlanta this year. We are watching the situation very closely with COVID-19. We understand that this is a new experience for everyone. So we are planning for every possibility. The conference center right now, it's very large. And we are only really looking to be about 250-300 people. But we have the entire conference facility at the Loews hotel. So plenty of ways to social distance and lots of other ways that we can stay safe and healthy. But we also offer a full refund all the way up until November 3, because we just know things might change for you or for your company. So it's great you could register now and take advantage of the early bird discount and know that if something changes, we want to honor that refund. We've also added a pre-conference day specifically for Quest training. So it's not part of the conference, but attached to it. So for those Quest customers on the line who have any of our Active Direct Recovery or Active Directory Auditing products in our portfolio, we're doing training specifically in those products. So you can go to theexpertsconference.com and take a look at the agenda, the pre-conference, all the speakers, and register from there. So we're really excited about that. The next TEC Talk we have lined up is June 17. I will send out an email about this. So it's in two weeks. Same time, 11:00 AM Eastern. We actually have a Quest person, also a TEC speaker, Colin Truran leading this one. Talking about the new normal for data privacy. Do data privacy laws-- are they still in effect during work from home orders and the pandemic that's going on? What about GDPR? What about reporting breaches and-- is the IOC still rolling out fines? And how do we handle-- how organizations handle and treat and store employee health data that they may have to track or alert other employees on. So a lot of questions I think around data privacy right now and Colin will be addressing that on June 17. So getting into today's presentation, as quickly as I can, I'd like to introduce Amy. Amy is the owner of three IT related businesses, Harbor Computer Services, Third Tier, and Sell My MSP. She's been working with small and medium businesses in the IT field for more than 20 years. She is a Microsoft MVP in several categories for the last 14 years. Her current award is in the Office Apps and Services. And she is also currently on the executive committee at Comp TIA for Managed Services. I'm really excited to have Amy here to address this very important topic around things and ways that you can mitigate those security concerns that CISA has alerted everyone to. So at this point, Amy, I'm going to hand it over to you. Well, thank you. I may have messed you up. I think I shared my screen too soon, but-- That's OK. [LAUGHTER] But I'm looking forward to the conference. It'll be my first TEC conference, so I'm really excited to be there and to be a speaker. And thank you for that introduction. So as you said, this is going to be a very demo heavy kind of thing because I'm a technical person. And so rather than just talk about what it is, I would prefer to show you. But I did include here on this slide the URL. And I'm sure you can look at this later and grab that URL or whatever or snippet right now. It basically comes down to three categories of things if we kind of look at that article and say, OK, what is it that we need to be most concerned about? And it's sort of enabling multi-factor authentication across the board, enabling logging and monitoring on different services so that you can keep track and set alerts and that kind of stuff. And then narrowing down your attack surface and limiting your exposure. And I certainly understand what all the rush has been about. I have been telling my clients that we are-- this is not the new normal. This is not going back to the way things were. This is the fast forward, that's what I call it. So my message is, we're now in the fast forward. It's like, while we were off gone on quarantine and everybody went to work from home, the chains came off the technology that were holding things back, and there was a rush to move forward. And I think that's what Satya was talking about and what he saw happening with the number of new tenants coming in. And also what these alerts are about that, hey, yep, we've got everybody working in there on email. And maybe they're storing some files in OneDrive and we kind of threw it out there. We really have to circle back around and make sure that we did things the right way and that it's very, very secure. Because the tools are there to secure this. And I think there's even more tools online than we used to have having we done all the stuff on premises. So it's time to use those tools. So pedals to the metal on technology and we've got to catch up our tenants. So that's what we're going to do today. So the CISA list is this, right? These are the items that they specifically called out. Enabling MFA for administrator accounts for all users also for Azure management. Enabling the Unified Audit Log disabling legacy protocols authentication when appropriate. And I will show you how to figure out when it's appropriate. Spoiler alert, it's always appropriate. But you can find out who's actually using it and fix those problems. Assigning administrative roles using the standard RBAC kind of stuff that you're probably already familiar with. Enabling alerts. Checking your Microsoft Secure Score, which is an awesome tool. And then integrating logs with any with any SIEM that you might already be using. And if you're not already using one, either getting one or using Microsoft's own Azure Sentinel for that. But whatever you choose, basically, know what's going on in your environment. And then I went and said, OK, those are all really wonderful. But there's a few other things that actually help us make an environment secure that I think are absolutely essential and should not be skipped. And those are the items that I've added in red. And so it's creating a break-glass account, because losing access to your tenant is a real thing that can happen and Microsoft cannot recover it for you. When we're talking about logging, extending that logging to the max retention period or whatever retention period is appropriate for your organization, because by default, it's kind of short. Like seven days. Review who's using legacy auth, right? Replicate security default conditional access policies. When you make a new tenant, you get a certain set of policies. But then you can't create your own conditional access policies if you use those default policies. So we have to replicate those who make our own so that we can then do our own conditional access things like the next item, limiting log in by country. I do this routinely for my clients because they're all in the United States. And for the most part, they don't need to be able to log into their tenant from any other state-- any other country. And if they're in some other country on vacation, we just go ahead and add that country as an exemption for that vacation period. But meanwhile, we've really limited the attack surface by saying, if you're going to attack us, you have to be in the United States to do it. And we do the same thing by limiting email by country. Some businesses can do that. Some are expecting email from the whole world. Most businesses are not expecting email from the whole world. And so any place that they do not need to receive email from we say, no email from these countries. Because there's just too much phishing out there, right? So we want to limit that. And then configuring our spam and phishing policies does not come configured out of the box at all. So that's something you need to do. We're going to prevent auto forwarding of email because that is a very common way that if the bad guys do get in through IMAP or some protocol that doesn't support MFA, that they'll stick an auto forward rule and ship out all of your email to their own Gmail address. And then use that to kind of monitor what's going on in your email and look for opportunities for spear phishing or just jumping in the middle of the conversation. And so those are the items that I added in that I feel like this list now, to me, represents like the minimum that you have to have to have a decently configured starting point for your 365 environments. So that's what I'm going to attempt to demo today. And it's a lot, so you can imagine we're going to go quickly. And I know the session is being recorded, so you'll be able to go back through and go, how did she do that again? And what were those steps? So just planned for that. So and as I mentioned, so we're going to demo multi-factor authentication and conditional access. And so bear with me as a jump out of this slide show and into my demo environment. All right, so here, we're actually using MyLive tenant today, because my demo environment did not load from Microsoft. That page is apparently down. So we're using MyLive tenant today, which is kind of cool. You'll see a bunch of stuff in here that I have configured for my own MSP business. But we'll go ahead and use this. So all right, so the first thing that we're going to take a look at is the multi-factor authentication and conditional access. And first thing we'll take a look at is the are RBAC stuff. Hang on just a second here. [? Any ?] [? do. ?] Grab my notes. OK, so if we're creating a new user-- and I'll just go ahead and show you this. So we're going to create a new user, right? I'm going to add a user in here. And I want this user to be a type of an admin, so we'll call this Amyadmin. And we'll just give it an Amyadmin. I'm going to go ahead and create this user account. Hide display name. There we go. I'm going to assign some licenses for this. We'll select that one. And we'll get us to where-- and we'll select that one. Also get us where we need to be. So if we want to have an admin user, right? You've heard of global admins, right? Most people go through and they just create a global admin. And the global admin gives you absolutely every permission that there is to have. And it's recommended that you have only two or three admin accounts, and absolutely fewer than five. So instead of assigning global admins, you'll see that my org here has eight admins. And that's because of our role as an MSP, we have a lot of things that folks need to do in here. But if you're a regular business, we would never sign global admin to more than two or three people. Instead, what we would do is go ahead and assign them-- maybe they're the they're the exchange admin role or they're the SharePoint admin role, or perhaps both. And what I would really want to point out to you was this little arrow over here on the right hand side underneath "show all by category", because you have a lot of fine grained control under here. So you've got a collaboration category where you have many different types of admins, devices, identities, others. Some read only options. So if you have folks it just need to see but not change. And you've got security compliance admins. So when they're talking about the RBAC, we have our back in several places. We have it in the Security Center, we have it in Exchange, and we have it when we're actually creating users. So in all three of those places, that's where we want to be sure that when you're creating an admin, that you're creating them with just the permissions that they need to be created for. The next thing I wanted to mention is that-- and this was one of the things that I added in-- is that you need a break-glass account. And for your break-glass account, what you're going to do is create a nonsense user name. Well, I can actually say this is my break-glass account, right? This is my account and I'm going to use if I lose access to my tenant. And I want this display name and this user name to be something absolutely ridiculous. And the reason that I want that-- and I wanted this to be in my OnMicrosoft account. The reason I want this is if multi-factor authentication goes down, I need to have an account that doesn't have multi-factor authentication on it. Now, I need to secure that account as well. So on this account, what I would say is let me generate the password. And it will accept passwords up to 256 characters. So I would select a 255 character password. I would use my little RoboForm tool, which you see here, and have it generates that random password for me that's just a bunch of gobbledygook that's 255 characters long with an absolutely long nonsense user name as well. And make that count very difficult to then break into. On the flip side of this, I'm going to also be setting alerts so that if that account ever logged in, I will immediately get text messages and emails and everything will tell me like, hey, that account logged in. So that I know if something happens to go sideways. But with a crazy user name and a super long password, the likelihood that account will be broken into is very remote. So the reason we do this is, as I mentioned a minute ago, Microsoft can not recover your tenant for you. So if you make a mistake in creating a conditional access rule that blocks out log in from everybody, you have to have this failsafe in there because Microsoft will not be able to break into your tenant. They have no backdoor into your tenant you need to create one for yourself. Right. Now, that we have our-- we know about RBAC, we know all their options for that, we know about our break-glass account, and the next thing that we're going to do is take a look at our conditional access rules. And our conditional access rules are in the Azure Active Directory. So in our Azure Active Directory, under security, you will find Conditional Access. Now, I want to point out these first four rules here at the top baseline policy. These are the four that Microsoft is going to create for you. And this is require MFA for admin, block the legacy authentication, require MFA for service management-- that's Azure-- And end-user protection, which is their wording for require MFA for all users. So between those four things, those are going to be enabled. I think the legacy authentication is still disabled. But those policies will be created and be enabled for you when you first create your tenant. But it then prevents you from creating any additional conditional access policies. And as you see down here, I have a bunch of these additional policies in my tenant. So what you need to do is actually go through and recreate those policies. And the interesting thing about them is if you click into one of those, there's a notice down here, right? This policy has been deprecated, no longer being enforced, can't be enabled. The reason it says that is because I've already created my custom policy, and so that's why this can't be enabled. But notice that this is the little pointer hand because this guy is clickable. And so you will see that in your own tenant and find that that is a clickable item. And what that does is actually bring you right out to an article from Microsoft that tells you how to recreate that policy. So even though Microsoft has created those policies you need to go through, follow these instructions, and recreate those policies. Because if you don't, it will not allow you to create your own custom conditional access policies later. So we absolutely need our require MFA for administrators. And let me show you what that policy actually looks like. So here here's my custom one that is currently in the on state. Require MFA for admins. If I go ahead and click on that it can show you what that rule actually looks like. And you'll just follow through the article to create these. I specifically want to call out this. So on the user in groups, we need we need admins. I've got 44 different admin roles selected here. So remember that our back list, we need to select all of those admin roles and bring them in here. And Microsoft updates these periodically so we have to come in and select them as well. So as they add ones, we need to go ahead and add them in. So I'll put all of my administrators in here. But then I also need to exclude, right? So every time that I create a group policy, I need to be sure to exclude those break-glass accounts, any service accounts, any accounts that are off, any account that is associated with AD Connect. So I need to always make an exclusion. So I'll come in here flip over to exclude, and add those excluded users that are for that purpose. The other thing that I want to point out down here is when you enable the policy, there is a new item down here at the bottom that is automatically going to exclude the person who is creating the policy from the policy. That can be a problem, right? So you've got your administrators and they're creating this MFA for admins, and it automatically excludes them from the MFA for admins rule. Kind of an issue. So if you're not paying attention, you can actually miss this. You need to slip back over to, "I understand my account is going to be impacted by this policy. Proceed anyway." and click save. Because you've excluded your accounts that you needed that you needed to exclude. You don't want to exclude any accidentally. So this little pink box is going to be present on every policy that you create in Azure now. I'm going to show you a another one of the policies. So one of our other policies is-- are we, load more, here we go-- MFA for Azure management, slightly different kind of policy here. So in this one, we're including all users. We are also excluding the users that we need to exclude for our AD Connect, and our service account, and our break-glass account. This one, we actually are going to apply to selected applications, rather than all applications. And in this one, the application that we're selecting is Azure Management. So as you see, you can actually apply these conditional access policies to specific applications only. And that's what we're doing here. So how I found that was to, rather than browse, just do the search. And it's Microsoft Azure Management that needs to do that. And so just like before, we've got the pink box that's an actual clickable. And it takes me to come into here to Best practices. And I've got my-- underneath here, under Conditional Access policies, again, are those policies. You can always jump over into the instruction set, which is really nice. I quite like that. I think Microsoft's done a good job with that. Let's see, where are we at? We created our multi-factor authentication rules, created our break-glass account. We took a look at the Azure rule, we took a look at the RBACs. We enabled the other one. The other policy that's in there is the authentication for all users. But that's really set up exactly the same way as what I showed you for the admin. So I think we're covered on those first items. Let's see where we're at with our policy here. Why does it always do that? Swap, thank you. And there we are. So we've done those particular items. And so now we want to move along through our to-do list here. So legacy protocols and security defaults are what we want to take a look at. So now we're going to disable those legacy protocols. And I'm going to show you how to find out who's actually using legacy protocols. So what are those legacy protocols? They are IMAP, SMTP, and POP, basically. So then I'm going to show you how to find the information on duplicating those policies. And then finally, we're going to limit by country from allowed locations so that we can narrow that attack surface. So back to the demo. Let's go back into here. So who is using legacy authentication in our portal? And this is kind of important to know, because if we're going to a block IMAP, we don't want to find out after the fact who is-- somebody is using IMAP on their phone. And then we've just prevented email on their phone. That would be a bad thing. So what I want to do is show you a way where you can actually find out who's using this stuff. And that's not where I need to be. Here's where I need to be. Under Reports and Usage Reports is where we're going to look. So in our Usage Reports, we've got all kinds of information that honestly, I don't find very useful. Like woo, we had 16,000 emails and 349,000 OneDrive files-- kind of, who cares? But there is an important report under here, and under Exchange. I love these little-- Microsoft hides all the important stuff under some little arrow or tiny checkbox. And so this is a very important little arrow here at the top of the screen, this Select a report. And look at what it opens up for-- all kinds of different reports. So if we go under Exchange and then App Usage, this is what we're looking for. So in the last 30 days, what we want to look here is the part here at the bottom of the screen. Here's a bunch of users. And the little check boxes show me which things that they have used in the last 30 days. So two people used Outlook on the web. Everybody except two people used Outlook. Three used Outlook for Windows. And a bunch of people used the Outlook Mobile. And underneath these little hamburger menus is the good stuff, though. So if we go into Columns, I can uncheck all this Outlook stuff, because I don't care. But what I do care about is who used IMAP, who used POP, and who used SMTP, because those are our legacy protocols. So I don't see anybody who has used IMAP, POP, or SMTP in my sample here. But if somebody did, there would be a little checkbox there. And I would be able to go to that person and say, can I see your phone for a minute? I need to get you off of IMAP. And so get them into using 365 directly, because the problem with these protocols is that they don't support multi-factor authentication. And that makes their account vulnerable. So we have to get rid of these protocols. So that's how you're going to find out first, which is going to be your very first step. And if you just have a few people that are using those, when we create our rule, I would go ahead and add those people as temporary exceptions to the rule so that you can at least get the majority of folks off and fully secure. However, on the other ones, make a temporary exemption. And then once you've worked with them, go in and remove them from that exemption so that you kind of got your list to work from that way too Da, da, da, go through, remove them from that exemption as you get them reconfigured. So let's take a look at how we block those legacy protocols. So again, we're in our Conditional Access, which we get to under Security and Active Directory, Conditional Access. And the Block legacy authentication is one of the preview rules. Notice that it's off. I had to recreate my own so that I can have other custom policies. So in my prevent legacy auth, here's what that rule looks like. It applies to all users. It applies to all cloud applications. And there's a condition selected. And it says Client apps. So this is the critical point of this. And it's going to say, on my Client apps, if it's a mobile or desktop client of other client status-- meaning POP, IMAP, SMTP, et cetera, older office protocols-- then the access that I'm going to grant for that is Block. So if any user using any cloud app, trying to use an older protocol, they get blocked. It's fairly straightforward. This is actually, if you take a look in the logs, IMAP is the number one thing that you're going to see in the logs where the bad guys are trying to hack into user accounts. They're not going straight to the admin portal and trying usernames and passwords. They're actually using IMAP to do it, because they know that IMAP doesn't support MFA. And so people turn on MFA, but they leave the legacy protocols on. And that's just leaving a backdoor wide open. So we need to go ahead and block that. And then while we're in here, I want to show you another Block line location, as well, which I think is critical. There's a concept in here called Named locations. And I have several named locations in here. These are places where people have traveled to. So I just create the location. So if I want to do a new location-- say, I have somebody traveling to Korea. I have a lot of manufacturing clients, so it's fairly common that they would travel to Korea. So I've got my-- I will switch over to Countries and Regions, come down in here, and I will find Korea, Republic of. And I will go ahead and create that location. So now I have a location also called Korea. I can now use these locations to create conditional access rules. So in my conditional access rule, I have one called Only log in from allowed locations. In my only allow logged in locations, I've got all users included and specific users excluded. I'm applying it to all my cloud applications. I have a condition selected. And this rule applies to any location except the United States. So currently, I'm only allowing log in from the United States. Because my grant here is that I'm blocking access. It's kind of weird to say I'm granting you blocked access. But that's how it works. So I'm blocking access. And so what I've done here is I have blocked access to all locations except the one that I excluded, which is the United States. And when we start doing travel out of the country again, I will have other ones in there as well. I could go ahead and I can add my-- I can select others from that list that I showed you a minute ago. So if I had somebody that's traveling to Korea or to Mexico on business trips, I can select those. And they get added to my exclusions, which means that people, when they're in those areas, would be able to log into their Office 365 account. To me, I think that that rule is absolutely critical. It is a huge footprint reduction. By default, in 365, your footprint is the world. Anyone can attempt to log into your account from anywhere in the world. Well, that's kind of dumb. My people don't log in from anywhere in the world. Typically, they log in from the US, unless there's some travel going on. And then we'll go ahead and add that travel. It just kind of makes sense, right? So these are the items that we want to go ahead and add. And rather than do that dance with the PowerPoint presentation, I'm going to throw it back over here for a sec. So where are we at now? We found out who's using legacy authentication protocols. We created a policy to block those legacy authentication. We have seen how to recreate all of the default conditional access policies now. We've limited login by country. We did not take a look at trusted IPs, so let me show you that. And you can see by the items that we've checked off, we're actually getting our environment a lot more secure, very, very quickly, by just adding a very few number of policies. Let's jump back out and take a look at the IP addresses though. I did mean to show you guys that. So I'll go back to under Named locations. There's a link here for Configure MFA for trusted IPs-- weird place to put that. Didn't I tell you Microsoft likes to bury things? Because this is an awesome place to be. So my trusted IPs is the part that I wanted to show you here. I'm going to skip multi-factor authentication for these two IP addresses. Why? Because I trust those IP addresses. So if I have employees that are sitting, working in the same office every single day, as an admin, I can be slightly less annoying to them if I whitelist their IP here and don't prompt them for multi-factor authentication when they are logging in from a place that I trust. So this gives you the opportunity to add in those trusted places. The other thing that you can do in here is set the number of days when people have to re-authenticate. And you can set it between 1 and 60. Typically, I will either use 7 or 14, depending on the security of the environment and all those kinds of things. Because we're an MSP with access to lots of other businesses, I keep it fairly short. For typical business, I would probably set it more at, like, 14 days. So they're going to get prompted every two weeks to re-authenticate themselves using multi-factor authentication. Here is also where I set up the methods available for that multi-factor authentication. They can use the app, the phone, a text message, get a call, or whatever. So some really critical things there that are hidden in a really bizarre place-- Named locations. What that has to do with configuring your trusted IPs for your multi-factor authentication, I have no idea. But that's where you're going to find the link-- crazy stuff, right? So we did that. The next thing that I want to show you guys is logging. So in the log here, we're going to take a minute and see how you can login to your SEIM, if you have one. And that's your Security Event Incident Management in Microsoft. If you're using Microsoft, they call it Azure Sentinel. It's fairly new. The cool thing about it is that it's free to import your 365 logs into it. So if you don't have one yet, you might want to play around with that, just to get the idea of what the power of having a SEIM is, some place to actually organize and consolidate your logs and do stuff with your logs. It's kind of great. If you do have one already, there are ways that you can bring these logs into there. And here's how you do that. So you got two places that you really need to do it. 365, it's a little time consuming, and we're tight on time. So I'm not going to demo this. But I wanted to provide the info for you. So in 365, what you do is, you go into Azure and you create an app. And the sole purpose of this app is just to be the thing that conduit to the logs. So you create the app, you give that app admin consent, meaning that it has consent to access those logs. You request a access token, and then in your SEIM, you call the 365 API using that access token. In cloud app security, which is the other place that you need to address logging, you actually set that up in the Cloud App Security portal. There's a place where you can just download a JAR file and then give it to your SEIM agent. And it will validate that the SEIM is actually working. So two things about this, it only supports Micro Focus ArcSight and generic CEF. Generic CEF is usually imported to pretty much anything. So you should be able to get that into whatever you have existing. So let's take a look at where you actually turn on the logging. At the beginning, I mentioned that we need to turn on the logging because it's not on by default. And it's going to be a little difficult for me to show you that in my production tenant because, of course, it's already on. But I'll show you where it would be if it were still there. So you'll come in under Security. I just launched the Security. In Security, when you click on Alerts for the first time and you go to Alert Policies or Dashboard, at the top of your screen, right next to the words Alert Policies, right up in this blank space here where my mouse is moving back and forth, there's going to be a yellow box that says, hey, alerting is not turned on for your environment. Do you to turn it on? And you will just click the Yes button to turn that on. It's kind of bizarre to me that it's not turned on by default. But you need to go in there and turn it on. They make it fairly simple to do. Under Managed Advanced Alerts, that is where you're actually going to get into Cloud App Security. Cloud App Security is a really awesome tool where you can go ahead and set up a lot of additional alerts in here too. And you've got your policies available as well. So all kinds of policies that are templatetized for you. Or you can set up your own. So you can go into templates and take a look at what Microsoft has. Or you can go ahead and set up your own policies. I am going to show you this break-glass admin account right now. This is the one that I told you about earlier, where I said I really need to know. So I've got my login by break glass. It's under the category of Privileged Accounts. Any activity that matches the criteria that I set up-- so the user name equals, and I've selected a couple of users under here as the actor. And then if that alert actually gets triggered to where that account logs in, what's going to happen is, it's going to send email to two people. And it's going to send text messages to two people. Because honestly, that account should never log in. So should that account log in, we want to know about it right away. And these are the options that it gives us. So things are going to blow up. And it's going to blow up on every incident that happened. So we will know if that account happens to get used, so a little bit of a failsafe for us there. Oh, I took a picture of it for you. That's awesome. Here's what that's going to look like. Remember, I said it was going to be right next to the audit log. So Turn on auditing is where you're going to find that. You also need to turn on mailbox auditing. And I put the PowerShell up here too. Because there's no nifty little button for that. You need to go into PowerShell, just run that little script right there, and it will turn on logging for your mailboxes, which is kind of important to know what somebody is account's been broken into, and what happened with it, and whatnot. We have done all of these things, including Limit email by country. The next thing I really want to take a look at is email policies. So we will quickly take a look at a couple of email policies. So I'm going to show you how to limit email by country. I'm going to point out where you configure the spam and phishing policies. And a couple of little settings in there that have those hidden check boxes in dropdowns that are easily overlooked, and also the Prevent forwarding of email-- auto-forwarding. So what auto-forwarding is, say, an account still has IMAP turned on. They got in by not using MFA because IMAP doesn't support it. They use Outlook on the web. And then what they do is, they go and they create a rule. And it says Forward all email to this Gmail account. And so the rule that we're going to create in Exchange actually says, do not allow any automatically-forwarded email off of my domain. That doesn't prevent somebody from forwarding an email-- "an" email. Say in selecting email forward, it prevents the creation of an auto-forward rule that goes off the domain. And so it's a very limited resource. I find that it almost never gets tripped accidentally. That this is really something that adds quite a bit of a measure of security, especially if you've yet to go through and secure the rest for your environment. So we can create that under a Mail Flow Rules. And I am going to actually show you how to do this, even though I've got-- this is my rule here. It's already in my Block external forwarding. So here's what this rule looks like. If an email-- the sender is located inside my organization, and the recipient is located outside the organization, and the message type is auto-forward, then reject the message with an explanation. Letting them know, hey, forwarding rules to external domains are not permitted. And I have an exception in here for one of our team's address. So if you need to make an exception to that rule, you can. But I also want to show you how you do that. Because a lot of people have trouble figuring out where those settings actually are because they're hidden. So you have to apply this rule if the sender is located inside, More Options-- add a condition. The recipient is located-- where is my recipient? Recipient is outside-- add a condition. The message properties include the message type. And here's where you find your auto-forward. That's the thing that's really hidden. Because when I select this here, notice it says, The message type is. It changed it on me. When I went and selected this, it was Message Properties that I had to select. When I'm looking at a rule that's already created, it says the message type is. So it changes the wording on you. And that makes it really difficult for people to find. So Message Properties, the type is auto-forward. That's how you're actually going to find that setting. If you've not done anything to secure your environment, do that first. That's is going to be one of your really critical, critical things to do. So I want to show you how to limit your email by location. Now, most of the time when you're setting up your email, you're going to do it from the Security Center. When you're setting up your email on security policies, you'll set it up from the Security Center, not from here. However, for this one, we actually want to set it up here because it's so much easier. And it's only this one setting that's easier. If I'm in my Security Center and I try to filter my email by country, I have to select each country individually. However, in my international spam here, if I wanted to go ahead and add countries that I don't want to receive email from, I can go Shift + click and select them all-- add all 248 countries out of 250. And then I can just un-click ones that I might actually need to get email from and then hit OK. And then what I end up with is all of my countries in my filtered list. So filter email message sent from the following countries or regions, meaning I'm not going to get any email from any of these countries. And that is absolutely fine for this company. And so that is a really great way to reduce your email footprint. Now, when we go to configure the rest of our email security policies, we actually do it from the Security Center. And we're going to do it from the Security Center under Mail Flow-- sorry, under Threat Management and down here under Policies. And this is where we see all of these really great policies-- our anti-phishing, safe attachments, safe links, anti-spam. And so let's take a look at our anti-spam rule first. And you'll see that we have several of them. But the most important one is this one. We've got our bulk spam actions. Where do I want my emails to go? I want them to go into quarantine. I want them to be delivered to the junk mail folder. Whatever you would like to see. Whatever is appropriate for your organization. Remember, this is an MSP that we're looking at. Our clients actually send us spam and say, is this spam or is this phishing? So we operate a risky environment, because we actually need to see those things. But we do send them to the junk folder. And then we send our bulk mail over there as well. And then down here, you're going to turn on your safety tips spam ZAP zero-hour purge is really awesome. So what this is-- the ZAP filter at Microsoft says even after an email has been delivered, if Microsoft's intelligence catches up and realizes that oh, hey, that URL we have finally checked it, or that website that it went to, it's been reported as being a bad site. It will go back in and zap that out of your inbox, even though it's already been delivered to you. That's a pretty cool feature. Here was that international spam that I pointed out here. That if you edit it here, one country at a time-- very, very painful. Under Spam Properties, this is the one that I really wanted to point out to you. These are additional things that can really help you fine tune the types of email that are getting through. So I typically will turn these all on, unless you find that they're causing a problem, then turn them off. So I would start with all on and then tune it back if you need to-- if there's empty messages. Who gets a blank email? Those are always bad. So let's mark that as spam. These things are going to do is not say, oh, if that happens, this is spam. It's going to say, if these happen, let's increase the likelihood that we're going to mark them as spam, just up them a little bit. So be sure to expand out these little arrows here and check those items. I want to show you too-- oh, so much time. Antique-phishing rule real quick-- No Phish All. When you create this rule, the first time that you're going to create it, all you're going to do is, it's going to ask you for a domain name. And then click, and it'll look like it's done. But it isn't done. All it did was create a space for you to create your rule. So you will have this rule, whatever you call it. I call mine No Phish All. But it won't have any settings configured in it. You have to come back into here and configure these settings. And that's everything down below here. So when you come in, you're going to go ahead and add your user base in here, one by one. It's a little bit painful, but that's going to cause Microsoft to take a look at these addresses and make sure that they are exactly those letters and haven't have been spoofed in any way. You will add any custom domains. You can also add domains from clients of yours, customers, vendors, that you know who are not protecting their mail in a way that you think it should be protected. Maybe if don't have a great IT environment, so you can actually add those domains in here. Microsoft will pay special attention to those and give them a extra thorough looking over because they're coming in. So we're protecting, actually, external domains to ourselves that we know that we're going to mark as a little more risky than others. And I think that's mainly the thing that I wanted to point out to you guys as being really critical in that rule. And I know that we're out of time. So we have really gotten through all of the settings that we needed to. If we take a look real quickly at where we're at, the only thing we did not get to today was the Microsoft Secure Score. I encourage you to go out and take a look at that. Secure Score is really nice because it gives you kind of a framework for seeing where you are relative to other companies. And Microsoft actually has a lot of security items in there. You can click on them and it will walk you right through how to add those. And it will even prioritize them for you as well. So I would consider that the secondary thing. If we do all the things we did today and then go to that afterwards, you'll be in really good shape. This has been excellent, Amy. That is an awful lot, as well. I want to make sure that people know, I will send out the slides afterwards. And I'll also send the link to where this will be posted live. It won't be live today, probably. It's probably tomorrow, but where you can also watch the recording. I'll send that link, check it in a day or two, and it should be up there. We do have some questions. And I would like to go through those, since this is being recorded. So if somebody wants to come back and listen to the question, the Q&A, they can. So first, this is the first one. I thought it was important. Is there a minimum license requirement for MFA or conditional access? No, it's included in all-- well, MFA, no. MFA is included in all the licenses. Now, Conditional Access is not. Conditional Access is included in Azure AD Premium 1. There's a couple of exceptions to that, but that's the gist of it. So here's someone talking about the recommended characters when you were talking about setting that password. So you said it recommends 255 characters for you break-glass account password. But this person is saying that the 23 characters are sufficient to defeat all current brute-force dictionary or hybrid password attacks, question mark. So I think maybe he's asking if 23 is sufficient enough, or, I guess, why use the full 255? Did I lose you, Amy? Uh-oh, folks, we might have lost Amy. I'm going to give it another second-- another minute-- to see if Amy can reconnect her audio as we get through this. I will say that if you go out to the expertsconference.com, all one word, you will see a tab there called Tech Talk. So you can look at past Tech Talks. And that's also where you will find recordings of the past Tech Talks and then the recordings for this one. It looks like Amy had a drop altogether. Must be having some technical difficulties over there. Our bandwidth issues are always a problem, it seems like, nowadays. We do have several more questions. I am sorry that we did not get to it. I am going to download these and I'll see if Amy can answer some of those. And I will email out the Q&A along with the slides. So that way, you can have your questions answered. That is certainly what the Experts Conference is all about, is engaging with peers, and experts, and asking your questions, and getting them answered. So I will make sure to get you the Q&A that we unfortunately couldn't get to today. Thank you for your time and attention. And I will be sending out those attendee receipts for those people who had requested that for their CPE credit. Oh, Amy, is that you? Yes, my power blipped out. We had a blackout. So let's do that Q&A real quick here then, instead of writing it out. I was going to email to you about that. Let's just go through and answer it so it's on the recording. So someone asked about the 255-character break-glass account password. They're saying that they thought 23 characters was sufficient to defeat brute-force dictionary hybrid password attacks. I guess, why would somebody use more than 23? That might be the question. Why not? Why not would be my answer. Today, [? the ?] 23, but [INAUDIBLE] always one step ahead of us. Since [INAUDIBLE] could be one step ahead of them for a change. Next one, are there any changes to the recommendations when using the Microsoft G version-- government version of Office 365? Any, maybe, big changes from what you went through that might be different? No it really should be exactly the same, whether you're in government, or education, or any of them. Someone asked, why not use Exchange Online Client Access rules instead of Conditional Access for blocking legacy authentication. Because you have to figure those per user. And the conditional access allows us to configure [INAUDIBLE]. That makes a lot of sense. That would save a lot of time, too. So here's somebody-- he says he's confused. He said two months ago, Microsoft said to enable security defaults instead of using baseline policy for conditional access. He posted a link to some Microsoft article. Yes, they did. It's really interesting. They've changed their mind on this a few times. So they even changed their mind on the break-glass account. So I'll tell you about this. They originally were suggesting that you create two break-glass accounts. You have one exempt from MFA, one exempt from conditional access in case either of those [INAUDIBLE]. You would still have an account you could get [INAUDIBLE] Then they said, well, you just now need one. And you need some recent Microsoft thing to say, oh, just skip it altogether. Just make sure you have enough global [INAUDIBLE]. And I'm not really comfortable with that. So I think you do want at least one break-glass account. In the security defaults, Microsoft pushed these out and said, hey, these are going to be the security defaults. And this is what we're going to [INAUDIBLE] and this is what we're going to use. And they went back and said oh, well, we're going to do that. But only in so far as you haven't created any of your own conditional access policies. In which case, ours are-- you won't be able to do that if you have any of ours in place. So it's been a little bit of a process with them. I'm not saying don't use the security defaults [INAUDIBLE] the process now is [INAUDIBLE] there is a secure by default thing, but recommending that you go ahead and recreate and make them your own so that you can then further utilize conditional access tasks. What happens with IP V6 addresses? They don't have a country assigned to them in the sign-in logs. I'm not 100% sure. There is a little checkbox that says Also block unknown addressing. And as far as I know, that's how Microsoft is addressing those currently. Next one, is it better to use the trusted IPs-- or I'm sorry, I said that wrong-- trusted IPs or named locations? I prefer the named locations over the trusted IPs, just because that trusted IP thing, as I pointed out, is kind of funny. And the name locations is something that's more visible that you'll be in more frequently as an admin. Of course, it's trusted IP. Oh, my gosh. And as you're saying this, I am typing the response. Our Cloud App Security and the Azure Sentinel only with A5, or do they work with A3? Cloud App Security is a separate license. It doesn't come with 3, but it may be part of 5. I think it is part of 5. It's definitely not part of 3. But you can add on just Cloud App Security if you don't want to go all the way to 5. What about creating canary accounts that look like VIPs and setting really high alerts and audits, almost like a canary server and in IDS or like a honeypot or honey port? I'm not that kind of a security person. You could certainly do that. I don't like to do anything that draws people to my tenant. But it's up to you. We've got a couple more questions that just came in. So here's somebody. What's the difference between using-- oh, you talked about this-- the difference between using the security defaults and creating custom policies for MFA? The difference is that if you use the default ones, you're not able to use your own. So you do have to go in, create your own, so that you can use conditional access for other things, like the named locations policy that we created. And awesome, it was a great presentation. Thank you, somebody else said, very informative. Those are always good to hear. And those further questions-- I know this is [INAUDIBLE]. There was a lot of things in that CISA article. And then a few other things that I wanted to add to it as your baseline. I definitely encourage people to go back through and look at it again. Because I know I just was throwing tons of stuff out there in a very short amount of time. But it's all really important. This is excellent, Amy. Thank you very much for walking us through this. Thank you for making it very demo-heavy. That the kind of content that we like to see at Tech. I know that is the type of content that attendees here and at the conference want to see. So I think it hit the perfect level, even if it's a lot. People can go back and watch that recording. So thank you, Amy. Thank you, attendees, for staying on, listening, and for your engagement today. And have a good rest of your week. Thank you.