Five Easy Security Wins in Windows

Every communication medium we've ever invented as humans has, at some point, been pressed into service as a malicious tool. A lot of us do what we can to use such tools for good, or at least for benign purposes. The worse-but-not-quite-worst of us humans love to hack, scam, and swindle others to get what they want. With Microsoft Windows having such a huge marketshare versus 9,001 flavors of Linux and Apple's Mac OS, MS's operating systems and programs are huge targets for malicious actors.

As a Windows sysadmin first and foremost, I feel that pain and do what I can to keep my users safe. (Side note: I also love to waste scammers' time--if they're talking to or emailing me, they're not using that time to take advantage of someone more trusting and/or gullible.) And despite being primarily a Windows sysadmin, I'm also a lover of open-source-everything, ESPECIALLY knowledge. Below, I'm going to share five easy(ish) things you can implement to beef up your Windows environment's security.

Now, these are fairly easy, but some of them are time-consuming. And of course, don't skip due diligence--make sure any change you make is right for your environment. Moving on... the list!

1. Bulk up your password policy in Group Policy. Too many organizations are still running awful password policies--think 8-character minimums with 90- or 30-day expiration periods. Not only is an 8-character password (or anything short enough for LM hashing) easy to crack, but having to change passwords frequently really pisses off most users. Instead, change your expiration period to 365 days, and require at least 15 characters. Not only will users not be able to use Pass1234 as a password anymore, but they also won't have to change it a month later to Pass1235. The 15-character count will also make LM hashes/databases useless, as they only work for passwords up to 14 characters. "But what if we have AD-integrated legacy apps that require shorter user passwords?" Well... ditch that crap. It's 2021.
   
   Estimated time: < 5 minutes (plus ~90 minutes for GP refreshes)
   
   Group Policy path: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy
   
   
2. Lock down mail-enabled security groups in Active Directory. If you have a bunch of mail-enabled security groups in Active Directory that any Tom, Dick, Harry, and Sally can send mail to, consider changing that. Reduce the number of public-facing mail groups, or at least make more of them internal-only if no one outside of your organization should be emailing them. Making these groups internal-only, or limiting how many you have in general, will help prevent spam emails from reaching more people if the spam makes it past email filters. All you need is to show advanced features (View > Advanced features) and compile a list of users'/groups' distinguished names (DNs). If either authOrig or dLMemSubmitPerms properties of a mail-enabled group are not set, that means anyone can send an email to that address. (Hello, 1,908,762,909 emails to allstaff@domain.com asking if you want to buy contact lists or gift cards.)
   
   Estimated time: 5 minutes per group
   
   Active Directory path: User object or other security group > Properties > Attribute Editor > copy distinguished name, and paste into: Mail-enabled security group object > Properties > Attribute Editor > authOrig (user DNs) OR dLMemSubmitPerms (group DNs)
   
   
3. Require SMB signing. If you don't already require SMB (Server Message Block) signing, this change will probably take you less than a minute to make. There are four possible settings regarding SMB signing, but the one that will keep your environment most secure is "Digitally sign communications (always)". So what does this SMB signing requirement do? Well, it shuts down SMB relay attacks--see this explanation in Microsoft's tech community.
   
   Estimated time: 1 minute (plus ~90 minutes for GP refreshes)
   
   Group Policy path: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft Network Server
   
   
4. Set up file screens in FSRM. If you have an on-premises file server running a Windows Server operating system, you'll want to familiarize yourself with FSRM (File Server Resource Manager). What file screens do is allow you to set up lists of trusted or untrusted files and extensions so that you can better control what can and can't get saved to your file server. While file screens are easy to set up, they can be a little time-consuming to put together depending on how thorough you are with whitelisting or blacklisting. You'll also need to determine which method is better for your environment. For example, whitelisting requires that you populate your file screen with entries for any specialized software you might run like *.ai, *.xcf, etc. Blacklisting will require that you populate the list with untrusted extensions like *.conficker, *.krab, *.vbs, and anything else you might find on known ransomware extensions lists. This isn't a perfect system, but it at least protects you from existing threats.
   
   Estimated time: > 1 hour
   
   FSRM path: File Screen Management > File Groups > Create new file group, and then go to File Screen Management > File Screens > Create new file screen > Define custom properties > Check file group
   
   

   

   An example of FSRM file screen creation to block files
   

   
   
5. Enable logging and start auditing privileged access. Group Policy and Event Logs come together in this easy win that gives you better visibility into what's happening in your Active Directory environment. Once you make the changes to Group Policy below, you'll be able to see event logs on your domain controllers when accounts are created and deleted, when security groups are created/deleted and have members added/removed. It's up to you how to set up alerts when those events happen, but I use PowerShell to scrape the logs on all DCs every so often and write files to our file server... and from there, FSRM handles the file monitoring and email alerting.
   
   Estimated time: < 5 minutes for Group Policy (plus 30+ minutes for setting up FSRM/alerts, if desired)
   
   Group Policy path: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policies
   
   • Audit account logon events (success, failure)
   • Audit account management (success, failure)
   • Audit object access (success, failure)
   • Audit privilege use (success, failure)
    

I hope this list has been helpful and useful for other Windows sysadmins. (I'm going to pester Justin to write something similar for Linux, and will also glare at him for suggesting that my #1 tip here should have been "Install Linux.") Secure environments take time to build up, but at least there are easy wins sometimes! And for other Windows sysadmins out there--what kind of easy security wins have you implemented? Tell us in the comments below!