Below are the steps you must consider when implementing this control.
Identify your organisation’s high risk events
Your organisation is going to have a lot of business processes. The first step of implementing this control is to understand what processes are used, so you can prioritise the ones that involve sensitive data, access, or financials.
Start off by making a list of internal business processes that carry high risk. High risk includes any process failures that could have a large impact to your organisation, such as a payment not being received, a payment being paid into the wrong account, or loss of access to an account that holds sensitive data. One of the most common incidents you need to be on the watch for are invoice scams, where payment details are changed after an invoice is sent - causing you or your customers to pay the wrong person.
To start preparing a list of high-risk processes, you need to consider processes requested verbally, in-person, or digitally (over email or social media).
That list can include:
- requesting a password request
- making or changing re-occurring payments
- assigning administrative access
- requesting sensitive information (for example customer or employee information).
For each of these processes, you need to identify:
- who within the organisation normally carries out these actions, or who has access to perform these actions,
- what is considered normal (or business as usual) for these processes, and
- how many of these requests are received on a regular basis.
Identifying what is “normal” may require you to sit down with those process owners and talk through a few examples. For example, if your organisation receives a lot of password resets due to the size of your organisation, you will need to consider this when designing an out-of-band verification process. If you don’t design it with what normal looks like, you run the risk of creating a process that will be actively avoided so people can get on with their day-to-day jobs.
Add or design a second level of verification
Once you have a list of your processes that are important to your organisation, you can start configuring a second layer of controls based on those with higher risk.
Implementing a second level of verification is more straightforward compared to multi-factor authentication as it tends to focus less on technology and more on manual processes.
Each high-risk business process on your list will need to be re-designed to include:
- A way of contacting the requester through a different channel to verify their request
- Having an escalation point in case it can’t be verified (for example the user’s manager or system owner)
- An incident response process if the verification process fails.
A different channel needs to be either a publicly listed channel (such as a phone number listed on an official website or social media profile), an internal directory, or a private channel where you have spoken directly with someone before (such as a saved SMS or phone number in your phone).
An important step of designing this control is to test it with a small group of people first. That way you can validate how often the process has to be carried out, and how much additional time it adds to the process. The wider team may need additional training or tools to perform this process and should be prioritised and rolled out before the new process gets put into place.
Request your third parties and suppliers who you often work with to have a similar process. This is an effective and low-cost security control that could help both you and any third parties you work with in the event someone in your organisation had their email compromised.
After you have a second level of verification in place for your prioritised processes, it is important to perform monitoring.
For your business processes, you will want to make sure that each verification failure is treated as a high priority security event and therefore needs to be actioned quickly.
Once an incident is recorded, the response steps should include:
- Letting anyone else who performs the process know about the request event (in the event it happens again),
- Flagging the request with the system or process owner so they can take any additional actions (such as flagging the user account, or contacting the bank).