Internet Draft David M'Raihi VeriSign Category: Sharon Boeyen Informational Entrust Document: Michael Grandcolas draft-mraihi-inch-thraud-01.txt Grandcolas Consulting LLC. Siddharth Bajaj VeriSign Expires: April 2007 October 2006 How to Share Transaction Fraud (Thraud) Report Data Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a data-format and protocol for defining and exchanging Transaction Fraud (Thraud) Report Data. It extends the INCH WG's IODEF XML [IODEF] incident reporting format. Both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms are presented. This work has been endorsed by the Initiative for Open AuTHentication [OATH]. INCH-THRAUD Expires - April 2007 [Page 1] How to Share Transaction Fraud (Thraud) Report Data October 2006 Table of Contents 1. Introduction...............................................3 2. Requirements Terminology...................................3 3. The Elements of Transaction Fraud Activity.................4 4. Thraud Activity Reporting via an IODEF-Document Incident...5 5. Fraud Report Element Definitions...........................6 5.1. The Fraud-Event-Payment element..........................7 5.1.1. Payee-Name..............................................8 5.1.2. Payee-Address-Line1.....................................8 5.1.3. Payee-Address-Line2.....................................8 5.1.4. Payee-City..............................................8 5.1.5. Payee-Postal-Code.......................................8 5.1.6. Payee-Country...........................................8 5.1.7. Payee-Amount............................................8 5.2. The Fraud-Event-Transfer element.........................9 5.2.1. Bank-ID.................................................9 5.2.2. Account-ID..............................................9 5.2.3. Account-Type............................................9 5.2.4. Transfer-Amount.........................................9 5.3. The Fraud-Event-Identity element.........................9 5.3.1. Identity-Information...................................10 5.4. The Payee-Amount element................................10 5.4.1. Element contents.......................................10 5.4.2. Currency...............................................10 5.5. The Transfer-Amount element.............................10 5.5.1. Element contents.......................................11 5.5.2. Currency...............................................11 5.6. The Account-Type element................................11 6. IODEF Required Elements...................................12 6.1. Fraud Report............................................12 7. Security Considerations...................................13 7.1. Thraud Data Authenticity and Integrity..................13 7.2. Thraud Data Confidentiality and Privacy.................14 8. IANA Considerations.......................................14 9. Conclusion................................................14 10. Acknowledgements..........................................14 11. References................................................14 11.1. Normative...............................................14 11.2. Informative.............................................15 Appendix A. Fraud Extensions XML Schema.......................15 Appendix B. Example of a Thraud Report........................16 12. Authors' Addresses........................................17 13. Full Copyright Statement..................................18 14. Intellectual Property.....................................18 INCH-THRAUD Expires - April 2007 [Page 2] How to Share Transaction Fraud (Thraud) Report Data October 2006 1. Introduction Financial institutions and merchants are confronted with online fraud attacks targeted against their customers through various means. Today there is no standardized data format and open protocol that organizations and law enforcement can use to share known/suspicious transaction fraud data. There is a clear opportunity for creating an open framework to enable organizations, using a variety of fraud monitoring products, to contribute information related to known or suspicious fraud activity. The very same framework should also formalize mechanisms for distributing correlated updates to all participating members. This internet draft introduces a data format to facilitate interoperability and exchange of transaction-related fraud data. More specifically, this document describes a data-format and protocol for defining and exchanging Transaction Fraud (Thraud) Report Data. It extends the INCH WG's IODEF XML [IODEF] incident reporting Format. Any verified organization can contribute online fraud attack records via openly defined protocols. The specific focus of this document is the proposal of XML document definitions for Fraud Reports and the protocols by which they can be exchanged. The document proposes a definition for both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms. In section 3 we introduce the different components of a transaction fraud. The reporting method via an IODEF-document is described in section 4, and we define the report elements in section 5. In the next section we describe the required elements with respect to the IODEF format and follow with security considerations in section 7. 2. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. INCH-THRAUD Expires - April 2007 [Page 3] How to Share Transaction Fraud (Thraud) Report Data October 2006 3. The Elements of Transaction Fraud Activity +-------------------------------------+ | Fraudsters | | (collect & verify victim credentials| | via phishing, malware etc.} | +-------------------------------------+ | |recruit | |< ----------------------share profits------------------------ | ^ | | +-----------+ +--------------+ +--------+ | Fraud | | | | | | Executors | | Financial |----|Fraud | | | | Organization | |Dest. | | |--Open Dest. Account-->| | |Account | | | +--------------+ +--------+ | | ^ | | +--------------+ | | |--Attempt Transfer --->| Victim | +-------+ | | | Financial | |Victim | | | | Organization |--o--|Account| +-----------+ +--------------+ | +-------+ | +-----------+ | Fraud | | Detection | | Sensors | | (realtime/| | offline) | +-----------+ Figure 1. Transaction Fraud Elements Transaction Fraud Activities are normally composed of the following entities: 1. The Fraudsters who collect victim's login credentials via various means, such as phishing, malware etc. And then verify (usually through login attempts) that those credentials are correct. At that time Fraudsters may either recruit Fraud executors directly or wholesale the collected credentials to other Fraudsters who will do the recruiting of the Fraud executors. INCH-THRAUD Expires - April 2007 [Page 4] How to Share Transaction Fraud (Thraud) Report Data October 2006 2. The Fraud Executors are those that actually will attempt the fraudulent transfer or payment. For fraudulent transfers, legitimate accounts at the same financial organization or a different one from the victim will be set up as the destination account for the fraudulent transfer. Alternatively a fraudulent payment attempt via check or electronic transfer to a named destination is attempted. 3. The Victims of both credential theft and transaction fraud. 4. The Financial Organization who holds either the victim/fraudster's accounts. 5. Sensors at the Financial Organization who attempt to detect fraudulent transaction attempts, either in realtime or offline. The intention of Thraud Reporting is to enable any organization that has detected fraud to share this information with other organizations. The receiving organization can use this information appropriately. For example, it could require manual review of transactions from 'risky' IP addresses that have been reported. 4. Thraud Activity Reporting via an IODEF-Document Incident A Thraud Activity Report is an instance of an XML IODEF-Document with added EventData, AdditionalData elements. The added elements compose a ThraudRecord Element. There may be multiple ThraudRecord Elements in a Thraud Activity Report. Required information with many optional items is populated into the ThraudRecord structure to a form a Thraud Activity Report. There are actually two types of Thraud Activity Reports an "inbound" and an "outbound" report. The "inbound" report is from a reporting organization to describe a transaction fraud. The "outbound" report is destined to subscribers, either through a subscription or following a query to obtain (possibly correlated) information about fraud elements. The primary difference in the "inbound" and "outbound" reports is the removal in the "outbound" reports of reporting organization information in order to protect confidentiality. We elaborate on this aspect in section 7, Security Considerations. This document defines new EventData IODEF XML elements; then identifies the attributes that are required in a compliant Thraud Activity Report. The Appendicies contain sample Thraud Activity Reports and the complete XML Document Type Definition and schema. The Incident element with fraud extensions is summarized below. It provides a standardized representation for commonly exchanged incident data. INCH-THRAUD Expires - April 2007 [Page 5] How to Share Transaction Fraud (Thraud) Report Data October 2006 For "inbound" reports it contains a unique identifier that is name spaced qualified by the domain name of the reporting organization. In "outbound" reports it contains an opaque unique identifier to protect privacy of data sources. The data elements in this document are expressed in Unified Modeling Language (UML) syntax. +------------------+ | Incident | +------------------+ | ENUM purpose |<>----------[ IncidentID ] | ENUM restriction |<>--{0..1}--[ AlternativeID ] | |<>--{0..1}--[ RelatedActivity ] | |<>--{0..*}--[ Description ] | |<>--{1..*}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>----------[ ReportTime ] | |<>--{1..*}--[ Contact ] | |<>--{0..*}--[ Expectation ] | |<>--{0..1}--[ History ] | |<>--{0..*}--[ EventData ] | | --> [ AdditionalData ] | | --> ThraudRecord (added) +------------------+ Figure 2. IODEF and Thraud Reporting A Thraud Activity Report is composed of one IODEF Incident element, containing one or more EventData elements that contain one or more ThraudRecord elements. This document describes ThraudRecord elements for the EventData. AdditionalData element containing transaction fraud-related information that does not map to existing Incident or EventData attributes. One Incident report may contain information on multiple incidents. After the report identification information listed in the Incident element, each individual transaction fraud event is detailed within a single EventData structure. 5. Fraud Report Element Definitions INCH-THRAUD Expires - April 2007 [Page 6] How to Share Transaction Fraud (Thraud) Report Data October 2006 A fraud report consists of an extension to the Incident/EventData/AdditionalData Element. The elements of the fraud report will identify and capture information related to payment fraud, transfer fraud and identity fraud. A payment fraud report is structured as follows. +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM dtype (xml) |<>---------[ Fraud-Event-Payment ] | | +--------------------------+ Figure 3. The Fraud-Event-Payment extension A funds transfer fraud report is structured as follows. +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM dtype (xml) |<>---------[ Fraud-Event-Transfer ] | | +--------------------------+ Figure 4. The Fraud-Event-Transfer extension An identity fraud report is structured as follows. +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM dtype (xml) |<>---------[ Fraud-Event-Identity ] | | +--------------------------+ Figure 5. The Fraud-Event-Identity extension 5.1. The Fraud-Event-Payment element The Fraud-Event-Payment element is used to report the payee instructions for a fraudulent payment or fraudulent payment attempt. Fraudsters sometimes use the same payee instructions for multiple fraudulent payment attempts. By reporting the payment instructions used, other institutions may be able to stop future fraudulent payment attempts to the same payee. INCH-THRAUD Expires - April 2007 [Page 7] How to Share Transaction Fraud (Thraud) Report Data October 2006 The structure of the Fraud-Event-Payment element is: +--------------------------+ |Fraud-Event-Payment | +--------------------------+ | |<>--{0..1}--[ Payee-Name ] | |<>--{0..1}--[ Payee-Address-Line1 ] | |<>--{0..1}--[ Payee-Address-Line2 ] | |<>--{0..1}--[ Payee-City ] | |<>--{0..1}--[ Payee-Postal-Code ] | |<>--{0..1}--[ Payee-Country ] | |<>--{0..1}--[ Payee-Amount] | | +--------------------------+ Figure 6. The Fraud-Event-Payment element The components of the Fraud-Event-Payment element are introduced below. 5.1.1. Payee-Name Zero or one value of STRING. The name of the payee. 5.1.2. Payee-Address-Line1 Zero or one value of STRING. The first line of the address of the payee. 5.1.3. Payee-Address-Line2 Zero or one value of STRING. The second line of the address of the payee. 5.1.4. Payee-City Zero or one value of STRING. The city of the payee. 5.1.5. Payee-Postal-Code Zero or one value of STRING. The postal code of the payee. 5.1.6. Payee-Country Zero or one value of STRING. The country of the payee. 5.1.7. Payee-Amount INCH-THRAUD Expires - April 2007 [Page 8] How to Share Transaction Fraud (Thraud) Report Data October 2006 Zero or one element of Payee-Amount. 5.2. The Fraud-Event-Transfer element The Fraud-Event-Transfer element is used to report the payee instructions for a fraudulent funds transfer or fraudulent funds transfer attempt. Fraudsters sometimes use the same payee instructions for multiple attempts. By reporting the funds transfer instructions used, other institutions may be able to stop future fraudulent payment attempts to the same payee. +---------------------------+ |Fraud-Event-Transfer | +---------------------------+ | |<>--{0..1}--[ Bank-ID ] | |<>--{0..1}--[ Account-ID ] | |<>--{0..1}--[ Account-Type ] | |<>--{0..1}--[ Transfer-Amount ] | | +---------------------------+ Figure 7. The Fraud-Event-Transfer element The components of the Fraud-Event-Transfer element are introduced below. 5.2.1. Bank-ID Zero or one value of STRING. The destination bank routing transit ID or other FI id. 5.2.2. Account-ID Zero or one value of STRING. The destination primary account number. 5.2.3. Account-Type Zero or one element of Account-Type. 5.2.4. Transfer-Amount Zero or one element of Transfer-Amount. 5.3. The Fraud-Event-Identity element The Fraud-Event-Identity element is used to report a fraudulent impersonation or fraudulent impersonation attempt. By reporting INCH-THRAUD Expires - April 2007 [Page 9] How to Share Transaction Fraud (Thraud) Report Data October 2006 the funds event, other institutions may be able to stop future fraudulent impersonation attempts. +-------------------------+ |Fraud-Event-Identity | +-------------------------+ | |<>--{0..1}--[ Identity-Information ] | | +-------------------------+ Figure 8. The Fraud-Event-Identity element 5.3.1. Identity-Information Zero or one value of STRING. The compromised, fake or fraudulent identity. 5.4. The Payee-Amount element The Payee-Amount element is used to report the amount of the payment fraud, which may be common across a set of related fraud attempts. +--------------------+ |Payee-Amount | +--------------------+ | DECIMAL | | | | STRING currency | | | +--------------------+ Figure 9. The Payee-Amount element The components of the Payee-Amount element are introduced below. 5.4.1. Element contents Required DECIMAL. Contains the amount of the payment. 5.4.2. Currency Required STRING. The three letter currency code. 5.5. The Transfer-Amount element INCH-THRAUD Expires - April 2007 [Page 10] How to Share Transaction Fraud (Thraud) Report Data October 2006 The Transfer-Amount element is used to report the amount of the funds transfer fraud, which may be common across a set of related fraud attempts. +--------------------+ |Transfer-Amount | +--------------------+ | DECIMAL | | | | STRING currency | | | +--------------------+ Figure 10. The transfer-Amount element The components of the Transfer-Amount element are introduced below. 5.5.1. Element contents Required DECIMAL. Contains the amount of the funds transfer. 5.5.2. Currency Required STRING. The three letter currency code. 5.6. The Account-Type element The Account-Type element is used to report the type of the destination account. +--------------------+ |Account-Type | +--------------------+ | ENUM (brokerage | | | checking | | | corporate | | | mortgage | | | retirement | | | saving) | | | +--------------------+ Figure 11. The Account-Type element Required ENUMERATION. Enumerated values are: 'brokerage', 'checking', 'corporate', 'mortgage', 'retirement' and 'saving'. INCH-THRAUD Expires - April 2007 [Page 11] How to Share Transaction Fraud (Thraud) Report Data October 2006 6. IODEF Required Elements This section identifies attributes and elements that are required to be present in a compliant fraud report. The required attributes are a combination of those required by the base IODEF element and those required by this profile. Attributes identified as required SHALL be populated in conforming fraud reports. +--------------+ | Incident | +--------------+ | ENUM Purpose |---[ IncidentID ] | |---[ ReportTime ] | |---[ Assessment ] | | ---> [ Impact ] | | ---> [ Confidence ] | |---[ Contact ] | | ---> [ ContactName ] | | ---> [ Email ] | | ---> [ Contact ] | | ---> [ ContactName ] | | ---> [ Email ] | | ---> [ Telephone ] | |---[ EventData ] | | ---> [ DetectTime ] | | ---> [ Flow ] | | | ---> [ System ] | | | ---> [ Node ] | | | ---> [ Address ] | | | | ---> [ vlan-num ] | | | ---> [ Location ] | | | ---> [ NodeName ] | | ---> [ AdditionalData ] | | ---> [ Fraud-Event-XXX ] +--------------+ Figure 12. IODEF Required Elements 6.1. Fraud Report A compliant IODEF fraud report SHALL contain elements as described below: Purpose - The value 'reporting' indicates that the report contains details of a new fraud incident to be added to the corpus. A new value 'delete' must be added to indicate that further analysis by the originator indicates that the incident was not fraudulent, and so the incident should be deleted from the corpus. IncidentID - As defined by IODEF. INCH-THRAUD Expires - April 2007 [Page 12] How to Share Transaction Fraud (Thraud) Report Data October 2006 ReportTime - As defined by IODEF. Assessment.Impact - As defined by IODEF. Assessment.Confidence - As defined by IODEF. Contact.Email - A contact email address for the reporting institution. Contact.ContactName - The name of the reporting institution. In case the reporting institute has consolidated reports from other institutions, this element MAY contain the name of the consolidator, not the original reporting institution. Contact.Contact.ContactName - The name of the reporting fraud analyst. Contact.Contact.Email - The email address of the reporting fraud analyst. Contact.Contact.Telephone - The telephone number of the reporting fraud analyst. EventData.DetectTime - The date and time at which the fraud or fraud attempt was detedted. EventData.Flow.System.Node.Addres.vlan-num - The IPv4 or IPv6 address or subnet mask, depending upon the value of the 'Address@category' attribute. EventData.Flow.System.Node.Location - The name and address of the owner of the DNS domain from which the fraud or fraud attempt was executed. EventData.Flow.System.Node.NodeName - As defined by IODEF. 7. Security Considerations This document focuses on the data format for exchanging transaction fraud data. The critical security concerns are the validity of submitted information (Thraud Reports) and outbound information (Thraud Watchlists) sent upon a query, as well as the protection of contributors privacy when sharing the data. 7.1. Thraud Data Authenticity and Integrity The Thraud Reports SHOULD be digitally signed. This would guarantee the origin and integrity of the submitted information. A possible method is to use the optional IODEF XML signature as defined in INCH-THRAUD Expires - April 2007 [Page 13] How to Share Transaction Fraud (Thraud) Report Data October 2006 [IODEF]. The potential recipients of Thraud Reports SHOULD be able to verify these digital signatures. 7.2. Thraud Data Confidentiality and Privacy The Thraud Reports MAY be encrypted when stored for future usage. Contributors of Thraud Reports might not be willing to disclose fraudulent transactions attached to their name. A simple mechanism MUST enable the query of any data to return a valid reponse without disclosing the unique Identifier of a specific organization. We suggest to use an opaque identifier for each report in order to index privately the reports. A hash function (e.g. SHA-1) MAY be used to generate the opaque identifier from the organization name: OpaqueIdentifier = SHA-1() The OpaqueIdentifier can be used to reference the report without disclosing the full organization identity. 8. IANA Considerations This document has no actions for IANA. 9. Conclusion This internet draft introduced Transaction Fraud (Thraud) reporting mechanisms to enable the sharing of Fraud data. Based on the IODEF- document format, the proposed extension should facilitate interoperability and provide increase security for online applications. 10. Acknowledgements We would like to thank Tim Moses for his extremely valuable contribution to completing this draft document. 11. References 11.1. Normative [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3668] S. Bradner, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. INCH-THRAUD Expires - April 2007 [Page 14] How to Share Transaction Fraud (Thraud) Report Data October 2006 11.2. Informative [OATH] Initiative for Open AuTHentication http://www.openauthentication.org [IODEF] R. Danyliw, J. Meijer and Y. Demchenko, The Incident Object Description Exchange Format http://tools.ietf.org/wg/inch/draft-ietf-inch-iodef/draft-ietf- inch-iodef-10.txt Appendix A. Fraud Extensions XML Schema Appendix B. Example of a Thraud Report 908711 2006-10-12T00:00:00-07:00 Open Authentication contact@openauthentication-fraud.com 2006-10-12T07:42:21-08:00
192.0.2.53
INCH-THRAUD Expires - April 2007 [Page 16] How to Share Transaction Fraud (Thraud) Report Data October 2006 Source of numerous attacks 1234567 3456789 saving 10000 12. Authors' Addresses Primary point of contact (for sending comments and question): David M'Raihi VeriSign, Inc. 685 E. Middlefield Road Phone: 1-650-426-3832 Mountain View, CA 94043 USA Email: dmraihi@verisign.com Other Authors' contact information: Sharon Boeyen, Entrust Inc., 1000 Innovation Drive, Phone: 1-613-270-3183 Ottawa, ON, K2K 3E7 Email: sharon.boeyen@entrust.com Michael Grandcolas Grandcolas Consulting LLC. 247 Ocean Park Blvd. Phone: 1-310-399-1747 Santa Monica, Ca 90405 Email: michael.grandcolas@hotmail.com Siddharth Bajaj VeriSign, Inc. 487 E. Middlefield Road Phone: 1-650-426-3458 Mountain View, CA 94043 USA Email: sbajaj@verisign.com INCH-THRAUD Expires - April 2007 [Page 17] How to Share Transaction Fraud (Thraud) Report Data October 2006 13. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. INCH-THRAUD Expires - April 2007 [Page 18]