Brian Russell, Leidos
Co-chair IoT WG
© Cloud Security Alliance, 2015
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
© Cloud Security Alliance, 2015
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.
2.
3.
4.
5.
6.
7.
Analyze privacy impacts to stakeholders
and adopt a Privacy-by-Design approach
to IoT development and deployment
Apply a Secure Systems Engineering
approach to architecting and deploying a
new IoT System
Implement layered security protections to
defend IoT assets
Implement data protection best-practices
to protect sensitive information
Define lifecycle controls for IoT devices
Define and implement an
authentication/authorization framework
for the organization’s IoT Deployments
Define and implement a logging/audit
framework for the organization’s IoT
ecosystem
© Cloud Security Alliance, 2015.
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.
© Cloud Security Alliance, 2015.
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
© Cloud Security Alliance, 2015.
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
© Cloud Security Alliance, 2015.
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
© Cloud Security Alliance, 2015.
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.
© Cloud Security Alliance, 2015.
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
© Cloud Security Alliance, 2015.
Define lifecycle controls for IoT devices
1. 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 Protocols
Protocol
M2m Authentication
Options
Discussion
MQTT
MQ 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.
CoAP
Constrained
application
protocol
preSharedKey
rawPublicKey
certificate
(web transfer protocol) CoAP supports multiple authentication
options for device-to-device communication. Pair with
Datagram TLS (D-TLS) for higher level confidentiality services.
XMPP
Extensible
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.
DDS
Data
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
Cloud Security Alliance, 2014.
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 oneway 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 tokenbased authentication approach such as OAUTH 2.
© Cloud Security Alliance, 2015.
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.
© Cloud Security Alliance, 2015.
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
© Cloud Security Alliance, 2015.
IoTWG Research Roadmap
Initiative
IoT IAM
Initiative Lead
Arlene Mordeno
Hardware Security Analysis of IoT
Devices
Priya Kuber
Smart Cities Cloud Security Guidance Brian Russell
Publication Date Sections
10/1/2015
12/1/2015
Section Lead
N/A
N/A
12/1/2015
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
Brian Russell
Brian Russell
Theodoros Stergiou
Ayoub FIGUIGUI
Brian Russell
Ayoub FIGUIGUI
9. 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. Introduction
2. Purpose
3. IoT Threats to Individuals and Organizations
4. Example IoT Use Cases
5. Challenges to Secure IoT Deployments
6. Radio Frequency Communications and the IoT
7. IoT in the Cloud
8. Related Security Guidance for a Secure IoT
9. Recommended Security Controls
Appendix A: Mapping to the CSA Cloud Controls Matrix (CCM)
Appendix B: References
Appendix C: IoT Operating Systems
Appendix D: IoT Protocols
Appendix E: CSA Software Defined Perimeter (SDP) and the IoT
Ayoub FIGUIGUI
Ayoub FIGUIGUI
Ravi Dhungel
Theodoros Stergiou
Brian Russell
Ayoub FIGUIGUI (can
help)
Ayoub FIGUIGUI
New Research Discussion
© Cloud Security Alliance, 2015
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
© Cloud Security Alliance, 2015.
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
© Cloud Security Alliance, 2014.
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/13RWCTqoyCUdiGK6Ao6MbLCiAw2QXUf28KmRK3Pbdfk/edit
© Cloud Security Alliance, 2014.
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, 2014.
?
?
?
© Cloud Security Alliance, 2015