# Securing Blockchain-Based Supply Chain Workflow against Internal and External Attacks
## 2 Proposed Methodology
### Constraints
In fact, detection of internal attacks requires monitoring the run-time execution of the actual software applications, which may compromise the real-time performance of the applications. To address this, we translated the constraints into efficient conditions that can be checked in real-time as demonstrated in the results. ### Example--External Attacks

This section presents an example attack simulation scenario for an external attack, using the following steps, in order. In fact, the first two steps are similar to an internal attack scenario, as discussed above. 1. A stakeholder \(W\) initiates a supply process for buying some product \(P\), using the ICT application \(W_{a}\). 2. Stakeholders \(X\), \(Y\), and \(Z\) bid for the product \(P\), using their apps \(X_{a}\), \(Y_{a}\), and \(Z_{a}\). For simplicity we assume \(W_{a}\), \(X_{a}\), \(Y_{a}\), and \(Z_{a}\) are the same portal and are connected to each other to support digital operations. 1. The execution of the applications is protected by a run-time security monitor, which reports any violations when detected. The security monitor's focus is to protect the local ICT applications. 2. All interactions among the applications are recorded in a distributed ledger (i.e., blockchain-based) with smart contracts that only protects the collective role (i.e., agreement) of the stakeholders in the supply chain process. 3. There is an external attack on Stakeholder \(W\)'s infrastructure; it has an impact on the supply chain process, e.g., data of their customers have been breached or their system is compromised due to some other attack. The blockchain cannot detect this attack because it cannot directly use this information to protect the system, as it is not encoded on the smart contracts. Our prototype monitor is able to handle this attack through dynamically reconfiguring the set of active stakeholders in the process, based on the list of safe stakeholders as described in the constraints. In fact, the prototype stops the compromised stakeholders \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Process**} & \multirow{2}{*}{**Operation**} & \multicolumn{2}{c}{**Normal Execution**} & \multicolumn{2}{c}{**Threat Detection**} & \multirow{2}{*}{**Overhead**} \\  & & **Time (s)** & & **Time (s)** \\ \hline \multirow{2}{*}{Procurement} & Issue & 0.00201 & 0.00203 & 0.9852\% \\  & Review & 0.00300 & 0.00303 & 0.9900\% \\ \hline \multirow{2}{*}{Supplier} & Issue & 0.00309 & 0.00312 & 0.9615\% \\  & Review & 0.00401 & 0.004045 & 0.8652\% \\ \hline \multirow{2}{*}{Warehouse} & Issue & 0.00403 & 0.004071 & 1.0071\% \\  & Review & 0.00406 & 0.00410 & 0.9756\% \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Evaluation of internal attacks. altogether from participating in the process. As discussed in the above scenario, consider that, in a supply chain process, one of the involved stakeholders is under a data breach attack and becomes vulnerable. The blockchain again fails to detect this local attack. However, our prototype is able to handle such incidents, through external information; that is, whenever a stakeholder becomes vulnerable, we add their identity as a constraint and the system does not allow the stakeholder to participate in the process. As sketched in Table 3, our monitor was able to detect external threats in real-time with an average negligible overhead. Specifically, the overhead of application execution increased approximately by 1%, and the smart contract by approximately 1.15%. The table shows the time (in seconds) required to complete the execution of a normal operation and also the time required to detect the threats in the corresponding columns. Threat detection involves fetching constraints from the network database and then comparing the constraints based on the application data to avoid their violation.