© cloud security alliance, 2015 brian russell, leidos co-chair iot wg

© Cloud Security Alliance, 2015

Internet of Things (IoT) WG

Brian Russell, LeidosCo-chair IoT WG


Agenda

• IoTWG Introduction• Security Recommendations

for Early IoT Adopters • IoTWG Collaborations• IoTWG Research Roadmap

• New Research Discussion• IoT IAM Summary Guidance• Hardware Security Analysis• Cloud security for Smart

Cities• Version 2 IoT Guidance

• How to contribute

IoTWG Introduction

• IoTWG originally created as an initiative within the Mobile WG

• Branched out as a stand-alone WG earlier this year

• Many volunteers have contributed to our guidance

• Released Security Guidance for Early Adopters of the IoT

• April 2015• Received positive feedback and

a request for collaboration

• Now working on multiple documents that cover a range of IoT needs


© Cloud Security Alliance, 2015.

Security Recommendations for Early Adopters of the IoT

1. Analyze privacy impacts to stakeholders and adopt a Privacy-by-Design approach to IoT development and deployment

2. Apply a Secure Systems Engineering approach to architecting and deploying a new IoT System

3. Implement layered security protections to defend IoT assets

4. Implement data protection best-practices to protect sensitive information

5. Define lifecycle controls for IoT devices6. Define and implement an

authentication/authorization framework for the organization’s IoT Deployments

7. Define and implement a logging/audit framework for the organization’s IoT ecosystem

Analyze privacy impacts to stakeholders and adopt a Privacy-by-Design approach to IoT development and deployment


• Important to consider the potential privacy ramifications to all stakeholders prior to putting the system into an operational state.

• Analysis should be undertaken to understand the indirect privacy ramifications of the various IoT component operations.

• Examine privacy of data-in-aggregate vs. privacy of the data collected by a single system to identify potentially serious privacy concerns

• Companies should reevaluate their personal data breach notification program to cover the aspects related to IoT.

•In the case of the IoT, it is critically important that trade-offs between functionality, security and privacy be made early on in the design process in order to ensure that all objectives are met equally.

• Stakeholders should be made aware of when data is provided to third parties, the controls used to secure it, and how and when the data is disposed of.

Analyze privacy impacts to stakeholders and adopt a Privacy-by-Design approach to IoT development and deployment (continued)


• If it is found that a device collects, processes or stores Privacy Protected Information (PPI), more stringent controls will be required. These controls should be a mix of policy-based and technical. For example:

• Provisioning of the device may require more administrative approvals

• A review by Internal Audit or Compliance should be conducted to determine if it is viable to have PPI data on IoT devices

• Data stored on the device should be encrypted using sufficiently strong cryptographic algorithms

• Data transmitted from/to the device should be encrypted using sufficiently strong cryptographic algorithms

• Access to the device, both physical and logical, should be restricted to authorized personnel

Apply a Secure Systems Engineering approach to architecting and deploying a new IoT System

• Most IoT value-added capabilities will be the result of a number of diverse components working together with data traversing many networks.

• As these systems are architected, it is important to define and inject security requirements into the designs to account for the implementation of security functionality prior to deployment.

• Threat modeling of IoT systems during design is recommended

• Includes definition of a protection architecture for the IoT


Implement layered security protections to defend IoT assets


• Network Layer• Increasingly, IoT devices are storing their data in the cloud for analysis. It is important to

secure this data appropriately through encryption and other means. (e.g. transmitting sensitive data such as healthcare data from a patient monitoring device to cloud storage).

• Application Layer• Ask for the security code review report from the vendor for any vulnerabilities that were

uncovered during the development of the IoT platform and their corresponding remediation.

• Device Layer• Ensure that the device’s firmware gets upgrades, updates, and patches regularly• Limit the data that is being collected or aggregated by a gateway to what is really

necessary

• Physical Layer• Document where devices are located. If possible, develop a graphical map showing where

IoT assets are located within a building.

• Human Layer• Designate a few leaders who are security evangelists. • These people should have the personality and the drive to be on the forefront of keeping

the IoT initiative going successfully with the least amount of security challenges.• Update User security training

Implement data protection best-practices to protect sensitive information


• Protection of data in its various states requires the application of encryption.

• The National Institute of Standards and Technology (NIST) provides good recommendations for algorithms, modes and key lengths to use for the protection of sensitive information.

• Performance considerations are important dealing with constrained devices such as those typically seen in the IoT.

• Elliptic Curve Cryptography (ECC) provides strong algorithms, yet small asymmetric key sizes, for:

• Encryption key establishment (Elliptic Curve Diffie-Hellman - ECDH)• Digital signatures (Elliptic Curve Digital Signature Algorithm - ECDSA) for

message/data signing operations

• When paired with a symmetric algorithm such as the Advanced Encryption Standard (AES), this cryptographic suite offers strong cryptographic protections suitable for disadvantaged devices.

Implement data protection best-practices to protect sensitive information (continued)


• Organizations adopting IoT capabilities need to first create an enterprise data security policy that includes approaches for protection of IoT data.

• begin with an explicit task of identifying data elements and associated classifications for information that the IoT devices transmit, receives or stores as part of an application

• Consider the range of data protection techniques for a unique IoT system

• Data At Rest (DAR) Security• Data In Transit (DIT) Security• Data In Use (DIU) Security• Data Loss Prevention (DLP)• Data Integrity and Aggregation Policies

Define lifecycle controls for IoT devices1. Plan

• Consider he supporting infrastructure required for security management and monitoring.

• Identify appropriate interfaces to existing security equipment, updating network architectures to segment specific IoT enclaves.

2. Deploy• Secure configurations for devices

3. Manage• Management of the edge devices themselves,

the software and firmware that is loaded onto those edge devices, licenses, and the application of routine patch updates to mitigate vulnerabilities in the devices.

4. Monitor & Detect• Planning for the capture of security-relevant data

and establishment of rules for identifying events or combinations of events-of-interest should be conducted early on in the engineering lifecycle

5. Remediate• Update incident response plans to incorporate

new IoT systems and define the procedures for handling compromise events.

6. Dispose• Establish policies and procedures for the secure

disposition of devices that have held sensitive information or key material that could provide access to sensitive information.


Authentication Options within IoT ProtocolsProtocol M2m Authentication

OptionsDiscussion

MQTTMQ Telemetry Transport

username/password MQTT (m2m comms) allows for sending a username and password, although recommends that the password be no longer than 12 characters. Username and password are sent in the clear, and as such it is critical that TLS be employed when using MQTT.

CoAPConstrained application protocol

preSharedKeyrawPublicKeycertificate

(web transfer protocol) CoAP supports multiple authentication options for device-to-device communication. Pair with Datagram TLS (D-TLS) for higher level confidentiality services.

XMPPExtensible Messaging and Presence Protocol

Multiple options available, depending on protocol

XMPP supports a variety of authentication patterns via the Simple Authentication and Security Layer (SASL – RFC4422). Mechanisms include one-way anonymous as well as mutual authentication with encrypted passwords, certificates and other means implemented through the SASL abstraction layer.

DDSData distribution service

X.509 Certificates (PKI) using RSA and DSA algorithms.Tokens

(publish/subscribe for real-time comms) Provides endpoint authentication and key establishment to perform subsequent message data origin authentication (i.e., HMAC). Both digital certificates and various identity / authorization token types are supported.

Zigbee(802.15.4)

Pre-shared keys Zigbee provides both network and application level authentication (and encryption) through the use of Master key (optional), Network (mandatory) and, optionally, Application Link keys

Authentication Options within IoT Protocols (continued)


Protocol M2m Authentication Options

Discussion

Bluetooth Shared Key The Standard pairing method is automatic; the Simply pairing method includes a human-in-loop to verify (following a simple Diffie-Hellman exchange) that the two devices display the same hash of the established key. Bluetooth offers both one-way as well as mutual authentication options. Bluetooth secure simple pairing offers ‘Just works’, ‘Passkey entry’ and ‘Out of Box’ options for device-device authentication.

Bluetooth-LE (low energy)

Unencrypted data authenticated using Connection Signature Resolving Key (CSRK)Device Identity/Privacy is via an Identity Resolving Key (IRK)

Bluetooth-LE introduces to the Bluetooth world a two-factor authentication system, the LE Secure Connections pairing model which combines – based on device capability – several of the available association models available. In addition, Elliptic-Curve Diffie Hellman is used for key exchange.

HTTP/REST Basic Authentication (cleartext) (TLS methods)OAUTH2

HTTP/REST typically requires the support of the TLS protocol for authentication and confidentiality services. Although Basic Authentication (where credentials are passed in the clear) can be used under the cover of TLS, this is not a recommended practice. Instead attempt to stand up a token-based authentication approach such as OAUTH 2.

Define and implement a logging/audit framework for the organization’s IoT ecosystem


• Given the constraints of today’s IoT devices, a tailored approach to maintaining situational awareness of an IoT ecosystem must be adopted.

• IoT deployments can include single sensors or consolidations of multiple sensors and other devices.

• In the latter case, it may be prudent to deploy a multi-layered architecture that consists of endpoints logging to a consolidator or propagator.

• This tiered architecture allows for the placement of highly constrained devices at the edge.

• These devices typically have minimal capabilities and are connected via some wireless protocol.

• These devices can connect back to a more capable device which is connected to the organization’s Local Area Network (LAN) and then offload collected information to another node for transport.

• There will be significant opportunity in the near future to begin understanding the relationship between in-line data (operational IoT data) and security audit data.

• Tuning data analytics systems to identify potential security events and feeding the filtered output to a SIEM would add significant security value.


IoTWG Collaborations

• The IoTWG welcomes collaborations that support relevant research

• Two collaborations have been established:• Federal Communications Commission (FCC) IoT SubWG

• Focused on providing recommendations on the role of the FCC and technical controls that should be implemented by the FCC to safeguard the IoT

• Securing Smart Cities• Acquisition guidance for civic leaders implementing a Smart City• Led by Cesar Cerrudo (IOActive)

• CSA IoTWG also provides feedback on other organization artifacts

• E.g., European Union Agency for Network and Information Security (ENISA)

• Cyber Security for Smart Cities • Cyber Security and Resilience for Intelligent Public Transport

IoTWG Research RoadmapInitiative Initiative Lead

Publication Date Sections Section Lead

IoT IAM Arlene Mordeno 10/1/2015 N/A

Hardware Security Analysis of IoT Devices Priya Kuber 12/1/2015 N/A

Smart Cities Cloud Security Guidance Brian Russell 12/1/2015

1, Introduction Brian Russell

2, Cloud Risks, Threats and Mitigations for Smart Cities Brian Russell3. Selecting Governmental vs. Public Clouds and understanding regulations4. Security Requirements to be covered by the Cloud Service Provider Theodoros Stergiou

5. Security Considerations for Big Data Ayoub FIGUIGUI

6. Secure Access to Cloud Services Brian Russell7. Secure Life-cycle management of users and devices through the cloud platform8. Data Privacy Ayoub FIGUIGUI9. Enabling Secure on-demand access by city officials and citizens

10. Important Reference Information

IoT Security Guidance for Early Adopters V2 Brian Russell 2/15/2016

1. Introduction2. Purpose

3. IoT Threats to Individuals and Organizations Ayoub FIGUIGUI4. Example IoT Use Cases Ayoub FIGUIGUI

5. Challenges to Secure IoT Deployments Ravi Dhungel

6. Radio Frequency Communications and the IoT7. IoT in the Cloud Theodoros Stergiou

8. Related Security Guidance for a Secure IoT

9. Recommended Security Controls

Brian RussellAyoub FIGUIGUI (can help)

Appendix A: Mapping to the CSA Cloud Controls Matrix (CCM) Ayoub FIGUIGUIAppendix B: References

Appendix C: IoT Operating SystemsAppendix D: IoT ProtocolsAppendix E: CSA Software Defined Perimeter (SDP) and the IoT


New Research Discussion


IoT IAM Summary Guidance

• Publication should occur this week• Led by Arlene Mordeno, Edgile• Thanks to the many contributors:

• K S Abhiraj• Amit Pick• Srinivas Tatipamula• Aaron Guzman• Tom Donahoe• Vinay Bansal• Jay Douglas• Sabri Khemissa• raghavender d• Mike Flegel• Abhik Chaudhuri, Tata Consultancy Services• Drew Van Duren• Sudharma Thikkavarapu• Shyam Sundaram• Ayoub FIGUIGUI, CGI Business Consulting• Chiheb chebbi

• First in a series of summary guidance aimed at practical and easy to follow (checklist style) recommendations for practitioners


Hardware Security Analysis for the IoT• Led by Priva Kuber, Contributers: Dr Shyam Sundaram, Ayoub FIGUIGUI, CGI Business Consulting &

Aaron Guzman• Initial Survey Results of IoT Startups (Priya Kuber) focused on commercial IoT devices

• Startups don’t consider information stored on a device as sensitive (any sensitive data is stored on a server),• Users want to share information (sharing mentality)• Startups rely heavily on the use of COTS services• Most startups are using AES, although most also consider encryption to be not important• Most devices don’t share a master key shared across devices; admin at server side• No security applied to the development environment• No threat modeling of products• No secure firmware updates• Investors don’t seem to care about security, much more focus on functionality

• Topic headers focused on secure IoT device development• Hardware analysis• Firmware / Software update process analysis• Authentication Analysis• Data Security Analysis• Protocol Security Analysis• Interface Analysis

• https://docs.google.com/document/d/1vrzIFV9j-WBs3wLfdv4wF-kCnYxTNT9eFYgp6Ebj0OA/edit?usp=sharing

https://docs.google.com/document/d/1vrzIFV9j-WBs3wLfdv4wF-kCnYxTNT9eFYgp6Ebj0OA/edit?usp=sharing

https://docs.google.com/document/d/1vrzIFV9j-WBs3wLfdv4wF-kCnYxTNT9eFYgp6Ebj0OA/edit?usp=sharing


Guidance for Securing Cloud Services for Smart Cities

• Kicking off this guidance document• Established sections and members of the WG are beginning to

collaborate on the document• 1. Introduction• 2. Cloud Risks, Threats and Mitigations for Smart Cities• 3. Selecting Governmental vs. Public Clouds and understanding regulations• 4. Security Requirements to be covered by the Cloud Service Provider• 5. Security Considerations for Big Data• 6. Secure Access to Cloud Services• 7. Secure Life-cycle management of users and devices through the cloud

platform• 8. Data Privacy• 9. Enabling Secure on-demand access by city officials and citizens• 10. Important Reference Information

• https://docs.google.com/document/d/13RW-CTqoyCUdiGK6Ao6MbLCiAw2QXUf28KmRK3Pbdfk/edit

https://docs.google.com/document/d/13RW-CTqoyCUdiGK6Ao6MbLCiAw2QXUf28KmRK3Pbdfk/edit




Version 2 IoT Security Guidance

• This is the 2nd release of our flagship research document• Expected publication February 2016• Significant expansion of initial document

• Heavy emphasis on use cases• New section on Radio Frequency (RF) comms and the IoT• New section on IoT in the Cloud

• Amazon Web Services• Microsoft Azure• Cisco Fog Computing• Mapping to related security guidance from other organizations• Mapping to the CSA Cloud Controls Matrix• Discussion on relation between CSA SDP and IoT Security

© cloud security alliance, 2015 brian russell, leidos co-chair iot wg

Documents