By Sonia Vaessler
As a Product Owner developing the security feature of a Web and Mobile platform, the Internet of Things (IoT) is a high priority. The Product Owner is expected to work together with the Product Managers, Blueprint Experts and the Agile teams to build identity, authorisation, authentication and crypto capabilities which are less complex, more effective and more decisive and which can be used globally.
According to Gartner, there will be nearly 26 billion devices on the Internet of Things by 2020. ABI Research estimates that more than 30 billion devices will be wirelessly connected to the Internet of Things by 2020.
As per a recent survey and study done by Pew Research Internet Project, a large majority of the technology experts and engaged Internet users who responded—83 percent—agreed with the notion that the Internet/Cloud of Things, embedded and wearable computing (and the corresponding dynamic systems) will have widespread and beneficial effects by 2025.
In the past, hackers were primarily motivated by ego. Now cybercrime is perpetrated for monetary gain and has become a significant sector of international criminal activity. These cyber criminals have established supply chains, are highly motivated to seek new opportunities, can react quickly when an opportunity is identified, and can easily recruit talent and technical resources to achieve their goals. Since cyber criminals have time, money, and technology on their side — and since they can target zero-day vulnerabilities that are unknown and therefore hard to protect against — it is virtually impossible to ensure 100% security against a persistent and targeted attack. Connecting systems and devices to the Internet introduces the risk of people potentially gaining unapproved access to private or sensitive data through a network.
Most stand-alone devices utilise well-known operating systems and software applications, which means that vulnerabilities are often quickly identified and resolved through patches and upgrades. Think about the device you are using to read this whitepaper — how often do you receive notifications about new versions and/ or security patches being available for your operating system or software applications?
Often our devices download and install these patches and upgrades automatically without us even being aware of it. However, deploying and installing patches and upgrades becomes much more complicated with Mobile and Web devices because they are part of a larger network. Often there is no automatic process for installing these updates or even notifying users that an upgrade or patch is available because:
The developers of an integrated Mobile and Web Solution have not considered comprehensive software updates as a security feature; instead, they provide general tech support tools to fix issues that individual users find.
Updating devices that are remotely distributed across multiple locations is too challenging.
It is not prudent for devices with critical functions to restart automatically after installing a patch or update.
Without including a way to identify known vulnerabilities, alert users of those vulnerabilities, and automatically distribute and install updates/patches, hackers can use the same techniques and tools to corrupt a Mobile and Web system over and over again. At the same time, attackers could use an automatic software update tool to compromise an entire network by loading his/her own special software version onto a device. So while enabling devices to stay up-to-date with the latest OS and software versions is crucial to avoiding known vulnerability attacks, product developers must also consider the security aspects of the software update tools themselves.
Securing a Mobile and Web system’s software and operating system requires a three-prong approach:
- Developing software through a secure development lifecycle process,
- Identifying software vulnerabilities and alerting system operators of available patches/updates, and
- Installing patches/updates across the entire system.
First and foremost, Mobile and Web software developers must follow a secure development lifecycle (SDLC) process when creating embedded software for Mobile and Web devices or system applications.
Security should be baked into the system requirements, design, and implementation testing, and there should be a plan for supporting the product’s security after deployment. The process should enable developers to identify and build to the product’s required security levels while facilitating a rational level of security investment in terms of cost so that organisations are not left with an all-or-nothing approach.
The second step to securing software is creating a unified process for identifying vulnerabilities within specific devices/applications and alerting system administrators when a software patch or update is available.
Finally, let’s talk about how to remotely install software patches and updates across system devices. Although updates are typically installed through a network or USB interface, this approach makes it possible for a hacker to insert malicious code. Ideally, any software updates should be performed through an authenticated connection using a digitally signed binary file that can be authenticated by the device. Furthermore, companies must assess whether operating system updates are critical, as they can be much more costly, complicated, and even risky to deploy.
A single Mobile and Web ecosystem can utilise multiple devices developed by multiple vendors, along with multiple systems to manage these devices. With so many different technologies involved, there is not a single way to authenticate all devices. Each device may use its own authentication approach, and some devices may (by their very nature) be less secure than others. All these factors make it a challenge to ensure that authenticated devices are what they claim to be. However, if device authentication is not handled properly, an attacker could potentially sniff the network and “play back” the login session without the other server or device even being aware that it is talking to a simulator.
Authentication is a crucial step for ensuring that external devices are interacting with a legitimate Mobile and Web platform and not a hacked system that is pretending to be the Mobile and Web platform. The platform also needs to authenticate that the device requiring access is legitimate.
The best way to achieve device authentication is for the manufacturer to embed a unique certificate on the device. This would enable the Mobile and Web platform to validate the device, and vice versa. We also suggest encrypting dynamic, random information within the authentication process itself to eliminate hackers from recording and playing back the authentication sessions.
Furthermore, businesses should be utilising state-of-the-art standard cryptology algorithms for authentication. Using obsolete cryptology standards results in well-known security flaws that can be used to attack systems, and using non-standard cryptology is risky because it often results in design flaws. System developers may assume that proprietary encryption is preferable because it is not a commonly used tool like standard cryptology, but the reality is that hackers can and will unravel non-standard encryption. It is much more preferable to use standard cryptology approaches like Transport Layer Security (TLS) because of the very fact that they are widely used and therefore well-tested.
Auditing requirements/forensics auditing trail or a security trail
Designing a secure IoT solution depends on a number of security considerations. One of the most important factors is the use of a secure IoT framework for building your ecosystem. Using a secure framework ensures that developers do not overlook security concerns and allows for rapid application development. Ideally, a framework contains security components baked into the framework in such a way as to provide security by default that developers do not have to think about.
Any computer that connects to an Internet Service Provider (ISP) becomes part of the ISP's network, whether it is a single computer or part of a local area network (LAN) at a workplace. Each ISP connects to another network, and so on. In this way, the Internet is literally a web of networks where information can be sent and received to any point on the web from any other point. This global collection of networks has no 'owner' or overall controlling network, so it operates like a community with all the pros and cons you might find in any other community.
System Data & Users
Mobile and Web systems are often used to gather sensitive data such as medical biometrics, personal schedules, and inventory and supply chain information. Even when systems donor gather information that is explicitly sensitive, there is often enough contextual data that — given the right analytics tools and cross-reference systems — someone could deduce further information.
To prevent potential data leaks or thefts, it is crucial that Mobile and Web system developers identify which types of data can be shared with which systems and which users. However, this can be complicated in a distributed Mobile and Web ecosystem because of the many types of users and their roles within a system (example below):
- Platform system operator
- Platform tenant operator (only uses specific component of Mobile and Web platform)
- System IT administrator
- Hardware/application/service provider
- Hardware/application/service consumer
Ensuring that each of these users can access everything they require from a Mobile and Web system, while simultaneously limiting their access to any other parts of the system, is quite complex.
Furthermore, a user may hold more than one role or have roles that change, meaning a system must be able to update user access rights dynamically and in real-time. Furthermore, each of these user roles may interface with the Mobile and Web platform differently.
Securing multiple interfaces that need to be both readily available and high-performing is an additional challenge.
The security of a Mobile and Web system’s data and users relies entirely on good policymaking. For example, organisations should use mask keys (i.e., arbitrary data) instead of information like names or identity numbers whenever possible. By masking data, organisations can more effectively obscure content that is sensitive or that becomes vulnerable when correlated with context. It also enables organisations to comply with certain regulatory requirements regarding cloud-based storage and enables them to share data more easily with third-parties without disclosing information about their patients or customers.
The next step is to have a well-defined user map that identifies a system’s various users, their roles, and their relationships with the Mobile and Web system.
Similarly, an organisation must define policies for which users can access which data or systems, how the data and systems can be accessed, and how users can utilise the data and systems.
It is also important to rate a Mobile and Web platform’s various interacting systems along a “trustworthiness” scale, as some systems may be less secure than others. For example, a user who tries logging into his/her email account from a personal laptop in a hotel lobby is naturally less “trustworthy” than a user who accesses his/her email account over a corporate network using a biometrics-enabled device. The first user should only have limited access to the system until he/she connects in a more secure way. By treating each system according to its unique level of trustworthiness, organisations can balance their often conflicting requirements of accessibility and security.
This policy-making may sound tedious, but it will prevent unintentional data loss, leakage, or unauthorised access.
Understanding — and limiting — who can access which data or systems also ensures that if there ever is a security breach, only that particular user or system will be affected.
Finally, consider giving responsible hackers and cyber experts an opportunity to challenge a system’s security. Although this may seem at first counterintuitive, it is often very effective to “use a thief to catch a thief.” After all, while processes and tools are useful for building a wall, there is no match for human intuition and innovation.
By its very nature, a Mobile and Web network is distributed across multiple locations and connected through the public Internet. This setup expands the network attack surface area because it allows multiple entry points into the system. A hacker can use the network to compromise the entire Mobile and Web system without actually attacking the system itself.
Using firewalls to protect the devices and the network that connects them is not practical. In the past, organisations have used VPNs to ensure secure connectivity between distributed networks. However, as we mentioned earlier, VPNs are not helpful in a Mobile and Web ecosystem because the devices may be located in public areas or in networks that are not under the control of trusted users.
A good encryption strategy is the most effective way to secure a Mobile and Web network, as it prevents hackers from accessing the messaging interface, gathering information on the network protocols, and identifying ways to attach the entire system. Examples of encrypted communication protocols include using TLS-based HTTPS and using MQTT over TLS. System administrators should also secure the XMPP, and they should utilise a valid X.509 PKI architecture to ensure that certifications are properly validated.
Furthermore, it is important to segregate communication channels so that even if one network channel is compromised, the other channels will remain secure.
For example, it is important to separate the remote provisional and control channel to the device from the statistics and information reporting channel.
This approach will also help if a device is on more than one Mobile and Web network, such as being on a vendor’s network (i.e., for software updates, support, and licensing) and being on an organisation’s Mobile and Web network (i.e., for applications). It is important to separate the two communication channels and not allow devices to jump from one to the other.
It is essential to secure IoT devices and the related systems services.