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 .
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="phish" xmlns:ns="http://www.w3.org/1999/xhtml"
xmlns:iodef="draft-ietf-inch-iodef-042.xsd"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
targetNamespace="phish"
elementFormDefault="qualified"
attributeFormDefault="qualified">
<xs:import namespace="draft-ietf-inch-iodef-042.xsd"
schemaLocation="draft-ietf-inch-iodef-042.xsd"/>
<!--
This Schema complies with draft-ietf-inch-phishingextns-00.txt
====================================================================
=== Top Level Class: PhraudReport ===
====================================================================
-->
<xs:element name="PhraudReport">
<xs:complexType>
<xs:sequence>
<xs:annotation>
<xs:documentation>This is an EventData.AdditionalData
structure for an IODEF Incident class.</xs:documentation>
</xs:annotation>
<xs:element name="PhishNameRef" type="xs:string"minOccurs="0"/>
<xs:element name="FraudParameter" minOccurs="0">
<xs:complexType mixed="true">
<xs:choice>
<xs:element name="string" type="xs:string"/>
<xs:element ref="phish:url"/>
<xs:element ref="phish:email"/>
<xs:element ref="phish:Source"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="FraudedBrandName" type="xs:string"/>
<xs:element name="LureSource">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element ref="phish:Source"/>
Cain & Jevans Expires December 24, 2005 [Page 26]
Internet-Draft IODEF Fraud Report Extensions June 2005
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="phish:OriginatingSensor"
minOccurs="1" maxOccurs="unbounded"/>
<xs:element ref="phish:EmailRecord"
minOccurs="0" maxOccurs="1"/>
<xs:element ref="phish:DCSite" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="phish:TakeDownInfo" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="phish:ArchivedData" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="phish:RelatedData" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="phish:CorrelationData" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="PRComments" type="xs:string"/>
</xs:sequence>
<xs:attribute name="Version" use="optional" default="1"/>
<xs:attribute name="FraudType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="phishemail"/>
<xs:enumeration value="recruitemail"/>
<xs:enumeration value="malwareemail"/>
<xs:enumeration value="fraudsite"/>
<xs:enumeration value="dnsspoof"/>
<xs:enumeration value="keylogger"/>
<xs:enumeration value="ole"/>
<xs:enumeration value="im"/>
<xs:enumeration value="cve"/>
<xs:enumeration value="archive"/>
<xs:enumeration value="spamreport"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
===========================================
=== Top Level Class: EmailRecord ===
===========================================
-->
<xs:element name="EmailRecord">
<xs:complexType>
<xs:sequence>
Cain & Jevans Expires December 24, 2005 [Page 27]
Internet-Draft IODEF Fraud Report Extensions June 2005
<xs:element name="EmailCount" type="xs:integer"
minOccurs="1" maxOccurs="1"/>
<xs:element name="EmailHeader" minOccurs="1">
<!-- This is an ugly way to deal with
multi-line header info. -->
<xs:complexType>
<xs:sequence>
<xs:element name="Header" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="EmailBody" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="EmailComments" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Children of PhraudReport ===
====================================================================
-->
<!--
##############################################################
#
# The Data Collection Site Data.
#
##############################################################
-->
<xs:element name="DCSite">
<xs:complexType>
<xs:sequence>
<xs:element name="DCSiteData" maxOccurs="unbounded">
<xs:complexType>
<xs:choice>
<xs:element name="siteurl" type="xs:anyURI"/>
<xs:element name="emailsite" type="xs:string"/>
<xs:element ref="phish:Source" id="IPAddress"/>
</xs:choice>
<xs:attribute name="DCSitetype" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="ipaddress"/>
<xs:enumeration value="unknown"/>
Cain & Jevans Expires December 24, 2005 [Page 28]
Internet-Draft IODEF Fraud Report Extensions June 2005
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="DCType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="keylogger"/>
<xs:enumeration value="automation"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
##############################################################
#
# The Originating Sensor Data; We use the IODEF:Node element and
# extend the nodecat categories.
#
##############################################################
-->
<xs:element name="OriginatingSensor">
<xs:complexType>
<xs:sequence>
<xs:element name="FirstSeen" type="xs:dateTime" minOccurs="0"/>
<xs:element name="name" type="iodef:MultilingTextType"
minOccurs="0"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="phish:Source"/>
<xs:element minOccurs="0" ref="iodef:Location"/>
</xs:sequence>
<xs:attribute name="OriginatingSensorType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="web"/>
<xs:enumeration value="webgateway"/>
<xs:enumeration value="mailgateway"/>
<xs:enumeration value="browser"/>
<xs:enumeration value="ispsensor"/>
<xs:enumeration value="human"/>
Cain & Jevans Expires December 24, 2005 [Page 29]
Internet-Draft IODEF Fraud Report Extensions June 2005
<xs:enumeration value="honeypot"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="Source">
<xs:complexType>
<xs:sequence>
<xs:element ref="phish:Protocol"/>
<xs:element name="Addr" type="xs:string"/>
<xs:element name="port" type="xs:string" minOccurs="0"/>
<xs:element name="vlan-name" type="xs:string" minOccurs="0"/>
<xs:element name="vlan-num" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="iodef:addrcat" use="required"/>
<xs:attribute default="unknown" ref="iodef:spoofed"/>
</xs:complexType>
</xs:element>
<xs:element name="Protocol" default="TCP">
<xs:simpleType>
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="TCP"/>
<xs:enumeration value="UDP"/>
<xs:enumeration value="ICMP"/>
<xs:enumeration value="Other"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!--
##############################################################
#
# The Take Down Data structure.
#
##############################################################
-->
<xs:element name="TakeDownInfo">
<xs:complexType>
<xs:sequence>
<xs:element name="TakeDownDate" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="TakeDownAgency" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="TakeDownComments" type="xs:string"
Cain & Jevans Expires December 24, 2005 [Page 30]
Internet-Draft IODEF Fraud Report Extensions June 2005
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ArchivedData">
<xs:complexType>
<xs:sequence>
<xs:element name="ArchivedDataURL" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="ArchivedDataComments" type="xs:string"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ArchivedDataType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="collectionsite"/>
<xs:enumeration value="basecamp"/>
<xs:enumeration value="sendersite"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="RelatedData">
<xs:complexType>
<xs:sequence>
<xs:element name="URLs" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CorrelationData"/>
<xs:element name="PRComments"/>
<!-- Elements and pieces that are used in many places.-->
<xs:element name="url" type="xs:anyURI"/>
<xs:element name="email">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\S@\S"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Cain & Jevans Expires December 24, 2005 [Page 31]
Internet-Draft IODEF Fraud Report Extensions June 2005
</xs:schema>
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.
<?xml version="1.0" encoding="utf-8"?>
<IODEF-Document
xmlns="draft-ietf-inch-iodef-042.xsd"
xmlns:ns="http://www.w3.org/1999/xhtml"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="draft-ietf-inch-iodef-042.xsd
draft-ietf-inch-iodef-042.xsd"
xmlns:iodef="draft-ietf-inch-iodef-042.xsd">
Cain & Jevans Expires December 24, 2005 [Page 34]
Internet-Draft IODEF Fraud Report Extensions June 2005
<Incident purpose="other">
<IncidentID Issuer="Pat">PAT2005-06</IncidentID>
<Description>This is a test report from actual data.
</Description>
<Contact contacttype="person" contactrole="creator">
<NameIdentifier format="emailAddress">
pcain@coopercain.com</NameIdentifier>
</Contact>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Assessment>
<Confidence rating="high" />
</Assessment>
<EventData>
<DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
<AdditionalData dtype="xml">
<PhraudReport FraudType="" Version="" xmlns="phish">
<FraudParameter>Subject: You have successfully updated
your password</FraudParameter>
<FraudedBrandName>Cooper-Cain</FraudedBrandName>
<LureSource>
<Address iodef:addrcat="ipv4-addr" iodef:spoofed="unknown">
<Addr>216.231.63.162</Addr>
</Address>
</LureSource>
<OriginatingSensor OriginatingSensorType="human">
<Address iodef:addrcat="ipv4-addr">
<Addr>10.0.0.4</Addr>
</Address>
</OriginatingSensor>
<EmailRecord>
<EmailCount>1</EmailCount>
<EmailHeader>
<Header>Return-path: <support@coopercain.com>
</Header>
<Header>Envelope-to: pcain@coopercain.com</Header>
<Header>Delivery-date: Fri, 10 Jun 2005 15:52:11 -0400
</Header>
<Header>
Received: from dsl231-063-162.sea1.dsl.speakeasy.net
([216.231.63.162] helo=coopercain.com)</Header>
<Header> by mail06.coopercain.com with esmtp (Exim)
</Header>
<Header> id 1DgpXy-0002Ua-IR</Header>
<Header> for pcain@coopercain.com;
Fri, 10 Jun 2005 15:52:10 -0400</Header>
<Header>From: support@coopercain.com</Header>
<Header>To: pcain@coopercain.com</Header>
<Header>Subject: You have successfully updated
Cain & Jevans Expires December 24, 2005 [Page 35]
Internet-Draft IODEF Fraud Report Extensions June 2005
your password</Header>
<Header>Date: Fri, 10 Jun 2005 12:52:00 -0700</Header>
<Header>MIME-Version: 1.0</Header>
<Header>Content-Type: multipart/mixed;</Header>
<Header>
boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A"
</Header>
<Header>X-Priority: 3</Header>
<Header>X-MSMail-Priority: Normal</Header>
<Header>X-EN-OrigIP: 216.231.63.162</Header>
<Header>
X-EN-OrigHost: dsl231-063-162.sea1.dsl.speakeasy.net
</Header>
<Header>X-Spam-Checker-Version: SpamAssassin 3.0.2
(2004-11-16) on </Header>
<Header> scan18.int.bizland.net</Header>
<Header>X-Spam-Level: *****</Header>
<Header>X-Spam-Status: No, score=5.6 required=6.0
tests=BAYES_95,CABLEDSL,HTML_20_30,</Header>
<Header>HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,
NO_REAL_NAME,</Header>
<Header>PRIORITY_NO_NAME autolearn=disabled
version=3.0.2</Header>
</EmailHeader>
</EmailRecord>
</PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
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]