Business Email Compromise
Recently, we posted the Business Email Compromise (BEC) checklist. We’ve gotten a lot of great feedback on the checklist…as well as a few questions. What if you’re new to security? What if your organization’s security program is newer, and still maturing? How can you leverage this list?
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.
Getting Started:
Let’s begin with the first category – Identify. The first action item under Identify is:
- Identify and catalog all of the authentication portals where attackers could test stolen credentials or leverage them for access.
What does that mean from a real-world perspective? The first step is understanding the external exposure of the organization. How can you do this? A few items that you might leverage to catalog the exposure would be:
- Asset tracking – what do you know about?
- Firewall audits (both ingress and egress) – what are you allowing in and out, and how can they proceed past the firewall protections?
- Network maps – do you have them? Are they up-to-date? These should be a living document, and reviewed regularly with staff who are not maintaining them as a sanity check.
- Vulnerability assessments – when is the last time you have one performed? These are valuable not only from a catalog perspective, but for detecting old, defunct, and unintentional exposure.
Don’t forget to consider access points that you may not directly control. Remote systems, such as cloud based email servers that rely on network authentication or vendor systems that leverage SSO (single sign on) are also attack vectors.
The next step would be to catalog your exposed surfaces and their authentication mechanisms. Do they leverage Active Directory (AD), SSO, or another method? Is multi-factor authentication available, and if so, is it employed? What is the crossover between these exposures – what could one compromised password potentially access in other systems?
Once you feel you have an adequate catalog, it’s time to consider the individual exposures, and review the information you have available from each.
- Does the device support logging, and is logging enabled?
- Are the logs being preserved? A minimum standard would be your organization’s records retention policy.
- Are the logs configured properly, so that success and failure are logged, and the specifics of the attempt are captured?
- Are the logs capturing information sufficient for investigation? For example, if the logs are capturing IP information, but you are using a DHCP scenario where IPs are leased for a short period of time, are the logs configured to capture hostname and user ID to properly identify any problematic systems?
This is a pretty big step for step 1 – so we’ll pause here for now. How does your organization compare against these suggestions?
Part 2, part 3. and Part 4, Detect, are now complete! 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.