Financial Services & BEC – Tales from the field…

Recently, Brent – our CEO – put together a Business Email Compromise checklist. The checklist:

  • Enumerates attack vectors
  • Briefly reviews impacts
  • Lists control suggestions mapped back to the NIST framework model

But, what does that mean for you? Our team put together an educational series based on the checklist, to help security programs at all levels. The next thing we’d like to share are a few war stories – tales from the field in various industries. These are drawn from our security and incident response work in these industries, and call out specific attack vectors and points to consider for these entities.

The first industry we’re going to discuss is the financial services industry. Banks, credit unions, and other financial entities share many common attack vectors that repeat across our incident response work. The points from the checklist:

Identify

Logging. In addition to running IR tabletops, take your pseudo-exercise one step farther. Many financial services clients have outsourced IT support, and the tabletop will have “provider to provide X logs within Y timeframe”. TEST this. Get a set of logs, examine them, and make sure that your provider is not only logging what you expect, but can provide these logs within your expected timeframe.

It is difficult to effectively triage an incident if the provider isn’t routinely providing the logs, the provision process hasn’t been tested recently, and/or the logs take several days to procure.

Protect

The most common attack vector that we’ve seen for financial services clients is Office 365 or other web based system, and the most common missing control is multi-factor authentication (MFA). We cannot stress this enough. Geolocation controls are the most commonly employed control that has the least useful result – attackers can access a VPN that changes their geolocation as easily as someone who wants to watch US based Netflix! Geolocation can have a place in your toolbelt, but it shouldn’t be the primary tool.

Marking external emails as EXTERNAL isn’t done nearly as often as I would have thought, and that was a surprise. Most email systems will support this type of message tagging – and the cultural objections seem to be mostly “it’s new and different”. Change is inevitable – except in vending machines!

Phishing education is done fairly often, and done reasonably well. The noticeable item here is a shift in perspective. Financial services organizations – and most organizations, to be honest – consider their highest spear phishing (targeted attempts) targets to be executives, C-Suite level, etc. There are a couple of other attack vectors here that are vital to consider. The first is anyone with elevated access into the environment – network administrators, IT departments, even the help desk. Compromising the accounts and/or credentials of people who can create and manipulate the credentials of others is a high value target.

The second attack vector is anyone who moves money – wire transfer, etc. These are generally people that are not as high up the corporate ladder, but they handle a lot of the nuts and bolts of many financial transactions. Some of the most valuable things you can do is train these individuals to spot anomalies, and create a culture where they can call something out without repercussion.

If you are commonly handling things like EFT, wire transfer, etc. via an email system, please consider what additional controls and cross-checks you can put into place to safeguard the process.

Detect

Know what “normal” looks like, for your environment. Have staff who knows what the day to day traffic in your environment looks like. Have more than one person, and have some basic guidelines documented. Review this documentation periodically, and train and train again. If the triage staff for an incident has to spend time establishing a baseline, and weeding out the outliers that are really legitimate, this will create a lag before your actual incident can be addressed.

Email forwarding rules are an extremely common indicator of compromise (IOC). Have a routine process to check for modifications to new rules and/or forwarding rules, and make sure it is performed regularly.

Respond

Know how to use the tools to audit logs and activity, and practice with them. As with Identify, take it a step farther than your IR plan and tabletop – actually simulate an incident. Gather logs, analyze them, and document the results. Involve your service provider if they are part of the plan, and have them actually perform the log activities that you would expect – providing data and analysis. A small amount of overhead for an exercise is a minimal price to pay over finding a surprise gap in execution when the plan needs to be deployed.

Response is a marathon, not a sprint. The most important takeaway from our IR work has been…you may see an attacker use the information gleaned from an incident immediately, or within three months. But our financial services clients are often seeing this information manipulated and used 18-24 MONTHS after the initial incident. A successful breach or compromise will remain an attack vector for the long term. Know this, and build your controls around this information.

Recover

Document all of the policies and procedures that you need to follow. Have a contact list at the ready, and update it regularly. Practice these activities with the people who will need to execute them in the event of an incident.

Socialize these steps at all levels of your organization, and secure the buy-in from various groups as you walk through your plan and controls. This will save time and energy bringing people up to speed in the event of a true incident.

We’ll address other organizations as this series continues – incident response is a fact of life, and one of our core functions for many clients.

If you would like to read the entire BEC series:

Part 1 – Identify

Part 2 – Identify, continued

Part 3 – Protect

Part 4 – Detect

Part 5 – Respond

Part 6 – Recovery

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.

 

This entry was posted in General InfoSec by Lisa Wallace. Bookmark the permalink.

About Lisa Wallace

Lisa Wallace joined MSI in 2015 as a security focal and project manager, and became Technical Director in 2017. She is involved in internal and external penetration testing application assessments digital forensics threat intelligence incident response eDiscovery efforts She is responsible for scoping our efforts across all workstreams, as well as project and staff coordination and management. She has worked in a variety of fields, including utilities, financial services, telecommunications, and consulting in a number of ancillary industries.