INCH P. Cain Internet-Draft The Cooper-Cain Group Expires: December 24, 2005 D. Jevans The Anti-Phishing Working Group June 22, 2005 Extension to IODEF-Document Class for Phishing, Fraud, and Other Non- Network Layer Reports draft-ietf-inch-phishingextns-00 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 24, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document extends the INCH XML incident reporting format for reporting phishing, fraud, widespread spam, and other non-network layer attacks and incidents. The extensions are an outgrowth of the Anti-Phishing Working Group (APWG) activities in data collection and sharing. Although we use the term "phishing attack", the data format extensions are flexible enough to support information gleaned from Cain & Jevans Expires December 24, 2005 [Page 1] Internet-Draft IODEF Fraud Report Extensions June 2005 activities throughout the entire phishing life cycle and extensible enough to be used for other types of electronic crime incidents such as fraud. The extensions support very simple reporting as well as optional fields for detailed, forensic reports and supports single phish/fraud incidents as well as consolidated reports of multiple phish incidents. RFC 2129 Keywords 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[RFC2119]. Cain & Jevans Expires December 24, 2005 [Page 2] Internet-Draft IODEF Fraud Report Extensions June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Why a Common Report Format is Needed . . . . . . . . . . . 4 1.2 Relation to the INCH IODEF Data Model . . . . . . . . . . 5 2. The Elements of Phishing/Fraud Activity . . . . . . . . . . 7 3. Fraud Actvitiy Reporting via an IODEF-Document Incident . . 8 4. PhraudReport Element Definitions . . . . . . . . . . . . . . 10 4.1 Version parameter . . . . . . . . . . . . . . . . . . . . 10 4.2 Identifying A Fraud campaign . . . . . . . . . . . . . . . 11 4.3 FraudedBrandName Element . . . . . . . . . . . . . . . . . 13 4.4 The Data Collection Site Element (DCSite) . . . . . . . . 13 4.5 OriginatingSensor Element . . . . . . . . . . . . . . . . 14 4.6 TakeDownInfo Element . . . . . . . . . . . . . . . . . . . 16 4.7 ArchivedData Element . . . . . . . . . . . . . . . . . . . 17 4.8 RelatedData Element . . . . . . . . . . . . . . . . . . . 18 4.9 CorrelationData Element . . . . . . . . . . . . . . . . . 18 4.10 PRComments Element . . . . . . . . . . . . . . . . . . . 18 4.11 EmailRecord Element . . . . . . . . . . . . . . . . . . 18 5. IODEF Required Elements . . . . . . . . . . . . . . . . . . 20 5.1 Fraud or Phishing Report . . . . . . . . . . . . . . . . . 20 5.2 Wide-Spread Spam Report . . . . . . . . . . . . . . . . . 21 5.3 Guidance on Usage . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 A. Phishing Extensions XML Schema . . . . . . . . . . . . . . . 26 B. Phishing Extensions XML DTD . . . . . . . . . . . . . . . . 33 C. Examples of Complete Fraud Activity Reports . . . . . . . . 34 C.1 Sample Phish/Malware Email Report . . . . . . . . . . . . 34 C.2 Received Email . . . . . . . . . . . . . . . . . . . . . . 34 C.3 Generated Report . . . . . . . . . . . . . . . . . . . . . 34 D. Sample Spam Report . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . 38 Cain & Jevans Expires December 24, 2005 [Page 3] Internet-Draft IODEF Fraud Report Extensions June 2005 1. Introduction Deception activities, such as Phishing and fraud, are an expanding attack types in the Internet. For this document we use the two terms interchangeably and characterize both attack types as broadly- launched social engineering attacks in which an electronic identity is misrepresented in an attempt to trick individuals into revealing their personal credentials ( e.g., passwords, account numbers, personal information, ATM PINs). A successful phishing attack on an individual allows the phisher (i.e., attacker) to exploit the individual's credentials for gain. Early phishing attacks were directed at individuals via email as a ruse from a bank security department, requesting the user's ATM number and PIN. Once phished, the bank account could be used by the phisher to perpetrate additional fraud, money laundering, or plain emptying of the account. As individuals become aware of phishing tactics, the phishers have evolved into using more complex and stealthier technologies, and have targeted institutions other than banks. Other miscreants are also using these same techniques for other types of attacks. 1.1 Why a Common Report Format is Needed The rise in phishing and fraud activities via e-mail, instant message, DNS corruption, and malicious code insertion has driven corporations, Internet Service Providers, consumer agencies, and financial institutions to begin to collect and correlate phishing attack information to better plan out mitigation activities and to assist in prosecution. Early on it became obvious that a common format for the data reported or exchanged between these parties was necessary and the IETF INCH XML format was selected for this use. Although originally designed for network-layer incident sharing (e.g., DoS attacks, compromised computers) the INCH format can be extended quite easily to support other incident profiles, as we have done. The use of a common format will also help organizations integrate multiple product outputs into a cohesive single attack view and will allow for the introduction of advanced services such as wholly automatic local notifications and usable data mining. The accumulation and correlation of information is very important when dealing with security incidents. In phishing attacks the source of the attack may be forged and it's quite possible that the targeted organization may not even be aware of the ongoing attack. Parties aware of the attack may wish to notify the target, or an organization's internal monitoring systems may detect the attack and wish to take mitigation steps. Unfortunately, there is no recognized standard way of expressing the detection of a phishing attack nor an Cain & Jevans Expires December 24, 2005 [Page 4] Internet-Draft IODEF Fraud Report Extensions June 2005 acceptable way to exchange the required information. For an organization that employs multi anti-phishing technologies, correlating data from multiple vendors or products is close to impossible as the data is reported in multiple, mostly incompatible, formats. This document defines a data format that is used to capture relevant information from a phishing attack and shared, correlated, or to populate a database. Additionally, the use of products that export information in this format will allow an organization to correlate and analyze phishing information across their organization, in effect information sharing with themselves. Although targeted at both the accumulation of phishing attack information from a single institution and a means of sharing attack information between cooperating parties, the actual information sharing process and related political challenges are not covered in this document. 1.2 Relation to the INCH IODEF Data Model Instead of defining report format and language from scratch, the phishing activities information is encoded as an extension to the INCH incident exchange format.[INCH]The use of an already existent and operational format allows for quicker vendor adoption and reuse of existing tools in organizations. To reduce duplication and to be compatible with modifications to the base IODEF definitions, this document only identifies additional structures; The reader is expected to have a copy of the IODEF documents handy while reading this one. One criticism of the INCH format is that it is too cumbersome (large and complex) to be used in an efficient manner for something as simple as fraud events. The goal of all common formatting is to be efficient when necessary and also to allow enough data to be included to provide a complete picture of the event. The INCH format has very few required elements to allow for efficiency, but allows extremely verbose elements to be used if supporting data is available. This flexibility allows the INCH formats to be used in a wide range of event reports but allows the product developer to only be required to support one format standard. 1.2.1 The INCH Extensions for Fraud In general, an INCH incident report contains detailed incident- specific data which populates an EventData Structure. That data is then incorporated, either singularly or in aggregation, with additional summary and contact data, into an Incident structure. The populated Incident structure is what is reported as a Fraud Activity Report. Cain & Jevans Expires December 24, 2005 [Page 5] Internet-Draft IODEF Fraud Report Extensions June 2005 Unsavory phishing activity may include multiple email messages, attacks, or events, scattered over various times, locations, and methodologies. As each of these activities may generate multiple reports to an incident team, the Fraud Activity Report is composed of one XML Incident element, recording one or more individual phishing events and may include multiple EventData elements. This document defines new attributes for the EventData and Record Item IODEF XML elements, then identifies attributes that are required in a compliant Fraud Activity Report. The Appendices contain sample Fraud Activity Reports and the complete Document Type Definition. The IODEF Extensions defined in this document comply with section4, "Extending the IODEF Format" in [INCH]. Cain & Jevans Expires December 24, 2005 [Page 6] Internet-Draft IODEF Fraud Report Extensions June 2005 2. The Elements of Phishing/Fraud Activity +-----------+ +------------------+ | Fraudster |<---<-- | Collection Point | <---O--<----<----+ +----+------+ +------------------+ | | ^ | | | +--|-----+ ^ | | Sensor | Credentials | +-|------+ | | +---------------+ | +-------+ \--->---| Attack Source |--Phish-->-----O------> | User/ | +---------------+ |Victim | +-------+ Internet-based Phishing and Fraud activities are normally comprised of at least four components. 1. The Fraudster, or the party perpetrating the fraudulent activity. Most times this party is not readily identifiable. 2. The Attack Source, where the phishing email, virus, trojan, or other attack is generated. 3. The User or intended target of the fraud/phish. 4. The collection point, where the victim sends their credentials or personal data if they have been duped by the phisher. If we take a holistic view of the attack, there are some additional components: 5. The network sensor, which is some thing that detects the fraud/ phish attempt or success. This element may be an Intrusion-Detection System, Firewall, Filter, email gateway, or even a human. 6. A forensic or archive site where an investigator has copied or otherwise retained the data used for the fraud attempt or credential collection. Cain & Jevans Expires December 24, 2005 [Page 7] Internet-Draft IODEF Fraud Report Extensions June 2005 3. Fraud Actvitiy Reporting via an IODEF-Document Incident A Fraud Activity Report is an instance of a IODEF-Document XML Incident element[INCH] with added EventData and AdditionalData elements. Some required information with many optional items are populated into the new structure to form a Fraud Activity Report. To facilitate completeness, the report originator should fill out as much as possible of the optional Incident element fields, but SHALL stay consistent with the IODEF-Document structure. This document defines new EventData IODEF XML elements; then identifies attributes that are required in a compliant Fraud Activity Report. The Appendices contain sample Fraud Activity Reports and the complete XML Document Type Definition and schema. The Incident element with fraud extensions is summarized below and provides a standardized representation for commonly exchanged incident data and associates a CSIRT assigned unique identifier with the described activity. +------------------+ | 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 ] | | --> PhraudReport (added) +------------------+ Figure 1. The INCH XML Incident Element (modified) A Fraud Activity Report is composed of one INCH Incident element, containing one or more EventData elements that contain one or more PhraudReport elements. This document defines the FraudReport element for the INCH Incident.EventData.AdditionalData element comprising of phishing and fraud-related information that does not map to existing Cain & Jevans Expires December 24, 2005 [Page 8] Internet-Draft IODEF Fraud Report Extensions June 2005 Incident or EventData attributes. We also define some additional attributes in the INCH Incident.EventData element to capture electronic mail header and routing information. One Incident report may contain information on multiple incidents. After the report identification information listed in the Incident element, each individual event is detailed within a single EventData structure. Cain & Jevans Expires December 24, 2005 [Page 9] Internet-Draft IODEF Fraud Report Extensions June 2005 4. PhraudReport Element Definitions A PhraudReport consists of an Extension to the Incident AdditionalData Element. The elements of the PhraudReport will identify and capture information related to the four components of a fraud activity. Other forensic information and commentary can be added by the reporter as necessary to show relation to other events, the output of an investigation, or for archival purposes. A PhraudReport element is structured as follows. +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM type (9 = xml) |<>---------[ PhraudReport ] | STRING meaning (xml) | +--------------------------+ +-----------------+ | PhraudReport | +-----------------+ | ENUM Version |<>--(0..*)--[ PhishNameRef ] | ENUM FraudType |<>--(0..*)--[ PhishNameLocalRef ] | |<>--(0..*)--[ FraudParameter ] | |<>--(0..*)--[ FraudedBrandName ] | |<>--(0..*)--[ LureSource ] | |<>--(0..*)--[ OriginatingSensor ] | |<>--(0..1)--[ EmailRecord ] | |<>--(0..*)--[ DCSite ] | |<>--(0..*)--[ TakeDownInfo ] | |<>--(0..*)--[ ArchivedData ] | |<>--(0..*)--[ RelatedData ] | |<>--(0..*)--[ CorrelationData ] | |<>--(0..1)--[ PRComments ] +-----------------+ Figure 2. The PhraudReport Extensions to the INCH XML Incident.AdditionalData Element The components of a FraudReport are introduced in functional grouping as some parameters are related and some elements may not make sense stand-alone. 4.1 Version parameter STRING. The version shall be the value 1.0 to be compliant with this document. Cain & Jevans Expires December 24, 2005 [Page 10] Internet-Draft IODEF Fraud Report Extensions June 2005 4.2 Identifying A Fraud campaign At times it may be useful to identify a specific phish or fraud for future analysis -- much like the Anti-Virus Vendors identify certain viruses. A specific phish/fraud can be identified using a combination of the FraudType, FraudParameter, and PhishRefName elements. 4.2.1 FraudType Parameter ENUM. The FraudType attribute contains a number representing the type of fraud attempted. The Email element has been separated into multiple numbers to support the primary types of email. 1. PhishEmail, and the FraudParameter is the email subject line of the phishing email. This type is a standard email phish, usually sent as spam, and is intended to derive financial loss to the recipient. 2. RecruitEmail, and the FraudParameter is the email subject line of the phishing email. This type of email phish does not pose a potential financial loss to the recipient, but covers other cases of the phish and fraud lifecycle. 3. MalwareEmail, and the FraudParameter is the email subject line of the phishing email. This type of email phish does not pose a potential financial loss to the recipient, but lures the recipient to an infected site. 4. Fraudsite, no FraudParameter. This identifies a known fraudulent site that does not necessarily send spam lures. 5. DNSspoof, with the malware name as a parameter. This is used for a spoofed DNS (e.g., malware changes localhost file so visits to www.example.com go to another IP address). 6. Keylogger, with the malware name as the FraudParameter. 7. OLE, no parameter. This identifies background OLE information. 8. IM. The subject line parameter may be the malicious link supplied to the user. 9. CVE, with the CVEnumber as the FraudParameter. 10. SiteArchive, with the data archived from the phishing server placed in the ArchiveInfo element. Cain & Jevans Expires December 24, 2005 [Page 11] Internet-Draft IODEF Fraud Report Extensions June 2005 11. Spamreport. 12. Unknown. When a FraudParameter is required, it is one of the following values: SubjectLine element STRING. This is the subject line of the email lure.Note that some phishers add a number of random characters onto the end of a phish email subject line for uniqueness; reporters should delete those characters before insertion into the PhishParameter field. MalwareName element STRING. This is the name of the malware that installed the keylogger or DNSspoofer. CVENumber element STRING. This is the CVEidentifier of this exploit used to phish. 4.2.2 LureSource Element SOURCE. Many times the phishing, spam, or fraud lure email is received from a spoofed IP address. If the real IP Address can be ascertained it should be populated into this field. A spoofed address may aso be entered, but the spoofed attribute SHALL be set. The field is an Address Element to allow for support of IPv6 and port numbers. 4.2.3 PhishNameRef Element STRING. This value can be agreed upon by vendor collaboration to note a common name for a given phish attack or "campaign". The agreed upon identifier could be useful in collaboration, support, media and public education. 4.2.4 PhishNameLocalRef Element STRING. Many contributors will have a local reference name or Unique-IDentifier (UID) that will be used before a commonly agreed term is adopted in PhishNameRef. The allows a cross-reference from the submitting organization's system to the central repository. Cain & Jevans Expires December 24, 2005 [Page 12] Internet-Draft IODEF Fraud Report Extensions June 2005 4.3 FraudedBrandName Element STRING. This is the identifier of the recognized brandname or company name used to launch the phishing activity. Some schemes, such as those enticing mules for money laundering or related activities, may use a lesser known or fictitious brand [e.g., xyz semiconductor company]. Those brand identifiers should also populate this field. 4.4 The Data Collection Site Element (DCSite) This section identifies the type, identifier, collection location, and other pertinent information about the credential gathering process by the fraudster. If the DCSite element is present, the DCSiteType element is required. There may be multiple DCSiteData elements. +-------------+ | DCSite | +-------------+ | ENUM DCType |<>--(0..*)---[ DCSiteData ] +-------------+ +------------------+ | DCSiteData | +------------------+ | ENUM DCSiteType |<>-----------[ DCSitePointer ] | | +------------------+ 4.4.1 DCType Parameter ENUM. This is the method of data collection, as determined by analyzing the victim computer, lure, or malware, and should be picked from the following list. 1. Web. The user is redirected to a website to collects the data. 2. Email Form. A form is embedded in the email lure. 3. Keylogger. Some form of keylogger was offered to the victim. 4. Automation. Other forms of automation such as background OLE automation. Cain & Jevans Expires December 24, 2005 [Page 13] Internet-Draft IODEF Fraud Report Extensions June 2005 5. Unspecified. 4.4.2 DCSiteData Element These elements gather the IPAddress, URL, or other identification of the data collection site where phished data is sent. This element includes an indication to the kind of data collector and the network identifier and, optionally, TCP/UDP port number of the site. 4.4.2.1 DCSiteType Parameter ENUM. This parameter specifies the address and other information in the DataCollectionSiteData element. 1. Web, with the website URL included in DCSitePointer. Data is collected on a website. 2. Email, with the email server DNS name in the DCSitePointer. The victim emails credentials to the collection site. 3. IP Address, with the DCSitePointer field holding the IP Version Protocol, IPAddress, and Port number of the collection site. The Protocol field defaults to TCP, if absent. This collection site uses other protocols to gather data from the victim. 4. Unknown. 4.4.2.2 DCSitePointer Element DCSitePointer is one of the following, depending on the DCSiteType parameter. URI Site URL. STRING Email Site SOURCE. This element contains the Protocol type, version, IPAddress, IP Protocol, and Ports list. 4.5 OriginatingSensor Element This section defines the identification and cognizant data of the network element that detected this fraud activity. Note that the network element does not have to be in the Internet itself (i.e., it Cain & Jevans Expires December 24, 2005 [Page 14] Internet-Draft IODEF Fraud Report Extensions June 2005 may be a local IDS system) nor is it required to be mechanical (e.g., humans are allowed). Multiple Originating Sensor Elements are allowed. +---------------------+ | OriginatingSensor | +---------------------+ | ENUM OrigSensorType |<>------------[ DateFirstSeen ] | |<>---(0..1)---[ Name ] | |<>------------[ Address ] | |<>---(0..1)---[ Location ] +---------------------+ The OriginatingSensor requires a type value and identification of the entity that generated this report. 4.5.1 OrigSensorType Parameter Type parameter is an ENUM from the following: 1. Web. This is a web Server or Service. 2. WebGateway, as in a Proxy or Firewall. 3. MailGateway. 4. Browser, or browser-type element. 5. ISPsensor. 6. Human 7. Honeypot. 8. Other. 4.5.2 DateFirstSeen Element REQUIRED. DATETIME. This is the date and time that this sensor first saw this phishing activity. 4.5.3 Name Element Cain & Jevans Expires December 24, 2005 [Page 15] Internet-Draft IODEF Fraud Report Extensions June 2005 Multilingual STRING. This is the DNS name or other identifier of the entity that generated this report. 4.5.4 Address Element SOURCE. This is the IPVersion, IPAddress, and optionally, port number of the entity that generated this report. 4.5.5 Location Element STRING. This isan optional location of the sensor. 4.6 TakeDownInfo Element This element identifies information regarding the disablement of the phish or fraud collector site and contains information regarding the party blocking or removing the site. A FraudReport may have multiple TakeDownInfo elements to support activities where multiple agencies are active. Note that the term "Agency" is used to identify any party performing the blocking or removal -- such as ISPs or private parties -- not just governmental entities. +-------------------+ | TakeDownInfo | +-------------------+ | |<>---(0..1)--[ TakeDownDate ] | |<>---(0..1)--[ TakeDownAgency ] | |<>---(0..1)--[ TakeDownComments ] +-------------------+ 4.6.1 TakeDownDate Element DATETIME. This is the date and time that takedown occurred. 4.6.2 TakeDownAgency Element STRING. This is a freeform string identifying the agency that performed the takedown 4.6.3 TakeDownComments Element Cain & Jevans Expires December 24, 2005 [Page 16] Internet-Draft IODEF Fraud Report Extensions June 2005 STRING. A free form field to add any exciting details of this takedown effort. 4.7 ArchivedData Element +-------------------+ | ArchivedData | +-------------------+ | ENUM Type |<>---(0..1)--[ ArchivedDataURL ] | |<>---(0..1)--[ ArchivedDataComments ] +-------------------+ The element is used to typecast and include a gzip archive file of a data collection site, base camp, or other site where the phisher developed their code. This element will be populated when, for example, an ISP takes down a phisher's web site and has copied the site data into an archive file. There are three types of archives currently supported, as specified in the type filed. 4.7.1 Type Parameter This parameter specifies the contents of the archive. 1. Data Collection Site. 2. Basecamp Site. 3. Sender Site. 4. Unspecified. 4.7.2 ArchivedDataURL Element URL. This is the URL where the gzip archive file is located. [As archives are quite large, a Fraud Report just points out where the archive is, and does not include it in the report.] 4.7.3 ArchivedDataComments Element STRING. This field is a free form area where one can comment on the archive and/or URL, if they so please. Cain & Jevans Expires December 24, 2005 [Page 17] Internet-Draft IODEF Fraud Report Extensions June 2005 4.8 RelatedData Element URL. These are non-phish web sites that are related to this incident (e.g., victim site, etc). 4.9 CorrelationData Element STRING. Any information that correlates this incident to other incidents can be entered here. 4.10 PRComments Element STRING. Comments specific to this phishing activity that does not fit in any other field. 4.11 EmailRecord Element Extensions are also made to the INCH IODEF Incident EventData element to support descriptive information received in phishing lure or spam emails. The ability to report spam is included within a PhraudReport to support exchanging information about large-scale spam activities, not necessarily a single spam message to a user. As such the spam reporting mechanism was not designed to minimize overhead and processing. Information related to the overall fraudulent activity is contained within the PhraudReport, while the EmailRecord element is used to capture forensic or detailed technical information about a specific attack. Incident Reports may have none, one, or multiple EmailRecords as its goal is to accumulate pertinent technical data associated with an specific attack as an investigation continues. +--------------------+ | EmailRecord | +--------------------+ | |<>-----------[ EmailCount ] | |<>-----------[ EmailHeader ] | |<>--(0..1)---[ EmailBody ] | |<>--(0..*)---[ EmailComments ] +--------------------+ 4.11.1 EmailCount Element NUMBER. This field indicates the number of email messages identified in this record detected by the reporter. Cain & Jevans Expires December 24, 2005 [Page 18] Internet-Draft IODEF Fraud Report Extensions June 2005 4.11.2 Email Originatin IPAddress This is the IP Version, Address, and port of the site originating the phish or spam email and is inserted into the LureSource element. Multiple EMailOrigIP elements are supported and encoded as Address elements. 4.11.3 EmailHeader Element STRING. The headers of the phish email are included in this element as a sequence of one-lined text strings. There SHALL be one EmailHeader element per mailRecord 4.11.4 EmailBody Element STRING. The body of the phish email is included here. If present, there should be at most one EmailBody element per EmailRecord 4.11.5 EmailComments Element STRING. Comments or relevant data not placed elsewhere about this email may be added in this text field. Cain & Jevans Expires December 24, 2005 [Page 19] Internet-Draft IODEF Fraud Report Extensions June 2005 5. IODEF Required Elements A Fraud Report requires certain identifying information, which is contained within the standard IODEF Incident data structure. The following table identifies attributes used in a Fraud Activity Report and their obligation. Note that the Required column notes attributes required by the base IODEF Incident element. Attributes identified as required SHALL be populated in conforming phishing activity reports. The following table is a visual description of the required fields. +--------------+ | Incident | +--------------+ | ENUM Purpose |---[ IncidentID ] | |---[ Assessment ] | | ---> [ Confidence ] | |---[ ReportTime ] | |---[ Contact ] | | ---> [ Role ] | | ---> [ Type ] | | ---> [ Name ] | |---[ EventData ] | | ---> [AdditionalData] | | ---> [ FraudReport ] | | ---> [ FraudType ] | | ---> [ FraudParameter ] | | ---> [ FraudedBrandName ] | | ---> [ LureSource ] | | ---> [ OriginatingSensor ] | | +--------------+ 5.1 Fraud or Phishing Report A compliant IODEF Fraud report is required to contain the following fields: Purpose IncidentID ReportTime Contact -> Role Cain & Jevans Expires December 24, 2005 [Page 20] Internet-Draft IODEF Fraud Report Extensions June 2005 Contact -> Type Contact -> Name Assessment EventData DetectTime AdditionalData PhraudReport FraudType FraudedBrandName LureSource OriginatingSensor 5.2 Wide-Spread Spam Report These following fields MUST be populated in a compliant Spam Activity Report: Incident Structure: IncidentID Purpose ReportTime Contact -> Role Contact -> Type Contact -> Name Assessment EventData DetectTime Cain & Jevans Expires December 24, 2005 [Page 21] Internet-Draft IODEF Fraud Report Extensions June 2005 AdditionalData PhraudReport FraudType == spamreport LureSource OriginatingSensor EmailRecord EmailCount EmailHeader 5.3 Guidance on Usage It may be apparent that the mandatory attributes for a phishing activity report make for a quite sparse report. As incident forensics and data analysis require detailed information, the originator of a FraudReport should include any tidbit of information gleaned from the attack. Information that is considered more sensitive than public can be marked to a higher sensitivity using the restriction parameter of each data element. Cain & Jevans Expires December 24, 2005 [Page 22] Internet-Draft IODEF Fraud Report Extensions June 2005 6. Security Considerations This document specifies the format of security incident data. As such, the security of transactions containing the incident report will vary from organization to organization. We do not want to burden the information exchange with unnecessary encryption requirements, as the transport service for the data exchange may provide adequate protections, or even encryption. The use of encryption is expected to be agreed upon on originator-recipient agreement. The critical security concern is that phishing activity reports may be falsified or the report may become corrupt during transit. Applying a digital signature on each report will counteract both of these concerns, but again the signature may be overkill for most activity report users. For this reason, phishing activity reports SHOULD be digitally signed with the optional IODEF XML signature, although we expect that each receiving entity will determine the need for this signature independently. Generators of phishing activity reports SHOULD digitally sign each report. Originators of fraud activity reports SHOULD digitally sign their report with the XML signature as described in[INCH]. Recipients of fraud reports SHALL be prepared to accept XML digitally signed reports and SHOULD support receiving encrypted reports. Cain & Jevans Expires December 24, 2005 [Page 23] Internet-Draft IODEF Fraud Report Extensions June 2005 7. IANA Considerations This document has no actions for IANA. Cain & Jevans Expires December 24, 2005 [Page 24] Internet-Draft IODEF Fraud Report Extensions June 2005 8. Contributors This document has received significant assistance from two groups addressing the phishing problem: members of the Anti-Phishing Working Group and participants in the Financial Services Technology Consortium's Counter-Phishing project. 9. Normative References [IDMEF] Curry, D. and H. Debar, "The Intrusion Detection Message Exchange Format", July 2004. [INCH] Meijer, J., Danyliw, and Demchenko, "The Incident Object Description Exchange Format Data Model and XML Implementation", November 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Patrick Cain The Cooper-Cain Group P.O. Box 400992 Cambridge, MA USA Email: pcain@coopercain.com David Jevans The Anti-Phishing Working Group 38 Rice Street, Suites 2-0/2-2 Cambridge, MA, 02140 USA Email: dave.jevans@antiphishing.org Cain & Jevans Expires December 24, 2005 [Page 25] Internet-Draft IODEF Fraud Report Extensions June 2005 Appendix A. Phishing Extensions XML Schema A digital copy of this file is available to prevent errors when re- entering text. See www.coopercain.com/incidents . This is an EventData.AdditionalData structure for an IODEF Incident class. Cain & Jevans Expires December 24, 2005 [Page 26] Internet-Draft IODEF Fraud Report Extensions June 2005 Cain & Jevans Expires December 24, 2005 [Page 27] Internet-Draft IODEF Fraud Report Extensions June 2005 Cain & Jevans Expires December 24, 2005 [Page 28] Internet-Draft IODEF Fraud Report Extensions June 2005 Cain & Jevans Expires December 24, 2005 [Page 29] Internet-Draft IODEF Fraud Report Extensions June 2005 Cain & Jevans Expires December 24, 2005 [Page 31] Internet-Draft IODEF Fraud Report Extensions June 2005 Cain & Jevans Expires December 24, 2005 [Page 32] Internet-Draft IODEF Fraud Report Extensions June 2005 Appendix B. Phishing Extensions XML DTD This will be supplied rather soonish. Cain & Jevans Expires December 24, 2005 [Page 33] Internet-Draft IODEF Fraud Report Extensions June 2005 Appendix C. Examples of Complete Fraud Activity Reports C.1 Sample Phish/Malware Email Report C.2 Received Email From: support@coopercain.com Sent: Friday, June 10, 2005 3:52 PM To: pcain@coopercain.com Subject: You have successfully updated your password Attachments: updated-password.zip Dear user pcain, You have successfully updated the password of your Coopercain account. If you did not authorize this change or if you need assistance with your account, please contact Coopercain customer service at: support@coopercain.com Thank you for using Coopercain! The Coopercain Support Team +++ Attachment: No Virus (Clean) +++ Coopercain Antivirus - www.coopercain.com C.3 Generated Report NOTE: Some wrapping and folding liberites have been applied to fit it into the margins. Cain & Jevans Expires December 24, 2005 [Page 34] Internet-Draft IODEF Fraud Report Extensions June 2005 PAT2005-06 This is a test report from actual data. pcain@coopercain.com 2005-06-22T08:30:00-05:00 2005-06-21T18:22:02-05:00 Subject: You have successfully updated your password Cooper-Cain
216.231.63.162
10.0.0.4
1
Return-path:
Envelope-to: pcain@coopercain.com
Delivery-date: Fri, 10 Jun 2005 15:52:11 -0400
Received: from dsl231-063-162.sea1.dsl.speakeasy.net ([216.231.63.162] helo=coopercain.com)
by mail06.coopercain.com with esmtp (Exim)
id 1DgpXy-0002Ua-IR
for pcain@coopercain.com; Fri, 10 Jun 2005 15:52:10 -0400
From: support@coopercain.com
To: pcain@coopercain.com
Subject: You have successfully updated Cain & Jevans Expires December 24, 2005 [Page 35] Internet-Draft IODEF Fraud Report Extensions June 2005 your password
Date: Fri, 10 Jun 2005 12:52:00 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A"
X-Priority: 3
X-MSMail-Priority: Normal
X-EN-OrigIP: 216.231.63.162
X-EN-OrigHost: dsl231-063-162.sea1.dsl.speakeasy.net
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on
scan18.int.bizland.net
X-Spam-Level: *****
X-Spam-Status: No, score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE, NO_REAL_NAME,
PRIORITY_NO_NAME autolearn=disabled version=3.0.2
 Cain & Jevans Expires December 24, 2005 [Page 36] Internet-Draft IODEF Fraud Report Extensions June 2005 Appendix D. Sample Spam Report [ ed. To be supplied, but it looks a lot like the fraud report] Cain & Jevans Expires December 24, 2005 [Page 37] Internet-Draft IODEF Fraud Report Extensions June 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cain & Jevans Expires December 24, 2005 [Page 38]