idnits 2.17.1 draft-morais-iotops-inxu-00.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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 November 2021) is 885 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 8520' is mentioned on line 1467, but not defined ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IOT Operations Working Group S.V. Morais 3 Internet-Draft 4 Intended status: Standards Track C.M. Farias 5 Expires: 26 May 2022 UFRJ 6 22 November 2021 8 Intra-Network eXposure analyzer Utility Specification 9 draft-morais-iotops-inxu-00 11 Abstract 13 This document proposes the Intra-Network eXposure analyzer Utility 14 (INXU) as a vulnerability management solution for IoT networks. The 15 goal of INXU is to extend the functions of the RFC 8520 and support a 16 Security Experts Team on protecting multiple heterogeneous IoT 17 networks, even when there is a few or none private information of the 18 networks. 20 INXU identifies and analyzes the capability of an IoT device being 21 exploited by an well known malicious activity. We also propose the 22 Malicious Traffic Description (MTD), a data-model to describe traffic 23 related to malicious activities. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 26 May 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 5 60 1.2. Key Aspects . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.3. INXU Intended Use . . . . . . . . . . . . . . . . . . . . 5 62 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 63 2. The MTD Data Model . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. The draft-inxu-mtd YANG Module . . . . . . . . . . . . . 8 65 2.2. MTD Data Model Definition of Control Fields in the Root 66 "mtd" Container . . . . . . . . . . . . . . . . . . . . . 10 67 2.2.1. mtd-url . . . . . . . . . . . . . . . . . . . . . . . 10 68 2.2.2. mtd-signature . . . . . . . . . . . . . . . . . . . . 10 69 2.2.3. last-update . . . . . . . . . . . . . . . . . . . . . 10 70 2.2.4. cache-validity . . . . . . . . . . . . . . . . . . . 10 71 2.3. MTD Data Model Definition of Traffic Description Fields in 72 the Root "mtd" Container . . . . . . . . . . . . . . . . 10 73 2.3.1. attack-descriptions . . . . . . . . . . . . . . . . . 11 74 2.3.1.1. to-device-attacks . . . . . . . . . . . . . . . . 11 75 2.3.1.2. from-device-attacks . . . . . . . . . . . . . . . 11 76 2.3.2. attacks-list . . . . . . . . . . . . . . . . . . . . 11 77 2.3.2.1. name . . . . . . . . . . . . . . . . . . . . . . 11 78 2.3.2.2. specific-devices . . . . . . . . . . . . . . . . 11 79 2.3.3. malware-descriptions . . . . . . . . . . . . . . . . 11 80 2.3.3.1. name . . . . . . . . . . . . . . . . . . . . . . 12 81 2.3.3.2. specific-devices . . . . . . . . . . . . . . . . 12 82 2.3.3.3. critical-acl-sets . . . . . . . . . . . . . . . . 12 83 2.3.3.4. to-device-attacks . . . . . . . . . . . . . . . . 12 84 2.3.3.5. from-device-attacks . . . . . . . . . . . . . . . 12 85 2.3.3.6. not-attack-traffic . . . . . . . . . . . . . . . 12 86 2.4. Augmentation to the ACL Model . . . . . . . . . . . . . . 13 87 2.4.1. mtd:local-networks . . . . . . . . . . . . . . . . . 13 88 2.4.2. direction-initiated . . . . . . . . . . . . . . . . . 13 89 2.4.3. src-dnsname and dst-dnsname . . . . . . . . . . . . . 13 90 2.4.4. risk . . . . . . . . . . . . . . . . . . . . . . . . 13 91 2.4.5. risk-threshold . . . . . . . . . . . . . . . . . . . 13 92 2.4.6. alert-threshold . . . . . . . . . . . . . . . . . . . 13 93 2.5. The MTD YANG Model . . . . . . . . . . . . . . . . . . . 14 94 2.6. MTD File Example . . . . . . . . . . . . . . . . . . . . 23 96 3. The Intra-Network eXposure analyzer Utility . . . . . . . . . 31 97 3.1. INXU Architecture and Components . . . . . . . . . . . . 31 98 3.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 33 99 3.3. Acquiring a MTD File . . . . . . . . . . . . . . . . . . 33 100 3.4. Processing a MTD URL . . . . . . . . . . . . . . . . . . 34 101 3.5. INXU Vulnerability Analysis Process . . . . . . . . . . . 34 102 3.5.1. Exposure Identification . . . . . . . . . . . . . . . 35 103 3.5.2. ACL Risk Assessment . . . . . . . . . . . . . . . . . 35 104 3.5.3. Threat Analysis . . . . . . . . . . . . . . . . . . . 35 105 4. Further Considerations and Next Steps . . . . . . . . . . . . 36 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 108 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 109 7.1. Normative References . . . . . . . . . . . . . . . . . . 37 110 7.2. Informative References . . . . . . . . . . . . . . . . . 38 111 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 39 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 114 1. Introduction 116 While more Internet of Things (IoT) devices are deployed, the 117 vulnerability management process turns even more difficult. This is 118 mostly caused by the high heterogeneity and density of the IoT 119 systems and devices, and challenges security teams on keeping 120 Firewall and Intrusion Detection/Prevention Systems (IDS/IPS) rules 121 up to date. 123 In some way, the Manufacturer Usage Description (MUD) [RFC8520] 124 provides an alternative protection by reducing the capability of an 125 IoT device being exploited -- as vector or target -- by malicious 126 activities over the Internet. MUD does this by providing means to 127 automatically build an allow-list of the IoT devices in a network 128 based on the device manufacturers specification of expected traffic. 129 This improves devices security by reducing their threat surface by 130 blocking traffic with unexpected nodes/protocols, but still allows 131 attacks which exploit vulnerabilities into the allowed traffic. 133 Besides this lack, the implementation of the [RFC8520] provides 134 information that can support the identification of well-known 135 vulnerabilities, as mentioned in its specification. This can be done 136 by combining the allow-lists provided by the MUD manager into a 137 communication graph of the connected IoT devices. With the 138 communication graph, we can compare the traffic allowed by MUD with 139 signatures of well-known malicious activities to identify -- and 140 potentially block -- exposure of vulnerabilities into the network. 142 Integrating this analysis in traditional IDS or IPS can improve their 143 efficacy and cover the MUD lack, but they only apply for scenarios 144 where there is a security management team, such as corporate, smart 145 grid and industrial IoT networks. On the other hand, in scenarios 146 where there is a high heterogeneity of devices and low (or none) 147 specialized support, such as in Home IoT Networks and Smart Cities, 148 the process for keeping the attack signatures updated is not that 149 simple. 151 Therefore, envisioning to overcome this gap, this document specifies 152 INXU (Intra Network eXposure analyzer Utility) as a security 153 extension of MUD that takes advantage of the MUD-based network 154 communication graph to prevent the exploitation of well-known 155 vulnerabilities. To do this, INXU blocks threats on the Local Area 156 Network (LAN) after identifying them by comparing the signature of 157 well-known malicious activities with the traffic flow allowed by the 158 MUD. In short words, while MUD builds allow-lists, INXU builds a 159 blocklist on top of MUD's allow-lists. 161 The core component of INXU is Malicious Traffic Description (MTD), a 162 document produced by a security specialist that describes ongoing 163 malicious activities and well-known vulnerabilities and helps INXU 164 find chains of connected IoT devices that can expose them to a 165 threat. On top of MUD's threat surface reduction, INXU adds another 166 security layer that enables protection against incidents not 167 addressed or even caused by the manufacturers. 169 The MTD data model, as in MUD, abstracts network addresses to allow 170 describing the traffic without the need to know the network's 171 addressing schema or the connected devices. This resource allows 172 creating portable descriptions of malicious traffic and protects the 173 privacy in the LAN by not exposing private information to third 174 parties in the security decision-making process. At the same time, 175 it simplifies the sharing of knowledge about attacks between distinct 176 networks. 178 Another relevant feature in INXU is its architecture that enables one 179 Security Operation Center (SOC) to protect multiple distinct networks 180 by sharing MTDs in a process similar to computer antivirus vaccines. 181 This feature makes INXU a tool to protect LANs and the entire 182 Internet ecosystem by making the operation of botnets and other 183 attacks that affect the Internet's stability more difficult. 185 1.1. Simple Example 187 An Internet Service Provider (ISP) connects tens to hundreds of 188 houses to the Internet. Each one of these homes contains a wide 189 range of IoT devices connected in their internal networks, in diverse 190 topologies, and with different usages by each end-user. By the 191 variety of scenarios, these home networks potentially contain a few 192 devices infected by a DDoS capable botnet. 194 Due to the attacks carried by this botnet, frequently the ISP has a 195 considerable part of its traffic being consumed by DDoS attacks, and 196 often the clients call helpdesk for problems with devices caused by 197 the botnet. The ISP knows that the malware's infection occurs by a 198 TCP/23 connection with a neighbour host, and the command and control 199 occurs by a TCP/80 connection with a server located at 200 mybotnet.example.com. 202 With this information, the ISP releases an MTD File describing this 203 traffic, which can be used by its clients. In the home networks, the 204 Customer Premises Equipment (CPE) collects the MTD File and compares 205 it to the network communication graph provided by MUD, identifies 206 exposures of vulnerabilities internally into the network, INXU 207 evaluates the risk of the exposures and suggests blocks to prevent 208 exploitations. 210 1.2. Key Aspects 212 This work in progress aims to propose a tool that reinforces IoT 213 networks' security by extending the functions provided by the 214 [RFC8520]. The specific contributions of INXU are listed below: 216 * Simplify the process of sharing attack signatures that targets or 217 exploits IoT systems; 219 * Allow a short team of security specialists to protect multiple 220 distinct IoT networks without expose the networks' privacy; 222 * Protect the Internet's ecosystem by hindering distributed attacks 223 that targets its infrastructure. 225 1.3. INXU Intended Use 227 The intended use for INXU is in the support of the vulnerability 228 management of diverse heterogeneous IoT networks in scenarios where 229 there is a short team of security specialists (e.g. Smart Cities). 230 It is also intended to be used in scenarios where the end networks 231 need their privacy kept, as Home IoT networks. 233 The deployment of INXU in networks populated by both IoT and general 234 purpose devices is NOT RECOMMENDED. 236 1.4. Terminology 238 * INXU: Intra-Network eXposure analyzer Utility. 240 * INXU Module: a system that crosses data from malicious activities 241 and MUD's allow-lists to identify and analyze the exposure of 242 vulnerabilities in the connected IoT devices. 244 * MTD: Malicious Traffic Description data model. 246 * MTD File: a file that contains descriptions of traffic associated 247 with malicious activities that targets or exploits IoT devices. 249 * MTD Manager: a system that requests and receives the MTD File. It 250 is responsible for verifying MUD File's authenticity and 251 integrity. The MTD Manager also requests the MTD File after it's 252 cache validity expires. 254 * MTD URL: a URL, configured in the MTD Manager, that locates the 255 MTD File provided by the SOC in charge to protect the client 256 network. 258 * MTD Server: a web server, managed by the SOC, that hosts the MTD 259 File. 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 263 "OPTIONAL" in this document are to be interpreted as described in BCP 264 14 [RFC2119][RFC8174] when, and only when, they appear in all 265 capitals, as shown here. 267 2. The MTD Data Model 269 The main aim of this data model is to enable describing malicious 270 traffic so that distinct networks can interpret and implement 271 security measures, no matter the connected IoT devices or network 272 topology. Another feature addressed by this data model is allowing 273 the association between the detected exposure and the malicious 274 activity that exploits it and the grouping of vulnerabilities related 275 to the same malicious activity. 277 The MTD data model makes use of Access Control Lists (ACLs) [RFC8519] 278 under YANG language [RFC7950] to describe the malicious traffic, 279 addressing the classification feature. Furthermore, such as in MUD, 280 there are available two network address abstractions to describe the 281 traffic so that different networks can adapt the description to its 282 context: one abstraction for addresses in the local networks, and the 283 other for using domain names to hosts on the Internet. The data 284 model also includes control fields that support the manageability of 285 the MTD File, so the contained data can be categorized in control 286 data and description data. 288 The description of malicious traffic can be divided into two 289 categories: 291 * Attack descriptions: the traffic associated with isolated attacks, 292 commonly associated with traffic that comes from outside the 293 internal network. This category can be used, for example, to 294 describe the process of scanning and exploitation of an zero-day 295 attack; 297 * Malware descriptions: the traffic associated with a malware, which 298 may include the multiple attacks that it is capable to carry and 299 the traffic associated with its operations. 301 Moreover, to prevent false-positive threat detections, the MTD data 302 model allows inserting context information into the descriptions. 303 The context information in the MTD data model plays the role of 304 specifying the correlation between the described malicious traffic, 305 determining the combinations of exposures that become a risk, and 306 suggesting the action to be taken with each detected threat. This 307 feature supports reducing false-positive detection, as a single 308 traffic exposure may not represent a threat itself. 310 Basically the context information supports the categorization of a 311 set of vulnerabilities as an effective threat or not. To incorporate 312 the contextual information, we considered the statements listed 313 below, which were assimilated from the IoTSec ontology in 314 [Mozzaquatro2015]: 316 * A Threat represents an effective risk if the exposure of one or 317 more vulnerabilities can be exploited by an attacker; 319 * A Vulnerability does not represent a risk by itself, as it can be 320 hidden behind security mechanisms, such as blocking its exposure 321 for potential attackers. 323 So, in short words, an asset is under threat only when an attacker 324 can exploit one or more vulnerabilities to take advantage of it. 325 Thus, merging the concepts from the ontology and the aims on MTD data 326 model, this document considers the following statements: 328 * Each Access Control Entry (ACE) has an associated severity defined 329 by the unsigned integer field named risk. When the exposure to 330 the ACE is detected, its risk is considered part of its ACL's 331 vulnerability classification; 333 * Each ACL has alert-threshold and risk-threshold fields, both 334 represented by unsigned integer values. When the sum of the 335 exposed ACEs risks reaches the risk threshold, the exposure to the 336 ACL is considered as a vulnerability; 338 * Under the attack category, ACLs that expose vulnerabilities are 339 considered as threats and should be blocked; 341 * In the malware category, each described malware contains a list of 342 critical ACL sets. A malware is classified as a threat when at 343 least one set of critical ACLs contains all its ACLs classified as 344 a vulnerability exposure. When one set's condition is satisfied, 345 its associated action-to-take has to be triggered. 347 The three possible actions to be taken are listed below: 349 * block-all: blocks all ACLs that expose vulnerabilities related to 350 the malware. Expected to be used when any traffic associated with 351 the malware threatens the IoT device; 353 * block-attack: blocks all ACLs that expose vulnerabilities under 354 the malware's attack-traffic group. Expected to be used when only 355 risky ACLs associated with attacks threatens the IoT device; 357 * block-not-attack: blocks all ACLs that expose vulnerabilities 358 under the malware's not-attack-traffic group. Expected to be used 359 when just blocking the operation traffic of the malware prevents 360 exploitation. 362 2.1. The draft-inxu-mtd YANG Module 364 A simplified graphical representation of the data models is used in 365 this document. The meaning of the symbols in these diagrams is 366 explained in [RFC8340]. 368 module: draft-inxu-mtd 369 +--rw mtd! 370 +--rw mtd-url inet:uri 371 +--rw last-update yang:date-and-time 372 +--rw mtd-signature? inet:uri 373 +--rw cache-validity? uint8 374 +--rw attack-descriptions 375 | +--rw to-device-attacks 376 | | +--rw attack-lists 377 | | +--rw attack-list* [name] 378 | | +--rw name -> /acl:acls/acl/name 379 | | +--rw specific-devices* inet:uri 380 | +--rw from-device-attacks 381 | +--rw attack-lists 382 | +--rw attack-list* [name] 383 | +--rw name -> /acl:acls/acl/name 384 | +--rw specific-devices* inet:uri 385 +--rw malware-descriptions 386 +--rw malwares-list* [name] 387 +--rw name string 388 +--rw specific-devices* inet:uri 389 +--rw critical-acl-sets* [name] 390 | +--rw name string 391 | +--rw critical-acl-set* -> /acl:acls/acl/name 392 | +--rw action-to-take draft-inxu-mtd:action-to-take 393 +--rw to-device-attacks 394 | +--rw attack-lists 395 | +--rw attack-list* [name] 396 | +--rw name -> /acl:acls/acl/name 397 | +--rw specific-devices* inet:uri 398 +--rw from-device-attacks 399 | +--rw attack-lists 400 | +--rw attack-list* [name] 401 | +--rw name -> /acl:acls/acl/name 402 | +--rw specific-devices* inet:uri 403 +--rw not-attack-traffic 404 +--rw to-device-not-attack-traffic* [name] 405 | +--rw name -> /acl:acls/acl/name 406 +--rw from-device-not-attack-traffic* [name] 407 +--rw name -> /acl:acls/acl/name 409 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 410 +--rw mtd 411 +--rw local-networks? empty 412 augment /acl:acls/acl:acl/acl:aces/acl:ace: 413 +--rw risk? uint8 414 augment /acl:acls/acl:acl: 415 +--rw risk-threshold? uint8 416 +--rw alert-threshold? uint8 417 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches 418 /acl:l4/acl:tcp/acl:tcp: 419 +--rw direction-initiated? mud:direction 420 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches 421 /acl:l3/acl:ipv4/acl:ipv4: 422 +--rw src-dnsname? inet:host 423 +--rw dst-dnsname? inet:host 425 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches 426 /acl:l3/acl:ipv6/acl:ipv6: 427 +--rw src-dnsname? inet:host 428 +--rw dst-dnsname? inet:host 430 2.2. MTD Data Model Definition of Control Fields in the Root "mtd" 431 Container 433 Here we describe the leafs placed into the "mtd" root container that 434 plays the role of controlling the operation of the MTD File. 436 2.2.1. mtd-url 438 Required field that stores the URL where the security authority hosts 439 the MTD File. 441 2.2.2. mtd-signature 443 Optional field used to store a URL where the MTD File signature file 444 can be found. It is applicable for offline authenticity verification 445 of the file. 447 2.2.3. last-update 449 Required field that contains the timestamp information of the MTD 450 File generation. 452 2.2.4. cache-validity 454 Optional field that contains the number of hours to the expiration of 455 the MTD File, starting from "last-update". This field supports 456 integer values between 1 and 160, and if not defined, it is assumed 457 to be 48 hours by the MTD Manager. 459 2.3. MTD Data Model Definition of Traffic Description Fields in the 460 Root "mtd" Container 462 The traffic description fields are divided in "attack-descriptions" 463 and "malware-descriptions" containers. These two categories are 464 needed because one malware can deliver multiple different attacks and 465 can also use other traffic -- here called not attack traffic -- 466 related to the malware operation. 468 The description of malware traffic allows the aggregation of 469 different attacks, and also other not attack traffic that only turn 470 into malicious when related to the malware operation. This 471 aggregation is important for the security measures decision-making 472 process, as sometimes only a traffic combination makes the malware 473 effective or blocking just one type of traffic can almost disable a 474 malware, such as the Mirai's Command and Control traffic. 476 The description of each leaf is detailed in the Sub-Sections below. 478 2.3.1. attack-descriptions 480 Container that holds the description of all attack traffic incoming 481 to or outgoing from an IoT device. 483 2.3.1.1. to-device-attacks 485 Container that describes all the attack traffic targeting an IoT 486 device on the LAN. 488 2.3.1.2. from-device-attacks 490 Container that describes all the attack traffic outgoing from an IoT 491 device on the LAN. 493 2.3.2. attacks-list 495 List type field to specify all the traffic in the same direction 496 (incoming/outgoing) that is associated with one attack. 498 2.3.2.1. name 500 Required string field with the name of the ACL that describes one 501 attack; 503 2.3.2.2. specific-devices 505 Optional list to specify the MUD URLs of the IoT devices affected by 506 the described attack. When this field is filled, INXU only considers 507 the devices here listed as targets of these ACLs. 509 2.3.3. malware-descriptions 511 List that holds the traffic description of all malware covered by the 512 MTD File 514 2.3.3.1. name 516 Required string field to uniquely name the described malware. 518 2.3.3.2. specific-devices 520 Optional list to specify the MUD URLs of the IoT devices that can be 521 affected by the malware. When this field is filled, INXU only 522 considers the devices here listed as affected by this malware. 524 2.3.3.3. critical-acl-sets 526 List to specify all the sets of critical ACL and their respective 527 actions to take when all listed ACLs get classified as risky. 529 2.3.3.3.1. critical-acl-set 531 List to specify a set of ACLs that, when all listed ACLs get 532 classified as risky, represents a threat caused by the malware. 534 2.3.3.3.2. action-to-take 536 Mandatory leaf to specify the action to be taken when the respective 537 set of critical ACLs turns into a threat. The action can be "block- 538 all", "block-attack", or "block-not-attack". 540 2.3.3.4. to-device-attacks 542 Container that holds all the malware's attack traffic targeting an 543 IoT device on the LAN. 545 2.3.3.5. from-device-attacks 547 Container that holds all the malware's attack traffic outgoing from 548 an IoT device on the LAN. 550 2.3.3.6. not-attack-traffic 552 Container that holds the traffic not related to attacks, but that 553 turns into malicious when in a malware context. 555 2.3.3.6.1. to-device-not-attack-traffic 557 List with all the ACLs that describe malware associate not attack 558 traffic targeting an IoT device on the LAN. 560 2.3.3.6.2. from-device-not-attack-traffic 562 List with all the ACLs that describe malware associate not attack 563 traffic outgoing from an IoT device on the LAN. 565 2.4. Augmentation to the ACL Model 567 This section describes the proposed augments to the ACL model. These 568 augments are responsible for creating the abstraction for the traffic 569 descriptions, enabling the portability of the knowledge to the 570 different networks, and supporting the risk assessment of each 571 vulnerability exposure. 573 2.4.1. mtd:local-networks 575 Optional leaf that, when present, means that the current ACE applies 576 to any device on the local IP networks. 578 2.4.2. direction-initiated 580 Optional field incorporated from MUD to specify the TCP connection 581 starter. 583 2.4.3. src-dnsname and dst-dnsname 585 Optional field to enable the usage of DNS domain names to specify the 586 remote host instead of using IPv4 or IPv6 addresses. 588 2.4.4. risk 590 Optional unsigned integer field to specify the risk associated with 591 the exposure of the specified ACE. Its default value is 1. 593 2.4.5. risk-threshold 595 Optional unsigned integer field to specify the minimal ACL risk value 596 to classify it as a vulnerability exposure. The ACL's risk value is 597 calculated by the sum of all its child ACE exposures' risks. Its 598 default value is 1. 600 2.4.6. alert-threshold 602 Optional unsigned integer field to specify the minimal ACL risk value 603 to trigger an alert to the exposure. The ACL's risk value is 604 calculated by the sum of all its child ACE exposures' risks. Its 605 default value is 1. 607 2.5. The MTD YANG Model 609 file "draft-inxu-mtd@2021-11-22.yang" 610 module draft-inxu-mtd{ 611 yang-version 1.1; 612 namespace "urn:ietf:params:xml:ns:yang:draft-inxu-mtd"; 613 prefix draft-inxu-mtd; 615 import ietf-yang-types { 616 prefix yang; 617 } 619 import ietf-access-control-list { 620 prefix acl; 621 } 623 import ietf-inet-types { 624 prefix inet; 625 } 627 import ietf-mud { 628 prefix mud; 629 } 631 import ietf-acldns { 632 prefix acldns; 633 } 635 organization "IETF IOTOPS (IOT Operations) Working Group"; 636 contact 637 "WG Web: http://tools.ietf.org/wg/iotops/ 638 WG List: iotops@ietf.org 639 Author: Sávyo Morais 640 savyovm@gmail.com 641 Author: Claudio Farias 642 cmicelifarias@gmail.com"; 644 description 645 "This module is a data-model to describe malicious network 646 traffic. 648 This module is intended to be serialized via JSON and stored 649 as a file, as described in I-D draft-morais-iotops-inxu-00. 651 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 652 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 653 'MAY', and 'OPTIONAL' in this document are to be interpreted as 654 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 655 they appear in all capitals, as shown here. 657 Copyright (c) 2021 IETF Trust and the persons identified as 658 authors of the code. All rights reserved. 660 Redistribution and use in source and binary forms, with or 661 without modification, is permitted pursuant to, and subject 662 to the license terms contained in, the Simplified BSD License 663 set forth in Section 4.c of the IETF Trust's Legal Provisions 664 Relating to IETF Documents 665 (http://trustee.ietf.org/license-info). 667 This version of this YANG module is part of 668 I-D draft-morais-iotops-inxu-00; see the I-D itself for 669 full legal notices."; 671 revision 2021-11-22{ 672 description "Initial revision."; 673 reference 674 "draft-morais-iotops-inxu-00: Intra-Network eXposure analyzer 675 Utility Specification"; 676 } 678 typedef action-to-take { 680 type enumeration { 681 enum "alert" { 682 value 0; 683 description 684 "Alert user about risky exposure to the malware"; 685 } 686 enum "block-not-attack" { 687 value 1; 688 description 689 "Block malware related not-attack-traffic risky 690 exposures and attack-traffic alert exposures"; 691 } 692 enum "block-attack" { 693 value 2; 694 description 695 "Block malware related attack-traffic exposures 696 and alert users about the block"; 697 } 698 enum "block-all" { 699 value 3; 700 description 701 "Block all malware related exposures and alert 702 users about the block"; 704 } 705 } 707 description 708 "Type to specify the action to take when a malware threat 709 is detected"; 710 } 712 container mtd { 713 presence "Enabled for this particular MTD URL"; 714 description "MTD-related information"; 715 uses mtd-groupig; 716 } 718 grouping mtd-groupig { 719 description 720 "This grouping is to create a set of definitions of 721 malicious traffic of attacks and malwares"; 723 leaf mtd-url{ 724 type inet:uri; 725 mandatory true; 726 description 727 "This is the MTD URL associated with the entry found 728 in a MTD File"; 729 } 731 leaf last-update { 732 type yang:date-and-time; 733 mandatory true; 734 description 735 "This is intended to be set when the current MTD File is 736 generated. MTD Managers SHOULD NOT check for updates 737 between this time plus cache validity."; 738 } 740 leaf mtd-signature { 741 type inet:uri; 742 description 743 "A URI that resolves to a signature file to verify the 744 autenticity of the MTD File."; 745 } 747 leaf cache-validity { 748 type uint8 { 749 range "1..168"; 750 } 751 units "hours"; 752 default "48"; 753 description 754 "The information retrieved from the MTD Server is 755 valid for these many hours, after which it should be 756 refreshed. MTD Manager implementations do not need to 757 discard MTD Files beyond this period."; 758 } 760 container attack-descriptions { 761 description 762 "This container has the descriptions of the attacks that 763 can be performed against or from the IoT devices"; 765 container to-device-attacks { 766 description 767 "The set of malicious traffic performed by the 768 infected device"; 770 uses attack-lists; 771 } 773 container from-device-attacks { 774 description 775 "The set of malicious traffic performed 776 addressing the target device"; 778 uses attack-lists; 779 } 780 } 782 container malware-descriptions { 783 description 784 "This container has the descriptions of the 785 malwares that can infect the devices"; 787 uses malwares-list; 788 } 789 } 791 grouping attack-lists { 792 description 793 "A grouping for acess lists of malicious traffic related 794 in a context of attacks."; 796 container attack-lists { 797 description 798 "The access lists of the attack's malicious traffic 799 targeting or departing from the local IoT devices."; 801 list attack-list { 802 key "name"; 804 description 805 "Each entry on this list refers to an malicious 806 traffic defined by an ACL that should present the 807 overall network communication of the attack."; 809 leaf name { 810 type leafref{ 811 path "/acl:acls/acl:acl/acl:name"; 812 } 814 description 815 "The name of the ACL for this entry."; 816 } 818 leaf-list specific-devices { 819 type inet:uri; 821 description 822 "List of MUD URLs of specific devices 823 related with the vulnerability"; 824 } 825 } 826 } 827 } 829 grouping malwares-list { 830 description 831 "A grouping for acess lists of malicious traffic related 832 in a context of malwares."; 834 list malwares-list { 835 key "name"; 837 description 838 "The access lists of the malware's malicious traffic 839 targeting or departing from the local IoT devices,"; 841 leaf name { 842 type string; 844 description 845 "The name of the Malware for each entry."; 846 } 847 leaf-list specific-devices { 848 type inet:uri; 850 description 851 "List of MUD URLs of specific devices 852 related with the vulnerability"; 853 } 855 list critical-acl-sets{ 856 key "name"; 858 description 859 "Each list entry represents a malware's critical set of 860 risky ACL exposures, followed by the action to take 861 when a critical set be detected."; 863 leaf name { 864 type string; 866 description 867 "The critical ACL set name"; 868 } 870 leaf-list critical-acl-set { 871 type leafref{ 872 path "/acl:acls/acl:acl/acl:name"; 873 } 875 description 876 "A list to specify a set of ACLs that, when 877 all listed ACLs get classified as risky, 878 represents a threat caused by the malware"; 879 } 881 leaf action-to-take { 882 type draft-inxu-mtd:action-to-take; 883 mandatory true; 884 description 885 "A leaf to specify the action to be taken when 886 the respective set of critical ACLs turns into 887 a threat."; 888 } 889 } 891 container to-device-attacks { 892 description 893 "The set of attack traffic performed by the 894 infected IoT device"; 896 uses attack-lists; 897 } 899 container from-device-attacks { 900 description 901 "The set of attack traffic performed targeting 902 the infected IoT device"; 904 uses attack-lists; 905 } 907 container not-attack-traffic { 908 description 909 "Container to group all not attack traffic 910 related to the malware"; 912 list to-device-not-attack-traffic { 913 key "name"; 915 description 916 "The list of malicious incoming traffic 917 related to malware's operation that is 918 not categorized as attack"; 920 leaf name { 921 type leafref { 922 path "/acl:acls/acl:acl/acl:name"; 923 } 925 description 926 "The set of not attack traffic 927 related to the malware performed by the 928 infected IoT device"; 929 } 930 } 932 list from-device-not-attack-traffic { 933 key "name"; 935 description 936 "The list of malicious outgoing traffic 937 related to malware's operation that is 938 not categorized as attack"; 940 leaf name { 941 type leafref { 942 path "/acl:acls/acl:acl/acl:name"; 943 } 944 description 945 "The set of not attack traffic 946 related to the malware trageting the 947 infected IoT device"; 948 } 949 } 950 } 951 } 952 } 954 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 955 description 956 "adding abstraction to avoid the need of IP addresses."; 957 container mtd { 958 description 959 "MTD-specific match."; 960 leaf local-networks { 961 type empty; 962 description 963 "IP addresses will match this node if they are 964 considered local addresses. A local address may be 965 a list of locally defined prefixes and masks 966 that indicate a particular administrative scope."; 967 } 968 } 969 } 971 augment "/acl:acls/acl:acl/acl:aces/acl:ace" { 972 description 973 "Add the risk level information associated to the ACE"; 974 leaf risk { 975 type uint8; 976 default "1"; 977 description 978 "Represents risk level of a device being exploited 979 when exposes the device through traffic matching the 980 described ACE."; 981 } 983 } 985 augment "/acl:acls/acl:acl" { 986 description 987 "Add an acceptable risk threshold and an alert risk threshold 988 to the ACL"; 989 leaf risk-threshold { 990 type uint8; 991 default "1"; 992 description 993 "The acceptable risk threshold represents the minimum 994 risk value for the exposure be considered a risk. 995 The actual risk of an ACL is calculated by the sum of 996 all the ACEs that matched on the INXU Module analysis"; 997 } 999 leaf alert-threshold { 1000 type uint8; 1001 default "1"; 1002 description 1003 "The acceptable alert threshold represents the minimum 1004 risk value for the exposure trigger an alert. 1005 The actual risk of an ACL is calculated by the sum of 1006 all the ACEs that matched on the INXU Module analysis"; 1007 } 1008 } 1010 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" 1011 + "/acl:l4/acl:tcp/acl:tcp" { 1012 description 1013 "Add direction-initiated"; 1014 leaf direction-initiated { 1015 type mud:direction; 1016 description 1017 "This node matches based on which direction a 1018 connection was initiated."; 1019 } 1020 } 1022 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" 1023 + "/acl:l3/acl:ipv4/acl:ipv4" { 1024 description 1025 "Adding domain names to matching."; 1026 uses acldns:dns-matches; 1027 } 1029 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" 1030 + "/acl:l3/acl:ipv6/acl:ipv6" { 1031 description 1032 "Adding domain names to matching."; 1033 uses acldns:dns-matches; 1034 } 1036 deviation "/acl:acls/acl:acl/acl:aces/acl:ace/acl:actions" { 1037 description 1038 "Field not used in this specification"; 1039 deviate not-supported; 1041 } 1042 } 1043 1045 2.6. MTD File Example 1047 This MTD file describes the traffic of an hipotetic variant of the 1048 Mirai botnet. In its attack model, this malware scans for other 1049 vulnerable devices in the same network, and its management services 1050 (Command and Control, Scan Report, and Loader) are placed in the 1051 network edge. 1053 file "mirai-lan-variant.json" 1054 { 1055 "draft-inxu-mtd":"mtd", 1056 "mtd-url":"https://example.com/mirai-lan-variant.json", 1057 "last-update":"2021-02-10T19:30:30-03:00", 1058 "attack-descriptions":{ 1059 "to-device-attacks": { 1060 "attack-lists": { 1061 "attack-list": [{}] 1062 } 1063 }, 1064 "from-device-attacks": { 1065 "attack-lists": { 1066 "attack-list": [{}] 1067 } 1068 } 1069 }, 1070 "malware-descriptions":{ 1071 "malwares-list":[ 1072 { 1073 "name":"Mirai-Example", 1074 "critical-acl-sets":[ 1075 { 1076 "name":"mirai-prevent-spread", 1077 "critical-acl-set": 1078 [ 1079 {"name":"mirai_infect_v4from"}, 1080 {"name":"mirai_infect_v4to"}, 1081 {"name":"mirai_scan_v4from"}, 1082 {"name":"mirai_scan_v4to"} 1083 ], 1084 "action-to-take": "BLOCK_ATTACK" 1085 }, 1086 { 1087 "name":"mirai-prevet-cnc", 1088 "critical-acl-set": 1090 [ 1091 {"name":"mirai_cnc_v4from"}, 1092 {"name":"mirai_cnc_v4to"} 1093 ], 1094 "action-to-take": "BLOCK_N_ATTACK" 1095 }, 1096 { 1097 "name":"mirai-prevet-minimal", 1098 "critical-acl-set": 1099 [ 1100 {"name":"mirai_cnc_v4from"}, 1101 {"name":"mirai_cnc_v4to"}, 1102 {"name":"mirai_infect_v4from"}, 1103 {"name":"mirai_infect_v4to"} 1104 ], 1105 "action-to-take": "BLOCK_ALL" 1106 }, 1107 ], 1108 "to-device-attacks": { 1109 "attack-lists": { 1110 "attack-list": [ 1111 {"name":"mirai_infect_v4to"}, 1112 {"name":"mirai_scan_v4to"} 1113 ] 1114 } 1115 }, 1116 "from-device-attacks": { 1117 "attack-lists": { 1118 "attack-list": [ 1119 {"name":"mirai_infect_v4from"}, 1120 {"name":"mirai_scan_v4from"} 1121 ] 1122 } 1123 }, 1124 "not-attack-traffic":{ 1125 "to-device-not-attack-traffic":[ 1126 {"name":"mirai_cnc_v4to"} 1127 ], 1128 "from-device-not-attack-traffic":[ 1129 {"name":"mirai_cnc_v4from"} 1130 ] 1131 } 1132 } 1133 ] 1134 }, 1135 "ietf-access-control-list:acls": { 1136 "acl": [ 1137 { 1138 "name":"mirai_infect_v4to", 1139 "risk-threshold":11, 1140 "type": "ipv4-acl-type", 1141 "aces": { 1142 "ace": [ 1143 { 1144 "name":"infect_23_to", 1145 "risk":10, 1146 "matches":{ 1147 "ipv4":{ 1148 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1149 mud:gateway", 1150 "protocol":6 1151 }, 1152 "tcp":{ 1153 "destination-port":{ 1154 "operator":"eq", 1155 "port":23 1156 } 1157 } 1158 } 1159 }, 1160 { 1161 "name":"infect_2323_to", 1162 "risk":10, 1163 "matches":{ 1164 "ipv4":{ 1165 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1166 mud:gateway", 1167 "protocol":6 1168 }, 1169 "tcp":{ 1170 "destination-port":{ 1171 "operator":"eq", 1172 "port":2323 1173 } 1174 } 1175 } 1176 }, 1177 { 1178 "name":"bin_download_to", 1179 "risk":1, 1180 "matches":{ 1181 "ipv4":{ 1182 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1183 mud:gateway", 1184 "protocol":6 1185 }, 1186 "tcp":{ 1187 "source-port":{ 1188 "operator":"eq", 1189 "port":80 1190 }, 1191 } 1192 } 1193 } 1194 ] 1195 } 1196 }, 1197 { 1198 "name":"mirai_scan_v4to", 1199 "risk-threshold":11, 1200 "type": "ipv4-acl-type", 1201 "aces": { 1202 "ace": [ 1203 { 1204 "name":"scan_23_to", 1205 "risk":10, 1206 "matches":{ 1207 "ietf-mud:mud":{ 1208 "local-networks":[ null ] 1209 }, 1210 "ipv4":{ 1211 "protocol":6 1212 }, 1213 "tcp":{ 1214 "source-port":{ 1215 "operator":"eq", 1216 "port":23 1217 }, 1218 } 1219 } 1220 }, 1221 { 1222 "name":"scan_2323_to", 1223 "risk":10, 1224 "matches":{ 1225 "ietf-mud:mud":{ 1226 "local-networks":[ null ] 1227 }, 1228 "ipv4":{ 1229 "protocol":6 1230 }, 1231 "tcp":{ 1232 "source-port":{ 1233 "operator":"eq", 1234 "port":2323 1235 }, 1236 } 1237 } 1238 }, 1239 { 1240 "name":"scan_report_to", 1241 "risk":1, 1242 "matches":{ 1243 "ipv4":{ 1244 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1245 mud:gateway", 1246 "protocol":6 1247 }, 1248 "tcp":{ 1249 "source-port":{ 1250 "operator":"eq", 1251 "port":48101 1252 }, 1253 } 1254 } 1255 } 1256 ] 1257 } 1258 }, 1259 { 1260 "name":"mirai_infect_v4from", 1261 "risk-threshold":11, 1262 "type": "ipv4-acl-type", 1263 "aces": { 1264 "ace": [ 1265 { 1266 "name":"infect_23_from", 1267 "risk":10, 1268 "matches":{ 1269 "ipv4":{ 1270 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1271 mud:gateway", 1272 "protocol":6 1273 }, 1274 "tcp":{ 1275 "source-port":{ 1276 "operator":"eq", 1277 "port":23 1278 }, 1279 } 1280 } 1281 }, 1282 { 1283 "name":"infect_2323_from", 1284 "risk":10, 1285 "matches":{ 1286 "ipv4":{ 1287 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1288 mud:gateway", 1289 "protocol":6 1290 }, 1291 "tcp":{ 1292 "source-port":{ 1293 "operator":"eq", 1294 "port":2323 1295 }, 1296 } 1297 } 1298 }, 1299 { 1300 "name":"bin_download_from", 1301 "risk":1, 1302 "matches":{ 1303 "ipv4":{ 1304 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1305 mud:gateway", 1306 "protocol":6 1307 }, 1308 "tcp":{ 1309 "destination-port":{ 1310 "operator":"eq", 1311 "port":80 1312 } 1313 } 1314 } 1315 } 1316 ] 1317 } 1318 }, 1319 { 1320 "name":"mirai_scan_v4from", 1321 "risk-threshold":11, 1322 "type": "ipv4-acl-type", 1323 "aces": { 1324 "ace": [ 1325 { 1326 "name":"scan_23_from", 1327 "risk":10, 1328 "matches":{ 1329 "ietf-mud:mud":{ 1330 "local-networks":[ null ] 1331 }, 1332 "ipv4":{ 1333 "protocol":6 1334 }, 1335 "tcp":{ 1336 "destination-port":{ 1337 "operator":"eq", 1338 "port":23 1339 } 1340 } 1341 } 1342 }, 1343 { 1344 "name":"scan_2323_from", 1345 "risk":10, 1346 "matches":{ 1347 "ietf-mud:mud":{ 1348 "local-networks":[ null ] 1349 }, 1350 "ipv4":{ 1351 "protocol":6 1352 }, 1353 "tcp":{ 1354 "destination-port":{ 1355 "operator":"eq", 1356 "port":2323 1357 } 1358 } 1359 } 1360 }, 1361 { 1362 "name":"scan_report_from", 1363 "risk":1, 1364 "matches":{ 1365 "ipv4":{ 1366 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1367 mud:gateway", 1368 "protocol":6 1369 }, 1370 "tcp":{ 1371 "destination-port":{ 1372 "operator":"eq", 1373 "port":48101 1374 } 1375 } 1376 } 1377 } 1379 ] 1380 } 1381 }, 1382 { 1383 "name":"mirai_cnc_v4to", 1384 "type": "ipv4-acl-type", 1385 "aces": { 1386 "ace": [ 1387 { 1388 "name":"cnc_socket_to", 1389 "risk":1, 1390 "matches":{ 1391 "ipv4":{ 1392 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1393 mud:gateway", 1394 "protocol":6 1395 }, 1396 "tcp":{ 1397 "source-port":{ 1398 "operator":"eq", 1399 "port":2030 1400 }, 1401 } 1402 } 1403 } 1404 ] 1405 } 1406 }, 1407 { 1408 "name":"mirai_cnc_v4from", 1409 "type": "ipv4-acl-type", 1410 "aces": { 1411 "ace": [ 1412 { 1413 "name":"cnc_socket_from", 1414 "risk":1, 1415 "matches":{ 1416 "ipv4":{ 1417 "ietf-acldns:dst-dnsname":"urn:ietf:params:\ 1418 mud:gateway", 1419 "protocol":6 1420 }, 1421 "tcp":{ 1422 "destination-port":{ 1423 "operator":"eq", 1424 "port":2030 1425 } 1426 } 1428 } 1429 } 1430 ] 1431 } 1432 } 1433 ] 1434 } 1435 } 1436 1438 3. The Intra-Network eXposure analyzer Utility 1440 INXU was designed to have as main features: (i) enable quick 1441 responses to new vulnerabilities; (ii) allow mitigation of the 1442 damages of a new vulnerability, simultaneously in multiple distinct 1443 networks; and (iii) enable a decision-making process about security 1444 measures on the network edge, avoiding the disclosure of private 1445 information to third parties. 1447 To cover these requirements, INXU enables a security expert team - 1448 such as a SOC or an ISP Abuse Desk - to describe the traffic of 1449 ongoing malicious activities using the MTD data model (more details 1450 of the MTD data model are discussed in Section 3). With these 1451 descriptions, the security experts team can use the INXU to prevent 1452 multiple distinct networks when releasing new MTD Files for every new 1453 malicious activity discovered, in a process similar to the antivirus 1454 programs vaccines. 1456 3.1. INXU Architecture and Components 1458 The ASCII diagram below shows the architecture of INXU. The proposed 1459 architecture contains 4 main components: MTD Server, MTD Manager, 1460 INXU Module, and MUD manager [RFC8520]. 1462 ................................................... 1463 . End system network edge . 1464 . _____________ . 1465 . | | . 1466 . | MUD manager | Communication . 1467 . | [RFC 8520] |--->graph>----+ . 1468 . |_____________| | ________ . 1469 . +---->| | . 1470 . ___________ | INXU | . 1471 . | | +---->|________| . 1472 . | MTD | | . 1473 . | Manager |---->MTD File>--+ . 1474 . |___________| . 1475 . | ^ . 1476 ......|..|......................................... 1477 | | 1478 | | __________ 1479 | +--get URL>-->| Server | 1482 |__________| 1484 The MTD Server is responsible for storing and delivering the 1485 malicious traffic descriptions made by a security expert. This 1486 component was designed to enable trusted third-party specialists to 1487 share knowledge about well-known malicious activities affecting IoT 1488 and allow IoT networks to make use of this knowledge to protect 1489 themselves. The MTD Server is composed by a HTTPS server that hosts 1490 and delivers the MTD File for the clients. The MTD File is a file 1491 where the network traffic associated with malicious activities are 1492 described to INXU. This component also contains data for version 1493 control, authenticity, and validity time. The content of a MTD File 1494 is defined by a security expert in a JSON file, following the YANG 1495 data model described in the Section 2. 1497 The MTD Manager has the function of managing the MTD File on the 1498 system. It is responsible for requesting the file to the MTD Server, 1499 verifying authenticity, and requesting a new file when the current 1500 file validity expires. The default way to ensure MTD File 1501 authenticity is by HTTPS protocol, but the MTD Manager can also use 1502 the means described in the Section 3.1 of the [RFC2818]. At the end 1503 of the process, the MTD Manager forwards the MTD File to the INXU 1504 Module. 1506 The INXU (Intra-Network eXposure analyzer Utility) module is the main 1507 component of this proposal. It is responsible for verifying all the 1508 network communications trying to identify possible exposures to 1509 malicious traffic. To do this, the INXU Module compares the 1510 malicious traffic described in a MTD File with the network graph 1511 generated by MUD manager. The exposure analysis process is detailed 1512 in Section 3.5. 1514 3.2. Workflow 1516 The workflow adopted to INXU may vary, but it will mostly follow the 1517 process described below. 1519 1. MTD Manager fetches the MTD File. 1521 2. After confirming MTD File authenticity, the MTD Manager sends it 1522 for the INXU Module. 1524 3. The MUD manager sends the network communication graph -- 1525 including the devices' MUD URLs -- to the INXU Module. 1527 4. INXU Module identifies potential vulnerability exposures into the 1528 network. 1530 5. INXU analyzes the detected vulnerabilities to evaluate if they 1531 represent an effective threat. After detecting threats, INXU may 1532 act as an Intrusion Prevention System and block the exposures, or 1533 serve as input source for other security systems, depending on 1534 the implementation. 1536 6. If the MUD manager detects any change in the network topology, or 1537 the MTD Manager gets new definitions from MTD Files, the process 1538 returns to step 4. 1540 3.3. Acquiring a MTD File 1542 The main method for acquiring a MTD File is by configuring the MTD 1543 URL into the MTD Manager. The MTD URL is a Universal Resource 1544 Locator (URL) [RFC3986] provided by the Security Experts team 1545 designated for protecting the network. 1547 MTD URLs MUST use the "https" scheme [RFC7230]. 1549 An alternative manner for acquiring a MTD File is by manually 1550 importing and its respective signature file into the MTD Manager. 1551 The mechanisms for doing so are not described in this document. 1553 3.4. Processing a MTD URL 1555 Disclaimer: The specification in this section is in our roadmap but 1556 still not done. Our initial intention is to use the same 1557 specification as [RFC8520] in Section 1.6. To simplify 1558 understanding, we copied the original MUD text, pasted it below, and 1559 replaced the MUD references with MTD. 1561 MTD Managers that are able to do so SHOULD retrieve MTD URLs and 1562 signature files as per [RFC7230], using the GET method [RFC7231]. 1563 They MUST validate the certificate using the rules in [RFC2818], 1564 Section 3.1. 1566 Requests for MTD URLs SHOULD include an "Accept" header field 1567 ([RFC7231], Section 5.3.2) containing "application/mtd+json", an 1568 "Accept-Language" header field ([RFC7231], Section 5.3.5), and a 1569 "User-Agent" header field ([RFC7231], Section 5.5.3). 1571 MTD Managers SHOULD automatically process 3xx response status codes. 1573 If a MTD Manager is not able to fetch a MTD URL, other means MAY be 1574 used to import the MTD File and its associated signature file. So 1575 long as the signature of the file can be validated, the file can be 1576 used. In such environments, controllers SHOULD warn administrators 1577 when cache-validity expiry is approaching so that they may check for 1578 new files. 1580 3.5. INXU Vulnerability Analysis Process 1582 The exposure analysis algorithm of the INXU Module uses malicious 1583 traffic descriptions from a MTD File to compare with the IoT traffic 1584 flows allowed by MUD -- provided by the network communication graph 1585 generated by MUD manager -- and tries to detect vulnerabilities on 1586 the network. In this context, INXU identifies one exposure when some 1587 graph edge matches with any entry of the MTD File. 1589 Based on the MUD files, each host expected to communicate with the 1590 IoT devices, or the IoT devices themselves, are represented by nodes 1591 on the network communication graph generated by MUD manager. The 1592 host network address represents the nodes, and in the case of IoT 1593 devices on the LAN, the MUD URL is associated with the node 1594 information. The graph edges represent TCP or UDP sockets, or ICMP 1595 communications, where a directed edge represents a communication 1596 path. 1598 3.5.1. Exposure Identification 1600 For each IoT node in the MUD-based communication graph, the Exposure 1601 Identification process verifies if five information match between 1602 edge and ACEs: source and destination host addresses, communication 1603 protocol, and source and destination ports -- for transport protocols 1604 -- or ICMP message type and code. We only consider an exposure when 1605 all five information match. 1607 The ACEs considered here MUST be applicable for any device OR include 1608 the IoT device's MUD URL in the specific-devices list. 1610 A match on source or destination host address happens when the 1611 addresses are equals OR when the ACE uses the local address 1612 abstraction and the node is local. 1614 Protocols match when the specified protocols (TCP, UDP, ICMP, or any) 1615 are equal both on ACE and edge OR when the ACE specifies any 1616 protocol. 1618 For the ICMP message type and code or for transport's source and 1619 destination ports, a match happens when the specified values are 1620 equals OR when the ACE specifies any value. 1622 3.5.2. ACL Risk Assessment 1624 Each vulnerability exposure is associated with an ACE and is in the 1625 context of an ACL. Therefore, a set of vulnerability exposures of a 1626 device becomes a risk when the sum of their ACE risks is bigger than 1627 the ACL's risk threshold. There is also a possibility of triggering 1628 an alert state when the ACL's risk exceeds the alert threshold. 1630 The risk threshold SHOULD be equals or bigger than the alert 1631 threshold. 1633 3.5.3. Threat Analysis 1635 After assessing the risk of each ACL, the next step in the process is 1636 the threat analysis, which is divided into two categories: isolated 1637 attack threat and malware threat. 1639 In the attack threat analysis, any risky ACL exposure is considered 1640 as a threat and SHOULD be blocked. If the ACL is not risky but your 1641 risk exceeds the alert threshold, an alert should be triggered. This 1642 category refers to the ACLs described in the attack-descriptions 1643 container of the MTD File. 1645 The malware threat analysis goes through the ACLs associated with 1646 malwares, which are described into the malware-descriptions container 1647 of the MTD File. This analysis iterates over the malware's list of 1648 critical ACL sets. 1650 In this category, the INXU Module verifies if all the ACLs contained 1651 in a critical set are classified as risky for a device. If this 1652 condition becomes true, the INXU Module SHOULD take the action 1653 specified in the set's action-to-take field. If malware threatens 1654 the device with more than one set of critical ACLs, the INXU Module 1655 MUST take an action based into a merge of all the threatening sets' 1656 action-to-take. 1658 4. Further Considerations and Next Steps 1660 During the development of INXU, we found some important points that 1661 could further enhance the proposal in the near future. First of all, 1662 although INXU sticks to the Network and Transport layers, many 1663 recently reported DDoS attacks exploited the DNS platform to cause 1664 damage. This issue requires some treatment in this application layer 1665 protocol of the TCP/IP model. As it is a crucial application for the 1666 Internet's functioning as we know it today, it is impossible to block 1667 traffic over the protocol completely, but we believe that some level 1668 of filtering will not negatively impact the devices' usability nor 1669 the network's performance. 1671 Another interesting future direction is that although INXU allows 1672 identifying, classifying, and mitigating malicious activities on the 1673 other hand it does that without any intervention from the user. All 1674 the blocking processes do not allow the end-users intervention on the 1675 blocks and may lead them to not adopt INXU. An option to overcome 1676 this issue is by integrating Software Bill of Materials (SBOM) 1677 related information into the MTD data model and in the Threat 1678 Analysis process, and allowing end-users feedback on blocking 1679 decisions. This may reduce INXU's impact on usability with low 1680 security loss and consequently improve its adoption. 1682 Also in this sense, we could use the MTD as a standard data model for 1683 attacks signatures involving IoT. It is a useful way to share how 1684 attacks can alter the network traffic to be used in controlled 1685 experiments and simulations. Also it can be seen also as a 1686 systematic way to share information on attacks -- in this sense 1687 network administrators, scientists and security analysts could have 1688 the same view over a given event in the network. 1690 Finally, also coming from the previous statement, INXU could be used 1691 as an input for IPS/IDS systems in order to prevent attacks and any 1692 other malicious event in the network. Since by using the MTD we 1693 could classify the traffic into appropriate or not. Furthermore INXU 1694 -- specially the MTD -- could be paired with an AI engine to learn 1695 about new network patterns and classify them as an attack or some new 1696 device in the network -- the system could write some new MTDs as it 1697 learns from the network. 1699 5. Security Considerations 1701 Since INXU uses MUD as a data source, the problems presented at the 1702 Security Considerations session of the [RFC8520] are still valid for 1703 this proposal, and some new ones arise. 1705 The first new risk is the possibility of INXU causing Denial of 1706 Service on their protected IoT devices depending on how the malicious 1707 activities are described in the MTD File. To prevent this issue, 1708 while describing a malicious activity, the Security Specialist SHOULD 1709 be as specific as possible by describing, for example, the specific 1710 devices that can be affected by the attack or malware and being 1711 assertive while defining ACE risks and ACL risk thresholds. 1713 As with MUD, the MTD Manager may receive a fake MTD File from a rogue 1714 MTD Server with a certificate issued by an accredited certification 1715 authority (CA). In this case, the same MUD mitigations apply: First, 1716 if the signer changes, this may be flagged as an exception by the MTD 1717 manager. Second, if the MTD file also changes, the MTD manager 1718 SHOULD seek administrator approval (it should do this in any case). 1719 In all circumstances, the MUD manager MUST maintain a cache of 1720 trusted CAs for this purpose. When such a rogue is discovered, it 1721 SHOULD be removed. 1723 Finally, INXU is not effective against attacks that are occurring 1724 prior to a new MTD file arriving or ongoing at the moment of an 1725 update. The classification of the attack is not accurate since it 1726 does not know the rules. A countermeasure is to use an anomaly 1727 detection system to identify such attacks. INXU is not responsible 1728 for that part. 1730 Further security considerations might arise during this document's 1731 evolution. 1733 6. IANA Considerations 1735 This memo includes no request to IANA. 1737 7. References 1739 7.1. Normative References 1741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1742 Requirement Levels", BCP 14, RFC 2119, 1743 DOI 10.17487/RFC2119, March 1997, 1744 . 1746 [RFC2818] Rescorla, E., "HTTP Over TLS", May 2000, 1747 . 1749 [RFC3986] Berners-Lee, T., Fielding, R. T., and L. M. Masinter, 1750 "Uniform Resource Identifier (URI): Generic Syntax", 1751 January 2005, . 1753 [RFC7230] Fielding, R. T. and J. Reschke, "Hypertext Transfer 1754 Protocol (HTTP/1.1): Message Syntax and Routing", June 1755 2014, . 1757 [RFC7231] Fielding, R. T. and J. Reschke, "Hypertext Transfer 1758 Protocol (HTTP/1.1): Semantics and Content", June 2014, 1759 . 1761 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1762 August 2016, . 1764 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1765 2119 Key Words", May 2017, 1766 . 1768 [RFC8340] Björklund, M. and L. Berger, "YANG Tree Diagrams", March 1769 2018, . 1771 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1772 "YANG Data Model for Network Access Control Lists (ACLs)", 1773 March 2019, . 1775 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1776 Description Specification", March 2019, 1777 . 1779 7.2. Informative References 1781 [Mozzaquatro2015] 1782 Mozzaquatro, B. A., Jardim-Goncalves, R., and C. 1783 Agostinho, "Towards a reference ontology for security in 1784 the Internet of Things", 2015, 1785 . 1787 Appendix A. Additional Stuff 1789 This becomes an Appendix. 1791 Authors' Addresses 1793 Sávyo Vinícius de Morais 1794 Natal- 1795 Brazil 1797 Email: savyovm@gmail.com 1799 Claudio Miceli de Farias 1800 UFRJ 1801 Rio de Janeiro- 1802 Brazil 1804 Email: cmicelifarias@gmail.com