# An Effective Blockchain-Based Defense Model for Organizations against Vishing Attacks
## 3 Preventing Social Engineering Attacks Using Security Principle
### Framework Design Description  
#### 4.3.1 Control Flow Description  
This section describes a scenario of the different interactions that could occur during the execution of the model within an organization. We choose, as a demonstration example, the Banking sector where the hacker aims to exploit the over-helpfulness of help desk employees. The SE attacker wants to switch [PERSON]'s account-associated phone number to one of his phone numbers. If he succeeds, the attacker might use [PERSON]'s account to complete numerous transactions. The scenario is inspired from ECC Council's _Certified Ethical Hacker Study Guide_[30], more specifically from the vishing attacks section. Following, we describe the control flow without deploying the proposed model and then after applying it.  
Control Flow Description before Applying the Proposed Model  
Social engineering attempts regularly target help desks. Since the staff employees are instructed to be helpful, they frequently divulge private information, including passwordsand network details, without first confirming the caller's identity. To be successful, the attacker has to know the identities of the workers and specifics about the person he is posing as. When calling a company's help desk, an attacker can pose as a senior figure to obtain access to confidential information. In this example, a person contacts the help desk of a bank corporation and claims to have changed his phone number, requesting to change the current bank account associated number to another new phone number. He continues by saying that his employer could fire him if he misses the transfer of an important advertising fee within the next thirty minutes. The help desk staff member immediately changes the bank account associated phone number out of sympathy and unintentionally allows the attacker access to the compromised bank account.  
In this scenario, the hacker achieved his goal by exploiting the over-helpfulness of the recipient (help desk employee). There is no control to verify the correctness of the recipient's action.  
Control Flow Description after Applying the Proposed Model  
It starts when the organization recipient receives an external call from an unknown person. The caller requests to change his or her account-associated phone number since the telecommunication provider has changed. The recipient will provide the caller with any public information. However, when asking for confidential information or modifying data, such as passwords or phone numbers in the case of a banking organization, the recipient will ask for more identity details already specified by the organization. Once receiving the caller's required identity parameters, the recipient will send a request through the blockchain network to modify or perform some tasks. Requests are transformed into smart contracts via a dedicated front-desk application and sent to one, two, or more transaction verifiers according to the organization's policies. The verifier could be a cybersecurity agent, a bank agent, a data custodian, or any permitted entity by the organization. They verify the request and can endorse (accept) or reject the transaction.  
In case of transaction acceptance by the verifiers, the requested information is returned to the recipient. In case of SE attack suspicion, the recipient is alerted of possible SE attacks demanding more details or ordering him or her to end the call and block the caller number.