idnits 2.17.1 draft-macaulay-6man-reputation-intelligence-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 33. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 437. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (May 30, 2012) is 4342 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF 2' is mentioned on line 154, but not defined == Missing Reference: 'REF 3' is mentioned on line 183, but not defined == Unused Reference: 'REF1' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'REF2' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'REF3' is defined on line 370, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group T. Macaulay 3 Internet-Draft 2Keys Security Solutions 4 Intended status: Informational D. McMahon 5 Expires: December 1, 2012 Bell Canada 6 E. Doron 7 Radware 8 P. Jungck 9 Cloudshield 10 May 30, 2012 12 Internet reputation intelligence: Problem Statement 13 draft-macaulay-6man-reputation-intelligence-00 15 Abstract 17 This draft represent the initial public discussion of the value of 18 proactive, reputation intelligence on the Internet and some of the 19 challenges associated with these services that may be partially 20 addressed through novel use of IPv6 features and functions. 22 This document is intended to outline the concept of Internet 23 reputation intelligence, the benefits it brings to network elements 24 and endpoints. This draft also addresses the challenges associated 25 with legacy security systems based on threat-signatures, and some of 26 the current weaknesses of reputation management systems. 28 Status of this Memo 30 By submitting this Internet-Draft, each author represents that any 31 applicable patent or other IPR claims of which he or she is aware 32 have been or will be disclosed, and any of which he or she becomes 33 aware will be disclosed, in accordance with Section 6 of BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 1, 2012. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions used in this document . . . . . . . . . . . . . . 3 51 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 59 Intellectual Property and Copyright Statements . . . . . . . . . . 11 61 1. Introduction 63 Threats on the public Internet in forms such as malware (malicious 64 software) and phishing have reached new levels of efficiency and 65 effectiveness, where vulnerabilities are routinely discovered and 66 exploited faster than vendors can release patches. Similarly, the 67 time between system penetration (when the attack succeeds), and 68 exploitation (when the asset is utilized in a manner unauthorized by 69 the owner) can be very small. 71 This situation is creating a major burden for risk managers. On the 72 business side, increased vulnerabilities and associated system 73 exploitations lead to increased regulation and legislative sanctions. 74 On the technical side, ever more security tools, products and vendors 75 are required to keep even basic IT services "reasonably" secure, 76 raising overall costs and complexity. 78 Security resources inside organizations are frequently overworked, 79 and are often limited to reactive measures. Enterprises are looking 80 towards a variety of service-providers (carriers, ISPs, managed 81 security service providers - MSSPs) to provide them with proactive 82 capabilities. Some service providers now create and maintain 83 reputation information, and use existing trusted, business 84 relationships with organizations to deliver this intelligence through 85 novel a variety of means; the challenge becomes the effective and 86 efficient delivery of this intelligence. 88 IPv6 may offer some useful abilities to deliver reputational 89 information in-band, in near-real-time, through the use of features 90 such as the flow label or headers extensions. IPv6 headers may be 91 formatted with reputation scores such that network elements or end- 92 points could read the reputations and apply organizational security 93 policy on inbound or outbound packets and flows. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in . 101 3. Background 103 Internet based threats in the form of malware and the agents that 104 control this software (organized crime, spies, hacktivists) have 105 surpassed the abilities of signature-based security systems to remain 106 up to date and provide timely mitigations. Whether they be: on the 107 enterprise perimeter in elements such as firewalls and proxies, in 108 elements such as Intrusion Detection Services (IDS) within the 109 organizational network, at the endpoint points in the form of anti- 110 virus or host-IDS, or as managed services in the form of anti-virus/ 111 spam "in the cloud", a signature-based system needs supplementary 112 support from reputation-based systems. 114 Signature-based security systems all rely upon malware being 115 detected, isolated, dissected, and templated into unique hash- 116 identifiers or regular expression filters, which are then distributed 117 far and wide as information-bases containing hundreds of thousands if 118 not millions of malware "signatures". In order to utilize these 119 signature bases, perimeter, network or end-point security elements 120 must typically assemble data payloads and hash the contents looking 121 for matches with the signature base. Some security systems try to 122 enhance or supplement signature-based approach with heuristic-based 123 analysis, looking for patterns in network traffic or packet contents 124 as indicators of malware or malicious activity. Signature-based 125 systems are highly effective for known malware, but they don't know 126 what they don't know. Meanwhile, heuristic based systems make 127 intelligence guesses, but are subject to desensitizing false- 128 positives. All these systems represent resource-intensive 129 infrastructure and administration. 131 The sensitivity of IP networks continues to grow as a new generation 132 of "smart" devices is enabled with Internet Protocol. These devices 133 include those using both fixed line and wireless networks for remote 134 operation and networking highly dispersed devices. The range of 135 these devices makes this situation new and exceptional in a security 136 context: control devices and sensors represent the interface between 137 the logic world of networks and software applications, and the 138 physical world where affects are kinetic in nature. This diverse 139 collections of IP-based assets is coming to be known as the Internet 140 of Things (IOT). In response to the accelerating threats and 141 elevating consequences associated with incidents, the security vendor 142 community and various non-profit entities have developed products and 143 services integrated with forms of reputation intelligence. This 144 intelligence enables proactive security controls to supplement 145 signature-based and heuristic systems, and better protect logical 146 systems. 148 Reputation intelligence typically consists of IP addresses and 149 domains (associated with IP addresses through DNS), which have been 150 observed engaged in either attack or victim-behaviours such as: 151 inappropriate messaging and traffic volumes, suspicious domain name 152 management, Botnet command-and-control traffic, attempts to send or 153 relay malware and other indicators of either malicious intent or 154 compromise.[REF 2] IP addresses may also end up on a security 155 reputation list if they are identified as compromised through vendor- 156 specific signature-based processes. The proactive element of the 157 reputation intelligence lies in the ability for hosts to be 158 forewarned of the reputation of addresses on the Internet. The 159 overall effect is a new layer of security which can be applied 160 within, on, or beyond the organizational perimeter. For instance, 161 security managers could configure perimeter access control services 162 to escalate authentication based on reputation, or instruct upstream 163 service providers or carriers to not route packets below a certain 164 reputation to organizational gateways. 166 Security reputation intelligence can be derived from a multiple 167 sources. It can come from security vendors or other analytics 168 organizations who trace active malware attack-vectors and publish 169 them to open and closed subscriber-lists. Another reputation source 170 is security or network-management infrastructure within a carrier or 171 service provider network, or vendor security products located on 172 customer premises. In these instances reputation may be learnt 173 through analytics aggregated on ambiguous data from many devices 174 after attacks. 176 At this time, security reputation intelligence from closed and open 177 sources is typically made available to perimeter and end-point 178 products through both standards-based and proprietary queries to on- 179 line information bases. In many cases, this reputation intelligence 180 is distributed over the open Internet and relies on subscriber "pull" 181 requests for batched downloads of large or incremental info-bases, or 182 individual queries on source IPs attempting to connect to a given 183 host. [REF 3] 185 This system of using proactive, security reputation intelligence has 186 many benefits, specifically: 187 1. provides an additional layer of security based on empirical 188 observations otherwise beyond the visibility of most 189 organizations 190 2. is proactive in natures, allowing threats to be managed at the 191 network level before the payload is delivered at the application 192 level 193 3. facilitates the conservation of application-layer security and 194 associated resource (processing, storage, licensing, 195 administration, power) 196 4. is flexible, and can be applied at different locations in the 197 subscriber infrastructure, from upstream of the perimeter to deep 198 in the internal network 199 5. is applicable to a variety of different communications elements 200 and end-points, from organizational messaging infrastructure to 201 remote, embedded sensors and controllers 203 Conversely, proactive, reputation intelligence has current 204 challenges. Specifically: 205 1. the "pull" distribution model is subject to direct attack/denial 206 of service at Internet distribution points 207 2. is often proprietary to vendor products and not interoperable, 208 requiring independent administration of elements 209 3. can create network-layer processing overhead on communications 210 elements and endpoints 211 4. introduces flow latency while reputation queries are sent, 212 received and processed 213 5. introduces intelligence latency as reputation lists will be 214 inevitably cached and periodically refreshed by subscribers 216 3.1. Use cases 218 The following are example use-cases for a security controls based 219 upon proactive reputation intelligence systems. 221 Cloud-based (Upstream) Use-case: Traffic to a user (a subscriber) of 222 reputation intelligence is routed through a proxy-type device off 223 premises (in the service-provider "cloud") configured to compare 224 source IPs of flows to the reputation intelligence. The proxy-type 225 device applies a policy established by the subscriber. For instance, 226 according to reputation score, drop the packets, quarantine the 227 packet for more inspection, issue alarms, or pass the packets and 228 associated flows to escalated-authentication systems, or do nothing. 230 Perimeter-based (subscriber-premises) Use-case: Security elements on 231 the subscriber perimeter or within the DMZ such as firewalls, IDS, 232 proxies, DNS, SMTP server and other assets are enabled to compare 233 source IPs of flows to reputation intelligence. The security element 234 applies a policy established by the subscriber according to the 235 reputation score. For instance, drop the packets, quarantine the 236 packet for more inspection, issue alarms, or pass the packets and 237 associated flows to escalated-authentication systems, or do nothing. 239 Internal network (subscriber-premises) Use-case: The objective is to 240 detect outbound communications to sites with a degraded reputation, 241 potentially indicating that the internal device has been compromised. 242 Security elements inside the subscriber enterprise such as zone- 243 firewalls, routers, IDS, proxies, DNS, SMTP servers and other assets 244 are enabled to compare destination IPs of flows to reputation 245 intelligence. For instance, a vulnerable internal device is 246 attempting to download a botnet malware payload from a known malware 247 drop-site domain (IE, malware.example.com); in response, the internal 248 security element may drop the packets, quarantine the packet for more 249 inspection, or issue alarms. 251 End-point Use-case: Subscriber end-points, such as desktops, servers, 252 phones, physical security (door strikes, cameras), automation and 253 control devices, environmental sensors and other elements are enabled 254 with reputation intelligence. These elements compare source or 255 destination IPs of flows to reputation intelligence. The subscriber 256 end-point applies a policy established by the subscriber according to 257 reputation score and possibly differentiated by the type of end- 258 point. Given that end-points may be very simple or low-power 259 devices, using the appropriate intelligence delivery systems may make 260 the policy-enforcement options comparably simple; for instance, drop 261 the packets. 263 Coarse-grade refinement: Organizations which possess independent 264 reputation capabilities may choose to also procure upstream or cloud- 265 based reputation services, which are used as adjuncts. For instance, 266 an organization operating a global network for internal 267 communications supporting thousands of servers and desktops will have 268 access to an internal reputation and intelligence base with unique 269 reputational insights. Such organizations may wish to receive 270 reputation intelligence from a third party to support further 271 processing on the perimeter, the internal network and/or end-points. 273 4. Security Considerations 275 The creation of a reputation intelligence is complex, and requires 276 the ability to collect large volumes of ambiguous network, sensor and 277 end-point system information. This information must then be 278 normalized, aggregated, weighted and correlated using sophisticated 279 intelligence algorithms. The first task of collecting information is 280 hard, but already accomplished by many carriers, service providers 281 and vendors as part of existing operations. It is the development 282 and application of intelligence algorithms to the large, ambiguous 283 data sets that creates reputation intelligence and adds novel and 284 unique value, and a proactive security potential. 286 Reputation intelligence algorithms are necessarily used by all 287 suppliers of reputation information to create some sort of relative 288 score or degree of positive or negative reputation. Frequently, 289 reputation algorithms are unpublished. As a result, the quality of 290 the intelligence can be difficult to assess and compare. For 291 instance, the following elements could be considered as functions 292 within a reputation algorithm that may influence the accuracy of the 293 intelligence: 294 o A function to account for large Internet portals with many, 295 independent URLs with good reputations, but also some proportion 296 of dangerous (bad reputation) URLs sharing the same IP address 298 o A function to account for the distance in time between the last 299 observed suspicious or illicit behavior and the present 300 o A function to account for the reputations of adjacent IP addresses 301 or domains 302 o A function to account for the original, per-processed source of 303 the intelligence (open source, closed source, domain of control, 304 uncontrolled domain) 305 o A function to account for the volume or velocity of suspicious or 306 illicit behavior (IE. High spam rate or low n' slow data 307 exfiltration) 308 o A function to account for the duration of suspicious or illicit 309 behaviour (IE. Sustained spam or infrequent beaconing) 310 o A function to account for lifetime of domain to source IP 311 associations (IE. Newly minted domain names or previously un- 312 observed/un-assigned addresses 313 o A function to account for the proportion of traffic from this 314 source which is benign versus demonstrably illicit 315 o A function to account of the nature of the suspicious or illicit 316 behavior (automated port scanning versus malware-drop) 317 o other? 319 Even given the assumption that reputation algorithms among suppliers 320 of reputation intelligence are somehow comparable, the issue of 321 common scales effects interoperation and security management. For 322 instance, reputation scores can be expressed in many manners: 323 o As a positive or negative score above or below a benign score or a 324 score for which no reputation information is available 325 o A negative score relative to a completely trusted class of IP 326 o A positive score relative to the least trusted IP addresses 327 o as a quantitative metric 328 o as a qualitative metric 330 Some reputation systems will start with un-processed activity logs 331 under the direct control of the intelligence supplier but also logs 332 submitted from a variety of sources. The degree to which the input 333 sources of intelligence are controlled has a baring on the potential 334 resistance of the intelligence to poisoning (injected with mis- 335 information to ruin good reputations and make bad reputations appear 336 better). For instance, a (presumably open-source) volunteer- 337 maintained form of reputation intelligence may be more prone to 338 poisoning than a carefully authenticated, closed-source of reputation 339 intelligence. Similarly, reputation intelligence derived from 340 sources physically outside the domain of control of the service 341 provider is more susceptible to poisoning than intelligence from 342 sources that control physically and logically control the log and 343 data sources. 345 Finally, under certain circumstances the management or application of 346 reputation intelligence may come with some form of legal or 347 regulatory burden. As a result, the calculation of reputation 348 intelligence may need to be distinct from the delivery of reputation 349 intelligence and yet again from the enforcement, in order to mitigate 350 legal or regulatory risks. 352 5. Acknowledgements 354 The authors wish to acknowledge the guidance and support of Michael 355 Richardson. 357 6. References 359 6.1. Normative References 361 [REF1] Bradner, S., Ed., "The Internet Standards Process - Revision 362 3", October 1996. 364 6.2. Informative References 366 [REF2] Macaulay, T., Ed., "Upstream Intelligence: anatomy, 367 architecture, case studies and use-cases.", Information 368 Assurance Newsletter, DOD , Aug to Feburary 2010 to 2011. 370 [REF3] Wikipedia, W., "Reputation Black List (RBLS)", May 2012. 372 Authors' Addresses 374 Tyson Macaulay 375 2Keys Security Solutions 376 1550 Laperriere Ave - Suite 202 377 Ottawa, Ontario 378 Canada 380 Email: tmacaulay@2keys.ca 382 David McMahon 383 Bell Canada 384 160 Elgin Street - Floor 5 385 Ottawa, Ontario 386 Canada 388 Email: dave.mcmahon@bell.ca 389 Ehud Doron 390 Radware 392 Email: ehudd@Radware.com 394 Peder Jungck 395 Cloudshield 397 Email: peder@cloudshield.com 399 Full Copyright Statement 401 Copyright (C) The IETF Trust (2012). 403 This document is subject to the rights, licenses and restrictions 404 contained in BCP 78, and except as set forth therein, the authors 405 retain all their rights. 407 This document and the information contained herein are provided on an 408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 410 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 411 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 412 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 415 Intellectual Property 417 The IETF takes no position regarding the validity or scope of any 418 Intellectual Property Rights or other rights that might be claimed to 419 pertain to the implementation or use of the technology described in 420 this document or the extent to which any license under such rights 421 might or might not be available; nor does it represent that it has 422 made any independent effort to identify any such rights. Information 423 on the procedures with respect to rights in RFC documents can be 424 found in BCP 78 and BCP 79. 426 Copies of IPR disclosures made to the IETF Secretariat and any 427 assurances of licenses to be made available, or the result of an 428 attempt made to obtain a general license or permission for the use of 429 such proprietary rights by implementers or users of this 430 specification can be obtained from the IETF on-line IPR repository at 431 http://www.ietf.org/ipr. 433 The IETF invites any interested party to bring to its attention any 434 copyrights, patents or patent applications, or other proprietary 435 rights that may cover technology that may be required to implement 436 this standard. Please address the information to the IETF at 437 ietf-ipr@ietf.org.