INCH D. Jevans
Internet-Draft The Anti-Phishing Working Group
Expires: June 14, 2005 P. Cain, Ed.
The Cooper-Cain Group
December 14, 2004
Extension to IODEF-Document Class for Phishing Reports
draft-jevans-phishing-xml-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 June 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Phishing, a broadly-launched social engineering attack in which an
electronic identity is misrepresented in an attempt to trick
individuals into revealing credentials, is expanding on the Internet.
Corporations, Service Providers, consumer agencies, and financial
institutions have started to collect and correlate phishing attack
information to better plan out mitigation activities and to assist in
Jevans & Cain Expires June 14, 2005 [Page 1]
Internet-Draft IODEF Phishing Reports December 2004
prosecution. Early on it became obvious that a common format for the
data reported or exchanged between this parties was necessary.
This document defines a data format for reporting phishing attacks
and sharing data between repositories of phishing attacks. The
format is an outgrowth of the Anti-Phishing Working Group (APWG)
activities in data sharing and is based upon the Incident Handling
Working Group's (INCH) XML-based format for sharing incident data.
Although we use the term "phishing attack", the data format is
flexible enough to support information gleaned from activities
throughout the entire phishing life cycle. The attack format is also
extensible enough to be used for other related reporting such as DNS
spoofs (eg. localhost file takeover on PCs) and keyloggers typically
related to the phishing attack. The format shall also support very
simple reporting as well as optional fields for detailed reports and
supports single phish reports as well as consolidated reports of
multiple phish reports.
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].
Jevans & Cain Expires June 14, 2005 [Page 2]
Internet-Draft IODEF Phishing Reports December 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 INCH Dependencies . . . . . . . . . . . . . . . . . . . . 5
2. Phishing Actvitiy Reporting via an IODEF-Document Incident . 6
3. PhishingReport Class Definition . . . . . . . . . . . . . . 8
3.1 Version parameter . . . . . . . . . . . . . . . . . . . . 8
3.2 PhishType parameter . . . . . . . . . . . . . . . . . . . 8
3.3 PhishedBrandName element . . . . . . . . . . . . . . . . . 9
3.4 DataCollectionType element . . . . . . . . . . . . . . . . 9
3.5 DataCollectionSite class . . . . . . . . . . . . . . . . . 9
3.6 OriginatingSensor class . . . . . . . . . . . . . . . . . 10
3.7 TakeDownInfo class . . . . . . . . . . . . . . . . . . . . 11
3.8 ArchivedData element . . . . . . . . . . . . . . . . . . . 11
3.9 RelatedSites element . . . . . . . . . . . . . . . . . . . 12
3.10 CorrelationData element . . . . . . . . . . . . . . . . 12
3.11 Comments element . . . . . . . . . . . . . . . . . . . . 12
4. Definition of PhishRecord class . . . . . . . . . . . . . . 13
4.1 PhishRecord class . . . . . . . . . . . . . . . . . . . . 13
5. IODEF Required Elements . . . . . . . . . . . . . . . . . . 14
6. Guidance on Usage . . . . . . . . . . . . . . . . . . . . . 15
7. Sample Phishing Report . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
A. Phishing Data DTD . . . . . . . . . . . . . . . . . . . . . 20
B. Example of a Complete Phishing Activity Report . . . . . . . 26
C. Mapping from the APWG work into this Document . . . . . . . 27
C.1 Overall Format . . . . . . . . . . . . . . . . . . . . . . 29
C.2 Header Format . . . . . . . . . . . . . . . . . . . . . . 29
C.3 Individual Report Format . . . . . . . . . . . . . . . . . 30
D. Still To Do in This Document . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . 37
Jevans & Cain Expires June 14, 2005 [Page 3]
Internet-Draft IODEF Phishing Reports December 2004
1. Introduction
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
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 should be 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.
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.
In general, an incident report contains detailed incident-specific
data which populates an EventData Structure. That EventData
structure 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 Phishing
Activity Report.
Unsavory phishing activity may include multiple email messages,
attacks, or events, scattered over various times, locations, and
methodoligies. As each of these activities may generate multiple
reports to an incident team, the Phishing Activity Report is composed
Jevans & Cain Expires June 14, 2005 [Page 4]
Internet-Draft IODEF Phishing Reports December 2004
of multiple XML Incident classes. Each Incident class is used to
report one or more individual phishing reports and may include
multiple RecordData elelments.
This document defines new attributes for the EventData and Record
Item IODEF XML classes, then identifies attributes that are required
in a compliant Phishing Activity Report. The Appendices contain
sample Phishing Activity Reports and the complete Document Type
Definition.
1.1 INCH Dependencies
As discussions started to define a format for this information, it
became apparent that the output needed two things: include cognizant
data, and be supported by large numbers of vendors and products.
Instead of reinventing a basic reporting formula, we selected the
IETF IncidentHandling Working Group's (INCH) already-defined
XML-based attack data exchange models and formats.
The IODEF Extensions defined in this document comply with section4,
"Extending the IODEF Format" in [INCH].
Jevans & Cain Expires June 14, 2005 [Page 5]
Internet-Draft IODEF Phishing Reports December 2004
2. Phishing Actvitiy Reporting via an IODEF-Document Incident
A Phishing Activity Report is an instance of a IODEF-Document XML
Incident class [INCH] with added EventData and AdditionalData
classes. Some required information with many optional items are
populated into the new structure to form a Phishing Activity Report.
To facilitate completeness, the report originator should fill out as
much as possible of the optional Incident fields, but SHALL stay
consistent with the IODEF-Document structure.
This document defines the new Incident classes for the
AdditionalData, EventData, and Record Item IODEF XML classes; then
identifies attributes that are required in a compliant Phishing
Activity Report. The Appendices contain sample Phishing Activity
Reports and the complete XML Document Type Definition and schema.
The Incident class 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 ] --> RecordData --> RecordItem --> PhishRecord added
| |<>--{0..*}--[ AdditionalData ] --> PhishingReport added
+-------------------+
Figure 1. The INCH XML Incident class (modified)
A Phishing Activity Report is composed of one Incident class,
containing one or more EventData attributes. This document defines a
PhishingReport class for the Incident.EventData.AdditionalData
comprising of phishing-related information that does not map to
existing Incident or EventData attributes. The following section
defines the new extensions specific to the Incident class EventData
Jevans & Cain Expires June 14, 2005 [Page 6]
Internet-Draft IODEF Phishing Reports December 2004
and AdditionalData classes
Jevans & Cain Expires June 14, 2005 [Page 7]
Internet-Draft IODEF Phishing Reports December 2004
3. PhishingReport Class Definition
A PhishingReport consists of an Extension to the Incident
AdditionalData class, and is structured as follows.
+---------------------------+
| EventData.AdditionalData |
+---------------------------+
| ENUM type (9 = xml) |<>---------[ PhishingReport ]
| STRING meaning (xml) |
+---------------------------+
+------------------------+
| PhishingReport |
+------------------------+
| ENUM Version |<>--(0..*)--[ PhishParameter ]
| ENUM PhishType |----(0..*)--[ PhishedBrandName ]
| |<>--(0..*)--[ DataCollectionType ]
| |<>--(0..*)--[ DataCollectionSite ]
| |<>----------[ OriginatingSensor ]
| |<>--(0..*)--[ TakeDownInfo ]
| |<>--(0..*)--[ ArchivedData ]
| |<>--(0..*)--[ RelatedSites ]
| |<>--(0..*)--[ CorrelationData ]
| |----(0..1)--[ Comments ]
+------------------------+
Figure 2. The PhishingReport Extensions to the INCH XML
Incident.AdditionalData class
3.1 Version parameter
STRING. The version shall be the value 1.0 to be compliant with this
document.
3.2 PhishType parameter
ENUM. The PhishType attribute contains one of the following numbers
representing these types:
1. Email, and the PhishParameter is the email subject line of
the phishing email. This is a standard email phish, usually sent
by spam.
2. Fraudsite, no PhishParamerter. This identifies a known
fraudulent site that does not necessarily send spam lures.
3. 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).
Jevans & Cain Expires June 14, 2005 [Page 8]
Internet-Draft IODEF Phishing Reports December 2004
4. Keylogger, with the malware name as the PhishParameter.
5. OLE, no parameter. This identifies background OLE
information.
6. IM, no parameter.
7. CVE, with the CVEnumber as the PhishParameter.
8. SiteArchive, with the data archived from the phishing server
placed in the ArchiveInfo class.
9. Unknown.
When a PhishParameter is required, it is one of the following values:
SubjectLine element
STRING. This is the subject line of the email lure.
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.
3.3 PhishedBrandName element
STRING. This is the identifier of the recognized brandname or
company name used to launch the phishing activity.
3.4 DataCollectionType element
ENUM. This is the method of data collection, as determined by
analysing the victim computer, lure, or malware.
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.
4. Automation. Other forms of automation such as background OLE
automation.
5. Unspecified.
3.5 DataCollectionSite class
This is the collection site where phished data is sent.
+-----------------------+
| DataCollectionSite |
+-----------------------+
| ENUM Type |<>--(0..*)---[ SiteData ]
+-----------------------+
Jevans & Cain Expires June 14, 2005 [Page 9]
Internet-Draft IODEF Phishing Reports December 2004
Type parameter
1. Web, no parameter. Data is collected on a website.
2. Email, with email site(es), comma separated, as parameter(s).
Data is sent to one or more email addresses.
3. IP Address, with protocol and comma separated IP address(es)
as parameter(s). Data is sent to one or more IP addresses using
the identified protocol.
4. Unknown.
SiteData is one of the following, depending on the type.
STRING Site URL.
STRING Email Site
ADDRESS site IP
3.6 OriginatingSensor class
+--------------------+
| OriginatingSensor |
+--------------------+
| ENUM Type |<>---(0..*)---[ OriginatingSensorName ]
| |<>---(0..*)---[ OriginatingSensorIPAddress ]
| |<>------------[ OriginatingSensorFirstSeen ]
+--------------------+
The OriginatingSensor requires a type value and identification of the
entity that generated this report.
Type parameter is an ENUM from the following:
1. Web Server/Service.
2. Web Gateway (Proxy or Firewall).
3. Mail Gateway.
4. Browser Element.
5. ISP sensor.
6. Human
7. Other.
OriginatingSensorName element
STRING. This is the DNS name of the entity that generated this
report.
OriginatingSensorIPAddress element
ADDRESS. This is the IPAddress of the entity that generated this
report.
OriginatingSensorFirstSeen element
DATETIME. This is the date and time that this sensor first saw
this phishing activity.
Jevans & Cain Expires June 14, 2005 [Page 10]
Internet-Draft IODEF Phishing Reports December 2004
3.7 TakeDownInfo class
+-------------------+
| TakeDownInfo |
+-------------------+
| |<>---(0..1)--[ TakeDownDate ]
| |<>---(0..1)--[ TakeDownAgency ]
| |<>---(0..1)--[ TakeDownComments ]
+------------------------------+
This class identifies information regarding the disablement of the
phish collector site. A PhishingReport may have multiple
TakeDownInfo classes.
TakeDownDate element
DATETIME. This is the date and time that takedown occurred.
TakeDownAgency element
STRING. This is a freeform string identifying the agency that
performed the takedown
TakeDownComments element
STRING. A free form field to add any exciting details of the
this takedown effort.
3.8 ArchivedData element
+-------------------+
| ArchivedData |
+-------------------+
| ENUM Type |<>---(0..1)--[ ArchivedDataURL ]
| |<>---(0..1)--[ ArchivedDataComments ]
+------------------------------+
The element is used to type and include a gzip archive file o a
datacolection site , basecamp, 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.
Type parameter
1. Data Collection Site.
2. Basecamp Site.
3. Sender Site
ArchivedDataURL
Jevans & Cain Expires June 14, 2005 [Page 11]
Internet-Draft IODEF Phishing Reports December 2004
URL. This is the URL where the gzip archive file is located.
[As archives are quite large, a Phishing Report just points out
where the archive is, and doe snot include it in the report.]
ArchivedDataComments
STRING. This field is a free form area where one can comment on
the archive and/or URL, if they so please.
3.9 RelatedSites element
URL. These are non-phish web sites that are related to this incident
(e.g., victim site, etc).
3.10 CorrelationData element
STRING. Any information that correlates this incident to other
incidents can be entered here.
3.11 Comments element
STRING. Comments specific to this phishing activity that does not
fit in any other field.
Jevans & Cain Expires June 14, 2005 [Page 12]
Internet-Draft IODEF Phishing Reports December 2004
4. Definition of PhishRecord class
Extensions are also made to the Incident EventData Additional Data
class, to support descriptive information received in phish emails.
4.1 PhishRecord class
Data specific to this phishing activity is represented within a new
extenxion to the RecordItem class of the RecordData class of an
EventData class in an Incident class.
+-----------------------+
| RecordItem |
+-----------------------+
| ANY (PhishRecord) |
| ENUM Type (xml) |
+-----------------------+
+-----------------------+
| PhishRecord |
+-----------------------+
| |<>--(0..*)---[ EmailOriginatorIP ]
| |<>--(0..*)---[ EmailHeader ]
| |<>--(0..*)---[ EmailBody ]
| |<>--(0..*)---[ EmailComments ]
+-----------------------+
EmailOriginatorIP element
ADDRESS. This is the IP Address of the site originating the
phish email.
EmailHeader element
STRING. The headers of the phish email are included in this
class.
EmailBody element
STRING. The body of the phish email is included here.
EmailComments element
STRING. Data not placed elsewhere about this email may be added
in this field.
Jevans & Cain Expires June 14, 2005 [Page 13]
Internet-Draft IODEF Phishing Reports December 2004
5. IODEF Required Elements
A Phishing Report requires certain identifying information, which is
contained within the standard IODEF Incident data structure. The
following table identifies attributes used in a Phishing Activity
Report and their obligation. Note that the Required column notes
attributes required by the base IODEF Incident class. 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 |---[ IncidentID ]
| |---[ Assessment ]|---[ Confidence ]
| |---[ ReportTime ]
| |---[ Contact ]|---[ Role ]
| | |---[ Type ]|---[ Name ]
| |---[ AdditionalData ]|---[ PhishReport ]|---[ Version ]
| | |---[ PhishType ]
| | |---[ OriginatingSensor ]|---OriginatingSensorFirstSeen ]
| |
+------+
These following MUST be populated in a compliant Phishing Activity
Report:
IncidentID
Assessment -> Confidence
ReportTime
Contact -> Role
Contact -> Type
Contact -> Name
AdditionalData -> PhishReport -> Version
AdditionalData -> PhishReport -> PhishType
AdditionalData -> PhishReport -> OriginatingSensor ->
OriginatingSensorFirstSeen
Jevans & Cain Expires June 14, 2005 [Page 14]
Internet-Draft IODEF Phishing Reports December 2004
6. 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 PhishingReport 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 paramater of each data class.
Jevans & Cain Expires June 14, 2005 [Page 15]
Internet-Draft IODEF Phishing Reports December 2004
7. Sample Phishing Report
A sample (and useful) phishing activity report, that is one that has
only the required and data items populated, is as follows:
[ ed. To be supplied]
Jevans & Cain Expires June 14, 2005 [Page 16]
Internet-Draft IODEF Phishing Reports December 2004
8. 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 phishing activity reports SHOULD digitally sign their
report with the XML signature as described in [INCH] .
Recipients of phishing reports SHALL be prepared to accept XML
digitally signed reports and SHOULD support receiving encrypted
reports.
Jevans & Cain Expires June 14, 2005 [Page 17]
Internet-Draft IODEF Phishing Reports December 2004
9. IANA Considerations
This document has no actions for IANA.
Jevans & Cain Expires June 14, 2005 [Page 18]
Internet-Draft IODEF Phishing Reports December 2004
10. 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.
11 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
David Jevans
The Anti-Phishing Working Group
38 Rice Street, Suites 2-0/2-2
Cambridge, MA, 02140
USA
EMail: dave.jevans@antiphishing.org
Patrick Cain (editor)
The Cooper-Cain Group
P.O. Box 400992
Cambridge, MA
USA
EMail: pcain@coopercain.com
Jevans & Cain Expires June 14, 2005 [Page 19]
Internet-Draft IODEF Phishing Reports December 2004
Appendix A. Phishing Data DTD
<?xml version="1.0" encoding="UTF-8" ?>
<!--
********************************************************************
********************************************************************
*** Incident Object Description Exchange Format
***
*** PhishingReport Class DTD
***
*** Version 01, November 2004
***
********************************************************************
********************************************************************
This Document defines the dtd for a PhishingReport class.
pjc 12/04
-->
<!--
This document supports these versions:
IO_DEF_draf_ietf_inch_iodef_03
PhishingReport:
draft_jevens_phishingreport_00
-->
<!--
====================================================================
== General Purpose Entities ==
====================================================================
-->
<!ELEMENT data.url (#PCDATA) >
<!ELEMENT data.email (#PCDATA) >
<!ELEMENT data.ipaddress (#PCDATA) >
<!--
************************
| PhishingReport |
************************
| ENUM Version |==(0..*)==[ PhishParameter ]
| ENUM PhishType |==(0..*)==[ PhishedBrandName ]
| |==(0..*)==[ DataCollectionType ]
Jevans & Cain Expires June 14, 2005 [Page 20]
Internet-Draft IODEF Phishing Reports December 2004
| |==(0..*)==[ DataCollectionSite ]
| |========[ OriginatingSensor ]
| |==(0..*)==[ TakeDownInfo ]
| |==(0..*)==[ ArchivedData ]
| |==(0..*)==[RelatedSites ]
| |==(0..*)==[CorrelationData ]
| |==(0..1)==[ PRComments ]
************************
-->
<!--
====================================================================
== PhishingReport class ==
====================================================================
-->
<!ENTITY % attlist.version "version CDATA
#FIXED '1.0' " >
<!ENTITY % attvals.phishtype
"(email|fraudsite|dnsspoof|keylogger|ole|im|cve|archive|unknown)">
<!ELEMENT phish:PhishingReport (phish:PhishParameter*, phish:PhishedBrandName*,
phish:DataCollectionType*, phish:DataCollectionSite*, phish:OriginatingSensor,
phish:TakeDownInfo*, phish:ArchivedData*, phish:RelatedSites*,
phish:CorrelationData*, phish:PRComments?) >
<!ATTLIST phish:PhishingReport
version CDATA #FIXED "1.0"
xmlns:phishCDATA#IMPLIED
phishtype %attvals.phishtype; #REQUIRED
>
<!--
====================================================================
== PhishParameter class ==
====================================================================
-->
<!ELEMENT phish:PhishParameter (#PCDATA)>
<!--
====================================================================
== PhishedBrandName class ==
====================================================================
-->
<!ELEMENT phish:PhishedBrandName (#PCDATA)>
<!--
====================================================================
Jevans & Cain Expires June 14, 2005 [Page 21]
Internet-Draft IODEF Phishing Reports December 2004
== DataCollectionType class ==
====================================================================
-->
<!ENTITY % attvals.dctype "(web|email|keylogger|automation|unspecified)">
<!ELEMENT phish:DataCollectionType (#PCDATA)>
<!ATTLIST phish:DataCollectionType
dctype %attvals.dctype; #REQUIRED
>
<!--
====================================================================
== DataCollectionSite class ==
====================================================================
==
+***********************+
| DataCollectionSite |
+***********************+
| ENUM Type |<>==(0..*)===[ SiteData ]==[ URL
| | [ Email
| | [ IPAddress
+***********************+
==
-->
<!ENTITY % attvals.dcsite "(web|email|ipaddress|unknown)">
<!ELEMENT phish:DataCollectionSite (data.url|data.email|data.ipaddress)>
<!ATTLIST phish:DataCollectionSite
type %attvals.dcsite; #REQUIRED
>
<!--
====================================================================
== OriginatingSensor class ==
====================================================================
+********************+
| OriginatingSensor |
+********************+
| ENUM Type |<>===(0..*)===[ OriginatingSensorName ]
| |<>===(0..*)===[ OriginatingSensorIPAddress ]
| |<>============[ OriginatingSensorFirstSeen ]
+********************+
-->
<!ENTITY % attvals.orgsentype "( web | webgateway | mailgateway | browser |
ispsensor | human | other )">
<!ELEMENT phish:OriginatingSensor (phish:OriginatingSensorName*,
Jevans & Cain Expires June 14, 2005 [Page 22]
Internet-Draft IODEF Phishing Reports December 2004
phish:OriginatingSensorIPAddress*,
phish:OriginatingSensorFirstSeen) >
<!ATTLIST phish:OriginatingSensor
type %attvals.orgsentype; #REQUIRED
>
<!ELEMENT phish:OriginatingSensorName (#PCDATA) >
<!ELEMENT phish:OriginatingSensorIPAddress (data.ipaddress) >
<!ELEMENT phish:OriginatingSensorFirstSeen (DateTime) >
<!--
====================================================================
== PRComments class ==
====================================================================
-->
<!ELEMENT phish:PRComments (#PCDATA)>
<!--
====================================================================
== TakeDownInfo class ==
====================================================================
+*******************+
| TakeDownInfo |
+*******************+
| |<>===(0..1)==[ TakeDownDate ]
| |<>===(0..1)==[ TakeDownAgency ]
| |<>===(0..1)==[ TakeDownComments ]
+*******************+
-->
<!ELEMENT phish:TakeDownInfo ( phish:TakeDownDate*, phish:TakeDownAgency*,
phish:TakeDownComments*)>
<!ELEMENT phish:TakeDownDate (DateTime) >
<!ELEMENT phish:TakeDownAgency (#PCDATA)>
<!ELEMENT phish:TakeDownComments (#PCDATA) >
<!--
====================================================================
== ArchivedData class ==
====================================================================
+*******************+
| ArchivedData |
+*******************+
| ENUM Type |<>===(0..1)==[ ArchivedDataURL ]
| |<>===(0..1)==[ ArchivedDataComments ]
+*******************+
Jevans & Cain Expires June 14, 2005 [Page 23]
Internet-Draft IODEF Phishing Reports December 2004
-->
<!ENTITY % attvals.archiveddata "( collectionsite | basecamp | sendersite )">
<!ELEMENT phish:ArchivedData ( phish:ArchivedDataURL*,
phish:ArchivedDataComments*)>
<!ATTLIST phish:ArchivedData
type %attvals.archiveddata; #REQUIRED
>
<!ELEMENT phish:ArchivedDataURL (data.url) >
<!ELEMENT phish:ArchivedDataComments (#PCDATA) >
<!--
====================================================================
== RelatedSites class ==
====================================================================
-->
<!ELEMENT phish:RelatedSites (data.url)>
<!--
====================================================================
== PhishParameter class ==
====================================================================
-->
<!ELEMENT phish:CorrelationData (#PCDATA)>
<!--
====================================================================
== PhishRecord class ==
====================================================================
+***********************+
| RecordItem |
+***********************+
| ANY (PhishRecord) |
| ENUM Type (xml) |
+***********************+
+***********************+
| PhishRecord |
+***********************+
| |<>==(0..*)===[ EmailOriginatorIP ]
| |<>==(0..*)===[ EmailHeader ]
| |<>==(0..*)===[ EmailBody ]
| |<>==(0..*)===[ EmailComments ]
Jevans & Cain Expires June 14, 2005 [Page 24]
Internet-Draft IODEF Phishing Reports December 2004
+***********************+
-->
<!ELEMENT phish:PhishRecord ( phish:EmailOriginatorIP*,
phish:EmailOriginatorHeader*,phish:EmailOriginatorBody*,
phish:EmailOriginatorComments*) >
<!ELEMENT phish:EmailOriginatorIP (data.ipaddress) >
<!ELEMENT phish:EmailOriginatorHeader (#PCDATA) >
<!ELEMENT phish:EmailOriginatorBody (#PCDATA) >
<!ELEMENT phish:EmailOriginatorComments (#PCDATA) >
Jevans & Cain Expires June 14, 2005 [Page 25]
Internet-Draft IODEF Phishing Reports December 2004
Appendix B. Example of a Complete Phishing Activity Report
<!-- Incude the base IODEF definitions. -->
<!-- This is the test report..... -->
<IODEF-Document>
<Incident purpose="statistics">
<IncidentID>pat_001</IncidentID>
<Contact contactrole="creator" contacttype="person">
<Timezone>EST</Timezone>
</Contact>
<ReportTime>2004-12-31:01:42</ReportTime>
<Assessment>
<Confidence rating="low"/>
</Assessment>
<EventData>
<Record>
<RecordData ident="0">
<RecordItem dtype="xml">
<phish:PhishRecord>
<phish:EmailOriginatorIP>
<data.ipaddress>207.148.245.213</data.ipaddress>
</phish:EmailOriginatorIP>
<phish:EmailOriginatorHeader>Empty header </phish:EmailOriginatorHeader>
<phish:EmailOriginatorBody>empty body</phish:EmailOriginatorBody>
<phish:EmailOriginatorComments> This was fake email to keep the
size of the sample report small.
</phish:EmailOriginatorComments>
</phish:PhishRecord>
</RecordItem>
</RecordData>
</Record>
</EventData>
<AdditionalData type="xml">
<phish:PhishingReport phishtype="email">
<phish:OriginatingSensor type="human">
<phish:OriginatingSensorFirstSeen>
<DateTime>2004-12-15:23:53:01</DateTime>
</phish:OriginatingSensorFirstSeen>
</phish:OriginatingSensor>
</phish:PhishingReport>
</AdditionalData>
</Incident>
</IODEF-Document>
Jevans & Cain Expires June 14, 2005 [Page 26]
Internet-Draft IODEF Phishing Reports December 2004
Appendix C. Mapping from the APWG work into this Document
Note: This appendix is Informational and will be removed in the next
version of the document.
As this document incorporates some previous work done by the APWG,
this section identifies where the APWG-required data items map into
the INCH data structures. The following figure summarizes the APWG
nomenclature as expressed as Incident classes/fields.
+------------------+---------------------+--------------------------+
| APWG identifier | member | IODEF class |
+------------------+---------------------+--------------------------+
| phishingreport | uniqueid | Incident.IncidentID |
| | | |
| Header | | Incident |
| | | |
| | format version | EventData.AdditionalData |
| | | PhishingReport.Version |
| | | |
| | datecreated | Incident.ReportTime |
| | | |
| | reporterorg | IncidentID.UID |
| | | |
| | reportername | Incident.Contact |
| | | |
| | reporteremail | Incident.Contact.Email |
| | | |
| | reportersignature | (still under flux in |
| | | Incident) |
| | | |
| | comments | Incident.Description or |
| | | Incident.EventData.Descr |
| | | ption |
| | | |
| | aggregateflag | Multiple EventData |
| | | structures |
| | | |
| phish | | EventData. |
| | | |
| | datedetected | DetectTime |
| | | |
| | phishtype | EventData.AdditionalData |
| | | PhishingReport.Eventtype |
| | | |
| | datacollectiontype | EventData.AdditionalData |
| | | PhishingReport.DataColle |
| | | tionType |
Jevans & Cain Expires June 14, 2005 [Page 27]
Internet-Draft IODEF Phishing Reports December 2004
| | | |
| | datacollectionsite | EventData.AdditionalData |
| | | PhishingReport.DataColle |
| | | tionSite |
| | | |
| | originatingsensorty | EventData.AdditionalData |
| | e | PhishingReport.Originato |
| | | Sensor.Type |
| | | |
| | originatingsensorna | EventData.AdditionalData |
| | e | PhishingReport.Originati |
| | | gSensor.SensorName |
| | | |
| | originatingsensorIP | EventData.AdditionalData |
| | ddress | PhishingReport.Originati |
| | | gSensor.IPaddress |
| | | |
| | forensics | EventData.Record |
| | | |
| | emailsite-url | PhishReport.DataCollecto |
| | | Site.SiteData |
| | | |
| | site-url | PhishReport.DataCollecto |
| | | Site.SiteData |
| | | |
| | emailsubject | PhishReport.PhishParamet |
| | | r |
| | | |
| | takedowndate | PhishingReport.TakedownI |
| | | fo.Date |
| | | |
| | takedownagency | EventData.AdditionalData |
| | | PhishingReport.TakedownI |
| | | fo.Agency |
| | | |
| | site-ip | PhishReport.PhishParamet |
| | | r and |
| | | PhishReport.DataCollecto |
| | | Site.SiteData |
| | | |
| | emailheaders | PhishRecord.EmailHeaders |
| | | |
| | emailbody | PhishRecord.EmailBody |
| | | |
| | brand | PhishReport.PhishedBrand |
| | | ame |
| | | |
| | senderip | |
Jevans & Cain Expires June 14, 2005 [Page 28]
Internet-Draft IODEF Phishing Reports December 2004
| | | |
| | otherlink | PhishingReport.RelatedSi |
| | | es |
| | | |
| | correlations | PhishingReport.Correlati |
| | | nData |
| | | |
| | comments | EventData. |
+------------------+---------------------+--------------------------+
C.1 Overall Format
Each phishing report is encapsulated in the phishingreport element
<phishingreport uniqueid> header followed by one or more reports
</phishingreport uniqueid> One or more phishing reports are included.
C.2 Header Format
Each report must have a header. Each header MUST have:
<keyword>>formatversion<</keyword> version number>/formatversion< The
version of the XML reporting format. Eg. 1.0
<datereportcreated> 32-bit UNIX time<datereportcreated> This is the
date that the phish report was created.
<reporterorg> organization who created the phish report</reporterorg>
Name or other id of who created the phish report (not the name of the
person who submitted it). Do we need a unique database of
reporternames? Eg. TMWD Çô Tumbleweed Communications Corp.
Each header MAY have:
<reportername>name of the person who created the
report</reportername> Name of an individual.
<reporteremail>email address of the person who created the
report</reporteremail> email address of the individual who created
the report.
<reportersignature>digitalsignature</reportersignature> An XML
digital signature of the canonicalized file, everything between the
<phishingreport></phishingreport>. We need the hash of the document,
the certs or URL to them, and the signature. What format should that
be? XML-DSIG? This verifies the authenticity of the report.
Jevans & Cain Expires June 14, 2005 [Page 29]
Internet-Draft IODEF Phishing Reports December 2004
<comments>>ext</comments> Any comments that the reporter chooses to
add to the individual phish report.
<aggregateflag>01 or nn</aggregateflag> This is a flag for whether
this XML doc represents a single phish attack event; or it is an
aggregated document that represents nn discrete events
C.3 Individual Report Format
Each individual report is encapsulated between phish.
<phish uniqueid> report fields </phish uniqueid> Each individual
report is encapsulated between the <phish></phish> with the
uniqueids.
Each report MUST have:
<datedetected>32-bit UNIX time</datedetected> This is the date that
the phish was reported by a consumer or detected by a trap or other
means.
<phishtype>phishtype optional_parameter</phishtype>
One of the following.
+----------------------+----------------------+---------------------+
| String | Parameter | Description |
+----------------------+----------------------+---------------------+
| Email | | a standard email |
| | | phish, usually sent |
| | | by spam |
| | | |
| Fraudsite | a known fraudulent | DNSspoof |
| | site that does not | |
| | necessarily send | |
| | spam lures | |
| | | |
| malwarename | spoofed DNS (eg. | Keylogger |
| | Malware changes | |
| | localhost file so | |
| | visits to | |
| | www.example.com go | |
| | to an incorrect IP | |
| | address) | |
| | | |
| malwarename | a keylogger site | OLE |
| | | |
| | Background OLE | IM |
Jevans & Cain Expires June 14, 2005 [Page 30]
Internet-Draft IODEF Phishing Reports December 2004
| | Automation | |
| | | |
| | Instant | CVE |
| | message/NNTP/etc | |
| | | |
| CVEnumber | CVE number?? For | |
| | malware exploits. Or | |
| | is this the | |
| | keylogger | |
| | malwarename? | |
+----------------------+----------------------+---------------------+
The optional parameter is a string, without whitespace, that may be
used to name the malware that installed the keylogger or the
DNSspoofer.
Each report MAY have:
<datacollectiontype>type</datacollectiontype>
The method of data collection. This is derived from the victimÇÖs
computer (eg. By analyzing the email lure or malware sent to them).
One of the following:
+---------------------------------+---------------------------------+
| String | Description |
+---------------------------------+---------------------------------+
| Web | User is redirected to a website |
| | that collects the data |
| | |
| EmailForm | A form is embedded in the email |
| | lure |
| | |
| Keylogger | Some form of keystroke logger |
| | |
| Automation | Other form of automation such |
| | as a background OLE automation |
+---------------------------------+---------------------------------+
NOTE: This is somewhat redundant with phishtype, especially if a
keylogger.
<datacollectionsite>type optional_parameters</datacollectionsite>
Where the data is sent. This can be found by seizing a capture site
and analyzing the code on the server. One of the following:
Jevans & Cain Expires June 14, 2005 [Page 31]
Internet-Draft IODEF Phishing Reports December 2004
+----------------------+----------------------+---------------------+
| String | Parameter | Description |
+----------------------+----------------------+---------------------+
| Web | | Data is collected |
| | | on a website. |
| | | Emailsite-url and |
| | | site-url fields are |
| | | used to specify the |
| | | location of the |
| | | site. |
| | | |
| Email | addr, addr | Data is sent to one |
| | | or more email |
| | | address. List them. |
| | | Comma separated. |
| | | |
| IP | ip, IP | Data is sent to one |
| | | or more IP address, |
| | | comma separated. |
| | | (how to specify |
| | | protocol e.g., |
| | | IRC?) |
+----------------------+----------------------+---------------------+
<originatingsensortype>type</originatingsensortype>
The type of technology that generated this XML document. One of the
following:
+---------------------------------+---------------------------------+
| String | Description |
+---------------------------------+---------------------------------+
| Web Server/Service | This XML doc was generated by a |
| | web server or service |
| | |
| Web gateway | This XML doc was generated by a |
| | web gateway |
| | |
| Mail gateway | This XML doc was generated by a |
| | mail gateway |
| | |
| Browser element | This XML doc was generated by a |
| | web browser element (i.e. |
| | plugin) |
| | |
| ISP sensor | An ISP sensor generated this |
| | XML document |
| | |
Jevans & Cain Expires June 14, 2005 [Page 32]
Internet-Draft IODEF Phishing Reports December 2004
| Human | A Human generated this XML |
| | doc/report (e.g.,. Discovered |
| | phishing base camp) |
| | |
| Other technology | This XML doc was generated by |
| | some other technology |
+---------------------------------+---------------------------------+
<originatingsensorname>name</originatingsensorname>
The DNS name of the entity that generated this XML document.
<originatingsensorIPaddress>name</originatingsensorIPaddress>
The IP address of the entity that generated this XML document.
<forensics<strings>/forensics<
Any length of strings of forensic information. Useful for law
enforcement. This could be watermarks in images, comments in HTML
fields, poisoned user data.
<emailsite-url>URL</emailsite-url>
This is the base URI of phishing site that is included in the email
lure. This can be used by email spam filters to detect and filter
out phishing emails by posting it to SURBL. This also can be used in
a Web browser to access the phishing site.
If the site is an SSL site, then the URL specifies https://URL
<site-url>URL</site-url>
This is the URI of the phishing data collection site that the browser
actually goes to in order to post data. This may differ from the
emailsite-url, because the URL included in the email might redirect
users to the actual data collection site, which is the site-url. The
emailsite-url is useful for spam filters, the site-url is useful for
takedown, law enforcement, or web proxy filters to prevent users from
visiting the collection site.
If the site is an SSL site, then the URL specifies https://URL
<emailsubject>subject</emailsubject>
The subject of the email phish lure.
<takedowndate>UNIX 32-bit time</takedowndate>
Jevans & Cain Expires June 14, 2005 [Page 33]
Internet-Draft IODEF Phishing Reports December 2004
If the site has been taken down, this is the date and time when that
was effected. Which site? Redirector or data collection site?
Multiples with designator?
<takedownagency>string</takedownagency>
Who took the site down. If more than one party took it down, you may
list multiple parties as freeform text here, or have multiple
takedownagency fields.
<site-ip>>p address (port number optional if not 80)</site-ip>
The IP address of the server hosting the phishing site in standard IP
address format A.C.D.E:portnum. If no portnumber specified, then
port 80 assumed.
These IP addresses could be used by ISPs and web filters to block
access to servers. However, this is dangerous if the sites are
running on hacked servers or ISPs that are hosting legitimate sites
as well. It can be very useful to filter out access to servers that
have hijacked DNS through modifying localhosts files for example
(e.g., 11.1.2004).
<emailbody uniqueid>body</emailbody uniqueid>
The body of the email. I think we need the uniqueid strings.
What about when the body is an image only? Ex. GDI exploit to
install keylogger or single image with hyperlink.
<emailheaders uniqueid>headers</emailheaders uniqueid>
The headers of the email
Do we need to create xml records for each entry in a decomposed
header? No, only the open relays and the apparent source and possibly
a few others..
<brand>brand name</brand>
The name of the company whoÇÖs brand is being used to launch the
phishing attack
<senderip>IP address (optional port number)</senderip>
The IP address of the mail server or relay that delivered the
phishing email. This can be used for RBLs. A single attack may have
multiple senderips if the mail was sent from multiple relays.
Jevans & Cain Expires June 14, 2005 [Page 34]
Internet-Draft IODEF Phishing Reports December 2004
<otherlink>URL</otherlink>
Links to non-phish sites that may be relevant (victim site, other
sites)
<correlations>strings</correlations>
Any correlations to known phishing kits or groups. Freeform text.
<comments>text</comments>
Any freeform text comments that the reporter chooses to add to the
individual phish report. e.g.,. "images sourced from victim
online-banking site" or "background popup populated with victim
privacy statement".
Jevans & Cain Expires June 14, 2005 [Page 35]
Internet-Draft IODEF Phishing Reports December 2004
Appendix D. Still To Do in This Document
This appendix will be removed when it is empty.
This list are the tasks that are still needed to be comleted withni
this document.
1. Make a test report that verifies every possible option.
2. Finish and insert the schema.
Add more detail on what the specific elements mean,
Jevans & Cain Expires June 14, 2005 [Page 36]
Internet-Draft IODEF Phishing Reports December 2004
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 (2004). 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.
Jevans & Cain Expires June 14, 2005 [Page 37]