The IoT Security Imperative – Part 3: IoT Platform Security Requirements

This is the third and final article in the IoT Security Imperative series. In part one, Physical-Cyber Risk Landscape, we discussed what makes IoT security different and in many cases more critical than traditional IT security. In part two, Device Security Requirements, we looked at the security characteristics and attributes that developers should look for in IoT devices. Here in part three, we look at the security requirements for the IoT platforms.

Security in IoT Development Platforms

In addition to security within the device, there is a tremendous amount of security functionality that resides in the IoT development platform, external to the device. Here we are using the term IoT Development Platforms in the broader sense, to include most of the components in Figure 1 above the device layer, such as the middleware, database, analytics, and development tools.

Selecting an IoT development platform is a critical decision for many who are venturing into building an IoT-enabled product or service. It will form the core and foundation of your offering and is a decision that can have very high ‘switching costs’ in the future — i.e. you will likely have to live with the platform you choose for a very long time, and therefore it pays to do the diligence to choose wisely.¹ There are many considerations and criteria beyond security when choosing a platform. However, in this article we are focusing on the security-related criteria and requirements that should be considered in the areas of authentication and access control, high volume administrative capabilities, external integration, and foundational security capabilities.

Authentication and access control — The system should provide fine-grained, role-based, hierarchical, and state-based access control. When strong security is needed, multi-factor authentication may be required:

• Fine-grained access control — Look for granularity of access control and authentication. For devices, it means granting/denying access down to the level of individual devices and their individual attributes, properties, and controls. For data, granularity of access control should be down to the file, record, and field level. Typical access rights include view, read, write/modify, delete, and create. The system should allow granting access privileges to specific individuals or application instances, as well as groups of individuals.
• Role-based/hierarchical security – llows the granting of privileges according to the role of a user. This should provide for a hierarchical approach and multiple dimensions of roles. For example, users may simultaneously be in a hierarchy by organization (company, division, department, group), function (e.g. R&D-Software-QA), geography, title/level, administrative role, and more. Similarly devices may be placed in various hierarchies that are used in determining their access rights.

• Event/state-based access control — The ability for access privileges to change based on specific events or state-changes, such as when ownership of a particular device changes hands, or rental equipment is returned, or a hotel guest checks out.
• Multi-factor authentication — Two-factor or multi-factor authentication should be available to authenticate users, applications, and devices. For devices this can include manufacturer-generated keys, platform-generated keys, device serial number, and so forth.

High-volume admin tools/architecture — When you combine large numbers of devices and users with the ability to do fine-grained management of identity, authentication, and access control, the number of possible permutations quickly becomes immense and potentially untenable without the right security/administrative architecture and tools. This includes things like hierarchal management of users and devices, policy-based security management, and scalable device commissioning and management tools:

• Hierarchical management – s mentioned, users/roles and devices should be organized in hierarchies that can inherit properties and rights from their parents. The administrative tools should make it easy to do mass updates that flow down through specific branches of the hierarchy, with easily specified exceptions. Ideally, these rules and updates are created automatically from defined security policies.
• Policy-based security management — Platforms that support a policy-based approach to managing security allow security policies to be specified in a way that business people can create and understand them. Then the system translates those policies into the appropriate authentication and access control rules and configuration.
• Secure device commissioning — The ability to efficiently and remotely onboard and setup/configure large numbers of devices, ensuring that their security has been configured properly and securely. Ability to test the security settings and device vulnerabilities upon commissioning and at regular or event-triggered intervals. Ability to scan the code in the device to check for existence of malicious code.
• Identity management/device ownership management – bility to efficiently associate devices to specific people or organizations. This may include short-lived associations, such as a guest at a hotel using certain devices during their stay.

External Integration — The platform should have the capability to integrate with external authentication, security management systems, and IoT gateways:

• Integration with external authentication — The platform should allow authentication to be done by an external authentication system such as LDAP or PAM.
• Single-sign-on/Integration with enterprise security platforms — The platform should allow integration with single sign-on (SSO) systems, as well as with common enterprise security management systems.
• PKI management and certificate authorities – uthentication and related capabilities often use public-private key approaches that require integration with external PKI management systems and certificate authorities.
• IoT Gateway Management — The platform should provide the ability to efficiently register, authenticate, manage, control, and administer security in IoT gateways, RFID readers, and IoT appliances.

Foundational Capabilities — There are a number of foundational security-related capabilities that support or enhance the above requirements, including encryption, secure communications, support for standards, logging and monitoring, and a secure underlying multi-tenant architecture/infrastructure:

• Secure communications — Provide trusted path communications using security protocols such as TLS and secure mechanisms such as unique session ID, rapid session expiration, and complete deletion of all session data upon termination.

• Encryption — The platform should provide for data to be encrypted at rest and in transit using high strength encryption algorithms, such as AES.
• Security standards — There are a tremendous variety of security standards that can apply to IoT platforms at different levels. Some are very mature and well established, while others are in flux.² In general, the platform should support the relevant standards whenever possible and be architected to support future standards.
• Auditing/logging/monitoring — Find out what types of events are logged by the system, how are those logs protected, and what tools are available to analyze and manage those logs. The system should also provide for rules to be set up to monitor events and create alerts when there are potential security issues.
• Secure multi-tenant architecture and infrastructure — Many, if not most, IoT development platforms use a multi-tenant single-instance architecture. Because many different companies and users are on the same system in these environments, it is important that the system architecture has strong security capabilities, segmenting and strongly protecting each company’s data and devices from unauthorized access by users from the other companies sharing the system.

Secure-by-Design Assessment

One of the mantras you’ll hear from us (and many others) is that security has to be architected in by design from the start and not bolted-on as an afterthought. Secure-by-Design, is therefore a key criteria for the platform you select. Some of the questions to ask of the provider:

• Requirements processes – re security needs included in all requirements specifications and processes for all components at all phases? How is this done?
• Review processes — How is security checked in design review and code review processes?
• Risk assessments and testing — What type of risk assessments are conducted? What type of vulnerability testing is done? Do they use an independent third party to check for vulnerabilities?

Cloud Security Assessment

The security of the cloud infrastructure used by the IoT platform should be assessed. This can be done by asking what type and frequency of security audits are done and whether or not the cloud provider’s data centers and systems are SSAE 16 Type 2, ISO27001:2013, and Safe Harbor certified. Hiring an experienced independent security consultant to represent you and assess the cloud provider’s security on your behalf can be very helpful, especially for smaller organizations that lack the depth of internal security expertise. An excellent set of resources can be found at the Cloud Security Alliance website, including guidance on assessing and ensuring cloud security (free registration required). Specific security capabilities to look for inthe cloud infrastructure provider include:

• Strong physical security at the data center, with multiple layers of protection: perimeter fencing, guards at every access point, automated authentication into the perimeter and at every door and interior doors of sensitive areas, CCTV surveillance, windowless computer rooms, and so forth.
• Rigorous background checks, security training, and ongoing security testing for all employees.
• Strong technology infrastructure security, such as multiple layers of protection and firewalls, audit trails, intrusion detection, secure OS, and “secure-by-design” application.

Investing in Diligence

When a new technology gets as much attention as IoT has recently, it generates tremendous pressures for companies to get to market quickly with their own IoT-capable products and services. It can be tempting to shortcut the security assessment and verification process and focus more on functionality and speed of development when selecting an IoT development platform to build on. Like many business decisions, this involves a tradeoff between short-term and long-term consequences.

In many cases, the pain of inadequate security seems like a remote and unlikely risk, while the consequences of being late to market are immediate and ‘in your face.’ It is easy to underestimate the long-term risks of inadequate security, which could involve loss of life and potentially irreparable damage to your brand. As we asserted in part one of this series, due diligence in assessment is a moral obligation to ensure that the platform you choose provides the security your users and customers expect and deserve.
_ _ _ _ _ _ _ _ _ _ _ _

For more research on The Internet of Things, see our IoT library.

____________________________________________________________

¹ The diligence should include trying out your finalist candidate platforms, to build some portion of your desired product or service. We will cover IoT Development Platforms more in future articles. — Return to article text above
² For example, an evolving standard for IoT communications security is TIA’s TR-50 M2M – Smart Device Communications. — Return to article text above

To view other articles from this issue of the brief, click here.