By Shiv Kumar Bhasin
Blockchain implements strong security technology that provides integrity, availability and mutual trust, but not confidentiality, across enterprise boundaries with no central arbiter. The distributed nature of blockchain technology that goes beyond organizational boundaries makes it difficult to assess a use case at hand is best solved with blockchain security features or by a combination of conventional security tools.
Even though a blockchain network is considered to have no single point of failure, organizations could still face risks from external events outside of their control. For example, a global internet outage would disrupt even a public blockchain network as distributed as Bitcoin or Ethereum, creating outages which would impact an organization’s operations as with any other technology. Private blockchain networks with a lower number of nodes would need to ensure that their network is sufficiently distributed globally and resilient with no single points of failure on an organization or platform level to ensure continuous operation even in the event of a natural disaster or coordinated attack.
In the current generation of blockchain technology, there are insufficient privacy controls. In public blockchains, the sequence of events and activities, such as the execution of smart contracts, is recorded, propagated to all nodes and visible in public. To date, blockchains, such as Bitcoin, are “pseudoanonymous” using the hashed public keys of the parties as pseudonyms, while other data, such as the date, time and amount of the transaction associated with that event is publicly visible. Events can be any event related to your use case; for example, in digital currencies they are transaction amounts and updated account balances.
Blockchain-based architectures can help address many security issues, and we’ll see more blockchain-based initiatives around fraud management and identity. At the same time, developers and security professionals will pay much greater attention to the security risks posed by interfaces with existing systems, serious software bugs, and potential future risks posed by quantum computing.
Whitelist, blacklist, and previous transaction-based information — retrieved from blockchain-backed, tamper-evident sources (think of these as the next-gen EWS or OFAC) — will enable banks, insurance carriers, and e-commerce retailers to much more effectively combat financial crime. Any organization subject to regulatory anti money laundering (AML), know your customer (KYC), identity verification (IDV), and enterprise fraud management (EFM) mandates has struggled with these requirements to adequately vet and monitor its user population for identity theft and suspicious activity.
Blockchain data sources and future
Blockchain will become a foundational technology for: 1) certificate issuance and authentication; 2) IDV; 3) malware and ransomware protection via binary reputation checks; and 4) document authenticity and integrity verification.
Blockchain is a nascent technology and attackers will find more ways to tamper with blockchain data and services. Some of the known risks include: compromise of encryption keys, software deficiencies and vulnerabilities, loss of encryption keys, legal compliance risks, market adoption risks, governance risks, smart contracts with malicious terms, lack of scalability due to unforeseen issues.
#2 IoT (Internet of Things)
No IoT device should be able to communicate on the internet without forcing the end user to change the default password. Manufacturers should randomise default passwords based on a few factors such as date of manufacture, serial number, and distributor. Devices should also come with a strict egress filtering policy that limits where they can communicate. For example, unless the user updates the configuration by default, the device should only be able to communicate back to sites owned by the manufacturer. Firmware updates should be signed with a digital certificate. Unfortunately, none of these best practices are common practices today.
There is a plethora of IoT standards and protocols, which creates security blind spots. Today’s IoT ecosystem is a complex web of industry-specific devices and use cases that use a wide range of communications protocols (such as AMQP, CoAP, and MQTT) to enable edge devices to communicate with gateways and cloud services, as well as with different data formats and software interfaces/APIs. This fragmented approach creates interoperability challenges when integrating multiple IoT-enabled devices into any existing enterprise architecture. These interoperability challenges breed complexity and increase security threats and vulnerabilities due to difficulties in applying consistent security policies across all devices and protocols.
While IoT scenarios face similar security vulnerabilities as the traditional desktop universe, the sheer number of IoT devices dramatically increases the scalability requirements. These scale requirements may trip up traditional security solutions that try to extend into IoT scenarios or require additional hardware investment, which will make such approaches economically unfeasible. Those IoT security solutions that can prove the ability to handle scale will ultimately realise greater market penetration and success than those that don’t scale.
There is a lack of clarity of responsibility regarding privacy and security. Managing identities of IoT devices is a critical piece of the IoT security puzzle. Unfortunately, in many IoT scenarios, security responsibilities can be unclear (is it the device manufacturer, the network operator, the app provider, or all of the above?). This lack of clarity requires that developers of IoT-connected objects design appropriate privacy policies and data handling into the device, with explicit instructions on how users can opt out of data sharing as well as explicit descriptions on data usage, storage, and sharing. S&R pros also face different country-specific data privacy regulations about requirements to collaborate with their legal and line of business counterparts to develop a multi-faceted approach for managing IoT data privacy.
Encryption is an absolute must. In IoT scenarios, encryption (whether on the data, the network or both) is an essential IoT security best practice. And although encryption is necessary to meet the usual requirements around personal privacy and confidentiality, many IoT scenarios now involve automation of industrial, business, and personal processes. This may create business value, but it also introduces scenarios where breaching of these IoT systems can lead to destruction of property and equipment and even personal safety issues. The higher potential risks associated with IoT scenarios mandates encryption of data in motion and at rest and that the security team maintain appropriate key management processes and procedures to ensure integrity of the encryption keys.
#3 RPA (Robotic Process Automation)
Given that RPA is an emerging technology in the service industries, there are no standards or formally agreed upon industry controls specific to RPA. Indeed, this has been given little focus to date as the drivers have been around cost reduction and the adoption has been modest to date. There seem to be two starkly different ways that people think about automation and cyber security. While some believe that bots are basically invulnerable, since they never deviate from rules and are immune to the kind of curiosity that makes you click on a phishing email, others have nightmares about increasingly smarter robots going rogue on their networks, making them resist RPA altogether.
Suddenly, your bot doesn’t do what it’s supposed to do. It’s a fearful scenario that can be panic inducing. What do you do? Well, you obviously unplug it, but don’t leave it at that. There’s a reason the bot lost its mind, and it’s not because it has one of its own. You have to go back and reconstruct what happened (i.e. malicious or change in code/business logic or not appropriate change management or other misuse by an employee), which is why it’s so important to make sure that you have an audit log that records all activity.
RPA is often promoted as a solution that can be deployed independently by a business unit. But like any other software solution, the IT and the information security departments must be critical stakeholders in planning, deploying, and managing the solution throughout its life cycle.
(The author is the CTO of SBI Bank)
If you have an interesting article / experience / case study to share, please get in touch with us at firstname.lastname@example.org