Internet Draft David M'Raihi
Category: Informational VeriSign
Document: draft-mraihi-inch-thraud-07.txt Sharon Boeyen
Expires: February 2009 Entrust
Michael Grandcolas
Grandcolas Consulting
LLC
Siddharth Bajaj
VeriSign
August 2008
Sharing Transaction Fraud Data
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes a document format for exchanging
transaction fraud (Thraud) information. It extends the Incident
Handling Working Group (INCH WG) Incident Object Description
Exchange Format (IODEF) incident reporting document format.
Sharing Transaction Fraud Data July 2008
Table of Contents
1. Introduction 3
2. Requirements Terminology 4
3. Anatomy of a Transaction Fraud 4
4. IODEF-Document Incident Class 6
5. Thraud Record Class Definitions 7
5.1. FraudEventPaymentType Class 8
5.1.1. PayeeName 9
5.1.2. PostalAddress 9
5.1.3. PayeeAmount 9
5.2. FraudEventTransferType Class 9
5.2.1. BankID 10
5.2.2. AccountID 11
5.2.3. AccountType 11
5.2.4. TransferAmount 12
5.3. FraudEventIdentityType Class 12
5.3.1. IdentityComponent 12
5.4. FraudEventOtherType Class 13
5.4.1. OtherEventType 13
5.4.2. OtherEventDescription 14
5.5. AmountType Class 14
5.5.1. Class Contents 14
5.5.2. Currency 14
5.6. AccountTypeType Class 14
6. IODEF Profile for an Activity Thraud Report 15
6.1. Mandatory components 15
6.2. Recommended Components 15
6.3. Deprecated Components 16
7. IODEF profile for a Signature Thraud Report 17
8. IODEF Additional Attribute Values 18
8.1. Purpose Attribute 18
9. Security considerations 18
10. IANA considerations 19
10.1. Media sub-type 19
10.2. XML namespace 20
11. Conclusion 20
12. References 21
12.1. Normative 21
12.2. Informative 21
13. Authors' Addresses 21
14. Full Copyright Statement 22
15. Intellectual Property 22
Appendix A. Thraud Record XML Schema 23
Appendix B. Example of a Thraud Report 24
M'RAIHI Expires - January 2009 [Page 2]
Sharing Transaction Fraud Data July 2008
1. Introduction
Financial organizations and merchants that offer online access
to their services frequently encounter fraud perpetrated against
their customers' accounts. In their attempts to combat these
frauds, the organizations and their law enforcement agencies
could benefit greatly by sharing intelligence about fraud
incidents and patterns with similar organizations and agencies.
This specification standardizes a document format by which they
can share such information. It is intended to facilitate multi-
vendor interoperability between conformant components of an open
fraud reporting framework.
Information sharing can take place directly between financial
organizations and merchants. However, the power of shared
intelligence is multiplied many times if the information is
gathered from multiple sources by a shared network, consolidated
and redistributed to participants.
In this arrangement, incident reports submitted to the network
are called inbound reports, and reports issued by the network
are called outbound reports.
Inbound reports will be submitted using a push-style protocol
(such as email or SOAP). And outbound reports will either be
distributed using a push-style protocol or a request/response
protocol (such as HTTP).
Inbound reports identify the contributor of the report, as this
information is essential in evaluating the quality of the
information it contains and in contacting the source for the
purpose of clarification. But, outbound reports commonly do not
identify the original sources, as those sources may not wish to
be identified to other subscribers. Such reports should,
instead, identify the consolidator as the source.
A report may describe a particular transaction that is known to
be, or believed to be, fraudulent, or it may describe a pattern
of behavior that is believed to be indicative of fraud. The
former type of report is called an 'activity report' and the
latter a 'signature report'.
The schema defined herein extends the IODEF XML incident
reporting schema [RFC5070].
In section 3 we introduce the actors in a typical transaction
fraud. Fraud reporting by means of an IODEF-Document is
described in section 4. We define the elements of a Thraud
Report in section 5. In section 6 we describe the Activity
Thraud Report profile of the IODEF specification. And in section
7 the profile for a Signature Thraud Report is described. In
section 8 we define new attribute values for the IODEF Incident
M'RAIHI Expires - January 2009 [Page 3]
Sharing Transaction Fraud Data July 2008
class. Security considerations are described in section 9. And,
Section 10 contains a request to IANA to register the associated
media sub-type and XML namespace identifier. The Appendices
contain the complete XML schema and a sample Thraud Report.
Data elements in this document are expressed in Unified Modeling
Language (UML) syntax [UML].
XML namespace prefixes are used throughout this document to
stand for their respective XML namespaces, as follows.
iodef: urn:ietf:params:xml:ns:iodef-1.0
thraud: urn:ietf:params:xml:ns:thraud-1.0
xs: http://www.w3.org/2001/XMLSchema
xsi: http://www.w3.org/2001/XMLSchema-instance
2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119].
3. Anatomy of a Transaction Fraud
The actors in a typical transaction fraud are shown in Figure 1.
M'RAIHI Expires - January 2009 [Page 4]
Sharing Transaction Fraud Data July 2008
+--------------------------------------+
| Fraudsters |
| (collect & verify victim credentials |
| via phishing, malware, etc.) |
+--------------------------------------+
|
|recruit
|
| ----------------disburse profits-----------------
| | |
v v |
+-----------+ +--------------+ +-------+
| | | | | Fraud |
| |--Open Dest Acct-->| Financial |---->| Dest. |
| | | Organization | |Account|
| Fraud | +--------------+ +-------+
| Executors | ^ funds
| | | transfer
| | +--------------+ +-------+
| | | Victim's | | |
| |---Init Transfer-->| Financial |<-o--|Victim |
| | | Organization | | |Account|
+-----------+ +--------------+ | +-------+
v
+-----------+
| Fraud |
| Detection |
| Sensors |
|(realtime/ |
| offline) |
+-----------+
Figure 1. Transaction Fraud Elements
Transaction fraud activities normally involve the following
actors:
1. Fraudsters are individuals or organizations that collect
victims' login credentials using a variety of means, including
phishing and malware, and verify them (usually by attempting to
login to the victim's account). Then the Fraudsters may either
recruit Fraud Executors themselves or wholesale the victims'
credentials to other Fraudsters, who will, in turn, recruit
Fraud Executors.
2. Fraud Executors are individuals who attempt the
fraudulent funds transfer or payment. In the case of fraudulent
funds transfers, an account at the same financial organization
as that of the victim, or a different one, is opened, as the
destination account for the fraudulent transfer. Alternatively,
a fraudulent payment is made using a check or electronic
transfer.
M'RAIHI Expires - January 2009 [Page 5]
Sharing Transaction Fraud Data July 2008
3. Victims of both credential theft and transaction fraud.
4. Financial Organizations that hold the victim's and the
Fraud Executor's accounts.
5. Sensors at the Financial Organization that detect
fraudulent transaction attempts, either in real-time or after
the fact.
The intention of Thraud reporting is to enable any organization
that has detected fraud to share this information, either
internally or with other potential victim organizations. The
receiving organization can use this information, for example, to
institute manual review of transactions initiated from
suspicious IP addresses.
4. IODEF-Document Incident Class
A Thraud Report SHALL be an instance of the IODEF-Document
class, as defined in [RFC5070]. The report SHALL contain at
least one Incident object, as defined in [RFC5070]. Each
Incident object SHOULD contain information about a single fraud
strategy. One Incident object MAY contain information about
multiple fraudulent transactions that are consistent with the
same fraud strategy. Each fraudulent transaction SHALL be
described in a separate EventData object. The data model for the
Incident class is defined in [RFC5070] and is repeated here, as
Figure 2, for the reader's convenience.
M'RAIHI Expires - January 2009 [Page 6]
Sharing Transaction Fraud Data July 2008
+-------------+
| Incident |
+-------------+
|ENUM |<>----------[ IncidentID ]
| purpose |<>--{0..1}--[ AlternativeID ]
|STRING |<>--{0..1}--[ RelatedActivity ]
| ext-purpose |<>--{0..1}--[ DetectTime ]
|ENUM |<>--{0..1}--[ StartTime ]
| lang |<>--{0..1}--[ EndTime ]
|ENUM |<>----------[ ReportTime ]
| restriction |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{1..*}--[ EventData ]<>--[ AdditionalData ]
| |<>--{0..1}--[ History ]
| |<>--{1..*}--[ AdditionalData ]
+-------------+
Figure 2. Data model of the Incident class
The AdditionalData abstract class is an extension point in the
schema of the EventData class. Implementers SHALL include
exactly one of the following objects in AddtionalData:
FraudEventPayment, FraudEventTransfer, FraudEventIdentity and
FraudEventOther. Collectively, these are known as Thraud
Records. The corresponding classes are defined by this
specification in section 5, below.
The Thraud profile of the Incident class is defined in sections
6 and 7, below.
5. Thraud Record Class Definitions
Thraud Records are expressed in XML. Therefore, the dtype
attribute of the AdditionalData element SHALL be assigned the
value 'xml'.
A payment Thraud Record SHALL be structured as shown in Figure
3. See also section 5.1.
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventPayment ]
+------------------+
Figure 3. The FraudEventPayment extension
A funds-transfer Thraud Record SHALL be structured as shown in
Figure 4. See also section 5.2.
M'RAIHI Expires - January 2009 [Page 7]
Sharing Transaction Fraud Data July 2008
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventTransfer ]
+------------------+
Figure 4. The FraudEventTransfer extension
An identity Thraud Record SHALL be structured as shown in Figure
5. See also section 5.3.
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventIdentity ]
+------------------+
Figure 5. The FraudEventIdentity extension
Other Thraud Records SHALL be structured as shown in Figure 6.
See also section 5.4. The FraudEventOther class has an open
definition to act as a placeholder for event types that emerge
in the future.
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>----[ FraudEventOther ]
+------------------+
Figure 6. The FraudEventOther extension
5.1. FraudEventPaymentType Class
The FraudEventPaymentType class is used to report payee
instructions for a fraudulent payment or fraudulent payment
attempt. Fraudsters sometimes use the same payee instructions
(including the amount) for multiple fraudulent payment attempts.
By reporting the payment instructions used in the fraud, other
oragnizations may be able to detect similar fraudulent payment
attempts to the same payee.
The structure of the FraudEventPaymentType class SHALL be as
shown in Figure 7.
M'RAIHI Expires - January 2009 [Page 8]
Sharing Transaction Fraud Data July 2008
+-------------+
| FraudEvent- |
| PaymentType |
+-------------+
| |<>--{0..1}--[ PayeeName ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..1}--[ PayeeAmount ]
+-------------+
Figure 7. The FraudEventPaymentType class
The contents of the FraudEventPaymentType class are described
below. At least one component MUST be present.
5.1.1. PayeeName
Zero or one value of type iodef:MLString. The name of the payee.
5.1.2. PostalAddress
Zero or one value of type iodef:MLString. The format SHALL be as
documented in Sections 2.23 of [RFC4519], which defines a postal
address as a free-form multi-line string separated by the "$"
character.
5.1.3. PayeeAmount
Zero or one value of type thraud:AmountType. See Section 5.5.
5.2. FraudEventTransferType Class
The FraudEventTransferType class is used to report the payee
instructions for a fraudulent funds transfer or fraudulent funds
transfer attempt. Fraudsters sometimes use the same payee
instructions (including the amount) for multiple fraudulent
funds transfer attempts. By reporting the funds transfer
instructions used in the fraud, other organizations may be able
to detect similar fraudulent funds transfer attempts to the same
payee.
The structure of the FraudEventTransferType class SHALL be as
shown in Figure 8.
M'RAIHI Expires - January 2009 [Page 9]
Sharing Transaction Fraud Data July 2008
+--------------+
| FraudEvent- |
| TransferType |
+--------------+
| |<>--{0..1}--[ BankID ]
| |<>--{0..1}--[ AccountID ]
| |<>--{0..1}--[ AccountType ]
| |<>--{0..1}--[ TransferAmount ]
+--------------+
Figure 8. The FraudEventTransferType class
The contents of the FraudEventTransferType class are described
below. At least one component MUST be present.
5.2.1. BankID
Zero or one value of type thraud:BankIDType. The structure of
the BankIDType class SHALL be as shown in Figure 9. The contents
SHALL be of type xs:string. The namespace attribute SHALL be of
type xs:anyURI and SHALL identify the numbering system used to
identify the bank or account.
+-------------------+
| BankIDType |
+-------------------+
| STRING |
| |
| STRING namespace |
+-------------------+
Figure 9. The BankIDType class
A list of registered namespace identifiers is maintained at:
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm
The following namespace attribute values and their semantics are
registered.
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#american_bankers_association
One of the nine-digit Routing Numbers registered to the
financial organization that holds the account, as administered
by The American Bankers Association.
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#canadian_payments_association
M'RAIHI Expires - January 2009 [Page 10]
Sharing Transaction Fraud Data July 2008
The three digit Institution Number registered to the financial
organization that holds the account, as administered by The
Canadian Payments Association.
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#iso13616_1_2007
The corresponding AccountId represents the ISO 13616
International Bank Account Number in the 'electronic form' (i.e.
containing no spaces) that is assigned to the account, as
administered by the Society for Worldwide Interbank Financial
Telecommunication (SWIFT). The corresponding BankId xs:string
value SHOULD be set to the null string. Receiving organizations
SHOULD ignore the corresponding BankId value.
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#iso9362_1994
The eight character Bank Identifier Code registered to the
financial organization that holds the account, as administered
by SWIFT.
Other namespace values MUST be agreed between participants.
Requests to register new values SHOULD be made at:
http://www.openauthentication.org/thraud/form/bank-id-
namespace
Note that a single organization may be identified by more than
one value for any one or more of these namespaces. So, receiving
organizations SHOULD take this into account in their matching
procedure.
5.2.2. AccountID
Zero or one value of type xs:string. The destination primary
account number, as administered by the financial organization
identified in the BankId element. In the case where the BankId
namespace attribute value is 'iso13616_1_2007', this element
SHALL contain the International Bank Account Number in the
'electronic form' (i.e. containing no spaces) that is assigned
to the account. In all other cases, the element SHALL contain
only the account number, as administered by the financial
organization that holds the account. The reporting organization
SHALL remove all prefixes that identify the country, bank or
branch.
5.2.3. AccountType
Zero or one value of type thraud:AccountTypeType. See section
5.6.
M'RAIHI Expires - January 2009 [Page 11]
Sharing Transaction Fraud Data July 2008
5.2.4. TransferAmount
Zero or one value of type thraud:AmountType. See Section 5.5.
5.3. FraudEventIdentityType Class
The FraudEventIdentityType class is used to report a fraudulent
impersonation or fraudulent impersonation attempt. By reporting
the impersonation event, other potential victims may be able to
detect similar fraudulent impersonation attempts.
The structure of the FraudEventIdentityType class SHALL be as
shown in Figure 10.
+--------------+
| FraudEvent- |
| IdentityType |
+--------------+
| |<>--{1..*}--[ IdentityComponent ]
+--------------+
Figure 10. The FraudEventIdentityType class
The contents of the FraudEventIdentityType class are described
below.
5.3.1. IdentityComponent
One or more values of type iodef:ExtensionType. This
specification defines two extensions: EmailAddress and UserID.
5.3.1.1. EmailAddress
In reporting an identity fraud event, the reporting institution
MAY include the victim's email address. This SHALL be achieved
by placing an object of type iodef:Email in the
IdentityComponent object. It SHALL contain the email address of
the intended fraud victim.
The IdentityComponent.dtype attribute SHALL be set to the value
"string".
The IdentityComponent.meaning attribute SHALL be set to the
value "victim email address".
5.3.1.2. UserID
In reporting an identity fraud event, the reporting institution
MAY include the victim's user id. This SHALL be achieved by
placing an object of type iodef:ExtensionType in the
IdentityComponent object. The data type of the extension
M'RAIHI Expires - January 2009 [Page 12]
Sharing Transaction Fraud Data July 2008
contents SHALL be xs:string. It SHALL contain the user id of the
intended fraud victim.
The IdentityComponent.type attribute SHALL be set to the value
"string".
The IdentityComponent.meaning attribute SHALL be set to the
value "victim user id".
5.4. FraudEventOtherType Class
The FraudEventOtherType class SHALL be used to report fraudulent
events other than those detailed above, such as new event types
that may emerge at some time in the future. This class enables
such events to be reported, using this specification, even
though the specific characteristics of such events have not yet
been formally identified. By reporting the details of these
unspecified event types, other institutions may be able to
detect similar fraudulent activity.
The structure of the FraudEventOtherType class SHALL be as shown
in Figure 11.
+-------------+
| FraudEvent- |
| OtherType |
+-------------+
| |<>----------[ OtherEventType ]
| |<>--{0..1}--[ PayeeName ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..1}--[ BankID ]
| |<>--{0..1}--[ AccountID ]
| |<>--{0..1}--[ AccountType ]
| |<>--{0..1}--[ PayeeAmount ]
| |<>--{0..1}--[ OtherEventDescription ]
+-------------+
Figure 11. The FraudEventOtherType class
Many of the components of the FraudEventOtherType class are also
components of the FraudEventPaymentType or
FraudEventTransferType classes. Their use in the
FraudEventOtherType class is identical to their use in those
classes. Therefore, their descriptions are not duplicated here.
Only components that are unique to the FraudEventOtherType class
are described below.
5.4.1. OtherEventType
One value of type xs:anyURI. A name that classifies the event.
M'RAIHI Expires - January 2009 [Page 13]
Sharing Transaction Fraud Data July 2008
A list of registered other event type identifiers is maintained
at:
http://www.openauthentication.org/thraud/resources/other-
event-type
Requests to register new values SHOULD be made at:
http://www.openauthentication.org/thraud/form/other-event-
type
5.4.2. OtherEventDescription
Zero or one values of type iodef:MLString. A free-form textual
description of the event.
5.5. AmountType Class
The AmountType class SHALL be as shown in Figure 12. It SHALL be
used to report the amount of a payment or transfer fraud.
+------------------+
| AmountType |
+------------------+
| DECIMAL |
| |
| STRING currency |
+------------------+
Figure 12. The AmountType Class
The contents of the AmountType class are described below.
5.5.1. Class Contents
REQUIRED DECIMAL. The amount of the payment or transfer.
5.5.2. Currency
REQUIRED STRING. The three letter currency code [ISO4217].
5.6. AccountTypeType Class
The AccountTypeType class SHALL be as shown in Figure 13. It
SHALL be used to report the type of the destination account.
M'RAIHI Expires - January 2009 [Page 14]
Sharing Transaction Fraud Data July 2008
+-----------------+
| AccountTypeType |
+-----------------+
| STRING |
| |
| STRING lang |
+-----------------+
Figure 13. The AccountTypeType class
Receiving organizations MUST be capable of processing contents
containing spelling variations.
6. IODEF Profile for an Activity Thraud Report
This section describes the profile of the IODEF Incident class
for a compliant Activity Thraud Report.
6.1. Mandatory components
A Thraud Report SHALL conform to the data model specified for an
IODEF-Document in [RFC5070]. The following components of that
data model, while optional in IODEF, are REQUIRED in a
conformant Thraud Report.
Receiving organizations MAY reject documents that do not contain
all these components. Therefore, reporting organizations MUST
populate them all.
Except where noted, these components SHALL be interpreted as
described in [RFC5070].
Incident.Contact.ContactName - The name of the reporting
organization. In case the reporting organization acts as a
consolidator of reports from other organizations, elements of
this class SHALL contain the name of the consolidator.
Incident.Contact.Email - An email address at which the reporting
organization may be contacted.
Incident.Contact.Telephone
Incident.EventData
Incident.EventData.AdditionalData - SHALL contain exactly one
Thraud Record.
6.2. Recommended Components
Receiving organizations SHOULD be capable of processing the
following components. However, they MUST NOT reject documents
either because they are present or absent.
M'RAIHI Expires - January 2009 [Page 15]
Sharing Transaction Fraud Data July 2008
If available, reporting organizations SHOULD include these
components in Thraud Reports. Except where noted, these
components SHALL be interpreted as described in [RFC5070].
Incident.Contact.Contact
Incident.Contact.Contact.ContactName - The name of the reporting
fraud analyst.
Incident.Contact.Contact.Email - The email address of the
reporting fraud analyst.
Incident.Contact.Contact.Telephone - The telephone number of the
reporting fraud analyst.
Incident.EventData.Method
Incident.EventData.Method.Description
Incident.Assessment.Confidence
Incident.Assessment.Impact
Incident.Assessment.MonetaryImpact
Incident.EventData.DetectTime
Incident.EventData.StartTime
Incident.EventData.EndTime
Incident.EventData.Flow
Incident.EventData.Flow.System
Incident.EventData.Flow.System.Service
Incident.EventData.Flow.System.Node.NodeName
Incident.EventData.Flow.System.Node.Address
6.3. Deprecated Components
This profile provides no guidance to receiving organizations on
the proper processing of the following components. Therefore,
the reporting organization has no assurance that the receiving
organization will handle them in an appropriate manner and
SHOULD NOT include them in a Thraud Report. However, receiving
organizations MUST NOT reject reports that do contain these
components.
Incident.DetectTime
Incident.AlternativeID
Incident.RelatedActivity
Incident.StartTime
Incident.EndTime
Incident.ReportTime
Incident.Description
Incident.Method
Incident.History
Incident.AdditionalData
Incident.ext-purpose
Incident.IncidentID.instance
Incident.Contact.Description
Incident.Contact.RegistyHandle
Incident.Contact.PostalAddress
Incident.Contact.Fax
Incident.Contact.TimeZone
M'RAIHI Expires - January 2009 [Page 16]
Sharing Transaction Fraud Data July 2008
Incident.Contact.AdditionalData
Incident.Contact.Contact.Description
Incident.Contact.Contact.RegistyHandle
Incident.Contact.Contact.PostalAddress
Incident.Contact.Contact.Fax
Incident.Contact.Contact.TimeZone
Incident.Contact.Contact.AdditionalData
Incident.Contact.ext-role
Incident.Contact.ext-type
Incident.Contact.Contact.ext-role
Incident.Contact.Contact.ext-type
Incident.EventData.Method.Reference
Incident.EventData.Method.Reference.Description
Incident.EventData.Method.AdditionalData
Incident.EventData.Method.Reference.URL
Incident.Assessment.TimeImpact
Incident.Assessment.AdditionalData
Incident.Assessment.Impact.type
Incident.EventData.Description
Incident.EventData.Contact
Incident.EventData.Assessment
Incident.EventData.Expectation
Incident.EventData.Record
Incident.EventData.EventData
Incident.EventData.Flow.System.OperatingSystem
Incident.EventData.Flow.System.Counter
Incident.EventData.Flow.System.Description
Incident.EventData.Flow.System.AdditionalData
Incident.EventData.Flow.System.ext-category
Incident.EventData.Flow.System.Node.Location
Incident.EventData.Flow.System.Node.DateTime
Incident.EventData.Flow.System.Node.NodeRole
Incident.EventData.Flow.System.Node.Counter
Incident.EventData.Flow.System.Node.Address.ext-category
Incident.EventData.Flow.System.Service.ProtoType
Incident.EventData.Flow.System.Service.ProtoCode
Incident.EventData.Flow.System.Service.ProtoField
Incident.EventData.Flow.System.Service.Application
7. IODEF profile for a Signature Thraud Report
A Signature Thraud Report SHALL convey information about the
behavior associated with fraudulent events, rather than
reporting the details of the specific events themselves.
Sharing Signature Thraud Reports helps receiving organizations
to detect suspicious behavior in their own systems.
A Signature Thraud Report SHALL conform to the profile described
in section 6.
M'RAIHI Expires - January 2009 [Page 17]
Sharing Transaction Fraud Data July 2008
8. IODEF Additional Attribute Values
Additional IODEF attribute standard values are defined here.
8.1. Purpose Attribute
The following additional values are defined for the
Incident.purpose attribute.
Add - The enclosed Thraud Record values SHOULD be added to the
corpus by the receiving organization.
Delete - The enclosed Thraud Record types SHOULD be deleted from
the corpus by the receiving organization.
Modify - The enclosed Thraud Record values SHOULD replace the
corresponding values in the corpus. Where no corresponding types
currently exist in the corpus, the enclosed values SHOULD be
added to the corpus by the receiving organization.
9. Security considerations
This document describes a document format for exchanging
information about successful or attempted transaction and
authentication fraud incidents. The information is intended to
be used to improve the effectiveness of participants' fraud
detection and prevention programs. The effectiveness of such
programs depends critically on the accuracy, reliability,
confidentiality and timeliness of both the information and the
participants in its exchange. Threats to accuracy, reliability
and confidentiality include (but are not limited to) those
described here.
Fraudsters may attempt to introduce reports that delete or
modify incident information in the corpus. Therefore, origin
authentication MUST be employed. Human review SHOULD be
performed prior to implementing modifications to the corpus.
Fraudsters may attempt to interrupt or redirect submissions,
thereby preventing the sharing of intelligence concerning their
fraud strategies. Therefore, authenticated receipts SHOULD be
employed.
Fraudsters may attempt to impersonate legitimate submitters,
thereby poisoning their reputations, and rendering ineffective
their future submissions. Origin authentication MUST be used to
ensure that the sources of reports are properly identified.
Fraudsters that can view incident reports may adapt their fraud
strategies to avoid detection. Therefore, reports MUST be
protected by confidentiality services including transport
encryption and access control.
M'RAIHI Expires - January 2009 [Page 18]
Sharing Transaction Fraud Data July 2008
In order to prevent inadvertent disclosure of incident data,
incident reports SHOULD be encrypted while in storage.
The submitter of an incident report may incorrectly identify
legitimate activity as a fraud incident. This may lead to
denial of service by a receiving organization that relies on the
report or information derived from the report. Receiving
organizations SHOULD operate a reputation service, in which the
reliability of the information from particular sources is
assessed and tracked and subsequent reports are weighted
accordingly. The source of reports MUST be authenticated.
Receiving organizations SHOULD use reports to step-up
authentication assurance, rather than simply denying service.
A receiving organization may misuse a Thraud report to deny
service, resulting in a loss for a legitimate user. If such a
user were to learn the identity of the source of the information
that led to the denial of service, then that source may become
implicated in any resulting claim for compensation. This, in
turn, may discourage reporting organizations from participating
in intelligence sharing. Therefore, original sources SHOULD NOT
be identified in consolidated reports.
Any origin authentication and data integrity mechanism that is
acceptable to both parties MAY be used.
Any transport confidentiality mechanism that is acceptable to
both parties MAY be used.
This specification does not include a data compression
technique. Therefore, it does not introduce any denial of
service vulnerabilities related to decompression.
10. IANA considerations
This specification proposes the registration of two identifiers:
- The media sub-type name 'thraud+xml' in the standard
registration tree.
- The xml namespace identifier - urn:ietf:params:xml:ns:thraud-
1.0.
10.1. Media sub-type
Type name: application
Subtype name: thraud+xml
Required parameters: none.
M'RAIHI Expires - January 2009 [Page 19]
Sharing Transaction Fraud Data July 2008
Optional parameters: same as the charset parameter of
application/xml as specified in [RFC3023].
Encoding considerations: same as encoding considerations of
application/xml as specified in [RFC3023].
Security considerations: this registration has all of the
security considerations described in [RFC3023] in addition to
those in section 9, above.
Interoperability considerations: this registration has all of
the interoperability considerations described in [RFC3023].
Published specification: the media type data format is defined
in this specification.
Applications that use this media type: transaction and
authentication fraud analysis and reporting applications and
risk-based transaction and authentication evaluation
applications.
Additional information
Magic number(s): none
File extension: .tfi
Macintosh file type codes: none
Person and email address to contact for further information: D
M'Raihi, dmraihi@verisign.com
Intended usage - LIMITED USAGE
Restrictions on usage: thraud media are intended for no usage
other than the exchange of fraud intelligence data.
Author: D M'Raihi
Change controller: D M'Raihi
10.2. XML namespace
IANA is requested to register the xml namespace identifier:
urn:ietf:params:xml:ns:thraud-1.0.
11. Conclusion
This specification introduces transaction fraud (Thraud)
reporting document structure that enable the sharing of fraud
data. Based on the IODEF-Document format, the proposed extension
facilitates interoperability to increase the security of online
applications.
M'RAIHI Expires - January 2009 [Page 20]
Sharing Transaction Fraud Data July 2008
12. References
12.1. Normative
[ISO13616-1:2007] Financial services - International bank
account number (IBAN) -- Part 1: Structure of the IBAN.
[ISO4217] International Organization for Standardization,
"International Standard: Codes for the representation of
currencies and funds, ISO 4217:2001", August 2001.
[ISO9362:1994] Banking - Banking telecommunication messages
- Bank identifier codes.
[RFC2119] S. Bradner, "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] M. Murata, "XML Media Types", RFC 3023, Jan 2001.
[RFC4519] Sciberras, A., "Schema for User Applications",
RFC 4519, June 2006.
[RFC5070] R. Danyliw, The Incident Object Description
Exchange Format, RFC 5070, December 2007, available at:
http://www.rfc-editor.org/rfc/rfc5070.txt
12.2. Informative
[UML] ISO/IEC 19501:2005 Information technology - Open
Distributed Processing - Unified Modeling Language (UML) Version
1.4.2.
13. Authors' Addresses
Primary point of contact (for sending comments and
question):
David M'Raihi
VeriSign, Inc.
685 E. Middlefield Road
Mountain View Phone: 1-650-426-3832
CA 94043 USA Email: dmraihi@verisign.com
Other Authors' contact information:
Sharon Boeyen
Entrust Inc.
1000 Innovation Drive Phone: 1-613-270-3181
Ottawa, ON, K2K 3E7 Email: sharon.boeyen@entrust.com
Michael Grandcolas
Grandcolas Consulting LLC.
M'RAIHI Expires - January 2009 [Page 21]
Sharing Transaction Fraud Data July 2008
247 Ocean Park Blvd. Phone: 1-310-399-1747
Santa Monica, Ca 90405 Email: michael.grandcolas@hotmail.com
Siddharth Bajaj
VeriSign, Inc.
487 E. Middlefield Road
Mountain View Phone: 1-650-426-3458
CA 94043 USA Email: sbajaj@verisign.com
14. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
15. Intellectual Property
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
M'RAIHI Expires - January 2009 [Page 22]
Sharing Transaction Fraud Data July 2008
Appendix A. Thraud Record XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:thraud-1.0"
xmlns:thraud="urn:ietf:params:xml:ns:thraud-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="
http://www.cert.org/ietf/inch/schema/rfc5070.xsd"/>
<xs:element name="FraudEventPayment"
type="thraud:FraudEventPaymentType"/>
<xs:element name="FraudEventTransfer"
type="thraud:FraudEventTransferType"/>
<xs:element name="FraudEventIdentity"
type="thraud:FraudEventIdentityType"/>
<xs:element name="FraudEventOther"
type="thraud:FraudEventOtherType"/>
<xs:complexType name="FraudEventPaymentType">
<xs:sequence>
<xs:element name="PayeeName" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PostalAddress" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PayeeAmount" type="thraud:AmountType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventTransferType">
<xs:sequence>
<xs:element name="BankID" type="thraud:BankIDType"
minOccurs="0"/>
<xs:element name="AccountID" type="xs:string" minOccurs="0"/>
<xs:element name="AccountType" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="TransferAmount" type="thraud:AmountType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventIdentityType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="IdentityComponent"
type="iodef:ExtensionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventOtherType">
<xs:sequence>
<xs:element name="OtherEventType" type="xs:anyURI"/>
<xs:element name="PayeeName" type="iodef:MLStringType"
minOccurs="0"/>
M'RAIHI Expires - January 2009 [Page 23]
Sharing Transaction Fraud Data July 2008
<xs:element name="PostalAddress" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="BankID" type="thraud:BankIDType"
minOccurs="0"/>
<xs:element name="AccountID" type="xs:string" minOccurs="0"/>
<xs:element name="AccountType" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PayeeAmount" type="thraud:AmountType"
minOccurs="0"/>
<xs:element name="OtherEventDescription"
type="iodef:MLStringType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AmountType">
<xs:simpleContent>
<xs:extension base="xs:decimal">
<xs:attribute name="currency" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="BankIDType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="namespace" type="xs:anyURI"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="UserId" type="xs:string"/>
</xs:schema>
Appendix B. Example of a Thraud Report
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-1.0
http://www.cert.org/ietf/inch/schema/rfc5070.xsd" lang="en">
<Incident purpose="reporting">
<IncidentID name="fraud.openauthentication.org">908711
</IncidentID>
<ReportTime>2006-10-12T00:00:00-07:00</ReportTime>
<Assessment>
<Impact severity="high" completion="failed"/>
<Confidence rating="high"/>
</Assessment>
<Contact type="organization" role="creator">
<ContactName>Example Corp.</ContactName>
<Email>contact@example.com</Email>
<Telephone>+1.972.555.0150</Telephone>
</Contact>
<EventData>
M'RAIHI Expires - January 2009 [Page 24]
Sharing Transaction Fraud Data July 2008
<DetectTime>2006-10-12T07:42:21-08:00</DetectTime>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.53</Address>
</Node>
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<AdditionalData dtype="xml">
<FraudEventTransfer xmlns="urn:ietf:params:xml:ns:thraud-
1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:thraud-1.0
http://www.openauthentication.org/thraud/Schema1-0.xsd">
<BankID
namespace="http://www.openauthentication.org/thraud/resources/ba
nk-id-
namespace.htm#american_bankers_association">123456789</BankID>
<AccountID>3456789</AccountID>
<AccountType lang="en">saving</AccountType>
<TransferAmount currency="USD">10000</TransferAmount>
</FraudEventTransfer>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
M'RAIHI Expires - January 2009 [Page 25]
