idnits 2.17.1 draft-fabini-smart-malware-lifecycle-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: ---------------------------------------------------------------------------- No issues found here. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-mcfadden-smart-endpoint-taxonomy-for-cless-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Fabini 3 Internet-Draft TU Wien 4 Intended status: Informational November 4, 2019 5 Expires: May 7, 2020 7 Communication Network Perspective on Malware Lifecycle 8 draft-fabini-smart-malware-lifecycle-00 10 Abstract 12 Today's systems, networks, and protocols are complex and include 13 unknown vulnerabilities that adversaries can exploit. The large- 14 scale deployment of network security protocols establishes an 15 additional threat by implementing a substrate for hidden 16 communications like covert or subliminal channels. The resulting 17 ecosystem builds a convenient platform for malicious, automated 18 software (malware) to infiltrate critical infrastructures, to 19 gradually infect large parts of the system and to coordinate 20 distributed malware operation. 22 Based on the observation that malware depends on network 23 communications to discover, propagate, coordinate, and unleash its 24 functionality, this memo recommends methods to identify potential 25 interfaces and interactions between malware and protocols. It 26 proposes a generic malware lifecycle model that defines a set of 27 generic malware states and possible transitions between these states. 28 Coordinated activities of distributed malware can be mapped to state 29 transitions in malware instances, supporting the identification of 30 (potentially hidden) network communication as a trigger for actions 31 and hints on protocols that enabled the communication. Eventually, 32 the proposed model aims at supporting the identification of 33 architectures, protocols, interfaces, and points in time that a) 34 either inhibit hidden malware communication or b) allow for optimized 35 detection of anomalies as main prerequisite for timely 36 countermeasures. 38 While earlier work focused on protecting single hosts from 39 compromise, this memo adopts a holistic view and considers the health 40 of the overall networked system to be of highest priority. Presuming 41 vulnerable systems, we stress that components or subsystems must be 42 disconnected on suspected infection in an attempt to continue (even 43 partial) operation of the overall (non-infected) system after the 44 disconnect. Containment - the isolation of an infected subsystem - 45 becomes an essential security feature in the context of critical 46 infrastructures that influences on deployed protocols, interfaces and 47 architectures. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on May 7, 2020. 66 Copyright Notice 68 Copyright (c) 2019 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 85 2. Generic Malware Lifecycle . . . . . . . . . . . . . . . . . . 4 86 2.1. Access . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 2.2. Infection . . . . . . . . . . . . . . . . . . . . . . . . 6 88 2.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 89 2.4. Propagation . . . . . . . . . . . . . . . . . . . . . . . 7 90 2.5. Control . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 2.6. Trigger . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 2.7. Attack . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 2.8. Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 3. Mapping the Lifecycle Model to Real Malware . . . . . . . . . 9 95 3.1. Case study: Stuxnet . . . . . . . . . . . . . . . . . . . 10 96 3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 11 97 3.1.2. Infection . . . . . . . . . . . . . . . . . . . . . . 11 98 3.1.3. Discovery . . . . . . . . . . . . . . . . . . . . . . 11 99 3.1.4. Propagation . . . . . . . . . . . . . . . . . . . . . 11 100 3.1.5. Control . . . . . . . . . . . . . . . . . . . . . . . 12 101 3.1.6. Trigger . . . . . . . . . . . . . . . . . . . . . . . 12 102 3.1.7. Attack . . . . . . . . . . . . . . . . . . . . . . . 12 103 3.1.8. Cleanup . . . . . . . . . . . . . . . . . . . . . . . 12 104 3.1.9. Discussion: Stuxnet . . . . . . . . . . . . . . . . . 12 105 4. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 13 106 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 110 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 111 8.2. Informative References . . . . . . . . . . . . . . . . . 14 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 114 1. Introduction 116 A central guideline of the IETF security area's activity focus is 117 summarized in RFC 3552 [RFC3552]: "Protecting against an attack when 118 one of the end-systems has been compromised is extraordinarily 119 difficult". This statement is still valid today but must be seen in 120 a historical context: in times of monolithic systems, the main goal 121 of security is (or was) to protect one's own networked end system 122 (PC, server) against compromise. This implies a worst case scenario 123 and "game over" in case of a system compromise. In a distributed 124 context, one single compromised system can be fatal whenever relying 125 on a chain of trust, which is a common security policy within closed 126 (corporate or enterprise) networks. 128 However, architectures and protocols have evolved. Emerging critical 129 infrastructures consist of ensembles of hundreds, thousands or tens 130 of thousands of identical networked systems like for instance smart 131 meters or other Internet of Things (IoT) devices. These systems all 132 run identical software and identical firmware on top of identical 133 hardware, all of them being potentially subject to identical 134 vulnerabilities. Likewise, most personal computers that are 135 connected to the Internet run one of a few operating system 136 alternatives, including Microsoft Windows, Apple MacOS, or various 137 Linux distributions. Portable software and common Application 138 Programming Interfaces (APIs) increase the likelihood that one 139 vulnerability affects multiple platforms. 141 When viewing a system as a complex set of components and relations 142 (Rechtin [CBCS]), there are cases when vital system functions can be 143 performed even in the case when some subsystems (components or links) 144 have been compromised. Therefore, today's security concepts and 145 research must support (a) identification and (b) containment, i.e., 146 isolation, of compromised subsystems at an architectural and protocol 147 level. It is important to note that these requirements *extend* (and 148 by no means contradict) the requirements stated in RFC 3552 [RFC3552] 149 with respect to the importance of protecting systems against 150 compromise. 152 On this purpose, this memo proposes to enlarge the scope of systems 153 security, starting from two main prerequisites, namely that (a) any 154 system (single end node, component, link) is vulnerable and (b) 155 malware must communicate to propagate, to discover and to coordinate 156 its distributed instances. Section 2 proposes a generic malware 157 lifecycle model consisting of malware states and transitions. This 158 generic state diagram is subsequently mapped to existing malware 159 implementations to infer on malware communication needs, as well as 160 on potential interfaces and protocols that malware may use for 161 discovery, infection, propagation, and control through available 162 network paths. By monitoring these interfaces, systems can detect 163 patterns of - potentially hidden - communications as an anomalous 164 component of the network traffic. Subsequent analysis of available 165 architectures, interfaces, and protocols can help in identifying 166 anomalous communications and stopping it in order to prevent malware 167 from propagation and execution. 169 We consider the identification of systematic and design shortcomings 170 of architectures and protocols with respect to hidden communications 171 to be an essential component of the security-by-design concept. A 172 first step is the definition of metrics and methods that can assess 173 the degree to which protocols under investigation support -- or 174 prevent -- hidden communications. The ability to evaluate protocols 175 and choose the ones that are proven to be covert-channel free enables 176 system architects to close existing gaps for hidden malware 177 communication. 179 Todo: the terms used in this memo should be eventually aligned to 180 [I-D.mcfadden-smart-endpoint-taxonomy-for-cless]. 182 1.1. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 2. Generic Malware Lifecycle 190 The state diagram depicted in Figure 1 illustrates a generic malware 191 lifecycle model. A graphical representation of the diagram along 192 with a detailed description can be found in the original publication 194 [GML] or its pre-published version at 195 https://publik.tuwien.ac.at/files/publik_261089.pdf. 197 Generic Stages of Malware Lifecycle. 199 +==============+ +==============+ 200 | DISCOVERY | | PATIENT ZERO | 201 | +----------+ | +=======+======+ +==================+ 202 | |Scan: | | | | INFECTION | 203 | |Blind, | | v | +--------------+ | 204 | |Topology, | | +========+======+ | |Exploit: | | 205 | |Passive,..| | | ACCESS +<--+ |Vulnerability,| | 206 | +----------+ +<--+ +-----------+ | | |Zero-day, | | 207 +==============+ | |Physical, | +-->+ |Payload, ... | | 208 | | |Network, | | | +--------------+ | 209 v | |Passive, | | +==================+ 210 +==============+ | |Persistent,| | 211 | PROPAGATION +-->+ |... | | 212 | +----------+ | | +-----------+ | 213 | | lateral, | | | | +================+ 214 | | vertical,| | | +--> | ATTACK | 215 | | ... | | | | | +------------+ | 216 | +----------+ | | | | |Disruption, | | 217 +==============+ | | | |Destruction,| | 218 +-------+ | | |Theft, | | 219 | +===============+ | |Extortion, | | 220 v ^ | |Repurpose, | | 221 +===========+ | +=============+ | |... | | 222 | CONTROL +-------+ | TRIGGER +-->+ +------------+ | 223 | +-------+ | | +---------+ | +================+ 224 | |C&C, | | | |External,| | | 225 | |Update,| | | |Internal,| | v 226 | |Module,| | | |... | | +=========+ 227 | |... | | | +---------+ +----->+ CLEANUP | 228 | +-------+ | +=============+ +=========+ 229 +===========+ 231 <--------------------------> <---------------------------> 232 NETWORK DOMAIN HOST DOMAIN 234 An extended graphical representation of this diagram along with 235 detailed descriptions can be found in [GML]. 237 Figure 1 239 Malware activity in Figure 1 revolves around the concept of access to 240 abstract resources. Essential from an defender's monitoring 241 perspective is that, depending on their implementation and target, 242 malware variants differ substantially in their use of communication 243 networks. Common to many recent malware is that it encrypts 244 communication, attempts to obfuscate it as legitimate traffic, and/or 245 uses hidden communication channels to stay unobserved. 246 Aggressiveness and "noise" that malware generates while propagating, 247 infecting and attacking differs substantially between malware types. 249 This is why this memo focuses on evaluating protocols, interfaces and 250 architectures with respect to their ability to inhibit or support 251 hidden communications. The proposed generic lifecycle model can 252 identify the malware's need for communication to trigger state 253 changes. ( Internal: provide hints to anomaly detection systems? 254 estimated amount of data as an order of magnitude: transferring a 255 malware update or additional malware modules requires more data 256 transfer than a single command. ) 258 The following subsections discuss briefly the generic stages of 259 malware lifecycle in line with [GML]. 261 2.1. Access 263 Starting point of malware operation is the so-called patient zero, 264 denoting a device or method that triggers the initial infection 265 within the system under observation. Examples for access options 266 include, but are not limited to physical access (e.g., through a 267 compromised USB stick inserted into a computer, through hard drive 268 replacement or through starting from a temporary boot device), 269 network access (e.g., as part of existing connections, or through a 270 hidden communication channel), application access (e.g., by sending a 271 legitimate email with compromised payload), or persistent access (for 272 instance an intentional or unintentional backdoor that is installed 273 by firmware or BIOS). 275 The patient zero may depend on qualified (human) support to bypass 276 existing security barriers and gain access to the system. This may 277 be, e.g., a staff member plugging a compromised USB stick into a 278 computer to infiltrate an air-gapped system, or an employee of the 279 computer manufacturer who adds a backdoor to the computer BIOS, 280 firmware or software. Once it has gained access to the target 281 system, the malware can start its operation. 283 Todo: Extend, discuss options. 285 2.2. Infection 287 Having gained (temporary) access to the system, malware depends on 288 system vulnerabilities to support its attempt to infect the system 289 and install itself persistently. Examples include the exploit of 290 backdoors, zero-day vulnerabilities or execution of a malicious email 291 attachment. 293 Todo: Extend, discuss options. 295 2.3. Discovery 297 Once the local system is infected, malware has several options. The 298 most common malware strategy is to first discover new potential 299 victims that are reachable via the communication network. 300 Alternatives for discovery differ in terms of communication verbosity 301 and range from blind scans to passive monitoring of incoming network 302 connections and many variants in between. Blind scans are the most 303 aggressive but also the most verbose variant of discovery, malware 304 actively scanning ranges of IPv4 or IPv6 addresses like, e.g., the 305 current subnet or all IPv4 addresses. In typical networks monitoring 306 devices can easily detect these blind scans because of the high 307 volume of additional illegitimate traffic. Adding some more 308 intelligence to the discovery process results in targeted scans to 309 decrease the amount of traffic that is needed for probing. Examples 310 include the support for distributed scan lists that record already 311 scanned (and infected) devices, or a prioritization of the scan 312 process to prefer system-critical devices like, e.g., the standard 313 gateway. Most stealthy and most difficult to detect is malware that 314 monitors passively its local network interfaces on incoming and 315 outgoing traffic to infer on the network topology and potential 316 targets. However, this stealthiness comes at the cost of reduced 317 malware propagation speed and is typical for complex attack patterns. 319 It is worth mentioning that the supported IP address version has 320 substantial impact on the discovery strategy that malware may use or 321 prefer. Whenever targeting IPv4 addresses, distributed malware can 322 scan the entire Internet within reasonable time. The large address 323 space of IPv6 and the resulting sparse population of subnets will 324 likely result in malware to prefer targeted active scans or passive 325 scanning for the discovery process. 327 Todo: Extend, discuss options. 329 2.4. Propagation 331 Following the discovery of a potential victim, malware attempts to 332 propagate over existing communication channels to gain access to 333 these victims and install new instances of itself in the network. 335 Todo: Extend, discuss options. 337 2.5. Control 339 All presented malware activities or state changes happen either 340 autonomously, which is typical for early malware variants, or guided 341 by some command & control infrastructures that recent malware 342 variants prefer to allow for later malware modification and 343 coordinated attacks. Examples of the latter variant include malware 344 that supports remotely controlled updates, loading of new modules and 345 distributed C&C structures. Such functionality facilitates the 346 update of encryption keys, communication patterns and functionality, 347 as well as the support for new communication protocols. Eventually, 348 this functionality enables offerings business models of "malware as a 349 service": botnet owners may operate infrastructures of compromised 350 devices that customers can rent and use to execute their custom- 351 tailored malicious code. 353 Todo: Extend, discuss options. 355 2.6. Trigger 357 Triggers are essential for supporting the coordination of 358 functionality in distributed malware instances, typical example being 359 the launch of a coordinated DDoS attack. Explicit control 360 communication (command) is one option for an external trigger, other 361 less suspicious options include the setting of conditions that 362 distributed malware instances can observe. Examples include timers 363 (some malware variants implementing explicit time synchronization 364 with dedicated time servers for improved accuracy) but also 365 availability of specific servers at specific domain names, etc. 367 Internal triggers are typically hard-coded into the malware or its 368 modules and support it in targeting and focusing its attacks. These 369 triggers can, for instance, control malware to launch its attacks on 370 specific hardware- or software systems only, or can limit its actions 371 to specific IP address ranges and/or DNS domains. 373 Todo: Extend, discuss options. 375 2.7. Attack 377 Once successfully propagated, malware can start its damaging 378 functionality that ranges from destruction and disruption to theft or 379 extortion. 381 Todo: Extend, discuss options. 383 2.8. Cleanup 385 Recent malware variants focusing on stealthy operation include hidden 386 communication and cleanup functionality to remove themselve from 387 infected systems. The cleanup starts either on completing the attack 388 or on external triggers after accomplishing their goal. 390 Todo: Extend, discuss options. 392 3. Mapping the Lifecycle Model to Real Malware 394 This section maps the known behavior of well-studied, prototypical 395 malware variants to the Malware Lifecycle Model. Eventually, this 396 mapping aims at identifying malware communication needs and 397 behavioral patterns that automated processes can use to discover 398 unknown malware. 400 Central observation with respect to the Malware Lifecycle Model's 401 applicability is that malware has huge incentives to communicate, and 402 that monitoring devices can detect this communication as anomaly. In 403 particular, network communication is a key component for malware to 404 unleash its full destructive potential. Infecting systems remotely 405 and automating and coordinating their distributed activities using 406 network communications brings huge benefits to malware authors. Most 407 notably, being physically located in distinct geographical, 408 jurisdictional, and/or legislational regions supports networked 409 operations while minimizing the risk of being prosecuted for the 410 results of these actions. 412 Bridging the air gap to an isolated system is conditioned by physical 413 access to the system. Options include access to the system or to 414 parts of it, either during the manufacturing process (e.g., by 415 compromising a computer's BIOS and adding a backdoor) or later on, 416 during installation or operation (e.g., by inserting a compromised 417 USB drive into the system). From a malware author's perspective, the 418 physical access alternative has severe drawbacks. First, the need 419 for physical access may leave traces that help in identifying the 420 originator. Second, the lack of updates and coordination: malware 421 must be fully functional at the time of first infection, updates for 422 it depending on recurring physical access to the system. However, 423 even in the case of air-gapped systems malware may subsequently 424 attempt to discover and infect locally connected systems (as 425 exhibited for instance by Stuxnet). These communication attempts may 426 be monitored and detected. 428 Summarizing, the main incentives for malware to communicate include 429 the following: 431 o Network-based malware coordination and control: the closer 432 coordinated distributed malware instances can act, the higher the 433 potential severity of their aggregated actions (for instance in 434 the case of DDoS attacks). Malware may use coordination to reduce 435 network traffic, too (for example by maintaining scan lists when 436 scanning for new victims). 438 o Network-based update: the complexity and sophistication of today's 439 malware increases the effort for its programming. This drives the 440 trend for modular malware that can install a minimum persistent 441 foothold, update itself and can load novel functionality on demand 442 as additional modules. Malware update can support malware authors 443 by protecting their assets in the case of malware identification 444 and/or takeover attempts by competing organizations. In such 445 cases, malware updates can support in the modifications of keys, 446 change of encryption algorithms, use of novel obfuscation methods, 447 etc. 449 o Network-based discovery of potential infection targets and 450 propagation: Scanning for infection candidates and propagation 451 range among the two most verbose activities of today's malware. 452 Worth noting is that specific malware functionality is typically 453 related to malware size, i.e., data volume that the malware must 454 transfer. Depending on the implementation, malware can decide to 455 transfer its entire body at propagation time or install a tiny 456 foothold during propagation that subsequently loads the required 457 modules. The data pattern that monitoring devices can identify 458 differs for these two alternatives: the self-carried malware will 459 be visible in monitoring logs only once, when transferring a large 460 amount of data. The modular variant consists of several smaller 461 data transfers. 463 o tbc... 465 The remainder of this section presents prototypical case studies of 466 existing malware variants, the mapping of their behavior to malware 467 lifecycle model stages and how the lifecycle model can support in 468 their detection. Tables 1-4 of [GML] compare and discuss features 469 and peculiarities of various malware variants in more detail. Future 470 versions of this draft are planned to structure and extend the 471 malware communication aspects that these tables summarize, eventually 472 building the base for a generic malware detection framework. 474 3.1. Case study: Stuxnet 476 Stuxnet [Stuxnet] is a computer worm that was reported for the first 477 time in June 2010. The effort associated with the design and 478 implementation of Stuxnet was substantial, pointing to nation states 479 or intelligence services as authors. This speculation is backed by 480 Stuxnet's stealthy behavior and targeted attack against Siemens 481 Simatic S7 Supervisory Control and Data Acquisition (SCADA) 482 Industrial Control Systems (ICS), eventually aimed at causing 483 physical damage. The following subsections map the known Stuxnet 484 behavioral and communication patterns to the generic Malware 485 Lifecycle model stages and transitionsl. 487 3.1.1. Access 489 The initial Stuxnet access (patient zero) targets air-gapped systems. 490 It uses the autostart functionality of Microsoft Windows 32 bit 491 operating system variants on inserting a USB stick. As soon as the 492 first system has been infected, Stuxnet attempts to discover and 493 access other computers within the same LAN. Whereas the initial 494 infection (USB drive autostart) can not be captured by the Lifecycle 495 Model, the access to other computers within the LAN can be monitored 496 within the network traffic. 498 3.1.2. Infection 500 Stuxnet exploits several zero-day vulnerabilities that were unknown 501 by the time of its release and allowed for privilege escalation on 502 several Microsoft Windows 32 bit operating system variants. In 503 addition, Stuxnet made use of two stolen certificates to sign its 504 drivers. The infection includes installation of dedicated RPC 505 servers and -clients and peer-to-peer clients for communication with 506 other infected Stuxnet instances within the same LAN, as well as 507 infection of connected network shares. Local infection and 508 installation is not in the scope of the Lifecycle Model, whereas the 509 infection of network shares may lead to unexpected network traffic 510 and monitored network anomalies. 512 3.1.3. Discovery 514 Following an initial infection, Stuxnet scans the local network for 515 potential, previously uninfected targets. Stuxnet also uses specific 516 domains to probe for Internet connectivity. All of these network 517 scan operations are typical and can be monitored and detected. 519 3.1.4. Propagation 521 Whenever Stuxnet identifies uninfected targets in the local network 522 with Siemens Step7 software installed, it propagates and attempts to 523 infect these PCs. Otherwise it enters a dormant mode. 525 3.1.5. Control 527 Stuxnet instances within the same network use peer-to-peer RPC calls 528 and encryption to update each other. This method allows one single 529 USB drive infection to update distributed Stuxnet instances in air- 530 gapped systems. Whenever Internet access is available, Stuxnet 531 contacts command and control servers using encrypted communication to 532 receive updates, additional features, and instructions. These update 533 RPC calls and the traffic to command and control servers can be 534 identified by network monitoring systems as anomalies. 536 3.1.6. Trigger 538 Stuxnet installation is conditioned by software (Siemens Step7) 539 software to be installed on, and/or Siemens PLCs being connected to 540 the Windows-based system. The Lifecycle Model can not capture these 541 triggers as they are proprietary to the malware and do not involve 542 network communication. 544 3.1.7. Attack 546 Once installed on a system that controls a PLC, Stuxnet acts as a 547 man-in-the-middle. Faulty commands, aimed to cause physical damage, 548 are sent to the PLC, and forged PLC response codes are forwarded by 549 Stuxnet back to the controlling application to pretend correct 550 operation. Complex (cross-layer) monitoring systems, featuring 551 sensors inside the PLC, could identify the mismatch between the 552 commands sent by the controlling application and the commands 553 received by the PLC. Likewise, system log correlation with network 554 traffic data could reveal anomalous behavior. 556 3.1.8. Cleanup 558 Stuxnet stores several encrypted copies of itself on infected 559 systems. Whereas cleanup on the host system should be feasible, 560 Stuxnet can not delete the malicious code that has been sent to the 561 PLC. Therefore, Stuxnet will leave traces that may identify its 562 presence. 564 3.1.9. Discussion: Stuxnet 566 An analysis of Stuxnet reveals communication patterns that can be 567 matched to specific stages of the Malware Lifecycle Model. Depending 568 on the specific network architecture and on the type of systems 569 connected to the network under observation, these communications may 570 appear more or less anomalous. In Internet of Things (IoT) networks 571 where automated machine-to-machine communications predominate, the 572 type of communication originated by Stuxnet will be highly visible. 574 The more human-triggered network communications are present in the 575 observed traffic, the more difficult the anomaly detection becomes, 577 However, a word of warning is due: Stuxnet incorporates technology 578 that was state-of-the-art more than ten years ago. Evolutions of 579 Stuxnet like Duqu and Duqu2, but also recent malware variants like 580 Gauss, BlackEnergy3, AdWind or Locky show that multi-layer 581 obfuscation and encryption will become the standard for advanced 582 malware. Moreover, malware like, e.g., Regin passively monitors the 583 actual network traffic to select the least suspicious communication 584 protocol as VPN tunnel for its command and control traffic. 585 Therefore, network monitoring and subsequent anomaly detection 586 systems will be challenged to identify anomalies in encrypted and 587 obfuscated network traffic. 589 4. Future work 591 This draft aims at defining the basic framework that advanced anomaly 592 detection methods will build upon. Plans and ongoing work include 593 the definition of metrics and methodologies to rate malware 594 communications, protocols, and interfaces to applications. As an 595 example a malware's adopted scanning strategy is commonly related to 596 its propagation speed. On one hand, aggressive probing by a malware 597 discovers a higher number of potential victims within a shorter time, 598 increasing the malware's speed and likelihood of propagation. The 599 cost of this propagation speed is an increased scanning traffic that 600 results in malware activity being detectable through network 601 monitoring. On the other hand, passive listening malware may spend 602 long periods of time unobserved in a system, monitoring and learning 603 its environment while waiting for activation through potentially 604 hidden communication channels. Discovery of such dormant persistent 605 threats depends, therefore, on detection of highly sporadic, hidden 606 activation signals in almost real-time. 608 5. Acknowledgements 610 Thanks to Kirsty P., Sage B., and Tanja Zseby for their comments that 611 helped substantially in scoping, structuring and wording the initial 612 version of this draft. 614 6. IANA Considerations 616 This memo includes no request to IANA. 618 All drafts are required to have an IANA considerations section (see 619 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 620 for a guide). If the draft does not require IANA to do anything, the 621 section contains an explicit statement that this is the case (as 622 above). If there are no requirements for IANA, the section will be 623 removed during conversion into an RFC by the RFC Editor. 625 7. Security Considerations 627 All drafts are required to have a security considerations section. 628 See RFC 3552 [RFC3552] for a guide. 630 8. References 632 8.1. Normative References 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 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 640 Text on Security Considerations", BCP 72, RFC 3552, 641 DOI 10.17487/RFC3552, July 2003, 642 . 644 8.2. Informative References 646 [CBCS] Rechtin, E., "Systems Architecting: Creating and Building 647 Complex Systems", Prentice Hall ISBN-13: 978-0138803452, 648 1991, 352 pages, 1991. 650 [GML] Eder-Neuhauser, P., Zseby, T., Fabini, J., and G. Vormayr, 651 "Cyber Attack Models for Smart Grid Environments", 652 Elsevier Sustainable Energy, Grids and Networks Volume 12, 653 2017, pp 10-29, December 2017. 655 Pre-published version available for download at 656 https://publik.tuwien.ac.at/files/publik_261089.pdf 658 [I-D.mcfadden-smart-endpoint-taxonomy-for-cless] 659 McFadden, M., "Endpoint Taxonomy for CLESS", draft- 660 mcfadden-smart-endpoint-taxonomy-for-cless-00 (work in 661 progress), July 2019. 663 [I-D.narten-iana-considerations-rfc2434bis] 664 Narten, T. and H. Alvestrand, "Guidelines for Writing an 665 IANA Considerations Section in RFCs", draft-narten-iana- 666 considerations-rfc2434bis-09 (work in progress), March 667 2008. 669 [Stuxnet] Falliere, N., O Murchu, L., and E. Chien, "W32.Stuxnet 670 Dossier", February 2011. 672 URL: 673 https://www.symantec.com/content/en/us/enterprise/media/ 674 security_response/whitepapers/w32_stuxnet_dossier.pdf 676 Author's Address 678 Joachim Fabini 679 TU Wien 680 Gusshausstrasse 25/E389 681 Vienna 1040 682 AT 684 Phone: +43 1 58801 38813 685 Email: Joachim.Fabini@tuwien.ac.at