Every now and again, something happens, and there is a genuine learning experience for our customers that it's worth writing it up and passing it on. This event was around bank details, the need to follow through on a few simple policies, and the importance of following them to the letter.
We have discussed this on several occasions. When a bank detail is changed, a great deal of care needs to be taken to ensure that you don't get duped. This is especially the case when that bank detail belongs to one of your primary suppliers. As your business grows, your primary suppliers tend to get the lion's share of a growing amount of your monthly payments, so when they change banks, you'll need to amend details that can potentially cause £10,000s or even £100,000s to be misdirected if you aren't careful. Our experience this month allows us to ram home some truths about how things work.
This month, Mimecast changed their bank details. An email arrived saying they were moving their bank account and that we needed to change the bank details for the monthly payment before the end of August.
The first lesson here is that email is an untrusted medium. Obviously, we accept emails all day long and act on them, but when it comes to changing bank details, we must treat email as it is (an untrusted source). In Nitec's case, we have a policy for checking bank details manually. We do not allow bank detail changes without a person–to–person telephone conversation with a known contact or a contact from the website (e.g., by ringing the main line and asking for Accounts).
In our case, a staff member called and spoke to someone, and all appeared good, so the payment for the month's end was added, and the beneficiary authorised.
Fast forward a day when the bank called to say that they had placed the transfer to the new beneficiary on hold.
Questions were asked on how the person had been checked, and it turned out that the number on the email had been contacted as it stated, "Call this number if you have any questions." In this case, it all turned out fine, but it is worth pointing out that anything in the email asking for changes should be considered poisoned. We called again using phone numbers we knew from previous use, and it turned out that the answer was the same. They had changed their bank details, and they were now correct. This highlighted an area for some tightening in our processes. It's worth trying to ensure that staff also understand the intent and purpose of the policy rather than just the mechanics. This aids better staff freestyling when the hacker is not following the script strictly. Something we arguably needed to do more of in this case.
One thing that came to me after this had been resolved was how everything had been amicably resolved. The bank called to say that the payment would be cancelled off the system, and frankly, we weren't that bothered; it did indeed lapse and get removed. As far as Mimecast are concerned, Nitec is good for the money, so no one was throwing toys out of prams.
In the next few days, everything was worked out in a calm and collected fashion, and the payment re–entered and paid. No fuss.
The no-fuss element of this is the one best focused on today. Whenever you aren't dealing with some hacker disaster, everything moves along normally, and a limited amount of moderate pressure is applied. My experience of talking things through with clients who have been on the wrong end of a hacking attempt is the natural injection of pressure, fines, threats, loss of work, etc., to try to get you to do what they ask without stopping to take stock. Total panic ensues.
So, the one takeaway from today is that whenever you feel under pressure to do something that makes you feel bad or has triggered your spidey sense at all, you should stop. Inject reasonable delay into the process and see how that person handles it. If they are genuine - and I proved it in this event - no real pressure is added, and time is available for you to ask reasonable questions and wait for answers. The stress and ramping of consequences are a significant tell of hackers and one you ignore at your peril. Never deviate from your policy, no matter how hard you are pressured. The guidelines are in place to protect you.
If you don't have any protections or policies currently, write some down so you can talk with staff ahead of time about what is expected and how to deal with bank detail changes. Nothing presents as much risk to your company's net worth as not having policies in place. It's right up there, at any rate, probably just pipped at the post by ransomware but still a significant and ever–present risk.
A final word to managers. If your management style is such that people shield you from problems because of your propensity to explode, you are the type of person hackers love. The likelihood of your staff falling victim to what might be better referred to as "Professional Social Engineers" rather than "hackers" is massively increased. Make sure that staff feel comfortable bringing these issues to you, and be careful your reaction doesn't dissuade them from doing it the next time. You can't do everything yourself, so you rely on the policies to protect you. "Losing it" with a member of staff who is inconveniently following the approach that just happens to affect you is a bad idea. Of course, this is only theoretical. None of our customers would be like that, I'm sure.