A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?
Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.
Part 1 and Part 2 covered the first checkpoint in the list – Discover. Part 3 covered the next checkpoint – Protect. Now we’re going to move on to the next point – Detect.
The first item on the list is:
- Review logs and email authentication detections at least daily. Look for abnormal login times, unusual locations or abnormal usage patterns and investigate them when found.
As a first step, *know* what your normal is. Do you have a remote workforce? Do you have a workforce in other time zones? In other areas of the world? The more complex your staffing situation is, the more time you should spend looking at the definition of “normal”. If your office is 8am-5pm, no remote workers, and have a staff that rarely travels, this will be simple. Get to know your logs. Consider setting up alerts for anything suspect – even if you’re analyzing false positives you *will* get a better handle on what is normal for your organization. Jim wrote a great blog on why you need people on your staff that know YOUR environment – take a look at that here.
- Pay careful attention to emails that have a sender and receiver in your domain, but have an external reply-to address. Ensure that these are flagged for review and alert the user visually to the potential risk.
This is BEC – business email compromise – after all. You knew we were going to talk about email, right? Almost all email systems have a system to flag external emails as “external”. Oddly, this does seem to require some political will in many organizations – which admittedly doesn’t make a lot of sense to me. If you have automated systems making use of your SMTP relay, it isn’t onerous on your users to see “External” on these notices. (If this is an issue for your organization, please email me and indicate why? I’m trying to broaden my understanding.)
The next point, and final point for Detect:
- Pay attention to user reports of password lockouts or other email access oddities. Investigate these to ensure that an attack is not currently in progress.
Your service desk/help desk/nomenclature of your choice *is* your first line of defense. Arm them well. Create a culture where oddities are tracked, and false positives are understood to happen – if you punish a misfire, they won’t report when someone is truly amiss. Leverage whatever incident tracking you use to look at reporting and averages – again, get to know your normal.
This doesn’t seem like a lot of ground to cover but it truly is. Getting to know your normal takes time and as many of your staff as possible should be involved in the task.
Part 5 in the series, Respond, continues here. Part 6 – Recovery – closes out the series.
Questions? Comments? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!
If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.