idnits 2.17.1 draft-paine-smart-indicators-of-compromise-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 (January 13, 2021) is 1199 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Paine 3 Internet-Draft UK National Cyber Security Centre 4 Intended status: Informational O. Whitehouse 5 Expires: July 17, 2021 NCC Group 6 January 13, 2021 8 Indicators of Compromise (IoCs) and Their Role in Attack Defence 9 draft-paine-smart-indicators-of-compromise-02 11 Abstract 13 Indicators of Compromise (IoCs) are an important technique in attack 14 defence (often called cyber defence). This document outlines the 15 different types of IoC, their associated benefits and limitations, 16 and discusses their effective use. It also contextualises the role 17 of IoCs in defending against attacks through describing a recent case 18 study. This draft does not pre-suppose where IoCs can be found or 19 should be detected - as they can be discovered and deployed in 20 networks, endpoints or elsewhere - rather, engineers should be aware 21 that they need to be detectable (either by endpoints, security 22 appliances or network-based defences, or ideally all) to be 23 effective. The purpose of this draft is to document both the 24 operational issues, but also the best practices associated with use 25 of IoCs today. This draft provides a foundation for proposals for 26 new approaches to operational challenges in network security. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 17, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may not be modified, and derivative works of it may not 61 be created, except to format it for publication as an RFC or to 62 translate it into languages other than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. What are IoCs? . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Case Study: Cobalt Strike . . . . . . . . . . . . . . . . . . 5 71 4.1. Overall TTP . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. IoCs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Why use IoCs? . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1. IoCs can be used even with limited resource . . . . . . . 6 75 5.2. IoCs have a multiplier effect on attack defence effort . 7 76 5.3. IoCs are easily shareable . . . . . . . . . . . . . . . . 7 77 5.4. IoCs can be attributed to specific threat actors . . . . 7 78 5.5. IoCs can provide significant time savings . . . . . . . . 8 79 5.6. IoCs allow for discovery of historic attacks . . . . . . 8 80 5.7. IoCs underpin and enable multiple layers of the modern 81 defence-in-depth strategy . . . . . . . . . . . . . . . . 8 82 6. Pain, Fragility and Precision . . . . . . . . . . . . . . . . 9 83 6.1. Pyramid of Pain . . . . . . . . . . . . . . . . . . . . . 9 84 6.2. Fragility . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6.3. Precision . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6.4. Comprehensive Coverage . . . . . . . . . . . . . . . . . 11 87 7. Defence in Depth . . . . . . . . . . . . . . . . . . . . . . 12 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 92 12. Informative References . . . . . . . . . . . . . . . . . . . 14 93 Appendix A. Case Study: APT33 . . . . . . . . . . . . . . . . . 16 94 A.1. Overall TTP . . . . . . . . . . . . . . . . . . . . . . . 17 95 A.2. IoCs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 98 1. Introduction 100 This draft aims to describe, and illustrate the purpose of, 101 Indicators of Compromise (IoCs), which are widely used in attack 102 defence (often called cyber defence) as well as their effective use. 103 The concept of the 'Pyramid of Pain' [PoP] will also be introduced to 104 show the properties of the broad range of defences that IoCs can 105 provide. This draft will also describe a real intrusion set (a 106 collection of indicators for a specific attack), delivered by APT33, 107 for which IoCs were identified and used in defence. This document is 108 not a comprehensive report of APT33 and is intended to be read 109 alongside APT33 open source material (for example, [Symantec]). 110 Another case study, Cobalt Strike, is also included and intended to 111 be read alongside open source material (for example, [NCCGroup]). 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Terminology 121 Attack defence: the activity of providing cyber security to an 122 environment through the prevention, detection and response to 123 attempted and successful cyber intrusions. This outcome is achieved 124 through the blocking, monitoring and response to adversarial activity 125 at a network, host and/or application level. 127 Domain Generation Algorithm (DGA): used in malware strains to 128 generate domain names periodically. Adversaries may use DGAs to 129 dynamically identify a destination for command and control traffic, 130 rather than relying on a list of static IP addresses or domains that 131 can be blocked more easily. 133 Tactics, Techniques and Procedures (TTPs): an attacker's 134 manifestation or modus operandi across technology, methodologies and 135 operations. Discrete parts of an attacker's TTP can form specific 136 Indicators of Compromise (IoCs) as if they were a fingerprint. 138 3. What are IoCs? 140 Indicators of Compromise (IoCs) are artefacts observed about an 141 attacker; their tactics, techniques, procedures or associated tooling 142 and infrastructure. These indicators can be observed at a 143 combination of network or endpoint (host) levels and can, with 144 varying degrees of confidence, help to identify an occurrence of an 145 intrusion or associated activity to a known intrusion set. These 146 IoCs are used by network defenders (blue teams) to protect their 147 networks by, for example, enabling detection of compromise or pro- 148 active blocking of malicious traffic. Examples of protocol-related 149 IoCs can include: 151 o IPv4 and IPv6 addresses in network traffic 153 o DNS domain names in network traffic, resolver caches or logs 155 o TLS Server Name Indication values in network traffic 157 o Code signing certificates in binaries or TLS certificate 158 information in network traffic such as SHA256 hashes 160 o Cryptographic hashes (e.g. MD5, SHA1 or SHA256) of malicious 161 binaries or scripts when calculated from network traffic or file 162 system artefacts 164 o Attack tools and their code structure, such as Mimikatz [Mimikatz] 166 o Attack techniques, such as Kerberos golden tickets [GoldenTicket] 167 which can be observed via network traffic or system analysis 169 IoCs are often discovered initially through manual investigation or 170 automated analysis and then shared at scale so a variety of 171 individuals and organisations can defend themselves. They can be 172 discovered in a range of sources, including in networks and at 173 endpoints, but wherever they exist, they need to be made available to 174 security appliances and associated apparatus to ensure that they can 175 be deployed quickly and widely. For IoCs to provide defence-in-depth 176 (see Section 7), which is one of their key strengths, they should be 177 deployed on both the network and on endpoints through solutions that 178 have sufficient privilege to act on them, to cope with different 179 points of failure. 181 IoCs can be of varying quality. An IoC without context is not much 182 use for network defence - a defender could do different things with 183 an IoC (e.g. monitor it, block it, log it) depending on this context. 184 Without the associated context, for example the threat actor it 185 relates to, the last time it was seen in use, its expected lifetime 186 or other related IoCs, the usefulness of an IoC is greatly reduced. 187 On the other hand, an IoC delivered with context is much more useful 188 to a network defender, who can then make an informed choice on how to 189 use it to protect their network. 191 IoCs go through a lifecycle, which includes: 193 o Development and discovery of the IoC 195 o Confidence level assignment 197 o Packaging 199 o Distribution e.g. via Malware Information Sharing Platform [MISP] 201 o Deployment 203 o Detection (useful lifetime) 205 o Investigation 207 o Actor shift resulting in new development and discovery activities 209 [#TODO - check if this satisfies requests for detail on IoC lifecycle 210 or if further explanation of these stages is needed for the purposes 211 of this draft] 213 How long an IoC remains useful will vary and be dependent on a 214 variety of factors including initial confidence level, fragility and 215 precision of the IoC. For example, a connection to a known botnet 216 command and control server may indicate a problem, but does not 217 guarantee it. Fragility can apply to an entire class of IoCs for a 218 range of reasons; for example, IPv4 addresses are becoming more 219 fragile due to addresses growing scarce, widespread use of cloud 220 services and domains changing ownership. 222 4. Case Study: Cobalt Strike 224 Cobalt Strike is a commercial command and control framework that 225 consists of an implant / beacon framework, network protocol and a 226 server. The beacon and network protocol are highly malleable. The 227 network protocol supports encryption and other techniques such as 228 domain fronting to attempt to avoid obvious passive detection. 230 4.1. Overall TTP 232 Detection of Cobalt Strike is possible if the C2 servers themselves 233 and their associate beacon configurations can be obtained. 234 Tradecraft has been developed that allows the fingerprinting of these 235 servers based on how they respond. This allows the beacon 236 configurations to be downloaded and the associated domain names and 237 IP addresses extracted as IoCs. 239 4.2. IoCs 241 The resulting mass IoCs for Cobalt Strike are: 243 IP addresses of the command and control servers 245 domain names used 247 Whilst these IoCs need to be refreshed regularly, due to the ease of 248 which they can be changed, they are easily distributable. Based on 249 the authors' experience of protecting public sector organisations, 250 they are also disruptive to threat actor operations that use Cobalt 251 Strike. 253 These IoCs cover the middle levels of the PoP (see Section 6). 254 Additionally, these IoCs can be used to check historical data for 255 evidence of past compromise, as well as deployed to block further 256 infection and/or to detect infection in a timely manner, thereby 257 contributing to preventing the loss of user and system data. 259 5. Why use IoCs? 261 5.1. IoCs can be used even with limited resource 263 IoCs are scalable and easy to deploy which makes them a really 264 valuable asset for smaller entities. IoCs are also inexpensive to 265 use. For example, take a small manufacturing subcontractor in a 266 supply chain that produces a critical, highly specialised, component. 267 The small manufacturer represents an attractive target because there 268 would be disproportionate impact on both the supply chain and the 269 prime contractor if it were compromised. In addition, it is likely 270 to have comparatively smaller resource to manage the risks it faces. 271 It is reasonable to assume that this small manufacturer will have 272 only basic security (in the form of firewalls, similar network 273 protection devices, or an outsource agreement), however it can still 274 leverage IoCs to great effect. IoCs can be deployed to give a 275 baseline protection against known threats by small entities without 276 access to a significant defensive team or the threat intelligence 277 relationships necessary to perform resource-intensive investigation. 279 In addition, as detailed further in Section 5.2, the prime contractor 280 can also supply IoCs to the subcontractor to provide an uplift in 281 defensive capability in order to protect the prime contractor. 282 Affording some level of protection to organisations across a spectrum 283 of resource, maturity, and sophistication is a major part of the 284 appeal for IoCs. 286 5.2. IoCs have a multiplier effect on attack defence effort 288 The correspondence is one-to-many: simply blocking one IoC may 289 protect thousands of users within an organisation. Discovering one 290 IoC can be intensive, but sharing IoCs via well-established routes 291 such as the Malware Information Sharing Platform (MISP) [MISP] will 292 protect thousands of organisations and end users. The shareability 293 and reproducibility of IoCs is a huge advantage; it allows a threat 294 defender to look for things consistently and automate the process of 295 defending their networks. It doesn't require intensive training (as 296 needed to, for example, manually analyse tipped machine learning 297 events), nor does it require time-intensive resource to deploy IoCs. 299 In the case of an ongoing email phishing campaign, IoCs can be 300 monitored, discovered and deployed quickly and easily. If they are 301 deployed quickly via a mechanism such as a protective DNS filtering 302 service, they can be more effective still, as the same email campaign 303 is mitigated before a recipient clicks the link or before malicious 304 payloads can call out for instructions. While this approach can 305 therefore be faster than some traditional defences, the most 306 important benefit is that other parties can be protected without 307 additional effort. 309 5.3. IoCs are easily shareable 311 This is due to two major factors: firstly, because lists of 312 identifiers are easy to distribute, and secondly, due to standards 313 such as Structured Threat Information Expression (STIX) [STIX] that 314 provide a well-defined format for sharing. This allows IoCs to give 315 blanket coverage for organisations and allow widespread mitigation in 316 a timely fashion. They can be shared with systems administrators - 317 from small to large organisations, from large teams to a single 318 individual - allowing them to implement defences on their network. 320 5.4. IoCs can be attributed to specific threat actors 322 Deployment of various modern system security services, such as 323 endpoint detection and response or firewall filtering, comes with an 324 inherent trade-off between breadth of protection and risk of false 325 positives (see Section 6). An organisation can examine their own 326 risk, impact and threat - they can perform their own information 327 assurance and threat modelling - and work to manage those threats 328 they wish to. This means an organisation can prioritise or accept 329 trade-offs against a subset of malicious actors; tying IoCs to threat 330 actors allows organisations to focus their defences against 331 particular risks. Organisations should have the technical freedom 332 and the capability to choose their risk posture and defence methods. 334 5.5. IoCs can provide significant time savings 336 Not only are there time savings from sharing IoCs, saving duplication 337 of investigation effort, but deploying them automatically at scale is 338 seamless for many enterprises. Where automatic deployment of IoCs is 339 working well, organisations and users get blanket protection with 340 minimal human intervention and minimal effort, a key goal of attack 341 defence. The ability to do this at scale and at pace is often vital 342 to respond to agile threat actors. Conversely, protecting a complex 343 network without automatic deployment of IoCs could mean updating 344 every single endpoint or network device consistently and reliably to 345 the same security level. The work this entails (including polling 346 for logs, locating assets and devices, and manually checking patch 347 levels) introduces complexity and a need for skilled analysts. While 348 it is still necessary to invest effort to eliminate false positives 349 when widely deploying IoCs, the cost and effort involved can be far 350 smaller than the work entailed in reliably patching all endpoint and 351 network devices - for example, particularly on legacy systems that 352 may be particularly complicated, or even impossible, to update. 354 5.6. IoCs allow for discovery of historic attacks 356 A network defender can use recently acquired IoCs in conjunction with 357 historic data, such as logged DNS queries or email attachment hashes, 358 to hunt for signs of past compromise. Not only can this technique 359 help to build up a clear picture of past attacks, but it also allows 360 for retrospective mitigation of the effects of any previous 361 intrusion. This use case is reliant on historic data not having been 362 compromised itself, by a technique such as Timestomp [Timestomp], or 363 being incomplete due to third party policies, but is nonetheless 364 valuable for detecting past attacks. 366 5.7. IoCs underpin and enable multiple layers of the modern defence-in- 367 depth strategy 369 Firewalls, Intrusion Detection Systems and Security Incident Event 370 Management platforms all employ IoCs to identify and mitigate 371 threats. Anti-Virus (AV) products, as part of a multi-faceted 372 approach, deploy IoCs via catalogues or libraries to all supported 373 client endpoints. Of course, IoCs do not address all attack defence 374 challenges - but they form a vital tier of any organisation's layered 375 defence. 377 As an example, open source malware can be deployed by many different 378 actors, each with their own modus operandi, commonly called "Tactics, 379 Techniques and Procedures" (TTPs), and their own infrastructure. 380 However, if the same executable is used, the hash remains the same - 381 and this IoC can be deployed in endpoints through AV to protect 382 regardless of TTP and infrastructure. Should this defence fail 383 however, other defences can prevent malicious actors progressing 384 further through the attack chain - for instance, by blocking known 385 malicious domain name look-ups and thereby preventing the malware 386 calling out to its command and control infrastructure. 388 A different malicious actor changes the intrusion set deployed across 389 different campaigns, but their access vectors often remain consistent 390 and well-known. Therefore, this TTP and pattern of activity can be 391 recognised and proactively defended against. For example, if their 392 access vector consistently exploits a vulnerability in software, 393 regular and estate-wide patching can prevent the attack from taking 394 place. Should these pre-emptive measures fail however, other IoCs 395 observed across multiple campaigns can be used to prevent the attack 396 at different stages in the attack chain. Hence, IoCs can underpin 397 multiple layers of any modern defence-in-depth strategy. 399 6. Pain, Fragility and Precision 401 The variety of IoC types inherently embody a set of trade-offs 402 between the risk of false positives (misidentifying non-malicious 403 traffic as malicious) and the risk of failing to identify attacks. 404 The pain of modifying attacks to subvert known IoCs inversely 405 correlates with both the fragility of various IoCs as a tool for 406 attack defence, and the precision with which IoCs identify an attack. 407 Research is needed to elucidate the exact nature of these trade-offs 408 between pain, fragility and precision. 410 6.1. Pyramid of Pain 412 IoCs form a "Pyramid of Pain" [PoP] that can be used for prevention, 413 detection and mitigation. This represents how much pain it is to an 414 adversary to change. The layers of the PoP range from hashes to TTPs 415 and the pain ranges from recompiling code to creating a new attack 416 strategy. 418 On the lowest (and least painful) level are hashes of malicious 419 files. These are easy for a defender to gather and can be deployed 420 to firewalls, for example, to block malicious downloads. To subvert 421 this defence, however, an adversary need only recompile code with 422 some trivial changes, thereby changing the hash. IoCs aren't the 423 only route for doing this blocking but are a quick, less intrusive 424 and more convenient method. 426 The next two levels are IPs and domain names. These are blockable, 427 with varying false positive rates (see Section 6.4), and often cause 428 more pain to an adversary to subvert; they may have to change IP 429 ranges, find a new provider, and change their code if the IP address 430 is hard-coded (rather than resolved). Domain names are more granular 431 than IP addresses and are more painful for an adversary to change. 433 /\ 434 / \ MORE PAIN 435 / \ LESS FRAGILE 436 / \ LESS PRECISE 437 / TTPs \ 438 / \ / \ 439 ============== | 440 / \ | 441 / Tools \ | 442 / \ | 443 ====================== | 444 / \ | 445 / network/host artefacts \ | 446 / \ | 447 ============================== | 448 / \ | 449 / domain names \ | 450 / \ | 451 ====================================== | 452 / \ | 453 / IP addresses \ | 454 / \ \ / 455 ============================================== 456 / \ LESS PAIN 457 / Hash values \ MORE FRAGILE 458 / \ MORE PRECISE 459 ====================================================== 461 Figure 1 463 Network and host artefacts, such as changed timestamps of files left 464 on the endpoint (see [Timestomp]) or a beaconing pattern on the 465 network, are harder still to change, as they relate specifically to 466 the attack taking place and may not be under the direct control of 467 the attacker. 469 Tools and TTPs form the top two layers of the pyramid; these layers 470 describe a threat actor's methodology - the way they perform the 471 attack. An example could be deployment of malicious code to perform 472 reconnaissance of a victim's network, which pivots laterally to a 473 valuable endpoint, then downloads a ransomware payload. Tools refer 474 to the software used to conduct the attack, whereas TTPs relate to 475 the broader attack strategy being used. Information on TTPs and 476 Tools take intensive effort to diagnose on the part of the defender, 477 but they are fundamental to the attacker and campaign and hence 478 incredibly painful for the adversary to change. 480 6.2. Fragility 482 For a network defender, the PoP can also be thought of in terms of 483 fragility. The less painful it is for the attacker to change the 484 IoC, the more fragile that IoC is as an attack defence tool. It 485 should be relatively simple to get a hash of the various file 486 attachments (and then deploy this through AV or other means) or to 487 get the email subject. However, when thinking in terms of fragility, 488 the hash IoCs or email subjects are fragile and can be changed; in 489 reality, they will be changed easily between campaigns. IPs and 490 domain names can also be changed between campaigns, but it is harder 491 - and if the IoCs didn't change but weren't blocked, that's a missed 492 opportunity. 494 6.3. Precision 496 The PoP can be also considered in terms of how precise the defence 497 can be, with the false positive rate roughly increasing as we move up 498 the pyramid. A hash (e.g. MD5, SHA1 or SHA2) can specify a 499 particular executable, so the false positive is nil. On the other 500 hand, TTPs or fuzzier rules may apply to various binaries, and even 501 benign software may share the same identifying methodology. This 502 corresponds with the consequences for fragility mentioned above, as 503 the more precise IoCs, such as hashes, are also the most fragile. 505 6.4. Comprehensive Coverage 507 IoCs provide the defender with a range of options across the PoP 508 layers, balancing between precision and fragility to give high 509 confidence events that are practical and useful. Broad coverage of 510 the PoP is important as it allows the defender to cycle between high 511 precision but high fragility options and more robust but less precise 512 indicators. As fragile indicators are changed, the more robust IoCs 513 allow for continued detection and faster rediscovery. This is why 514 it's important to collect as many IoCs as possible across the whole 515 PoP. 517 At the top of the PoP, TTPs identified through anomaly detection and 518 machine learning are more likely to have false positives, which gives 519 lower confidence and, vitally, requires better trained analysts to 520 understand and implement the defences. Hashes, at the bottom, are 521 precise and easy to deploy but are fragile and easily changed within 522 and across campaigns by malicious actors. 524 In the middle of the pyramid, IoCs related to network information 525 (such as domains and IP addresses) can be particularly useful. They 526 allow for broad coverage, without requiring each and every endpoint 527 security solution to be updated. This means they can shine in 528 contexts where ensuring endpoint security isn't possible such as 529 "Bring Your Own Device" (BYOD), IoT and legacy environments. Using 530 these network level IoCs can also protect against a compromised 531 endpoint as, even if the compromise passes unnoticed, the IoCs can 532 still be checked against network traffic, allowing detection of the 533 attack. For example, in a BYOD environment, enforcing security 534 policies on the device can be difficult, so non-endpoint IoCs and 535 solutions are needed to allow detection of compromise even with no 536 endpoint coverage. 538 Covering a broad range of IoCs gives defenders a wide range of 539 benefits: easy to deploy, high confidence enough to be effective, 540 painful enough to change and disruptive to bad actors. The 541 combination of these factors cements IoCs as a particularly valuable 542 tool for defenders with limited resources. 544 7. Defence in Depth 546 Endpoint Detection and Response (EDR) or Anti-Virus (AV) are often 547 the first port of call for protection from intrusion but endpoitn 548 solutions aren't a panacea. One issue is that there are many 549 environments where it is not possible to keep them updated, or in 550 some cases, deploy them at all. For example, the Owari botnet, a 551 Mirai variant [Owari], exploited Internet of Things (IoT) devices 552 where such solutions could not be deployed. It is because of such 553 gaps, where endpoint solutions can't be relied on (see [CLESS]), that 554 a defence-in-depth approach is commonly advocated, using a blended 555 approach that includes both network and endpoint defences. 557 If an attack happens, then you hope an endpoint solution will pick it 558 up. If it doesn't, it could be for many good reasons: the endpoint 559 solution could be quite conservative and aim for a low false-positive 560 rate, it might not have ubiquitous coverage or it might only be able 561 to defend the initial step of the kill chain [KillChain]. In the 562 worst cases, the attack specifically disables the endpoint solution 563 or the malware is brand new and so won't be recognised. Going up the 564 pyramid, IP addresses are next, and here we have ACLs (access control 565 lists) that can go on firewalls - or your favourite DNS filtering 566 service for protection. Using IPs will blanket-defend a range of 567 endpoints, from printers [IoT] to "Bring Your Own Device" (BYOD) to 568 capable endpoints. Going further through the pyramid, domains are 569 next - these are more granular. 571 One example of how IoCs provide a layer of a defence-in-depth 572 solution is Protective DNS (PDNS), a free and voluntary DNS filtering 573 service provided by the UK NCSC for UK public sector organisations 574 [PDNS]. In 2018, this service blocked access to 57.4 million DNS 575 queries for 118,527 unique reasons (out of 68.7 billion total 576 queries) for the organisations signed up to the service [ACD2019]. 28 577 million of them were for domain generation algorithms (DGAs) [DGAs], 578 including 15 known DGAs which are a type of TTP. 580 IoCs such as malicious domains can be put on PDNS straight away and 581 can then be used to prevent access to those known malicious domains 582 across the entire estate of over 460 separate public sector entities 583 that use NCSC's PDNS [Annual2019]. Coverage can be patchy with 584 endpoints, as the roll-out of protections isn't uniform or 585 necessarily fast - but if the IoC is on PDNS, a consistent defence is 586 maintained. This offers protection, regardless of whether the 587 context is a BYOD environment or a managed enterprise system. Other 588 IoCs, like Server Name Indicator values in TLS or the server 589 certificate information, also provide IoC protections. 591 Similar to the AV scenario, large scale services face risk decisions 592 around balancing threat against business impact from false positives. 593 Organisations need to be able to retain the ability to be more 594 conservative with their own defences, while still benefiting from 595 them. For instance, a commercial DNS filtering service is intended 596 for broad deployment, so will have a risk tolerance similar to AV 597 products; whereas DNS filtering intended for government users (e.g. 598 PDNS) can be more conservative, but will still have a relatively 599 broad deployment if intended for the whole of government. A 600 government department or specific company, on the other hand, might 601 accept the risk of disruption and arrange firewalls or other network 602 protection devices to completely block anything related to particular 603 threats, regardless of the confidence, but rely on a DNS filtering 604 service for everything else. 606 Other network defences can make use of this blanket coverage from 607 IoCs, like middlebox mitigation, proxy defences, and application 608 layer firewalls, but they're out of scope for this draft. Note too 609 that DNS goes through firewalls, proxies and possibly to a DNS 610 filtering service; it doesn't have to be unencrypted, but these 611 appliances must be able to decrypt it to do anything useful with it, 612 like blocking queries for known bad URIs. 614 8. Security Considerations 616 This draft is all about system security. However, when poorly 617 deployed, IoCs can lead to over-blocking which may present an 618 availability concern for some systems. While IoCs preserve privacy 619 on a macro scale (by preventing data breaches), research could be 620 done to investigate the impact on privacy from sharing IoCs, and 621 improvements could be made to minimise any impact found. The 622 creation of a privacy-preserving IoC sharing method, that still 623 allows both network and endpoint defences to provide security and 624 layered defences, would be an interesting proposal. 626 9. Conclusions 628 IoCs are versatile and powerful. IoCs underpin and enable multiple 629 of the layers of the modern defence-in-depth strategy. IoCs are easy 630 to share, providing a multiplier effect on attack defence effort and 631 they save vital time. Network-level IoCs offer protection, 632 especially valuable when an endpoint-only solution isn't sufficient. 633 These properties, along with their ease of use, make IoCs a key 634 component of any attack defence strategy and particularly valuable 635 for defenders with limited resources. 637 For IoCs to be useful, they don't have to be unencrypted or visible 638 in networks - but crucially they do need to be made available, along 639 with their context, to entities that need them. It is also important 640 that this availability and eventual usage copes with multiple points 641 of failure, as per the defence-in-depth strategy, of which IoCs are a 642 key part. 644 10. IANA Considerations 646 This memo includes no request to IANA. 648 11. Acknowledgements 650 Thanks to all those who have been involved with improving cyber 651 defence in the IETF and IRTF communities. 653 12. Informative References 655 [ACD2019] Levy, I. and M. S, "Active Cyber Defence - The Second 656 Year", 2019, . 659 [Annual2019] 660 NCSC, "Annual Review 2019", 2019, 661 . 664 [CLESS] Taddei, A., Wueest, C., Roundy, K., and D. Lazanski, 665 "Capabilities and Limitations of an Endpoint-only Security 666 Solution", 2019, . 669 [DGAs] MITRE, "Dynamic Resolution: Domain Generation Algorithms", 670 2020, . 672 [FireEye] O'Leary, J., Kimble, J., Vanderlee, K., and N. Fraser, 673 "Insights into Iranian Cyber Espionage: APT33 Targets 674 Aerospace and Energy Sectors and has Ties to Destructive 675 Malware", 2017, . 679 [FireEye2] 680 FireEye, "OVERRULED: Containing a Potentially Destructive 681 Adversary", 2018, . 685 [GoldenTicket] 686 Soria-Machado, M., Abolins, D., Boldea, C., and K. Socha, 687 "Kerberos Golden Ticket Protection", 2014, 688 . 692 [IoT] NCC Group, "Security Impact of IoT on the Enterprise", 693 2019, . 696 [KillChain] 697 Lockheed Martin, "The Cyber Kill Chain", 2020, 698 . 701 [Mimikatz] 702 Mulder, J., "Mimikatz Overview, Defenses and Detection", 703 2016, . 707 [MISP] MISP, "MISP", 2019, . 709 [NCCGroup] 710 Jansen, W., "Abusing cloud services to fly under the 711 radar", 2021, . 714 [Owari] NCSC, "Owari botnet own-goal takeover", 2018, 715 . 718 [PDNS] NCSC, "Protective DNS", 2019, 719 . 721 [PoP] Bianco, D., "The Pyramid of Pain", 2014, . 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, 726 DOI 10.17487/RFC2119, March 1997, 727 . 729 [STIX] OASIS Cyber Threat Intelligence, "STIX", 2019, 730 . 733 [Symantec] 734 Symantec, "Elfin: Relentless", 2019, 735 . 738 [Timestomp] 739 OASIS Cyber Threat Intelligence, "Timestomp", 2019, 740 . 742 Appendix A. Case Study: APT33 744 To further contextualise IoCs, we describe a real-world case study: a 745 current campaign by the threat actor APT33, also known as Elfin and 746 Refined Kitten (see [Symantec]). APT33 has been assessed by industry 747 to be a state-sponsored group [FireEye], yet in this case study, IoCs 748 still gave defenders an effective tool against such a sophisticated 749 and powerful adversary. The group has been active since at least 750 2015 and is known to target a range of sectors including 751 petrochemical, government, engineering and manufacturing. Activity 752 has been seen in countries across the globe, but predominantly in the 753 USA and Saudi Arabia. 755 A.1. Overall TTP 757 The techniques employed by this actor exhibit a relatively low level 758 of sophistication: typically, spear phishing is used with document 759 lures that imitate legitimate publications. Once inside a target 760 network, the actor will attempt to pivot to other machines to gather 761 documents and gain access to administrative credentials. In some 762 cases, users are tricked into providing credentials that are then 763 used to enable the use of RULER, a freely available tool that allows 764 exploitation of an email client. The attacker, in possession of a 765 target's password, uses RULER to access the target's mail account, 766 and embed a malicious script which will be triggered when the mail 767 client is next opened, resulting in the execution of malicious code 768 (often additional malware retrieved from the Internet) (see 769 [FireEye2]). 771 When a destructive tool is deployed, it relies on overwriting the 772 master boot record (MBR) of the hard drives in as many PCs as 773 possible. This type of tool, known as a wiper, results in data loss 774 and renders devices unusable until the operating system is 775 reinstalled. In some cases, the actor is able to use administrator 776 credentials to invoke execution across a large swathe of a company's 777 IT estate at once; where this isn't possible the actor may attempt to 778 spread the wiper to as many PCs as possible manually, or by using 779 wormlike capabilities against unpatched vulnerabilities on the 780 internal network. 782 A.2. IoCs 784 As a result of investigations by both industry and NCSC in 785 partnership, a set of IoCs were compiled that could then be shared 786 out with government and industry to enable network defenders to 787 search for these indicators in their networks. Detection of these 788 IoCs is likely indicative of APT33 targeting and could indicate 789 potential compromise and subsequent use of destructive malware. 790 Network defenders could also initiate processes to block these IoCs 791 and foil future attacks. This set of IoCs comprised: 793 o 9 fragile indicators including hashes and email subject lines 795 o 5 IP addresses 797 o 7 domains 799 These IoCs mostly cover the bottom few levels of the PoP, with the 800 network level IoCs giving resilience not provided by the fragile 801 indicators. Not only can these IoCs be used to check historical data 802 for evidence of past compromise, but they can also be deployed to 803 block further infection and/or to detect infection in a timely 804 manner, thereby contributing to preventing the loss of user and 805 system data. 807 Authors' Addresses 809 Kirsty Paine 810 UK National Cyber Security Centre 812 Email: kirsty.p@ncsc.gov.uk 814 Ollie Whitehouse 815 NCC Group 817 Email: ollie.whitehouse@nccgroup.com