The current scenario - Critical aspects
SDN security is in its infancy at present, and so many of the challenges shown above have not been fully addressed by the industry.
The advantages of Securechain over traditional security approaches is that its inherent programmability can be technology and vendor agnostic, and so can interface with any SDN vendor and across vendors’ different technology and APIs.
Because Securechain is blockchain-based, it runs everywhere and cannot be taken down. Its rules for accessing or rejecting elements cannot be tampered with without changing the blockchain, and as the records are stored in the blockchain, it provides for an unchangeable, forensically auditable record of events.
The use cases developed and solution architecture
Two basic use-cases are shown below, to aid understanding of the Securechain operation.
- ADDING A DEVICE TO THE SDN:
One basic use-case is adding a device to the Software Defined Network. The first thing to happen would be the admin panel or trusted entity sends the request to the Blockchain from a whitelisted ‘Command Wallet’ to the ‘SDN Wallet’. This request is then stored in the blockchain, which acts as the sole gateway into the SDN. The code interfacing the blockchain with the outside world is polling for new instructions and once it has seen a valid request, it will process its contents. In this scenario the transaction/request has come from a whitelisted wallet, with a valid instruction, so the instruction can be implemented and the valid network element added. NB - In practice, this code would reside within the Ethereum Blockchain itself, but is shown here externally for ease of understanding. The network will inform the SDN controller to allow the device to start functioning and the element will then be part of the SDN.
- ROGUE ELEMENT REJECTION:
The second use-case is the rejection of a rogue element. In this case, a hacker with a valid instruction, but with a wallet address that is not whitelisted, and/or without the correct code within, is sending a message to the Blockchain to attempt to add a rogue device. Because this instruction has originated from a hacker, the system rejects it, and the device is not added to the SDN. At the same time, an alert is sent to the network admin to warn them of the hack, providing key details of the including wallet ID of the hacker and timestamp. In addition the rogue request is stored forever in the blockchain, which allows for a security audit at a later date free of the possibility of tamper.