The recent Verkada breach, initially reported to Bloomberg by the hacking group known as Advanced Persistent Threat 69420, is yet another recent example of the vulnerabilities inherent in our increasingly connected world. With estimates as high as 1 trillion connected devices by 2025, it is inevitable that every organization will have exposure through IoT devices, and they must carefully consider more than just the security of the IoT devices themselves. After all, any ecosystem, especially one as pervasive as IoT, is only as secure as its weakest link.
When designing, deploying and configuring/implementing IoT devices and their related infrastructure, compliance and security should be evaluated at each layer and for each vendor in the ecosystem. Sometimes organizations perform reviews for their IoT device compliance and security, and in those cases, the IoT devices might be evaluated during vendor selections; but are organizations equally evaluating the compliance and security of the “private cloud” the device runs on? Or the device management solutions that are monitoring the IoT devices?
Not only should the compliance and security of the entire ecosystem be an important consideration at selection and implementation, but it is critically important to consider and incorporate an ongoing monitoring capability.
This particular hack was not overly sophisticated; a publicly exposed Verkada development system was storing a hardcoded “Super Admin” account and password. Through that single compromised account, the hacking group pivoted their access through Verkada’s infrastructure to obtain “root” access on the cameras Verkada had sold and deployed to hospitals, governments, psychiatric wards, banks, non-profits, major enterprises, universities, hospitality companies and other organizations that touch the lives of untold numbers of people. The hackers, claiming to have access to over 150,000 cameras, may have had the ability to access the broader networks of Verkada’s customers because the attackers could potentially hijack the cameras to execute their own code. One of the hackers responsible for the breach is quoted as saying “obtaining this degree of access to the camera didn’t require any additional hacking, as it was a built-in feature.” Many IoT devices promote full remote access and configurations as a selling point, and are often deployed in locations that are difficult or expensive to get to and physically update each device. This further emphasizes the importance and need for robust security measures around the remote platforms able to access those devices.
An IoT device itself may be secured to the point of being ‘compliant’, but the underlying applications and access across multiple customers certainly do not make the IoT device secure. This is most obviously indicated by the ability to remotely gain root-level access with a single set of credentials.
There are several important lessons about IoT ecosystem security to be learned from this breach, and in future blogs, we will explore those lessons from a few angles: the IoT device/application provider, the organizations impacted, and the compliance and privacy implications introduced. We will provide practical strategies for evaluating the security of the entire ecosystem and mitigating risk from each angle. For example, Verkada’s platform advertises HIPAA, GDPR and PCI compliance – all of which require varying degrees of security controls or even penetration tests. Were these evaluations and tests inadequate? Was there a significant change that occurred after review or implementations of these controls or the penetration testing performed? Could Verkada have been aware of potential vulnerabilities, but hadn’t yet addressed the issue?
As we expand upon the concept of end-to-end IoT ecosystem security, there are a few key questions to consider early in an IoT deployment lifecycle:
- What are the potential ramifications of a breach at any layer (device, connectivity/transport, the management or control application and where that control resides [remote/local])?
- Does my third-party risk program assess the risk of IoT devices and technology prior to procurement and introduction to the company’s environment?
- Who is responsible for the ongoing security of the IoT device’s management or control application, and is this responsibility dependent upon the layer in which the breach occurred?
- How is a device connected to my organization’s network and/or access to data? How is it connected to another organization’s network and/or data?
- What controls are in place at each layer, should a breach occur, to limit exposure and access?
In addition to considering these questions initially, and proactively monitoring their IoT solutions, organizations should be sure to routinely review and update the processes, policies, and technology in place to ensure the end-to-end security of their IoT deployments. As the world becomes increasingly connected and IoT becomes more prevalent and important in organizations, it is imperative to establish appropriate risk management processes now before it is too late.