Network Working Group O. Garcia-Morchon Internet-Draft Philips Intended status: Informational T. Dahm Expires: April 22, 2019 Google October 19, 2018 Automated IoT Security draft-garciamorchon-t2trg-automated-iot-security-01 Abstract The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs are well-recognized but the design space of IoT applications and systems is complex and exposed to multiple types of threats. In particular, threats keep evolving at a fast pace while many IoT systems are rarely updated and still remain operational for decades. This document describes a comprehensive agile security framework to integrate existing security processes such as risk assessment or vulnerability assessment in the lifecycle of a smart object in an IoT application. The core of our agile security approach relies on two protocols: the Protocol for Automatic Security Configuration (PASC) and the Protocol for Automatic Vulnerability Assessment (PAVA). PASC is executed during the onboarding phase of a smart object in an IoT system and is in charge of automatically performing a risk assessment and assigning a security configuration - applicable to the device or the system - to defeat the identified risks. The assigned security configuration fits the specific environment and threat model of the application in which the device has been deployed. PAVA is executed during the operation of the IoT object and ensures that vulnerabilities in the smart object and IoT system are discovered in a proactive way. These two protocols can benefit users, manufactures and operators by automating IoT security. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Garcia-Morchon & Dahm Expires April 22, 2019 [Page 1] Internet-Draft Automated IoT Security October 2018 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Conventions and Terminology Used in this Document . . . . . . 2 2. Integrating automated security processes in the IoT lifecycle 3 2.1. Automated Security Processes for Manufacturers . . . . . 3 2.2. Automated Security Processes for Users . . . . . . . . . 3 2.3. Automated Security Processes for System Integrators . . . 4 3. Integrating security workflows in the IoT lifecycle . . . . . 4 3.1. Security workflows: which ones and how they are traditionally applied. . . . . . . . . . . . . . . . . . 4 3.2. Automating security workflows . . . . . . . . . . . . . . 6 4. Automated IoT security protocols: PASC and PAVA . . . . . . . 7 4.1. PASC: Protocol for Automatic Security Configuration . . . 8 4.2. Protocol for Automatic Vulnerability Assessment (PAVA) . 10 5. Conclusions and security considerations . . . . . . . . . . . 10 6. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Conventions and Terminology Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Garcia-Morchon & Dahm Expires April 22, 2019 [Page 2] Internet-Draft Automated IoT Security October 2018 2. Integrating automated security processes in the IoT lifecycle The lifecycle of many smart objects in IoT applications such as building automation follows the design and manufacturing processes of traditional hardware components. This means that devices go through a number of phases in their lifecycles that are predefined and rigid, namely design, manufacturing, installation, commissioning, or operation, to name a few of them [IOTSec]. This implies that security is often pre-configured, and this pre-configuration leads to a number of security problems for manufacturers, users, and system operators. To deal with these problems, we propose the definition of two protocols, PASC and PAVA. PASC aims at automating the security configuration based on information provided by devices, users, manufactures, and system operators. PAVA aims at automating the discovery of new bugs, potential vulnerabilities, and security misconfigurations by gathering information from the actual system, analyzing it, and updating security settings. 2.1. Automated Security Processes for Manufacturers A manufacturer cannot be aware at design place about the security risks that might appear in the future. Also, often a manufacturer cannot be absolutely certain how his product will be used later on and in what function. A famous example is the newspaper which can also be used as fly swat. Thus, it is very hard for the manufacturer to foresee and implement all security mechanisms and policies that would be applicable to its devices in a wide variety of use cases. This document introduces security automation into the IoT ecosystem by pursuing a Test Driven Development (TDD) approach as explained in [TDD]. The benefit of TDD for the manufacturer is that products, which pass all the tests, are ready to be shipped. Additionally, manufacturers benefit from this automation approach since they do not need to decide which security mitigations they require on a product. Instead of it, they just need to describe the expected usage of the product, e.g., via MUD files, the PASC and PAVA protocols will then automatically configure the security settings in the system. 2.2. Automated Security Processes for Users A user is often interested in buying, combining, and running devices from multiple manufacturers. Uses might also have different security and privacy needs. From this point of view, users might have issues making sure that the security settings of his purchased devices and subsystems work together. Garcia-Morchon & Dahm Expires April 22, 2019 [Page 3] Internet-Draft Automated IoT Security October 2018 Users benefit from integrating security into the full IoT lifecycle since security configuration is transparently done in an automatic way by means of the PASC and PAVA protocols - they need to do nothing. Security settings are automatically configured according to the specific deployment environment that a user only needs to confirm. 2.3. Automated Security Processes for System Integrators System integrators and operators have to make sure that the overall system - including multiple devices from different manufactures and interacting with many users - is deployed and executed in a secure way. Sometimes, it is also necessary or desired to use products not according to their original purpose, but to repurpose them for a more beneficial use case. Fixed configurations hinder those tasks and make it also difficult to rapidly act in the event of security vulnerabilities. System operators benefit of PASC and PAVA since they minimize operational cost while ensuring that the system remains secure at any moment: PASC allows them to configure security automatically; PAVA allows for automated vulnerability detection A potential instantiation of part of these protocols follows a Software Defined Network methodology in which network interactions are enabled/ disabled by the network controller depending on the information available in the collected MUD files from the devices. Operators can also adopt the TDD approach and proof compliance with existing security policies for any IoT device by running continuous PAVA tests against the existing IoT installation. If events like software updates introduce an unexpected behavior, the SDN infrastructure will immediately catch and report it. 3. Integrating security workflows in the IoT lifecycle This section first discusses existing security workflows and how they are usually applied and then it explains how to integrate those security workflows in the IoT lifecycle. 3.1. Security workflows: which ones and how they are traditionally applied. Dealing with security threats and finding suitable security mitigations is challenging: there are very sophisticated threats that a very powerful attacker could use; also, new threats and exploits appear in a daily basis. Therefore, the existence of proper secure product creation processes that allow managing and minimizing risks during the lifecycle of the IoT devices is at least as important as Garcia-Morchon & Dahm Expires April 22, 2019 [Page 4] Internet-Draft Automated IoT Security October 2018 being aware of the threats. A non-exhaustive list of relevant processes include: 1. A Business Impact Analysis (BIA) assesses the consequences of loss of basic security attributes, namely, confidentiality, integrity and availability in an IoT system. These consequences might include impact on data lost, sales lost, increased expenses, regulatory fines, customer dissatisfaction, etc. Performing a business impact analysis allow determining the business relevance of having a proper security design placing security in the focus. 2. A Risk Assessment (RA) analyzes security threats to the IoT system, considering their likelihood and impact, and deriving for each of them a risk level. Risks classified as moderate or high must be mitigated, i.e., security architecture should be able to deal with that threat bringing the risk to a low level. Note that threats are usually classified according to their goal: confidentiality, integrity, and availability. For instance, a specific threat to recover a symmetric-key used in the system relates to confidentiality. 3. A privacy impact assessment (PIA) aims at assessing Personal Identifiable Information (PII) that is collected, processed, or used in the IoT system. By doing so, the goals is to fulfill applicable legal requirements, determine risks and effects of the manipulation of PII, and evaluate proposed protections. 4. Procedures for vulnerability assessment (VA) aim at assessing whether the IoT system is secure or any vulnerabilities are present. This can be due to changes in the context information such as people involved in the IoT system or new software vulnerabilities discovered. 5. Procedures for incident reporting (IR) and mitigation refer to the methodologies that allow becoming aware of any security issues that affect an IoT system. Traditionally, BIA, RA, PIA or VA are to be realized during the creation of a new IoT system, introduction of new technologies in the IoT system, or deployment of significant system upgrades. In general, it is recommended to re-assess them on a regular basis taking into account new use cases or threats. VA is also often realized before deployment, e.g., by performing a penetration test before the new product release is deployed. Incident reporting is done during operation of the IoT system, when a vulnerability is discovered. Garcia-Morchon & Dahm Expires April 22, 2019 [Page 5] Internet-Draft Automated IoT Security October 2018 All these processes, namely BIA, RA, PIA, VA, and IR, are a must in the design of any IoT system. If they are not performed, the risk of not having a secure enough system is very high. However, even if these procedures are in place, the IoT systems can still have an unsatisfactory security level because of two main reasons: fixed design decisions do not necessarily apply to all deployments due to specific requirements of users and operators or the nature of the final system. new vulnerabilities might appear. _Manufactured _SW update _Decommissioned / / / | _Installed | _ Application | _Removed & | / | / reconfigured | / replaced | | _Commissioned | | | | | | / | | | | _Reownership & | | | _Application | | _Application | | / recommissioned | | | / running | | / running | | | | | | | | | | | | | \\ +##+##+###+#############+##+##+#############+##+##+##############>>> \ \/ \______________________________________/ / time // \ \ \ / BIA \ Continuous VA--->IR / RA and PIA <__________| RA and PIA Figure 1: Security workflows integrated in the lifecycle of a thing in the Internet of Things. 3.2. Automating security workflows Automating IoT security means integrating IoT security workflows in the IoT lifecycle. Figure 1 depicts this concept: on the top part of that figure, we see the traditional steps in the lifecycle of a device: manufacturing, installation, commissioning, application running, etc. Usually, the security workflows discussed in Section 2.1 would only happen at the beginning. The goal is to move integrate them during the lifecycle - as shown on the bottom part of the figure. With this we aim at: 1. making sure that the security settings, methods and policies applied to a given IoT deployment fit the requirements and threats in that specific deployment. 2. ensuring fast reaction in case of new vulnerabilities or changes in the security requirements. In the figure, we observe that RA and PIA are moved from the design phase to the installation and commissioning phases of the devices Garcia-Morchon & Dahm Expires April 22, 2019 [Page 6] Internet-Draft Automated IoT Security October 2018 since it is then when the actual environment in which smart objects are deployed is really known. At this point of time, it is possible to gather information about the security requirements of the users, other devices in the system that my pose a threat to the new devices or even new vulnerabilities that might have appeared since the manufacturing of the device till the installation phase. The VA is executed not only during implementation, but it keeps running during the operation of the IoT system. Information gathered during VA is fed into the RA and PIA processes to update security settings. Similarly, security incidents found out during continuous VA lead to IR. When smart objects are sold or the system updated, this triggers again RA and PIA. 4. Automated IoT security protocols: PASC and PAVA This section introduces the two protocols for automated IoT security that this document proposes: Protocol for Automatic Security Configuration (PASC) and Protocol for Automated Vulnerability Assessment (PAVA). The underlying idea of the protocols is shown at a very high level in Figure 2. PASC is used initially when a device first joins the IoT system to adjust the system and device security settings. Then PAVA starts its operation monitoring potential vulnerabilities. If changes in security settings are required, those are then applied by means of PASC messages. Garcia-Morchon & Dahm Expires April 22, 2019 [Page 7] Internet-Draft Automated IoT Security October 2018 ______________________________________________________________ | | | | IoT device Controller Router Information | | source | | | | ++ PASC onboarding ++> | | | <++PASC device info +++++ | | | | | Risk & privacy assessment | | | | | | <+++++ PASC security config. +++++>| | | | | | | | | | | | | | | | | | +++ PAVA log ++++++> | | | <++ PAVA active monitoring ++> | | | <++ PAVA vulnerabilities +++++ | | | | | Risk & privacy assessment | | | | | | <+++++ PASC security config. +++++>| | | | | ____________________________________________________________ Figure 2: PASC and PAVA interactions. In the event of a PAVA_VULNERABILITY being received from an INFORMATION SOURCE which is not already patched in the IoT device, the CONTROLLER SHOULD aim to mitigate this PAVA_VULNERABILITY by blocking access to the vulnerable IoT device temporary until the device can be updated. 4.1. PASC: Protocol for Automatic Security Configuration Figure 1 depicts the main parties involved in an IoT system: an IoT DEVICE, a device controlling the IoT domain called CONTROLLER, a ROUTER towards the IoT domain, and an INFORMATION SOURCE such as it might be a local user, the manufacturer of the IoT device or a cloud IoT management system. The protocol flow is as follows: o The IoT DEVICE performs a PASC ONBOARDING exchange in which the system CONTROLLER obtains information about the device from the IoT DEVICE itself. Garcia-Morchon & Dahm Expires April 22, 2019 [Page 8] Internet-Draft Automated IoT Security October 2018 o The CONTROLLER can also receive PASC DEVICE INFO from other INFORMATION SOURCES such as a local user, the manufacturer, vulnerability cloud, o The CONTROLLER automatically performs a RISK ASSESSMENT and PRIVACY IMPACT ANALYSIS based on the information about the new IOT DEVICE, system, and information o Finally, the CONTROLLER configures the system security by means of PASC SECURITY CONFIGURATION MESSAGE. Configuration can apply to the new IoT DEVICES, existing IoT devices, or networking infrastructure such as the ROUTER. In certain IoT environments, a simple practical instantiation of PASC can be created by extending and combining a number of protocols. PASC ONBOARDING resemble steps of the Manufacturer Usage Descriptor (MUD) protocol by explicitly listing any internal and external accesses the device needs to make, and/or clearly specify if there's an intentionally open server (e.g., HTTPS port exposed) and might be reused after potential enhancements. Additionally the PASC ONBOARDING needs to include the security policy of the environment the IoT devices are deployed within, for example by verifying the exposed HTTPS server includes a non-vulnerable TLS 1.2 implementation with the desired cipher suites. PASC SECURITY CONFIGURATION MESSAGE might be instantiated in a SDN fashion by means of influencing the routing flows . PASC SECURITY CONFIGURATION MESSAGES might also apply to end devices, and they might realized with extensions of ACE. Another alternative consists in changing actual software configurations in the end devices although this is a less realistic approach for IoT use cases. The Test Specification must therefore be a description of the expected behavior of the IoT device that can be used to adjust tests accordingly. For example, the specification should explicitly list any internal and external accesses the device needs to make, and/or clearly specify if there's an intentionally open server (e.g., HTTPS port exposed). This Thing description SHOULD come from Manufacturer Usage Description (MUD). Additionally the Test Specification needs to include the security policy of the environment the IoT devices are deployed within, for example additional tests to verify the exposed HTTPS server includes a non-vulnerable TLS 1.2 implementation with the desired cipher suites. Network Services modules on the SDN Controller provide for core network services (such as DHCP, DNS, NTP) and mediated access to external resources (e.g., cloud services). A set of "foundational tests" (e.g., DHCP timeouts) SHOULD be part of any Test Specification. The system can capture a packet trace for the Garcia-Morchon & Dahm Expires April 22, 2019 [Page 9] Internet-Draft Automated IoT Security October 2018 individual device, which can be analyzed during the RISK ASSESSMENT as described in point 3 of section 3.1. 4.2. Protocol for Automatic Vulnerability Assessment (PAVA) The Protocol for Automatic Vulnerability Assessment (PAVA) aims at assessing for vulnerability when the IoT DEVICES are operational. PAVA is designed to be a key factor for Test Driven Development (TDD) [TDD]. The main aspects of PAVA are as follows: 1. PAVA relies on each IoT DEVICE sending standardized reports PAVA_LOG of potential vulnerabilities to CONTROLLER, e.g., the SDN controller managing the IoT security domain. Such reports would build on RFC5424 (Syslog protocol), RFC5425 (TLS for Syslog) and RFC5426 (Syslog over UDP). 2. The CONTROLLER can also perform PAVA_ACTIVE_MONITORING that refers to messages aiming at verifying that the IoT DEVICE does not suffer known vulnerabilities. 3. The CONTROLLER can also receive PAVA_VULNERABILITIES messages from any INFORMATION SOURCE. 4. Based on the above information, the CONTROLLER can update RISK and PRIVACY ASSESSMENTS. The CONTROLLER reports and methodology can be based on related work such as RFC6872. 5. If needed, the controller can update security settings with a PASC_SECURITY_CONFIGURATION message. Output of this decision can result in 4 different actions: * incident report towards the user * update of security profiles in IoT DEVICES of the IoT security domain. * automatic incident reporting towards the manufacturer * automatic incident reporting towards the platform provider 5. Conclusions and security considerations Security is a key factor in the acceptance and long-term success of IoT systems. Non-smart versions of physical objects in the real word, for example light switches or door locks, can benefit from the modern approach to software engineering. he building and manufacturing industry for example are relatively slowly changing industry sectors due to high demands and regulations on safety and Garcia-Morchon & Dahm Expires April 22, 2019 [Page 10] Internet-Draft Automated IoT Security October 2018 security of the physical products they produce, e. g. bridges or houses, however, the IT and Web industry are one of the most dynamic industry sectors currently existing and can bring capabilities to make products even safer. Additionally, there is a fundamental difference of traditional connected and networked devices "for people" vs. IoT devices which are typically headless. E. g., many standard application layer authentication mechanisms like OAuth assume a person is there to "do something" in a challenge response sequence. Also, people have an identity, that typically links to authorization of resources, while an IoT device is more single-purpose and typically has no intrinsic sense of other resources it might/should communicate with. This distinction between devices lends itself to a number of considerations in terms of authentication, access control, manageability, and other challenges that will take time to properly normalize in a modern IoT enabled world. From a security perspective, it is important to ensure that IoT devices can be trusted. There are simply too many of them, and due to their constrained nature there are often compromises that weaken security overall. The main contribution of this document is to describe and propose protocols to automate IoT security to deal with the complex IoT security design space. This is done in two steps. First, the PASC protocol allows to automatically configure devices and deploying security profiles - sets of security configurations - to the devices and system infrastructure. Most IoT devices are typically focused on their physical task rather than on being general purpose computing platforms. Therefore, the security profiles described in this document aim to bridge the initial risk analysis gap between the involved industry sectors and put a higher emphasis on the minimizing risk and containing the blast radius factors. Second, the PAVA protocol allows to automatically monitor and audit the operation of the network and system. This ensures fast reaction to any potential vulnerabilities and attacks. 6. Next steps This draft proposes to automate IoT security by means of PASC & PAVA protocols. IoT security automation would have clear benefits for manufactures, users, and system operators. If this direction is attractive and supported, we envision the following IETF work: Garcia-Morchon & Dahm Expires April 22, 2019 [Page 11] Internet-Draft Automated IoT Security October 2018 1. Definition of IoT use cases, overall architecture for IoT security automation, and applicable techniques(e.g., MUD, SDN, ACE,...) to realize PASC & PAVA. 2. Define minimum viable PASC & PAVA protocols, i.e., protocols that allow realizing the concept of automated security with the smallest amount of work. This definition will target building automation use cases. This work requires the following: * specifying the information required during onboarding: (1) general provisioning information, for example QR codes containing information like MAC address of the IoT device for easy ingestion of those information into hardware databases; (2) a description of the expected behavior of the IoT device from Manufacturer Usage Description (MUD); (3) environment specific requirements, for example a security policy that is machine-readable; (4) network & application specific information including the definition of the supported protocols, e.g., IPv4, IPv6, application specific networking information, e.g., SSID, and authentication and authorization methodology, e.g., using WPA2 or 802.1X. * describing the required input for the automation part: (1) end-users should be allowed to enter security and privacy preferences that should be easily convertible into a machine readable policy; (2) manufacturers provide MUD files potentially with some extensions to support automated security uses cases; (3) system integrators provide the environment specific network and security specifications as listed above. * defining the output required or desired by users, routing infrastructure and end devices. This includes routing and firewalling policies for routing infrastructure; security policies and configurations for the end devices including blocked services, whitelist of services in other devices; security configurations and security reports for end users, system operators, and manufacturers (see Section 3.2 point #5). * standardizing the PASC Messages, message fields, and interactions between new device, controller, and routing infrastructure including transport protocol for PASC and PAVA messages as well as encoding of security configuration using YANG. * creating the RA and PIA logic to generate the (SDN) security configuration in controller and deploy to routers. This can include individual pre-computed flow tables per routing device Garcia-Morchon & Dahm Expires April 22, 2019 [Page 12] Internet-Draft Automated IoT Security October 2018 determining which end-devices can talk to each other and which services are available to each other. Non-allowed communication patterns are blocked. * standardizing the PAVA policy and messages for vulnerability assessment as well as messages/Information required from services to perform PAVA. This involves the definition of a policy that determines the behaviour of PAVA regarding the monitoring capabilities (active vs passive), data collection capabilities, and reporting capabilities. There are several groups within IETF and IRTF working on aspects related to the ideas presented in this group and for which this work can be interesting: 1. IRRF Thing to Thing Research Group (T2TRG) [T2TRG] investigates open research issues in turning a true "Internet of Things" into reality, an Internet where llow-resource nodes ("things", "constrained nodes") can communicate among themselves and with the wider Internet, in order to partake in permissionless innovation. 2. IETF Automated Networking Integrated Model and Approach (ANIMA) [ANIMA] develops a system of autonomic functions that carry out the intentions of the network operator without the need for detailed low-level management of individual devices. 3. IETF Operations and Management Area Working Group (OPSAWG)[OPSAWG] receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. 4. IETF Interface to the Routing System (I2RS) [I2RS] facilitates real-time or event driven interaction with the routing system through a collection of protocol-based control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or by notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, 5. IETF Security Automation and Continuous Monitoring (SACM) [SACM]. In their charter, they write: "Securing information and the systems that store, process, and transmit that information is a challenging task for enterprises of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols and models aiding collection and Garcia-Morchon & Dahm Expires April 22, 2019 [Page 13] Internet-Draft Automated IoT Security October 2018 evaluation of endpoint elements enable automation, thus freeing practitioners to focus on high priority tasks. Due to the breadth of this work, the working group will address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209)." An open question for the authors is where this work could be done best. 7. Informative References [ACE] "IETF Authentication and Authorization for Constrained Environments", Web https://datatracker.ietf.org/wg/ace/charter/, n.d.. [ANIMA] "IETF Automated Networking Integrated Model and Approach", Web https://datatracker.ietf.org/wg/anima/about/, n.d.. [I2RS] "IETF Interface to the Routing System", Web https://datatracker.ietf.org/wg/i2rs/about/, n.d.. [ID-MUD] Lear, E., Droms, R., and D. Domascanu, "Manufacturer Usage Description Specification", March 2017. [IOTSec] Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- the-Art and Challenges for the Internet of Things Security", draft-irtf-t2trg-iot-seccons-15 , May 2018. [OPSAWG] "IETF Operations and Management Area Working Group", Web https://datatracker.ietf.org/wg/opsawg/about/, n.d.. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [SACM] "IETF Security Automation and Continuous Monitoring", Web https://datatracker.ietf.org/wg/sacm/about/, n.d.. [T2TRG] "IRTF Thing-to-Thing (T2TRG) Research Group", Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d.. [TDD] Janzen, D. and H. Saiedian, "Test-driven development concepts, taxonomy, and future direction", Web https://ieeexplore.ieee.org/abstract/document/1510569, n.d.. Garcia-Morchon & Dahm Expires April 22, 2019 [Page 14] Internet-Draft Automated IoT Security October 2018 Authors' Addresses Oscar Garcia-Morchon Philips High Tech Campus 5 Eindhoven, 5656 AA The Netherlands Email: oscar.garcia-morchon@philips.com Thorsten Dahm Google todo Dublin Ireland Email: thorstendlux@google.com Garcia-Morchon & Dahm Expires April 22, 2019 [Page 15]