idnits 2.17.1 draft-garciamorchon-t2trg-automated-iot-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 346: '... the CONTROLLER SHOULD aim to mitigat...' RFC 2119 keyword, line 400: '...hing description SHOULD come from Manu...' RFC 2119 keyword, line 410: '..., DHCP timeouts) SHOULD be part of any...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [RFC2119], but that reference does not seem to mention RFC 2119 either. -- The document date (October 19, 2018) is 2014 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 634 looks like a reference -- Missing reference section? 'IOTSec' on line 627 looks like a reference -- Missing reference section? 'TDD' on line 645 looks like a reference -- Missing reference section? 'T2TRG' on line 642 looks like a reference -- Missing reference section? 'ANIMA' on line 618 looks like a reference -- Missing reference section? 'OPSAWG' on line 631 looks like a reference -- Missing reference section? 'I2RS' on line 621 looks like a reference -- Missing reference section? 'SACM' on line 639 looks like a reference -- Missing reference section? 'ACE' on line 614 looks like a reference -- Missing reference section? 'ID-MUD' on line 624 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Garcia-Morchon 3 Internet-Draft Philips 4 Intended status: Informational T. Dahm 5 Expires: April 22, 2019 Google 6 October 19, 2018 8 Automated IoT Security 9 draft-garciamorchon-t2trg-automated-iot-security-01 11 Abstract 13 The Internet of Things (IoT) concept refers to the usage of standard 14 Internet protocols to allow for human-to-thing and thing-to-thing 15 communication. The security needs are well-recognized but the design 16 space of IoT applications and systems is complex and exposed to 17 multiple types of threats. In particular, threats keep evolving at a 18 fast pace while many IoT systems are rarely updated and still remain 19 operational for decades. 21 This document describes a comprehensive agile security framework to 22 integrate existing security processes such as risk assessment or 23 vulnerability assessment in the lifecycle of a smart object in an IoT 24 application. The core of our agile security approach relies on two 25 protocols: the Protocol for Automatic Security Configuration (PASC) 26 and the Protocol for Automatic Vulnerability Assessment (PAVA). PASC 27 is executed during the onboarding phase of a smart object in an IoT 28 system and is in charge of automatically performing a risk assessment 29 and assigning a security configuration - applicable to the device or 30 the system - to defeat the identified risks. The assigned security 31 configuration fits the specific environment and threat model of the 32 application in which the device has been deployed. PAVA is executed 33 during the operation of the IoT object and ensures that 34 vulnerabilities in the smart object and IoT system are discovered in 35 a proactive way. 37 These two protocols can benefit users, manufactures and operators by 38 automating IoT security. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 22, 2019. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Conventions and Terminology Used in this Document . . . . . . 2 75 2. Integrating automated security processes in the IoT lifecycle 3 76 2.1. Automated Security Processes for Manufacturers . . . . . 3 77 2.2. Automated Security Processes for Users . . . . . . . . . 3 78 2.3. Automated Security Processes for System Integrators . . . 4 79 3. Integrating security workflows in the IoT lifecycle . . . . . 4 80 3.1. Security workflows: which ones and how they are 81 traditionally applied. . . . . . . . . . . . . . . . . . 4 82 3.2. Automating security workflows . . . . . . . . . . . . . . 6 83 4. Automated IoT security protocols: PASC and PAVA . . . . . . . 7 84 4.1. PASC: Protocol for Automatic Security Configuration . . . 8 85 4.2. Protocol for Automatic Vulnerability Assessment (PAVA) . 10 86 5. Conclusions and security considerations . . . . . . . . . . . 10 87 6. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 7. Informative References . . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Conventions and Terminology Used in this Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in "Key words for use in 96 RFCs to Indicate Requirement Levels" [RFC2119]. 98 2. Integrating automated security processes in the IoT lifecycle 100 The lifecycle of many smart objects in IoT applications such as 101 building automation follows the design and manufacturing processes of 102 traditional hardware components. This means that devices go through 103 a number of phases in their lifecycles that are predefined and rigid, 104 namely design, manufacturing, installation, commissioning, or 105 operation, to name a few of them [IOTSec]. This implies that 106 security is often pre-configured, and this pre-configuration leads to 107 a number of security problems for manufacturers, users, and system 108 operators. 110 To deal with these problems, we propose the definition of two 111 protocols, PASC and PAVA. PASC aims at automating the security 112 configuration based on information provided by devices, users, 113 manufactures, and system operators. PAVA aims at automating the 114 discovery of new bugs, potential vulnerabilities, and security 115 misconfigurations by gathering information from the actual system, 116 analyzing it, and updating security settings. 118 2.1. Automated Security Processes for Manufacturers 120 A manufacturer cannot be aware at design place about the security 121 risks that might appear in the future. Also, often a manufacturer 122 cannot be absolutely certain how his product will be used later on 123 and in what function. A famous example is the newspaper which can 124 also be used as fly swat. Thus, it is very hard for the manufacturer 125 to foresee and implement all security mechanisms and policies that 126 would be applicable to its devices in a wide variety of use cases. 128 This document introduces security automation into the IoT ecosystem 129 by pursuing a Test Driven Development (TDD) approach as explained in 130 [TDD]. The benefit of TDD for the manufacturer is that products, 131 which pass all the tests, are ready to be shipped. Additionally, 132 manufacturers benefit from this automation approach since they do not 133 need to decide which security mitigations they require on a product. 134 Instead of it, they just need to describe the expected usage of the 135 product, e.g., via MUD files, the PASC and PAVA protocols will then 136 automatically configure the security settings in the system. 138 2.2. Automated Security Processes for Users 140 A user is often interested in buying, combining, and running devices 141 from multiple manufacturers. Uses might also have different security 142 and privacy needs. From this point of view, users might have issues 143 making sure that the security settings of his purchased devices and 144 subsystems work together. 146 Users benefit from integrating security into the full IoT lifecycle 147 since security configuration is transparently done in an automatic 148 way by means of the PASC and PAVA protocols - they need to do 149 nothing. Security settings are automatically configured according to 150 the specific deployment environment that a user only needs to 151 confirm. 153 2.3. Automated Security Processes for System Integrators 155 System integrators and operators have to make sure that the overall 156 system - including multiple devices from different manufactures and 157 interacting with many users - is deployed and executed in a secure 158 way. Sometimes, it is also necessary or desired to use products not 159 according to their original purpose, but to repurpose them for a more 160 beneficial use case. Fixed configurations hinder those tasks and 161 make it also difficult to rapidly act in the event of security 162 vulnerabilities. 164 System operators benefit of PASC and PAVA since they minimize 165 operational cost while ensuring that the system remains secure at any 166 moment: PASC allows them to configure security automatically; PAVA 167 allows for automated vulnerability detection A potential 168 instantiation of part of these protocols follows a Software Defined 169 Network methodology in which network interactions are enabled/ 170 disabled by the network controller depending on the information 171 available in the collected MUD files from the devices. Operators can 172 also adopt the TDD approach and proof compliance with existing 173 security policies for any IoT device by running continuous PAVA tests 174 against the existing IoT installation. If events like software 175 updates introduce an unexpected behavior, the SDN infrastructure will 176 immediately catch and report it. 178 3. Integrating security workflows in the IoT lifecycle 180 This section first discusses existing security workflows and how they 181 are usually applied and then it explains how to integrate those 182 security workflows in the IoT lifecycle. 184 3.1. Security workflows: which ones and how they are traditionally 185 applied. 187 Dealing with security threats and finding suitable security 188 mitigations is challenging: there are very sophisticated threats that 189 a very powerful attacker could use; also, new threats and exploits 190 appear in a daily basis. Therefore, the existence of proper secure 191 product creation processes that allow managing and minimizing risks 192 during the lifecycle of the IoT devices is at least as important as 193 being aware of the threats. A non-exhaustive list of relevant 194 processes include: 196 1. A Business Impact Analysis (BIA) assesses the consequences of 197 loss of basic security attributes, namely, confidentiality, 198 integrity and availability in an IoT system. These consequences 199 might include impact on data lost, sales lost, increased 200 expenses, regulatory fines, customer dissatisfaction, etc. 201 Performing a business impact analysis allow determining the 202 business relevance of having a proper security design placing 203 security in the focus. 205 2. A Risk Assessment (RA) analyzes security threats to the IoT 206 system, considering their likelihood and impact, and deriving for 207 each of them a risk level. Risks classified as moderate or high 208 must be mitigated, i.e., security architecture should be able to 209 deal with that threat bringing the risk to a low level. Note 210 that threats are usually classified according to their goal: 211 confidentiality, integrity, and availability. For instance, a 212 specific threat to recover a symmetric-key used in the system 213 relates to confidentiality. 215 3. A privacy impact assessment (PIA) aims at assessing Personal 216 Identifiable Information (PII) that is collected, processed, or 217 used in the IoT system. By doing so, the goals is to fulfill 218 applicable legal requirements, determine risks and effects of the 219 manipulation of PII, and evaluate proposed protections. 221 4. Procedures for vulnerability assessment (VA) aim at assessing 222 whether the IoT system is secure or any vulnerabilities are 223 present. This can be due to changes in the context information 224 such as people involved in the IoT system or new software 225 vulnerabilities discovered. 227 5. Procedures for incident reporting (IR) and mitigation refer to 228 the methodologies that allow becoming aware of any security 229 issues that affect an IoT system. 231 Traditionally, BIA, RA, PIA or VA are to be realized during the 232 creation of a new IoT system, introduction of new technologies in the 233 IoT system, or deployment of significant system upgrades. In 234 general, it is recommended to re-assess them on a regular basis 235 taking into account new use cases or threats. VA is also often 236 realized before deployment, e.g., by performing a penetration test 237 before the new product release is deployed. Incident reporting is 238 done during operation of the IoT system, when a vulnerability is 239 discovered. 241 All these processes, namely BIA, RA, PIA, VA, and IR, are a must in 242 the design of any IoT system. If they are not performed, the risk of 243 not having a secure enough system is very high. However, even if 244 these procedures are in place, the IoT systems can still have an 245 unsatisfactory security level because of two main reasons: fixed 246 design decisions do not necessarily apply to all deployments due to 247 specific requirements of users and operators or the nature of the 248 final system. new vulnerabilities might appear. 250 _Manufactured _SW update _Decommissioned 251 / / / 252 | _Installed | _ Application | _Removed & 253 | / | / reconfigured | / replaced 254 | | _Commissioned | | | | 255 | | / | | | | _Reownership & 256 | | | _Application | | _Application | | / recommissioned 257 | | | / running | | / running | | | 258 | | | | | | | | | | \\ 259 +##+##+###+#############+##+##+#############+##+##+##############>>> 260 \ \/ \______________________________________/ / time // 261 \ \ \ / 262 BIA \ Continuous VA--->IR / 263 RA and PIA <__________| RA and PIA 265 Figure 1: Security workflows integrated in the lifecycle of a thing 266 in the Internet of Things. 268 3.2. Automating security workflows 270 Automating IoT security means integrating IoT security workflows in 271 the IoT lifecycle. Figure 1 depicts this concept: on the top part of 272 that figure, we see the traditional steps in the lifecycle of a 273 device: manufacturing, installation, commissioning, application 274 running, etc. Usually, the security workflows discussed in 275 Section 2.1 would only happen at the beginning. The goal is to move 276 integrate them during the lifecycle - as shown on the bottom part of 277 the figure. With this we aim at: 279 1. making sure that the security settings, methods and policies 280 applied to a given IoT deployment fit the requirements and 281 threats in that specific deployment. 283 2. ensuring fast reaction in case of new vulnerabilities or changes 284 in the security requirements. 286 In the figure, we observe that RA and PIA are moved from the design 287 phase to the installation and commissioning phases of the devices 288 since it is then when the actual environment in which smart objects 289 are deployed is really known. At this point of time, it is possible 290 to gather information about the security requirements of the users, 291 other devices in the system that my pose a threat to the new devices 292 or even new vulnerabilities that might have appeared since the 293 manufacturing of the device till the installation phase. 295 The VA is executed not only during implementation, but it keeps 296 running during the operation of the IoT system. Information gathered 297 during VA is fed into the RA and PIA processes to update security 298 settings. Similarly, security incidents found out during continuous 299 VA lead to IR. When smart objects are sold or the system updated, 300 this triggers again RA and PIA. 302 4. Automated IoT security protocols: PASC and PAVA 304 This section introduces the two protocols for automated IoT security 305 that this document proposes: Protocol for Automatic Security 306 Configuration (PASC) and Protocol for Automated Vulnerability 307 Assessment (PAVA). 309 The underlying idea of the protocols is shown at a very high level in 310 Figure 2. PASC is used initially when a device first joins the IoT 311 system to adjust the system and device security settings. Then PAVA 312 starts its operation monitoring potential vulnerabilities. If 313 changes in security settings are required, those are then applied by 314 means of PASC messages. 316 ______________________________________________________________ 317 | | | 318 | IoT device Controller Router Information 319 | | source 320 | | | 321 | ++ PASC onboarding ++> | | 322 | <++PASC device info +++++ | 323 | | | 324 | Risk & privacy assessment | | 325 | | | 326 | <+++++ PASC security config. +++++>| | 327 | | | 328 | | | 329 | | | 330 | | | 331 | | | 332 | +++ PAVA log ++++++> | | 333 | <++ PAVA active monitoring ++> | | 334 | <++ PAVA vulnerabilities +++++ | 335 | | | 336 | Risk & privacy assessment | | 337 | | | 338 | <+++++ PASC security config. +++++>| | 339 | | 340 | ____________________________________________________________ 342 Figure 2: PASC and PAVA interactions. 344 In the event of a PAVA_VULNERABILITY being received from an 345 INFORMATION SOURCE which is not already patched in the IoT device, 346 the CONTROLLER SHOULD aim to mitigate this PAVA_VULNERABILITY by 347 blocking access to the vulnerable IoT device temporary until the 348 device can be updated. 350 4.1. PASC: Protocol for Automatic Security Configuration 352 Figure 1 depicts the main parties involved in an IoT system: an IoT 353 DEVICE, a device controlling the IoT domain called CONTROLLER, a 354 ROUTER towards the IoT domain, and an INFORMATION SOURCE such as it 355 might be a local user, the manufacturer of the IoT device or a cloud 356 IoT management system. 358 The protocol flow is as follows: 360 o The IoT DEVICE performs a PASC ONBOARDING exchange in which the 361 system CONTROLLER obtains information about the device from the 362 IoT DEVICE itself. 364 o The CONTROLLER can also receive PASC DEVICE INFO from other 365 INFORMATION SOURCES such as a local user, the manufacturer, 366 vulnerability cloud, 368 o The CONTROLLER automatically performs a RISK ASSESSMENT and 369 PRIVACY IMPACT ANALYSIS based on the information about the new IOT 370 DEVICE, system, and information 372 o Finally, the CONTROLLER configures the system security by means of 373 PASC SECURITY CONFIGURATION MESSAGE. Configuration can apply to 374 the new IoT DEVICES, existing IoT devices, or networking 375 infrastructure such as the ROUTER. 377 In certain IoT environments, a simple practical instantiation of PASC 378 can be created by extending and combining a number of protocols. 379 PASC ONBOARDING resemble steps of the Manufacturer Usage Descriptor 380 (MUD) protocol by explicitly listing any internal and external 381 accesses the device needs to make, and/or clearly specify if there's 382 an intentionally open server (e.g., HTTPS port exposed) and might be 383 reused after potential enhancements. Additionally the PASC 384 ONBOARDING needs to include the security policy of the environment 385 the IoT devices are deployed within, for example by verifying the 386 exposed HTTPS server includes a non-vulnerable TLS 1.2 implementation 387 with the desired cipher suites. PASC SECURITY CONFIGURATION MESSAGE 388 might be instantiated in a SDN fashion by means of influencing the 389 routing flows . PASC SECURITY CONFIGURATION MESSAGES might also apply 390 to end devices, and they might realized with extensions of ACE. 391 Another alternative consists in changing actual software 392 configurations in the end devices although this is a less realistic 393 approach for IoT use cases. 395 The Test Specification must therefore be a description of the 396 expected behavior of the IoT device that can be used to adjust tests 397 accordingly. For example, the specification should explicitly list 398 any internal and external accesses the device needs to make, and/or 399 clearly specify if there's an intentionally open server (e.g., HTTPS 400 port exposed). This Thing description SHOULD come from Manufacturer 401 Usage Description (MUD). Additionally the Test Specification needs 402 to include the security policy of the environment the IoT devices are 403 deployed within, for example additional tests to verify the exposed 404 HTTPS server includes a non-vulnerable TLS 1.2 implementation with 405 the desired cipher suites. 407 Network Services modules on the SDN Controller provide for core 408 network services (such as DHCP, DNS, NTP) and mediated access to 409 external resources (e.g., cloud services). A set of "foundational 410 tests" (e.g., DHCP timeouts) SHOULD be part of any Test 411 Specification. The system can capture a packet trace for the 412 individual device, which can be analyzed during the RISK ASSESSMENT 413 as described in point 3 of section 3.1. 415 4.2. Protocol for Automatic Vulnerability Assessment (PAVA) 417 The Protocol for Automatic Vulnerability Assessment (PAVA) aims at 418 assessing for vulnerability when the IoT DEVICES are operational. 419 PAVA is designed to be a key factor for Test Driven Development (TDD) 420 [TDD]. The main aspects of PAVA are as follows: 422 1. PAVA relies on each IoT DEVICE sending standardized reports 423 PAVA_LOG of potential vulnerabilities to CONTROLLER, e.g., the 424 SDN controller managing the IoT security domain. Such reports 425 would build on RFC5424 (Syslog protocol), RFC5425 (TLS for 426 Syslog) and RFC5426 (Syslog over UDP). 428 2. The CONTROLLER can also perform PAVA_ACTIVE_MONITORING that 429 refers to messages aiming at verifying that the IoT DEVICE does 430 not suffer known vulnerabilities. 432 3. The CONTROLLER can also receive PAVA_VULNERABILITIES messages 433 from any INFORMATION SOURCE. 435 4. Based on the above information, the CONTROLLER can update RISK 436 and PRIVACY ASSESSMENTS. The CONTROLLER reports and methodology 437 can be based on related work such as RFC6872. 439 5. If needed, the controller can update security settings with a 440 PASC_SECURITY_CONFIGURATION message. Output of this decision can 441 result in 4 different actions: 443 * incident report towards the user 445 * update of security profiles in IoT DEVICES of the IoT security 446 domain. 448 * automatic incident reporting towards the manufacturer 450 * automatic incident reporting towards the platform provider 452 5. Conclusions and security considerations 454 Security is a key factor in the acceptance and long-term success of 455 IoT systems. Non-smart versions of physical objects in the real 456 word, for example light switches or door locks, can benefit from the 457 modern approach to software engineering. he building and 458 manufacturing industry for example are relatively slowly changing 459 industry sectors due to high demands and regulations on safety and 460 security of the physical products they produce, e. g. bridges or 461 houses, however, the IT and Web industry are one of the most dynamic 462 industry sectors currently existing and can bring capabilities to 463 make products even safer. 465 Additionally, there is a fundamental difference of traditional 466 connected and networked devices "for people" vs. IoT devices which 467 are typically headless. E. g., many standard application layer 468 authentication mechanisms like OAuth assume a person is there to "do 469 something" in a challenge response sequence. Also, people have an 470 identity, that typically links to authorization of resources, while 471 an IoT device is more single-purpose and typically has no intrinsic 472 sense of other resources it might/should communicate with. This 473 distinction between devices lends itself to a number of 474 considerations in terms of authentication, access control, 475 manageability, and other challenges that will take time to properly 476 normalize in a modern IoT enabled world. 478 From a security perspective, it is important to ensure that IoT 479 devices can be trusted. There are simply too many of them, and due 480 to their constrained nature there are often compromises that weaken 481 security overall. 483 The main contribution of this document is to describe and propose 484 protocols to automate IoT security to deal with the complex IoT 485 security design space. This is done in two steps. First, the PASC 486 protocol allows to automatically configure devices and deploying 487 security profiles - sets of security configurations - to the devices 488 and system infrastructure. Most IoT devices are typically focused on 489 their physical task rather than on being general purpose computing 490 platforms. Therefore, the security profiles described in this 491 document aim to bridge the initial risk analysis gap between the 492 involved industry sectors and put a higher emphasis on the minimizing 493 risk and containing the blast radius factors. Second, the PAVA 494 protocol allows to automatically monitor and audit the operation of 495 the network and system. This ensures fast reaction to any potential 496 vulnerabilities and attacks. 498 6. Next steps 500 This draft proposes to automate IoT security by means of PASC & PAVA 501 protocols. IoT security automation would have clear benefits for 502 manufactures, users, and system operators. 504 If this direction is attractive and supported, we envision the 505 following IETF work: 507 1. Definition of IoT use cases, overall architecture for IoT 508 security automation, and applicable techniques(e.g., MUD, SDN, 509 ACE,...) to realize PASC & PAVA. 511 2. Define minimum viable PASC & PAVA protocols, i.e., protocols that 512 allow realizing the concept of automated security with the 513 smallest amount of work. This definition will target building 514 automation use cases. This work requires the following: 516 * specifying the information required during onboarding: (1) 517 general provisioning information, for example QR codes 518 containing information like MAC address of the IoT device for 519 easy ingestion of those information into hardware databases; 520 (2) a description of the expected behavior of the IoT device 521 from Manufacturer Usage Description (MUD); (3) environment 522 specific requirements, for example a security policy that is 523 machine-readable; (4) network & application specific 524 information including the definition of the supported 525 protocols, e.g., IPv4, IPv6, application specific networking 526 information, e.g., SSID, and authentication and authorization 527 methodology, e.g., using WPA2 or 802.1X. 529 * describing the required input for the automation part: (1) 530 end-users should be allowed to enter security and privacy 531 preferences that should be easily convertible into a machine 532 readable policy; (2) manufacturers provide MUD files 533 potentially with some extensions to support automated security 534 uses cases; (3) system integrators provide the environment 535 specific network and security specifications as listed above. 537 * defining the output required or desired by users, routing 538 infrastructure and end devices. This includes routing and 539 firewalling policies for routing infrastructure; security 540 policies and configurations for the end devices including 541 blocked services, whitelist of services in other devices; 542 security configurations and security reports for end users, 543 system operators, and manufacturers (see Section 3.2 point 544 #5). 546 * standardizing the PASC Messages, message fields, and 547 interactions between new device, controller, and routing 548 infrastructure including transport protocol for PASC and PAVA 549 messages as well as encoding of security configuration using 550 YANG. 552 * creating the RA and PIA logic to generate the (SDN) security 553 configuration in controller and deploy to routers. This can 554 include individual pre-computed flow tables per routing device 555 determining which end-devices can talk to each other and which 556 services are available to each other. Non-allowed 557 communication patterns are blocked. 559 * standardizing the PAVA policy and messages for vulnerability 560 assessment as well as messages/Information required from 561 services to perform PAVA. This involves the definition of a 562 policy that determines the behaviour of PAVA regarding the 563 monitoring capabilities (active vs passive), data collection 564 capabilities, and reporting capabilities. 566 There are several groups within IETF and IRTF working on aspects 567 related to the ideas presented in this group and for which this work 568 can be interesting: 570 1. IRRF Thing to Thing Research Group (T2TRG) [T2TRG] investigates 571 open research issues in turning a true "Internet of Things" into 572 reality, an Internet where llow-resource nodes ("things", 573 "constrained nodes") can communicate among themselves and with 574 the wider Internet, in order to partake in permissionless 575 innovation. 577 2. IETF Automated Networking Integrated Model and Approach (ANIMA) 578 [ANIMA] develops a system of autonomic functions that carry out 579 the intentions of the network operator without the need for 580 detailed low-level management of individual devices. 582 3. IETF Operations and Management Area Working Group 583 (OPSAWG)[OPSAWG] receives occasional proposals for the 584 development and publication of RFCs dealing with operational and 585 management topics that are not in scope of an existing working 586 group and do not justify the formation of a new working group. 588 4. IETF Interface to the Routing System (I2RS) [I2RS] facilitates 589 real-time or event driven interaction with the routing system 590 through a collection of protocol-based control or management 591 interfaces. These allow information, policies, and operational 592 parameters to be injected into and retrieved (as read or by 593 notification) from the routing system while retaining data 594 consistency and coherency across the routers and routing 595 infrastructure, 597 5. IETF Security Automation and Continuous Monitoring (SACM) [SACM]. 598 In their charter, they write: "Securing information and the 599 systems that store, process, and transmit that information is a 600 challenging task for enterprises of all sizes, and many security 601 practitioners spend much of their time on manual processes. 602 Standardized protocols and models aiding collection and 603 evaluation of endpoint elements enable automation, thus freeing 604 practitioners to focus on high priority tasks. Due to the 605 breadth of this work, the working group will address enterprise 606 use cases pertaining to the assessment of endpoint posture (using 607 the definitions of Endpoint and Posture from RFC 5209)." 609 An open question for the authors is where this work could be done 610 best. 612 7. Informative References 614 [ACE] "IETF Authentication and Authorization for Constrained 615 Environments", 616 Web https://datatracker.ietf.org/wg/ace/charter/, n.d.. 618 [ANIMA] "IETF Automated Networking Integrated Model and Approach", 619 Web https://datatracker.ietf.org/wg/anima/about/, n.d.. 621 [I2RS] "IETF Interface to the Routing System", 622 Web https://datatracker.ietf.org/wg/i2rs/about/, n.d.. 624 [ID-MUD] Lear, E., Droms, R., and D. Domascanu, "Manufacturer Usage 625 Description Specification", March 2017. 627 [IOTSec] Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- 628 the-Art and Challenges for the Internet of Things 629 Security", draft-irtf-t2trg-iot-seccons-15 , May 2018. 631 [OPSAWG] "IETF Operations and Management Area Working Group", 632 Web https://datatracker.ietf.org/wg/opsawg/about/, n.d.. 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, 636 DOI 10.17487/RFC2119, March 1997, 637 . 639 [SACM] "IETF Security Automation and Continuous Monitoring", 640 Web https://datatracker.ietf.org/wg/sacm/about/, n.d.. 642 [T2TRG] "IRTF Thing-to-Thing (T2TRG) Research Group", 643 Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d.. 645 [TDD] Janzen, D. and H. Saiedian, "Test-driven development 646 concepts, taxonomy, and future direction", 647 Web https://ieeexplore.ieee.org/abstract/document/1510569, 648 n.d.. 650 Authors' Addresses 652 Oscar Garcia-Morchon 653 Philips 654 High Tech Campus 5 655 Eindhoven, 5656 AA 656 The Netherlands 658 Email: oscar.garcia-morchon@philips.com 660 Thorsten Dahm 661 Google 662 todo 663 Dublin 664 Ireland 666 Email: thorstendlux@google.com