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 covered the beginnings of the first points under the Identify heading. There are a few more items to be covered under that umbrella, and we’ll discuss those here. Part 1 started the identification process, and now we’ll continue to finish this item from the list.
We’ve covered logging and internal sources pretty thoroughly there, but I’d like to call out one item again – web-based email systems. These are becoming more and more common, and are rarely under direct control of the enterprise – they’re hosted elsewhere.
- Are these webmail systems logging?
- Are they logging in sufficient detail to allow for investigation of an incident?
- What is the log retention policy of the provider, and is that sufficient according to your data retention policies?
Do not take anyone’s word for this – test. Request a set of logs toward the end of the retention period, and ensure that your provider can supply them. Examine these logs as you would for a true incident. Make changes to process with the provider if necessary, and repeat until the results match your expectation.
The next point is a fun and valuable one:
- Identify and flag similar or suspicious domains that could be used for spoofing or to trick users into revealing credentials.
This is where the geeky command line people on your team will have a party. There are free, command line, Linux-based tools available to help you identify domains that could be used to spoof your users. URLCrazy and DNSTwist are the two I’m most familiar with, although a number of free and paid web-based tools are also available. (Lisa’s theory of technical geekdom – if you give them something FUN to do, they’ll work harder at it…) Check your logs – have you seen traffic from these false domains? Are they registered by less than legitimate entities – and worth blocking their traffic?
Now you know what you have, and what logs you have. How are you going to use it?
- Implement a system for users to alert the security team on suspicious email activity and a mechanism to alert users to emerging attack patterns as they happen against your organization.
How will your team monitor for suspicious email activity? How can users report suspicious items? Do not make this process dependent on an individual…absence or vacation can put you at risk if it rests solely in single hands. A shared mailbox, an automated system…there are a number of good solutions depending on your staff and the maturity of your program.
The last item under Discover is an important one.
- Make sure that someone with appropriate access to perform email log analysis, authentication analysis and make control changes is available at all times. Have a backup staffing plan in place for long incident timelines. Socialize this information as appropriate.
Who’s on first? Yes, your staff should have a life – and no one person should carry the load. An on-call rotation may work well for you. Consider what happens if an executive feels they were breached, or clicked on that email, on a late Friday evening. Should that wait until Monday? Maybe…or maybe not. In the event of an incident, sleeping, eating, and other life hazards WILL prevent people from working 24/7. Plan in advance how you’ll handle a long engagement.
A lot to think about here, again. We’ll discuss Protect as the next items in the series.