Introduction

Enterprises or individuals (collectively referred to as End-Users or “EU)” recently have been burned by Threat Actors (“TA”) who pose as authority representatives from a government, bank, telecom provider, IT service provider, or any other service provider (collectively referred to as Service Providers or “SP”). They try, through what is colloquially called voice phishing, to pry information from the EU which might enable them to compromise the EU’s enterprise systems, data, bank accounts, etc. In an attempt to thwart the threat attempts, we have developed a Verification System (“VS”) which allows the EU to verify that any voice call requests can be verified as legitimate or a threat. 

How is it achieved? 

This is accomplished by training the EU to have no trust for any incoming phone call from any SP seeking proprietary information. They are instructed to initiate a verification sequence to validate that the request is from a legitimate entity at the SP. 

This provides confidence because it is achieved through multi-factors, all of which are only known by the two participating and valid entities – the SP and the EU. 

There is always an a priori information known only by each entity. In the case of the SP, they would know the EU’s phone number, email address or that the EU is a valid registered user of the Customer Portal (“CP”). The EU would know of the SP-provided phone number, email address, or CP. The CP is protected by a UserID/Password sequence. 

No matter what medium is used for verification – SMS, email, CPl – the process for the verification follows a very similar procedure. There is always something that is known between the two parties that is not generally published for public consumption such as an SP-provided SMS phone number (“SPN”), Private email address (“PEA”), or a customer portal (“CP”) with a UserID/Password (“UIP”) login sequence. 

The sequence would be as follows: 

1. The SP has reason to contact the EU, and this is done through a voice call to the EU. The SP may be a IT SP responding to a service request ticket, or a bank looking for confirmation on a potentially fraudulent transaction. 
2. The agreed upon policy between the SP and the EU is that the verification procedure will be initiated for any voice call initiated by the SP to the EU 
3. The EU, using the agreed upon medium (SMS on a mobile device, an email on mobile, laptop or other computing device, or a web-based customer portal accessed by any of the above devices, the EU starts the verification request (“VR”) by sending a Verify Code (“VC”),  #verify for example, to a pre-agreed but private SPN, or a pre-agreed PEA. In these cases, the VC must be initiated from an EU email address or phone number known by the SP. In the case of the CP, the EU logs into the CP with their specific UIP, and clicks on a Verify button within the CP. 
4. Any of the above Verify commands initiate a sequence of events within our VS that will be completed when the EU has been satisfied that the SP been verified or can reject the verification. In the event that the VR comes from an unknown phone number or email address, the VR process will not be started. However, all VR will be logged for compliance and historical recall. 
   • The VS will generate a random number (usually 6 digits, but could be any number) that will be:  

1. 1. • Sent back to the EU through the medium (SMS, email, or CP) from where the VR originated and to the respective phone number (SMS) or email address (email) that originated the VR. In the case of CP-originated VR, the code will be pushed to a banner on the CP.  In all cases the code will be sent with an appropriate message indicating its use. The message will read something thing like “The verification code ‘012345’ should be provided BY your service provider. If the code matches the one previously provided to you, you may initiate the confirmation response”. 

• • • Provided to the SP in a SP console with a message that will read something like “ Please provide code ‘012345’ to the EU. 

1. • The SP will provide the code to the EU via the phone call. 

• •  If the EU is satisfied that the SP has provided the corresponding matching code: 

1. 1. •  the EU may give a verbal confirmation to the SP that they are satisfied with the legitimacy of the SP and continue the phone call in which case the SP must manually log this response, 

• • • the EU may send a Confirmation Code (“CC”), #confirm for example, to the SPN or the PEA. In the case of the CP, the EU would click on the “Confirm” button within the CP. 

1. • If the EU is not satisfied that the SP has provided the matching code the EU may: 

1. 1. • Hang-up the phone  

• • • Re-initiate the VR 

          5. There are some ancillary functions of the VR that can be considered in specific applications. In the event that the SP has a service or help desk platform, the entire sequence of events ( VR, and corresponding response) can be logged within a service ticket for posterity when the Verification Sequence has been completed. This could be automatic or at the approval of the SP personnel.