Docstoc

Business Idea Submission Form - NACHA

Document Sample
Business Idea Submission Form - NACHA Powered By Docstoc
					                                                                 NACHA Business Ideas Submission Form
                                                                                 9/22/2010 3:17:17 PM




                           Business Idea Submission Form
SUBMIT TO:             Kelley Shay, Executive Assistant
                       NACHA – The Electronic Payments Association
                       E-mail: kshay@nacha.org
                       Fax: 703-787-0996

ADMINISTRATIVE INFORMATION

1. Project Name: ACH Data Security and Authentication Framework

2. Date: August 20, 2010

3. Project Sponsor(s) (Name/Organization): The Internet Council and the Risk Management Advisory
   Group

   Fred Laing, President
   UMACHA
   7100 Northland Circle, Suite 407
   Brooklyn Park, MN 55428

4. NACHA Staff Contact:

   Susan Pandy, Senior Director, Internet & eCommerce
   703.561.3953/spandy@nacha.org

   Deborah Shaw, AAP, CTP, Managing Director, Network Enforcement & Risk Management
   703.561.3919/dshaw@nacha.org

   Jeanette Fox, AAP, Senior Director, Risk Investigations and Services
   703.561.3914/jfox@nacha.org

5. Potential Leaders/Participants:

   Fred Laing, President, UMACHA
   Steve Helgen, US Bank
   Chris Alexander, Federal Reserve
   Patricia Campbell, Christian Financial FCU
   Susan Doyle, Commerce Bank
   Brad Metzler, TD America
   Miriam Hanlon, Hudson Valley Bank
   Steve Stradal or Michael Volk, US Bank
   Devon Marsh, Wells Fargo


9/22/2010 3:17:17 PM                                                                               1
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                                         NACHA Business Ideas Submission Form
                                                                                                         9/22/2010 3:17:17 PM

6. PROJECT INFORMATION

7. Please indicate the type of project:

                     NACHA membership benefit or group
                     ACH Network application, enhancement, or pilot;
                     ACH Network risk management service
                     Regulatory compliance
                     Education, training or implementation resource
                     NACHA administrative or IT service
          X          Other: Risk management

8. What is the idea, and what issue or problem would be addressed?

The Internet Council (TIC) and the Risk Management Advisory Group (RMAG) are recommending a
comprehensive plan to address ACH Network data security and authentication that includes: (1) a set of
rules proposals, (2) a plan to revise the Board’s Interim Policy on ACH Data Breach Notification, and
(3) NACHA Operating Guidelines recommendations.

ISSUE BEING ADDRESSED

This proposal will create a uniform approach to data security in the ACH Network through the
development of a standardized set of rules requirements, policies, and guidelines that encompass adequate
data security1 and risk requirements to minimize the occurrence of losses and the effect on reputation risk
from data breaches, corporate account takeovers, and cyber attacks.

This proposal provides a framework for ACH data security that encompasses all of the relevant
requirements to protect the lifecycle of sensitive ACH information from beginning to end. Currently, the
NACHA Operating Rules (Rules) contain a number of data security and authentication requirements that
are generally based on individual Standard Entry Class (SEC) Codes and/or triggering events.

The marketplace has changed since security requirements were included in the Rules several years ago in
response to the growth of ecommerce transactions, the rise of the Internet and advanced technologies.
Security requirements are no longer directly characterized solely by whether transactions occur in an
Internet versus a non-Internet environment, but rather by how they were authorized and the vast amount
of data that may be transmitted and stored electronically. The operational, business, risk management, and
privacy aspects of data security are not only a concern for companies transacting payments on the
Internet, but for all companies that store, process and transmit financial information electronically.

Today’s electronic payments environment is vulnerable to the increasing threat from data breaches and
other unscrupulous activity such as account hijacking, viruses, network intrusions, employee fraud, email
fraud, and hacking. Account takeover is a significant problem for businesses and for financial institutions
resulting in financial losses in which organized crime rings take over accounts and initiate unauthorized
wire transfers and ACH credits. These threats demand that financial institutions and businesses become
ever more vigilant in their data protection and security efforts, lest they bear the burden of damaged
reputations, lost customers and the costs of litigation and remediation.



1
  Adequate Security is defined as “security commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or
unauthorized access to or modification of information” (p. 6) [OMB Circular A-130, Appendix III] in NIST’s Federal Information Processing
Standards (FIPS) Publication 200 – Minimum Security Requirements for Federal Information and Information Systems.
9/22/2010 3:17:17 PM                                                                                                                        2
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM

A uniform data security framework will jointly benefit the ACH Network and its stakeholders against
rising security challenges. It is also important for the ACH Network that ACH participants are protecting
ACH data with effective security in place to manage risk. The reputation risk to the ACH Network is of
paramount importance, particularly given the increased level of sophistication that is now prevalent in
fraudulent schemes and frequently reported in the media.

NACHA has the opportunity to take a proactive stance towards Network security by implementing a
framework that will ensure that the ACH Network remains high quality despite increasingly sophisticated
threats. This proposal is meant to ensure that there are basic data security obligations for Network
participants to protect the ACH data within their purview. It is likely that many, if not most, financial
institutions and other ACH participants already have these provisions in place, but these rules will
reiterate these obligations and ensure that they exist Network-wide. This proposal is not intended to move
the ACH Network towards incorporating PCI standards. It is intended to ensure that there are security
warranties and obligations related to ACH data in the Rules versus no such warranties and obligations.

SET OF RULES PROPOSALS

These new rules would constitute a security framework for the ACH Network referred to as the “NACHA
Six Pillars of Data Security and Authentication (The ‘NACHA Six’),” that would encompass uniform
requirements for the protection of sensitive ACH data, the verification of Receivers’ identities by
Originators, the assurance that ODFIs know their Originators and Third-Party Senders, the utilization of
access controls, the deployment of fraud management systems, and a data security assessment. These
rules provisions would apply, as appropriate, to ODFIs, RDFIs, Originators, Third-Party Service
Providers, and Third-Party Senders and would address all types of payments (e.g., all SEC Codes) in the
ACH Network, including transactions that are corporate and consumer, check conversion and non-check
conversion, and physical and electronic. The rules recommendations are:

        1. Protect Sensitive ACH Data: ODFIs, RDFIs, Originators, Third-Party Service Providers and
           Third-Party Senders must use commercially reasonable methods and procedures to protect all
           sensitive ACH data and banking information related to ACH entries for all SEC Codes. A
           definition of Sensitive ACH Data will be incorporated into the Rules.

                •   Sensitive ACH Data is defined as data related to ACH entries for the consumer or
                    business customer of an RDFI and includes: (1) the bank account number together
                    with the bank routing number, (2) the customer’s name together with the customer’s
                    Social Security Number, and (3) the customer’s authentication credentials.

                    This suggested definition is derived from: (1) the NACHA Interim Policy Statement
                    on ACH Data Breach Notification, (2) the Office of the Comptroller of the
                    Currency’s (OCC) 2005 Interagency Guidance on Response Programs for
                    Unauthorized Access to Customer Information and Customer Notice (OCC 2005-13),
                    The National Institute of Standards & Technology (NIST) Special Publication 800-
                    122 – Guide to Protecting the Confidentiality of Personally Identifiable Information
                    (PII), and (3) Section 501(b) of the Gramm-Leach-Bliley Act (GLBA) which
                    requires financial institutions to establish standards for protecting the security and
                    confidentiality of financial institution customers’ non-public personal information
                    (FIL-22-2001).




9/22/2010 3:17:17 PM                                                                                        3
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                     NACHA Business Ideas Submission Form
                                                                                     9/22/2010 3:17:17 PM

        2. Verify the Receiver’s Identity: Require ODFIs to warrant that Originators have made a
           commercially reasonable effort to verify the identity of the Receiver for all SEC Codes2.
           ODFIs, that have relationships with Third-Party Senders, will warrant that their Third-Party
           Senders have assured that Originators are verifying the identity of the Receiver.

        3. Identify Third-Party Senders and Originators: Require ODFIs to warrant that they have
           utilized a commercially reasonable method to verify the identity of the Originator or Third-
           Party Sender of any ACH entry. This requirement will apply for origination of ACH Entries
           related to all SEC Codes.

        4. Deploy Commercially Reasonable Access Controls: ODFIs, Originators, and Third-Party
           Senders must have commercially reasonable Access Controls in place to protect ACH data
           and banking information related to ACH entries3.

                •    Access Controls are defined as administrative, physical and technical controls for
                     systems that process ACH data that permit an authority to control access to areas and
                     resources in a given physical facility or computer-based information.

                     This suggested definition is derived from: (1) the Payment Card Industry Data
                     Security Standard (PCI DSS) requirement numbers 7, 8, and 9, (2) the STAR
                     Network rules, (3) the National Institute of Standards & Technology (NIST) Federal
                     Information Processing Standards (FIPS) Publication No. 200 - Minimum Security
                     Requirements for Federal Information and Information Systems, (4) the 2010 Federal
                     Financial Institutions Examination Council (FFIEC) Retail Payment Systems
                     Information Security Handbook, and (5) the International Organization for
                     Standardization (ISO) 27001/27002.

        5. Deploy Fraud Management Systems: ODFIs, Originators, and Third-Party Senders must
           deploy commercially reasonable Fraud Management Systems for all SEC Codes related to
           ACH entries. Define Fraud Management Systems in the Rules. This term would replace
           “fraudulent transaction detection system” currently used with the WEB transaction.

                •    A Fraud Management System is defined as a set of policies, procedures,
                     communication standards, systems and behavior expectations that provide adequate
                     controls needed to minimize the potential for fraudulent activity related to ACH
                     entries.

                     This suggested definition is derived from: (1) the Federal Trade Commission (FTC)’s
                     definition of “identity theft” which is used to refer to fraud perpetrated by (a)
                     obtaining access to and illegally using a consumer’s existing financial information,
                     such as a credit card number or bank account number, or (b) illicitly obtaining
                     identity information about a consumer to open new financial accounts using the
                     consumer’s name as outlined in its 2006 Identity Theft Survey Report, (2)
                     Cendrowski Corporate Advisors (CCA) The Handbook of Fraud Deterrence (Wiley,
                     2006), (3) the Association of Fraud Examiners (ACFE; www.acfe.org), and (4) the
                     Committee of Sponsoring Organizations of the Treadway Commission’s(COSO)



2
 Further evaluation is necessary to see if this can apply in practice to electronic check applications.
3
 Consideration will be given to exempting entries where the Originator is a consumer.
9/22/2010 3:17:17 PM                                                                                      4
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

                     Enterprise Risk Management (ERM) framework as it applies to an assessment of
                     fraud risk and the COSO Internal Controls framework.

        6. Assessment for Data Security: ODFIs, Originators, and Third-Party Senders must conduct an
           annual data security assessment for origination related to all SEC Codes.

BOARD POLICY STATEMENT REVISIONS

In addition, the Interim Policy on ACH Data Breach Notification will be revised and proposed as a long-
term Policy to reflect elements of this rules proposal and lessons learned since the Interim Policy was
implemented. This policy statement will be finalized in 1Q – 2Q 2011 and brought to the Board for
review and approval.

GUIDELINES

NACHA Operating Guidelines recommendations will be finalized in 2Q – 3Q 2011 to support the rules
proposals. The Guidelines will provide additional points of reference to ACH participants to facilitate
compliance with rules and best practices.

9. What are the objectives of initiative?

The objectives of this initiative are:

•   Develop a uniform data security framework for the ACH Network that leverages existing industry
    data security programs and standards that will provide clarity to ACH Network participants about
    compliance with data security requirements in the ACH Network; thereby improving compliance with
    the Rules.
•   Define sensitive ACH data for both corporate and consumer transactions.
•   Ensure the integrity of the Network and reduce vulnerability.
•   Promote lifecycle management of ACH information and information security governance.

10. What are the expected deliverables?

The deliverables for this proposal include a rules proposal, a revised policy statement and relevant
guidelines to support the rules proposal.

DELIVERABLES FOR RULES PROPOSAL
• A business case for a rules proposal for the NACHA Six Pillars of Data Security and Authentication.
• A Request For Information on the rules proposal for the NACHA Six Pillars of Data Security and
   Authentication (4Q 2010).
• Evaluate feedback from the RFI (1Q 2011)
• Request For Comment on the rules proposal for the NACHA Six Pillars of Data Security and
   Authentication (2Q 2011).
• Evaluate feedback from the RFC (2Q 2011).
• Issuance of a ballot based on feedback from the Request For Comment and further discussion (3Q
   2011).
• Proposed Implementation Date for rules proposal of March 2012.

DELIVERABLES FOR POLICY STATEMENTS
• Finalize revised NACHA Policy Statement on Data Breach Notification (1Q – 2Q 2011)
9/22/2010 3:17:17 PM                                                                                      5
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

•   Board review and approval to replace current interim policy with revised long-term policy (2Q – 3Q
    2011)

DELIVERABLES FOR BEST PRACTICES & GUIDELINES
•     Finalize the NACHA Operating Guidelines for the new rules (2Q – 3Q 2011).

BUSINESS CASE INFORMATION

11. What are the anticipated benefits, by party?

    Originators: Originators will benefit from a uniform set of minimum data security requirements for
    all SEC Codes. They will be able to design their processes to be the same no matter what applications
    they are originating. Originators will benefit by this focus on a comprehensive approach to data
    security helping to ensure that the ACH Network remains high quality and low risk. Originators that
    elect not to retain sensitive ACH data longer than required by the Rules would benefit from cost
    savings by eliminating the costs associated with secure storage for an extended period of time.
    Originators should realize that the costs to implement this proposal by implementing a data security
    program to comply with this rules set will be less expensive than alternative in terms of possible
    losses, problems or requirements that remain inconsistent across ACH applications. Originators will
    benefit from an updated Board Policy Statement on data breach notification that reflects current
    practices and lessons learned.

    ODFIs: ODFIs will benefit from a uniform set of minimum data security requirements for all SEC
    Codes. ODFIs will benefit from data security terms being more clearly defined as they apply to the
    ACH Network and by the guidance that will be provided on commercially reasonable methods of
    complying with the various data security requirements. ODFIs will benefit by this focus on a
    comprehensive approach to data security helping to ensure that the ACH Network remains high
    quality and low risk. ODFIs will benefit from an updated Board Policy Statement on data breach
    notification that reflects current practices and lessons learned.

    RDFIs: RDFIs will benefit from the increased focus and requirements related to data security. RDFIs
    will know that there is a uniform set of minimum data security requirements that ODFIs and
    Originators are applying to the RDFI’s customer’s data and transactions. In addition, RDFIs will
    benefit from more uniform requirements and guidelines related to accepting, storing, providing and
    destroying data included in ACH transactions. RDFIs will benefit from an updated Board Policy
    Statement on data breach notification that reflects current practices and lessons learned.

    NACHA: NACHA will benefit from this rules set because it will ensure that there is a comprehensive
    and uniform focus on data security while allowing for the flexibility necessary to accommodate
    changes in technology. The ACH Network would further benefit because this uniform set of standards
    will apply to every ACH transaction and to all parties resulting in a payment system that continues to
    be safe and secure, particularly in light of continued growth trends. NACHA will benefit also by an
    updated Board Policy Statement on data breach notification that reflect current practices and lessons
    learned. Of particular importance is updating and making the Board Policy Statement on Data Breach
    Notification a long-term versus an interim policy.

    Third-Party Service Providers: Third-Party Service Providers including Third-Party Senders will
    benefit from a uniform set of minimum data security requirements for all SEC Codes. Third-Parties
    involved in the origination of ACH transactions will be able to design their data security processes to
    be the same no matter what applications they are involved in originating. This is also true for Third-
    Parties that assist RDFIs in the receipt, storage, provision, or destruction of ACH data. Third-Parties
9/22/2010 3:17:17 PM                                                                                          6
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM

   will benefit by this focus on a comprehensive approach to data security helping to ensure that the
   ACH Network remains high quality and low risk. Third-Parties will benefit from an updated Board
   Policy Statement on data breach notification that reflects current practices and lessons learned.

   Receiver: Receivers will benefit by the ACH Network remaining high quality and low risk despite
   increasingly sophisticated cybercriminals. As these rules provisions will apply to corporate as well as
   consumer transactions, corporate Receivers will benefit by the added focus on data security related to
   these transactions.

   Operators: ACH Operators will benefit from this rule set as it will ensure a comprehensive and
   uniform focus on data security that will benefit the quality of ACH transactions and the reputation of
   the Network.

   RPAs: A uniform set of requirements creates an education and communications opportunity for
   RPAs.

   What are the anticipated costs?

   Originators: The costs for Originators will depend on how comprehensive their data security
   processes are currently. Originators will need to compare the new rules set, and related guidelines,
   against their current practices to determine what improvements are needed. This includes considering
   commercially reasonable procedures to handle sensitive ACH data, verifying Receivers’ identities,
   deploying Access Controls and deploying Fraud Management Systems. Originators will also incur
   costs to conduct an annual security assessment if they are not already conducting one.

   ODFIs: The costs for ODFIs will depend on how comprehensive their current data security processes
   are within their institution and in relation to their Originators and Third-Party Senders. ODFIs will
   need to consider what changes will need to be made to their contracts with Originators and Third-
   Party Senders to ensure that the warranties related to data security are addressed. ODFIs will need to
   determine how best to confirm that their Originators and Third-Party Senders are in compliance with
   the requirements related to protecting sensitive ACH data, verifying the Receiver’s identity,
   deploying Access Controls, deploying Fraud Management Systems, and conducting an annual data
   security assessment. ODFIs, themselves, will need to incur costs, if additional processes and
   procedures are necessary, to comply with the requirements to protect sensitive data, verify the identity
   of Originators and Third-Party Senders, deploy Access Controls, deploy a Fraud Management
   System, and conduct a data security assessment.

   RDFIs: RDFIs may incur costs related to ensuring that sensitive ACH data is properly handled,
   stored and destroyed.

   NACHA: NACHA will incur costs in its risk, rules, and Internet Council area to develop and
   implement this rules proposal, guidelines and revised Board Policy Statement.

   Third-Party Service Providers: Third-Party Service Providers may incur costs to comply with these
   rules provisions in their roles of supporting either ACH origination or receipt. Their costs will depend
   on their role and their current practices, particularly related to protecting sensitive ACH data. Third-
   Party Senders will need to compare the new rules set, and related guidelines, against their current
   practices to determine what improvements are needed. This includes considering commercially
   reasonable procedures to handle sensitive ACH data, assuring that Originators are verifying
   Receivers’ identities, deploying Access Controls, deploying Fraud Management Systems, and
   conducting an annual security assessment if they are not already conducting one.
9/22/2010 3:17:17 PM                                                                                        7
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                       NACHA Business Ideas Submission Form
                                                                                       9/22/2010 3:17:17 PM


    Receiver: While this rule will not impose requirements on Corporate Receivers, they should consider
    changes to how they store and destroy sensitive data.

    Operators: Operators will not incur costs from these rules proposals.

12. What are any significant challenges?

The challenges to creating a comprehensive approach to data security and authentication in the ACH
Network includes the education to the marketplace, particularly to the smaller to medium-sized
Originators and ODFIs that are difficult to reach. Additionally many companies and financial institutions
lack the necessary data security professionals and may lack an understanding of the importance of data
security risk and compliance. In some instances, organizational networks may need to be reconfigured
which can be a major task if it was not configured appropriately in the first place. These rule changes may
also result in ODFIs needing to make revisions to their contracts with Originators and Third-Party
Senders.

13. What are the business risks of pursuing this initiative?

The risk to pursuing this initiative is that the proposed policies, rules and guidelines will not be sufficient
enough to enhance the security of the ACH Network. Another risk is the challenge of developing and
maintaining guidelines for commercially reasonable standards that change rapidly over time.

14. Are there alternatives to this idea?

Alternatives to this proposal include the following three options:

        1.       Maintain the status quo.

        2.       Piecemeal or application-specific approach.

        3.       Phased approach. A phased approach would introduce the new set of requirements
                 through a series of phases.

The first alternative would leave the ACH Network open to current and new fraud schemes. The second
alternative would apply data security requirements to different applications. This might result in
fraudsters shifting which application they use to avoid detection. In addition, the sophistication of
fraudsters shows that they can be successful with every medium. A phased approach would slow down
the adoption of rules that are needed sooner rather than later to address current problems. In addition,
either a piecemeal or phased approach would be less cost effective and time efficient than this
comprehensive proposal.

15. What are the risks/opportunity costs of not pursuing this initiative?

The absence of uniform data security requirements in the Rules creates a significant risk for the ACH
Network and its participants, including operational, fraud, and reputation risk. The protection of the
information that is electronically stored, transmitted, or processed via the ACH Network is critical to trust
in the Network and to the continued growth of ACH transaction volume.

As ACH volume grows and more consumer financial information is processed and stored, ACH Network
participants are more susceptible to data security breaches and incidents of fraud. ACH data that is stored,
9/22/2010 3:17:17 PM                                                                                              8
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                     NACHA Business Ideas Submission Form
                                                                                     9/22/2010 3:17:17 PM

processed, or transmitted electronically is vulnerable to compromise by network intrusions, account-
hijacking, hacking, or other fraudulent activities. This information may be used to initiate fraudulent
transactions and other identity-theft related crimes. Given the impact of this fraud on consumers,
companies, and the reputation of the ACH Network, it is critical that the Network establish a
comprehensive set of requirements related to data security.

If the Network does not move expeditiously, then it may become subject to regulation.

16. Are there reasons why the initiative should begin expeditiously (e.g., marketplace
    developments, level of priority, regulatory compliance, etc.)?

NACHA should move quickly to standardize data security and authentication requirements across ACH
applications and ACH participants to ensure stronger risk mitigation practices by financial institutions and
businesses. Financial institutions are already subject to many of these requirements by other payment
networks.

IMPLEMENTATION INFORMATION

17. What are the requirements to participate in this initiative?

An understanding of the Rules, the Electronic Funds Transfer Act (EFTA), Regulation E, generally
accepted data security compliance programs, auditing, and policies and procedures for organizational
information governance.

18. What level of effort would be required to participate?

Research, document creation, socialization of the proposal, revisions to the proposal based on feedback,
and rule approval and implementation would most likely take about 12 – 18 months with the team
dedicating 10 - 15 hours per month to the project.

19. What information, data, or additional resources would be required to pursue this initiative?

Additional information pertaining to the cost of data security compliance for various ACH Network
participants will be gathered to determine the cost impact to stakeholders. Costs will vary based on size
of business and financial institution and type of applications being processed.

20. Is the initiative dependent on any other initiative or deliverable being completed?

None identified at this point.

21. How long will it take to complete the initiative?

We anticipate 12 to 18 months with dedicated team members for 10 - 15 hours per month.



22. What metrics are available to track progress?

The success of this data security and authentication framework will be measured over time by metrics
related to fraud such as the return rate for unauthorized debits.

9/22/2010 3:17:17 PM                                                                                        9
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                 NACHA Business Ideas Submission Form
                                                                                 9/22/2010 3:17:17 PM

23. Please assess these other implementation factors for the initiative:

           a. Level of industry interest               5                   (1 – Low; 5 – High)
           b. Technical feasibility                    3                   (1 – Simple; 5 – Complex)
           c. Impact on ACH transaction volume         1                   (1 – Low; 5 – High)




9/22/2010 3:17:17 PM                                                                                   10
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

                                           Appendix A
                                    Data Security Business Case
                     Background on Proposed Rules and Guidelines Language

   1. Protect Sensitive ACH Data:

       Proposed Rule:

       ODFIs, RDFIs, Originators, Third-Party Service Providers and Third-Party Senders must use
       commercially reasonable methods and procedures to protect all sensitive ACH data and banking
       information related to ACH entries for all SEC Codes.

       Define Sensitive ACH Data in the Rules.

       Suggestions for Language & Placement in the Rules:

       Proposed Definition for Article Eight, Definition of Terms Used in These Rules: Sensitive ACH
       Data is defined as data related to ACH entries for the consumer or business customer of an RDFI
       and includes: (1) the bank account number together with the bank routing number, (2) the
       customer’s name together with the customer’s Social Security Number, and (3) the customer’s
       authentication credentials.

       Include obligation in Article [One], Section 1.2 Participating DFIs Must Comply With Rules.

       Rationale for Rule:

       NACHA took its first official step in defining sensitive ACH data in the Interim Policy on ACH
       Data Breach Notification. This definition regards the combination of certain elements of the
       RDFI’s consumer’s data as being sensitive.

       The rules and practices around protecting sensitive ACH data can be improved by looking at the
       standards used by the card networks, the Federal Government, and the financial institution
       regulators. The card networks require companies to protect all cardholder information under PCI
       DSS. The Federal Government addresses the protection of sensitive or confidential information as
       the backbone of basic information security tenets to protect information and information systems
       from unauthorized access, use, disruption, modification, or destruction in order to provide
       confidentiality, integrity and availability (FIPS 200, p.7). FIPS 199 – Standards for Security
       Categorization of Federal Information and Information Systems requires all federal agencies to
       develop, document, and implement agency-wide information security programs for the
       information and information systems that support the operations and the assets of the agency,
       including those provided or managed by another agency, contractor, or other source. The FFIEC’s
       Information Security Handbook includes security measures should be taken to ensure the
       confidentiality, integrity, and availability of information and to instill accountability for actions
       taken on the institution’s systems.

       Coverage in Current Rules:

       The current Rules address protecting sensitive data only in relation to ARC and BOC Entries.

       Article Two - Rights and Responsibilities of ODFIS, Their Originators and Third-Party Senders

9/22/2010 3:17:17 PM                                                                                     11
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

       •     Subsection 2.5.1.5. Additional ODFI Warranties for ARC Entries (c) …The Originator will
             establish and implement commercially reasonable methods to store: (i) the Eligible Source
             Document used to initiate the ARC Entry until it is destroyed; and (ii) all banking information
             related to ARC entries.
       •     Subsection 2.5.2.5. Additional ODFI Warranties for BOC Entries (h) … The Originator will
             establish and implement commercially reasonable methods to store: (i) the Eligible Source
             Document used to initiate the BOC Entry until it is destroyed; and (ii) all banking information
             related to BOC entries.

       Proposed Guidelines:

       •     The Guidelines will include explain what constitutes sensitive data in the ACH Network and
             provide examples of what is and is not sensitive ACH data and provide guidance for
             commercially reasonable procedures for protecting sensitive ACH data throughout the
             transaction lifecycle, from transmission, to storage, to data-at-rest, to destruction and/or
             reconstruction. These methods to protect sensitive ACH data begin with a recommendation to
             limit the amount of sensitive data that is stored and retained, but also includes methods such
             as data destruction and disposal, encryption, data leak prevention, data masking, three-tiered
             architecture (i.e. use of firewalls), and consumer education.

                                              Sensitive ACH Data
           Bank account number and Bank routing          This number is not in itself confidential, its
           number                                        aggregation with other components of a
                                                         transaction could potentially create harm if
                                                         compromised.
           Customer Name and Social Security Number      This data if associated with an ACH
                                                         transaction could potentially create harm if
                                                         compromised.
           Login ID and PIN/password for authenticated   If compromised, this data can prove harmful
           access                                        to both the financial institution and it’s
                                                         customers by enabling fraudulent activity
                                                         such as corporate account takeover and
                                                         fraudulent creation of debit and credit entries.

       The Guidelines will recommend the following:

       1. ACH Network participants should identify the sensitive ACH data that needs to be
          protected and then develop a strategy to protect that data.
          o A plethora of laws, requirements and standards have been created to address the need for
             information security. However, compliance does not ensure adequate protection of data.
             Existing requirements tend to be overly prescriptive, addressing one form of risk while
             overlooking the changing nature of information and data as it is processed and flows
             through enterprise systems and networks. As a result, the purpose of security in the ACH
             Network should be to ensure the Confidentiality, Integrity, and Availability (CIA) of
             sensitive ACH information and data.
          o Security should be understood as a process and not an end state. Understanding security
             as a process is the best approach for the most effective and cost-efficient security for
             sensitive ACH information because this approach dictates that the data is followed along
             the path that it takes while being processed. Understanding the spectrum of
             vulnerabilities of the systems by which the information or data will flow along this path

9/22/2010 3:17:17 PM                                                                                     12
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                      NACHA Business Ideas Submission Form
                                                                                      9/22/2010 3:17:17 PM

               is critical. This exercise will lead to the identification of potential risks to the security of
               the information or data that can be followed by an analysis to determine the impact and
               frequency of these risks throughout the transaction lifecycle. This process is known as an
               Information/Data Risk Assessment.
           o   Distinguish “information” from “data” because protection of information in forms other
               than digital is often overlooked; particularly in the policies and procedures that provide
               that protection. Data is the electronic version while information as described herein, is
               paper or other non-electronic information. Once the risks are known, then administrative,
               physical and electronic controls can be deployed to mitigate the risks. Administrative
               controls are policies, procedures, training and signs. Physical controls can range from
               physical guards to badges, doors, walls and fences. Electronic or technical controls are
               generally enforced within or by a computer system.
           o   A number of methods and tools are available for assessing information security risk,
               conducting audits and benchmarking against peers. Basically, all entities in the process
               should have a strong security program in place to protect the data. Security programs can
               be modeled after the International Standards Organization (ISO) 27002 and a security
               program operation is defined in ISO-27001.
           o   Security professionals consider all data and information that flow via a Web interface to
               be the greatest concern in the current electronic marketplace. Lack of proper design and
               control of these interfaces is subject to exploitation that can lead to shutdown of the
               interface such as by a distributed denial of service attack, disclosure of data being
               processed or complete system compromise resulting in access to all data within the
               system to fraudsters.
           o   It is important to recognize that the best security is that which is designed into the
               systems that will be used for processing the data and information, followed by repetitive
               assessment and risk management to ensure secure maintenance of the system.

       2. ACH Network Participants keep storage and retention of sensitive ACH data to a
          minimum.
          o NIST publication SP 800-88, Guidelines for Electronic Media Destruction, established
             for the first time the standard which governs electronic media destruction by stating that
             one should “limit storage amount and retention time to that which is required for
             business, legal, and/or regulatory purposes, as documented in the financial institution’s
             data retention policy.”
          o PCI DSS Requirement No. 3 suggests that as a method for minimizing risk, that
             cardholder data should not be stored unless absolutely necessary. The requirement
             specifically states “Keep cardholder data storage to a minimum. Limit storage amount
             and retention time to that which is required for business, legal, and/or regulatory
             purposes, as documented in the data retention policy.”
          o Develop policies to remove sensitive ACH data on a regular basis.

       3. Protection sensitive ACH data using the following best practices, procedures and
          methods:

           o   Data Destruction and Disposal
                  In many instances, companies are faced with competing laws, policies, and interests
                  when it comes to the retention or destruction of records. However, some companies
                  and individuals are legally required to destroy certain types of records that leave their
                  possession and can be held liable for failing to do so.
                  In 2005, the Federal Trade Commission (FTC) enacted the Disposal Rule, which is
                  part of the Fair and Accurate Credit Transactions Act (FACTA) of 2003, which
9/22/2010 3:17:17 PM                                                                                         13
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

                   updates portions of the Fair Credit Reporting Act (FCRA). Both laws regulate the
                   handling of consumer data. As of June 1, 2005, any business, large or small, that uses
                   consumer reports is required to “properly dispose of consumer reports” and the
                   information derived from them, using “reasonable measures.”
                   The Disposal Rule applies to any company that handles consumer information,
                   including consumer reporting agencies, lenders, insurers, employers, landlords,
                   mortgage brokers, car dealers, and other businesses. The law applies to both physical
                   and electronic records in any format, so it deals with erasing electronic data as well
                   as disposing of paper records.
                   “Disposal” includes not only the discarding or abandoning of consumer information,
                   but also the selling, donating, or transferring of any medium that stores the consumer
                   data, including computer equipment.
                   To comply with the rule, your company must take “reasonable measures,”
                   implementing and monitoring policies and procedures that require the “burning,
                   pulverizing, and shredding of papers containing consumer information, and the
                   destruction or erasure of electronic media containing consumer information so the
                   information cannot practicably be read or reconstructed.”
                   NIST defines four methods of data sanitization in NIST Special Publication 800-88,
                   Guidelines for Media Sanitization – disposal, clearing, purging, and destroying.
                   NACHA has chosen to outline only three of these methods below since clearing and
                   purging represent the same method.
                       o Disposal is the act of discarding media with no other sanitization
                            considerations (e.g., discarding paper in a recycling container, deleting
                            electronic documents using standard file deletion methods, and discarding
                            electronic storage media in a standard trash receptacle).
                       o Purging is a more advanced level of sanitization that renders media unreadable
                            even through an advanced laboratory attack. Purging consists of using
                            specialized utilities that repeatedly overwrite data; however, with
                            advancements in electronic storage media. Degaussing is also an acceptable
                            method of Purging electronic storage media; however, this typically renders
                            the media unusable in the future.
                       o Destroying is rendering media unusable (e.g., disintegration, incineration,
                            pulverizing, shredding and melting). This is a common sanitization method
                            for single-write storage media such as a CD or DVD for which other
                            sanitization methods would be ineffective. This is also a common practice
                            when permanently discarding hard drives.
                   The best strategy is for companies to develop policies for the safeguarding of
                   personally identifiable information at all data touch points. Companies can mitigate
                   these risks by developing a plan for document and data destruction, conducting an
                   assessment to identify the risks, implementing the plan and employee education, and
                   auditing to ensure the Disposal Rule is being followed.

           o   Encryption – Data at Rest and Data in Transit
                  Breaches of sensitive personal information can be prevented by the use of encryption
                  and/or content security controls. Encryption can also help businesses meet specific
                  privacy standards when sharing or transmitting information. Legislation and industry
                  trends are likely to become more restrictive as some states are considering laws that
                  would require encryption for all transmissions for all businesses that send personal,
                  identifiable information over the internet.
                  Data can exist in two different states: “at rest” and “in transit.” Data-at-rest is the
                  state of data when in storage (e.g., on a server or a laptop). Data-in-transit is data that
9/22/2010 3:17:17 PM                                                                                       14
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM

                   is in motion, being transferred – such as from a client laptop to a server or even from
                   server to server. Both states present opportunities for security breaches and the data
                   should therefore be protected in both states.
                   Two well understood encrypted transfer protocols for protecting data during the file
                   transfer are Secure Sockets Layer (SSL) protocol (a.k.a. FTPS or Secure FTP) and
                   Secure Shell (SSH) protocol (a.k.a. SFTP or SSH File Transfer Protocol). The Open
                   Pretty Good Privacy (PGP) provides an additional level of protection for data-at-rest
                   or data in storage. The SSL protocol enables encryption and decrypting of FTP
                   sessions across networks to provide authentication of credentials and secure private
                   communications. While SSL and SSH encrypt data while in transit, PGP is used to
                   encrypt individual files in storage.
                   Security experts recommend a combination of these protocols with PGP file
                   encryption to ensure that files are protected before, during and after transfer. A
                   combination of protection methods reduces the risk of unauthorized disclosure of
                   sensitive data during all phases of the file transfer process.

           o   Data Leak Prevention
                  Data leak prevention should be thought of in terms of insurance for a company
                  because the cost involved to install a leak prevention solution could offset the costs
                  of an actual or potential loss of data. The goal of a data leak prevention system is to
                  prevent or minimize the loss of legally protected or valuable data.
                  Data leakage tools can help make it harder to steal data. For example, a customer
                  service representative that has access to customer data may be tempted to write down
                  the information and leave the building with it. Data leakage tools can keep the person
                  from sending the data out electronically, writing it to a USB drive or sending it to a
                  printer. In this case, data leakage could prevent a customer service representative
                  from sharing large amounts of sensitive information via email whether intentionally
                  or unintentionally.
                  One of the problems in building a data leakage prevention system is finding out
                  where all the sensitive data is located. Data that started out in a database can find its
                  way to a wide range of locations, winding up on various PCs, spreadsheets and
                  portable devices. With so many possible places for data to migrate, companies often
                  have no idea where all the sensitive data is.
                  Finding out where the data resides is one of the best first uses of data leakage tools.
                  Tools from vendors can scan the network, searching and building a catalog of the
                  locations of sensitive data. Even if a company has not decided to take the steps to
                  build a leakage prevention system, the tools are very helpful in finding how big a
                  problem there is. It also tells the organization where to direct educational efforts so
                  that internal users will not put data at risk.
                  The next question is where to monitor for data leaks. The complete answer is to
                  monitor at the servers, on individual PCs and at the Internet gateways, but that does
                  not mean everyone needs to implement the complete solution, because again the
                  answer depends on what’s the greatest threat. The top concern with many managers
                  is stopping people from sending sensitive information from the corporate email
                  servers. Many vendors provide email solutions in appliance and software form. Many
                  of the email solutions can also encrypt the email and perform other functions.

           o Masking Sensitive Data
                   Data obfuscation begins with identifying what sensitive data needs to be masked in
                   both digital form and in clear text. Effective data masking requires data to be altered

9/22/2010 3:17:17 PM                                                                                    15
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                                                            NACHA Business Ideas Submission Form
                                                                                                                            9/22/2010 3:17:17 PM

                             in a way that the actual values cannot be determined or reengineered yet the
                             functional appearance is maintained.
                             A bank account number may read “123456789” when masked would appear as
                             “1234XXXXX.” This maintains the bank account holder’s identity yet removes
                             enough of the sensitive data so the original number cannot be regenerated.
                             Data should be masked when it is not absolutely necessary to validate all of the data.
                             For example, a call center representative only needs the last four digits of an account
                             number or Social Security number to verify that account belongs to the customer on
                             the other end of the phone.

                 o Three-Tiered Architecture – Use of Firewalls



                                                                 S e c urity T ie r 1 (D M Z )                  S e cu rity T ie r 2 (A pp )                  S e cu rity T ie r 3 (D B )
                                                                                                                                                               E x a m p le :
                                      E x a m p le :                                                             E xa m p le :
                                                                                                                                                               F ire w a ll re stric ts
                                      F ire w a ll re stricts                                                    F ire w a ll re s tricts
                                                                                                                                                               a cc es s b a se d o n
                                      a cce ss , in an d                                                         a c ce ss b a s ed o n
   P u b lic N e tw o rks                                                                                                                                      o n ly th e h os ts a n d
                                      o u t, o n T C P p o rts                                                   o n ly th e h o sts an d
                                                                                                                                                               p ro to co ls re q u ire d
                                      8 0 , 4 4 3 , 25                                                           p ro to co ls re qu ire d
                                                                       W e b S e rve r                                                                         fo r T ie r 3 , e .g .
                                      O N LY                                                                     for T ie r 2 .
                                                                                                                                                               T C P 14 3 2 for S Q L .
                                        F ire w a ll
   P riva te N e tw o rks
                                  R ou te r
                                                                       F T P S erve r            F ire w a ll                                  F ire w a ll
                                                                                                                 A p p lica tio n S e rve r                    D a ta b a se S e rve r

       C o rp o ra te
       B ac kb o n e



                              In te rn a l N e tw o rks                 M a il R e la y                              M a il S e rv er
                                                                          S erve r


   T h is d ia g ra m re p re s e n ts “lo g ica l” s e g m e n ta tio n re q u ire d to filte r tra ffic th ro u g h m u ltip le virtu a l se c u rity zo n e s. T h is ca n b e
   a cco m p lis h e d w ith m u ltip le fire w a lls (d iffe rin g ve n d o rs re co m m e n d e d), o r a s in g le fire w a ll w ith m u ltip le se cu rity zo n e s.
   A lth o u g h th re e tie rs a re re p re se n te d a b o ve, th e b a se re q u ire m e n t fo r se g m e n ta tio n o f se n sitiv e in fo rm a tio n syste m s is
   o n ly tw o z o n e s. A s lo n g a s tra ffic ca n b e se p a ra te d fro m th o se sy ste m s th a t p ro ce ss in fo rm a tio n fro m th o se th a t s to re it,
   th e n th e re q u ire m e n ts h a v e b e e n m e t.



                 o Consumer Education
                             At the payment site or before the payment site, use these best practices:
                                 Alert consumer to give payment information to trusted merchants only.
                                 Alert the consumer that the merchant is securely storing the data by using
                                 generally accepted data security methods.
                                 Alert the consumer that the information is conveyed on secure dedicated lines
                                 and portals for processing payment.
                                 Explain the security policy and procedures used to protect the consumer data to
                                 keep it safe within the merchant’s system.
                                 Alert customer to the existing of data breach notification laws.
                                 Alert customer to exit out of any Windows that may contain payment information
                                 at a publicly used computer as the ‘back’ button could reveal private and
                                 sensitive information.
                                 Offer the ability to print the order using masked account numbers.


9/22/2010 3:17:17 PM                                                                                                                                                   16
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                      NACHA Business Ideas Submission Form
                                                                                      9/22/2010 3:17:17 PM

                         If a holding time exists to wait for good funds, clearly state the number of days
                         the product will be delayed to the customer.

                     Any communication that you have with the customer regarding security, safety and
                     privacy should be reviewed by your legal department before publishing.

Checklist to Protect and Minimize Risk to Sensitive ACH Data and Information

                                                 Method                                                      Status
 Use robust authentication methods to add confidence to the entity on the transmitting end of the
 interface, such as digital certificates and/or dedicated lines.
 Use 128-bit RC4 (minimum) encryption of communication lines into the web server.
 Use three-tiered architecture at the interface with the web server in a DMZ (e.g., an additional
 firewall should be behind the application server and another firewall behind the database or
 server.
 Manage firewalls according to industry best practices.
 Use an intrusion prevention system that is monitored when the interface is active.
 All servers should meet the NIST standards for hardening and include installation and monitoring
 of a host intrusion detection system.
 Scan all devices (servers, switches, firewalls, etc.) weekly for vulnerabilities and monitor for
 compliance with industry best practices.
 Communication across the interface should be an application-to-application where possible (i.e.
 sending and receiving interfaces should be designed to speak to each other and provide an
 expected handshake between the two systems). Applications that face external applications or the
 web should be protected by application security appliances or application firewalls to ensure that
 requests of them are valid.
 Each program in a secure interface should follow industry standard coding practices and have
 passed a code review by a qualified evaluator.
 Limit access to all devices to those individuals who are specifically required to access the devices
 to perform operational support and ensure the security of the interface.
 Maintain tight control over access controls and audits of that access to all data (e.g., encryption at
 rest).
 Use data leak prevention services.
 Conduct quarterly penetration testing and annual risk assessment.

   The chart below is from NACHA’s 2009 publication, Guidelines to Secure ACH Network
   Transactions and addresses the ways that various ACH Network participants handle sensitive ACH
   data, outlines the risks, and some approaches for risk mitigation. Available on the NACHA website at
   https://www.nacha.org/member-
   apps/index.cfm?action=store.product&ProductID=206&ProductCategoryID=26.




9/22/2010 3:17:17 PM                                                                                         17
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                                            NACHA Business Ideas Submission Form
                                                                                                            9/22/2010 3:17:17 PM

       Chart – Safeguarding Sensitive Data in the ACH Network

                                                                            Sensitive ACH Data
 ACH Network
                      Financial Institution Account      Financial Institution Routing/Transmission             Consumer Account No. with Originator
  Participant
                                    No.                                        No.                                      or Tax ID No. (if used)
  Originator                   How I get it?                          How do I transmit it?                               How do I store it?
                         Entered by Consumer or          While this number is not in itself confidential, its    This number should be digitally signed
                        automatically correlated by          aggregation with other components of a             and encrypted so that it cannot be altered
                        Originator with data held in        transaction is, and should be signed and                        while in storage.
                                 storage.                            encrypted during transit.
     ODFI                      How I get it?                          How do I transmit it?                               How do I store it?
                                                                                                                 This number should be digitally signed
                        Received from Originator.        While this number is not in itself confidential, its   and encrypted so that it cannot be altered
                                                            aggregation with other components of a                          while in storage.
                                                           transaction is, and should be signed and
                                                                     encrypted during transit.
  Third Party                  How I get it?                          How do I transmit it?                               How do I store it?
Sender/Service                                           While this number is not in itself confidential, its    This number should be digitally signed
   Provider             Received from Originator.           aggregation with other components of a              and encrypted so that it cannot be altered
                                                           transaction is, and should be signed and                         while in storage.
                                                                     encrypted during transit.


ACH Operator                   How I get it?                          How do I transmit it?                               How do I store it?
                                                                                                                 Not necessary to store any data at this
                      Received from ODFI or Third        Data should be received already encrypted and                          stage.
                                 Party.                  should only be passed in encrypted form to the
                                                                           Receiver.
Receiving Point                How I get it?                          How do I transmit it?                               How do I store it?
                                                                                                                   Data should be stored for auditing
                      Received from ACH Operator.        There is really no need to transmit the data any         purposes in secure form (signed and
                                                                              further.                            encrypted) so it cannot be altered or
                                                                                                                                reused.
    Risks                Risk to the data integrity      Risk to integrity of transaction when reused or         Risk to the availability of the number if
                         through alteration during            replayed as a complete transaction.                erased from the storage database(s).
                          storage and/or transit.                                                               Risk to the confidentiality of the number if
                                                                                                                    obtained by unauthorized entity.
  Mitigation           Use of digital signatures for      Use of time-stamping or hashing schemes to            Use of robust access control schemes to
  Mechanism            protecting the integrity of the         protect against reuse and replay.                  enable retrieval of the number from
                                   data.                                                                                        storage.
                                                                                                                Use of strong encryption schemes for the
                                                                                                                  protection of the data while in transit
                                                                                                                             and/or storage.


       Case Studies

                  Case Study 1 – Unsecure Third Party Communications for Payroll

                  Company B uses a third party service provider to process its ACH payroll transactions. Each pay
                  period, an Excel worksheet is prepared that contains key employee information, including names,
                  Social Security numbers, routing and transit numbers and account numbers. Company B then
                  uses a third party service provider, EZ ACH, to create and originate an ACH file. Company B
                  emails the Excel worksheet to EZ ACH.

                  Problem: Sensitive ACH information is being transmitted over an unsecure electronic network
                  and in an unsecure format.

                  Preventative Measures: Only transmit information in a secure format such as: 1) secure
                  websites that use encryption, 2) encrypted email, or 3) encrypted file transfer protocol.


       9/22/2010 3:17:17 PM                                                                                                                18
       L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
       9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

       Case Study No. 2 – Payroll System Vulnerable to Exploits and Data Not Encrypted

       An ACH payroll processor with a web interface for employers to enter payroll information is
       exploited by a fraudster that breached the network using a hacker exploit called SQL injection,
       providing the hacker with access to the unencrypted database. The hacker was able to alter
       pending transactions to go directly to an account controlled by the hacker, making the hacker
       $29,000 richer from stolen payroll funds. Because this system was not properly or routinely
       patched, which would have prevented the exploit from occurring, the system was rendered
       vulnerable for intrusion. Furthermore, because the data was not encrypted and could be read,
       understood and edited by the hacker; theft became easy. The hacker could have been prevented
       from entering plain text data into the encrypted fields if, at a minimum, the sensitive fields in the
       SQL database had been encrypted, thereby limiting the impact of a breach to its system. The
       problems revealed by this case study underscore the importance of a properly patched system and
       use of data encryption as the first line of defense against vulnerabilities and fraud.

       Problems: A hacker using a known exploit can gain access to the internal network (i.e. the
       database) program used by the company. Data that is available in plain text format can be easily
       understood, altered or stolen by a fraudster.

       Preventative Measures: 1) Maintain all patches as published and released by the software
       manufacturer regularly, and 2) Encrypt sensitive data fields in data stores to make it more
       difficult for anyone who has compromised a system to figure out what the data is and what can be
       done with it.

   2. Require Verification of Receiver’s Identity

       Proposed Rule:

       Amend the Rules to require ODFIs to warrant that Originators have made a commercially
       reasonable effort to verify the Receiver’s identity for all SEC Codes. ODFIs with relationships
       with Third-Party Senders will warrant that their Third-Party Senders have assured that
       Originators are doing the verification of the identity of the Receiver. *Note: Further evaluation
       necessary to see if this can apply in practice to electronic check applications.

       Suggestions for Language & Placement in the Rules:

       Suggest that this be included in Article Section – General Warranties and Liabilities of
       Originating Depository Financial Institutions

       Rationale for Rule:

       Authentication describes the process of verifying the identity of a person or entity. Authentication
       is a critical component to establishing identity and effecting transactions in the ACH Network. A
       critical element in ensuring retail payment systems integrity is the appropriate identification and
       authentication of retail payment system customers. These controls can minimize the processing
       errors and fraud and protect the confidentiality of the customer and institution information.

       Coverage in Current Rules:

       Current Rules address this concept of verifying the Receiver’s identity only for BOC, TEL
       and WEB SEC Codes.
9/22/2010 3:17:17 PM                                                                                       19
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM


       •   Article Two – Rights and Responsibilities of ODFIs, Their Originators and Third-Party
           Senders
           o Subsection 2.5.2.5 Additional ODFI Warranties for BOC Entries – In addition to the
               other warranties contained within these Rules, an ODFI originating a BOC Entry
               warrants to each RDFI, ACH Operator, and Association that: …(d) Verification of
               Receiver’s Identity. The Originator has established and implemented commercially
               reasonable procedures to verify the identity of the Receiver.
           o Subsection 2.5.15.4 Additional ODFI Warranties for TEL Entries – In addition to the
               other warranties contained within these Rules, an ODFI originating a TEL Entry warrants
               to each RDFI, ACH Operator, and Association that: (a) Verification of Receiver’s
               Identity. The Originator has established and implemented commercially reasonable
               procedures to verify the identity of the Receiver.
           o Subsection 2.5.17.4 Additional ODFI Warranties for WEB Entries – In addition to the
               other warranties contained within these Rules, an ODFI originating a WEB Entry
               warrants to each RDFI, ACH Operator, and Association that: (b) Verification of
               Receiver’s Identity. The Originator has established and implemented commercially
               reasonable procedures to verify the identity of the Receiver.

       Proposed Guidelines:

       The table below provides some general industry practices for authentication for various SEC
       Codes.

       Table: General Industry Practices for Authentication

                                                     Paper
              SEC Code                   Single-Entry                           Recurring
                PPD              Verify that the account number on file with the Originator (e.g., utility
                                          bill account number) matches the name on the check.
                                                Check Conversion
                 ARC             Verify that the account number on file with the Originator (e.g., utility
                 BOC                      bill account number) matches the name on the check.
                 POP                                      Verify the signature.


                                               Internet/Mobile
                                        New Customer                        Existing Customers
            WEB/Mobile            Out-of-band-authentication                  Shared secrets
                                            (OOBA)
                                       Device recognition                         Tokens
                                 Challenge questions (e.g., from            One-time passwords
                                     credit bureau reports)
                                 Micro deposit to bank account                  Smart cards
                                   IP Address and relocation             IP Address and geolocation
                                                                                Biometrics
                                                Telephone
                                        New Customer                         Existing Customers
                 TEL


9/22/2010 3:17:17 PM                                                                                    20
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

       The best way in which Originators can minimize the potential for fraudulent ACH transactions is
       to employ robust authentication methods to verify the identity of the Receiver before accepting
       ACH debit authorizations both physically and electronically. The more robust the authentication,
       the less likely the transaction will be fraudulent and the less likely the payment will be returned to
       the Originator as unauthorized. Since the Originator may ultimately be responsible for
       unauthorized or fraudulent ACH transactions when those transactions are returned, it is to their
       benefit to incorporate adequate levels of authentication into their ACH payment processes.

       The selection and use of authentication technologies and methods should depend upon the results
       of a financial institution’s risk assessment process. Where risk assessments indicate that the use
       of single-factor authentication is inadequate, financial institutions should implement multifactor
       authentication, layered security, or other controls reasonably calculated to mitigate those risks.
       Single factor authentication alone is inadequate for high-risk transactions involving access to
       customer information or the movement of funds to other parties.

       Originators should understand the trends in the adoption of multifactor authentication and layered
       security, or additional risk mitigation controls to verify the identity of the Receiver in the
       financial services industry. The Federal Financial Institution Examination Council (FFIEC)
       released guidance to financial institutions in October 2005, Authentication in an Internet Banking
       Environment, which provides an appendix that describes several of the authentication techniques,
       processes and methodologies that are widely available in the marketplace. Originators should
       periodically refer to the FFIEC for any updates to this guidance.

       When considering which authentication methods to deploy, Originators should determine whether
       their ACH transactions will be conducted with existing customers, new customers or both.
       Originators should also consider whether the transaction is Single-Entry (non-recurring) or
       Recurring to determine adequate levels of authentication.

       The Originator has the responsibility to choose an appropriate solution for authentication that will
       minimize the potential for fraudulent transactions. Common examples in use today include asking
       for several forms of identifying information and checking that information against databases,
       asking challenge questions based upon credit bureau or other information, or sending the consumer
       a specific piece of information, either online or offline, and then asking the consumer to verify that
       information as a second step in the authentication process.

       Multifactor authentication uses multiple characteristics to determine a consumer’s identity, for
       example by obtaining and verifying more than one of the following: something the consumer
       knows (password), plus something the consumer has (a personal computer or a smartphone),
       something the consumer is (voice or fingerprint) and someplace the consumer is (geolocation).

       The widely-deployed use of user ID/password protection schemes are no longer considered
       adequate protection for online information. Though user ID/PIN/password are still the most
       common solution for online authentication, there is growing wide scale interest in replacing
       passwords with more robust authentication methods such as multifactor authentication.

       Some other factors to consider in selecting an authentication method that is commercially
       reasonable include typical transaction amount, type of goods offered, method of delivery, and
       controls of goods or funds. It is important to note that it will never be considered commercially
       reasonable to have done nothing. Similarly, assigning a password and allowing a Receiver to use
       that password in the same Internet session as the sole method of authenticating the Receiver is
       also not considered commercially reasonable.
9/22/2010 3:17:17 PM                                                                                      21
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM


       The use of newer and emerging technologies presents new security challenges. As new retail
       payment products and services are developed, it may become necessary to modify methods for
       customer identification and authentication to ensure their effectiveness.

       Customer Verification Techniques [Excerpt from FFIEC 2005 Authentication in an Electronic
       Banking Environment]

       Customer verification is a related but separate process from that of authentication. Customer
       verification complements the authentication process and should occur during account origination.
       Verification of personal information may be achieved in three ways:

               •   Positive verification to ensure that material information provided by an applicant
                   matches information available from trusted third party sources. More specifically, a
                   financial institution can verify a potential customer’s identity by comparing the
                   applicant’s answers to a series of detailed questions against information in a trusted
                   database (e.g., a reliable credit report) to see if the information supplied by the
                   applicant matches information in the database. As the questions become more
                   specific and detailed, correct answers provide the financial institution with an
                   increasing level of confidence that the applicant is who they say they are.


               •   Logical verification to ensure that information provided is logically consistent (e.g.,
                   do the telephone area code, ZIP code, and street address match).

               •   Negative verification to ensure that information provided has not previously been
                   associated with fraudulent activity. For example, applicant information can be
                   compared against fraud databases to determine whether any of the information is
                   associated with known incidents of fraudulent behavior. In the case of commercial
                   customers, however, the sole reliance on online electronic database comparison
                   techniques is not adequate since certain documents (e.g., bylaws) needed to establish
                   an individual’s right to act on a company’s behalf is not available from databases.
                   Institutions still must rely on traditional forms of personal identification and
                   document validation combined with electronic verification tools.

               Another authentication method consists of the financial institution relying on a third party
               to verify the identity of the applicant. The third party would issue the applicant an
               electronic credential, such as a digital certificate, that can be used by the applicant to
               prove his/her identity. The financial institution is responsible for ensuring that the third
               party uses the same level of authentication that the financial institution would use itself.

       Other resources:
          • NIST 2004 Special Publication 800-63 – Electronic Authentication Guidelines
               http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf.
          • FFIEC 2005 Authentication in an Electronic Banking Environment
               http://www.ffiec.gov/pdf/authentication_guidance.pdf.




9/22/2010 3:17:17 PM                                                                                        22
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM


   3. Require ODFIs to Verify the Identity of Originators and Third-Party Senders

       Proposed Rule:

       Amend the Rules to require ODFIs to warrant that they have utilized a commercially reasonable
       method to verify the identity of Originators and Third-Party Senders of any ACH entry. This
       requirement will apply for origination of ACH Entries related to all SEC Codes.

       Suggestion for Language & Placement in the Rules

       Suggest including in Chapter Two, Section 2.4, General Warranties and Liabilities of Originating
       Depository Financial Institution.

       Rationale for Rule

       Know your customer (KYC) is the due diligence and bank regulation that financial institutions
       and other regulated companies must perform to identify their clients and ascertain relevant
       information pertinent to doing financial business with them. OCC Bulletin 2006-39 clearly
       addressed the need for ODFIs to know details about all participants in third party relationships by
       indicating that financial institutions “should know, at a minimum, for which Originators they are
       initiating entries into the ACH Network.” Thus, banks should consider requiring Third-Party
       Senders to provide certain information on their Originator customers such as the Originator’s
       name, taxpayer identification number, principal business activity, and geographic location. Also,
       before originating transactions, a bank should verify (directly or through a Third-Party Sender)
       that the Originator is operating a legitimate business. This should be an ongoing process
       throughout the business relationship beyond the initial onboarding process.

       Current Rules:

       •   Article Two Rights and Responsibilities of ODFIs, Their Originators, and Third-Party
           Senders
           • Subsection 2.4.1.8 The ODFI has Verified the Identity of Originator or Third-Party
               Sender That Uses an Unsecured Electronic Network – The ODFI has utilized a
               commercially reasonable method to establish the identity of an Originator or Third-Party
               Sender that entered into an Origination Agreement via an Unsecured Electronic Network.
           • Subsection 2.5.2.5 Additional ODFI Warranties for BOC Entries – In addition to the
               other warranties contained within these Rules, an ODFI originating a BOC Entry
               warrants to each RDFI, ACH Operator, and Association that: (a) Verification of Identity
               of Originator or Third-Party Sender. The ODFI has established and implemented
               commercially reasonable procedures to verify the identity of the Originator or Third-
               Party Sender of the BOC Entry.
           • Subsection 2.14.1 Identification of Originators by Third-Party Senders – A Third-Party
               Sender must, upon the ODFI’s request, provide the ODFI with any information the ODFI
               reasonable deems necessary to identify each Originator for which the Third-Party Sender
               Transmits Entries. The information must be provided to the ODFI by the Third-Party
               Sender within two Banking Days of receipt of the ODFI’s request.  




9/22/2010 3:17:17 PM                                                                                    23
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                      NACHA Business Ideas Submission Form
                                                                                      9/22/2010 3:17:17 PM


       Proposed Guidelines:

       Emphasize the need for ODFIs to be proactive in imposing controls around their business
       relationships (i.e., not only on the front-end of the business relationship but at regular intervals).
       The intent is to require regular monitoring of business relationships by ODFIs and to encourage
       additional controls beyond Service Level Agreements and Statements on Auditing Standards
       (SAS) No. 70 reporting.

       The words “Know Your Customer” in the financial sense describe the process by which a financial
       institution checks the identity, background and other aspects of the source of wealth of potential and
       existing customers. Also known as KYC, legislation and regulation require firms to obtain evidence of
       identity of a customer at take-on and to keep a record of that evidence for as long as there is a
       relationship with a customer. Legislation and regulation also require a firm to keep up to date its
       knowledge of a customer throughout the life of the relationship, so that changes in the customer's
       activity can be assessed and dealt with – all with the principal aim of preventing Money Laundering
       and Financial Crime.

       During the life of a customer relationship, the firm wants to be able to carry out checks on a
       customer’s transactions to make sure that they are genuine and to be able to research any which
       may appear unusual. In particular with transactions, a firm must be able to complete due diligence
       quickly where there are concerns, to be sure that settlement or delivery is completed on or by the
       planned value date – a firm does not want to have to be paying back-value for delaying a
       transaction when speedier due diligence could have avoided it. http://www.duediligence.net/.

   4. Deploy Commercially Reasonable Access Controls

       Proposed Rule:

       •   Require ODFIs, Originators, and Third-Party Senders must have commercially reasonable
           Access Controls in place to protect ACH data and banking information related to ACH
           entries.
       •   Define Access Controls in the Rules.

       Suggestions for Language & Placement in the Rules:

       •   Proposed Definition in Article Eight: Access controls are administrative, physical and
           technical controls for systems that process ACH data that permit an authority to control
           access to areas and resources in a given physical facility or computer-based information
           system.

       Suggest including obligation Article One, Section 1.2.

       Rationale for Rule:

       The 2010 FFIEC Retail Payment Systems Information Security Handbook refers to “physical and
       logical controls for the origination, transmission, and storage of retail payment systems
       transactions (56),” the card networks under PCI DSS have several requirements to restrict access
       to both logically and physically; the STAR Network restricts physical, system or network access
       on a business need to know basis as outlined in documented policies and procedures; and FIPS
       200 outlines minimum security requirements that include access control.
9/22/2010 3:17:17 PM                                                                                        24
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM


       Coverage in Current Rules:

       There is no current rules provision that address access controls for origination of ACH Entries.

       Proposed Guidelines:

       Access controls, in one form or another, is considered by most information systems security
       professionals to be the cornerstone of their security programs. The various features of
       administrative, physical, and technical access control mechanisms work together to construct the
       security architecture so important in the protection of an organization’s critical and sensitive
       information assets.

       1. Administrative controls define the human factors of security. It involves all levels of
          personnel within an organization and determines which users have access to what resources
          and information by such means as: training and awareness, disaster preparedness and
          recovery plans, personnel recruitment and separation strategies, and personnel registration
          and accounting. Other examples include:
          o Management should assign appropriate logical access to staff responsible for retail
              payment-related services and should base access rights on the need to separate the duties
              of personnel responsible for originating, approving, and processing the transactions.
          o Appropriate identification and authentication techniques include requiring unique
              authenticators for each staff member with strong password requirements.
          o Password management practices and policies.
          o Establish an access control policy that includes examples of job-related access profiles
              (role based access control).

       2. Physical controls are employed to prevent unauthorized personnel from entering computing
          facilities (i.e., locations housing computing resources, supporting utilities, computer hard
          copy, and input data media) and to help protect against natural disasters. Examples of these
          controls include, but are not limited to: closed-circuit surveillance cameras, motion or thermal
          alarm systems, security guards, picture IDs, locked and dead-bolted steel doors, and
          biometrics (includes fingerprint, voice, face, iris, handwriting, and other automated methods
          used to recognize individuals).
          o Physical controls should limit access to only those staff assigned responsibility for
              supporting the operations and business line centers that process retail payment and
              accounting transactions.
          o Physical controls should also provide for the ability to monitor and document access to
              these facilities.
          o Authorize access by an y visitors and maintain a physical audit train of visitor activity.
          o Maintain inventory logs of all media and conduct media inventories at least annually.
          o Other preventative physical controls include: backup files and documentation, fences,
              badge systems, double door systems, backup power, site selection, and fire extinguishers.

       3. Technical controls use technology as a basis for controlling the access and usage of sensitive
          data throughout a physical structure and over a network. Technical controls are far-reaching
          in scope and encompass such technologies, including but not limited to: encryption, smart
          cards, network authentication, access control lists (ACLs), file integrity auditing software,
          access control software, antivirus software, library control systems, passwords, dial-up access
          and callback systems.

9/22/2010 3:17:17 PM                                                                                      25
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                  NACHA Business Ideas Submission Form
                                                                                  9/22/2010 3:17:17 PM

               o Limit access to system components and sensitive ACH data to only those individuals
                   whose job requires such assess (e.g., “need to know” access rights).
               o Controls should include identifying and authenticating retail payment system
                   customers to help ensure the integrity of the payments.
               o Using digital certificates, leveraging the public key infrastructure (PKI), employing
                 biometrics and card or token-based techniques can provide cost-effective solutions
                 for augmenting traditional technical controls.
               o ISO 27002 also distinguishes among logical access to IT systems using network,
                 operating system, application and information, and mobile computing and
                 teleworking access controls.
               o Many electronic banking applications use Internet-based, open network standards and
                 rely on commonly accepted technologies to secure transmissions (e.g., secure socket
                 layer [SSL] or other virtual private network [VPN]).
               o Establish a secure session before Receivers can submit their personal banking
                 information or other sensitive ACH data, and maintain the secure session until the
                 time of final data transmission.
               o Incorporate commercially reasonable practices to employ multifactor authentication
                 methods for remote access to the network by administrators, employees, and third
                 parties.
               o Establish password management policies and practices.
               o Render all passwords unreadable during transmission and storage on all system
                 components using strong cryptography.
               o Limit repeated access attempts by locking out the user ID after not more than six
                 attempts.
               o Disable secure sessions that have been idle for more than 15 minutes.
               o Authenticate all access to any database containing sensitive ACH data. This includes
                 access by applications, administrators, and all other users.

       •   The 2010 FFIEC’s Retail Payment Systems IT Examination Handbook outlines the following:
           o Financial institutions should implement the appropriate physical and logical security
              controls to ensure retail payment system transactions are processed, cleared, and settled
              in an accurate, timely, and reliable manner.
           o Logical access controls are tools used for identification, authentication, authorization, and
              accountability. They are components that enforce access control measures for systems,
              programs, processes, and information. The logical access controls can be embedded
              within operating systems, applications, add-on security packages, or database and
              telecommunication management systems.
           o Security risk assessments should consider physical and logical security controls for the
              origination, approval, transmission, and storage of retail payment system transactions.
           o Risk assessments should include service providers, third-party originators, and external
              networks that process, store, or transport customer data.
           o Retail payment systems contain confidential customer information subject to GLBA
              section 501(b) security guidelines. The board and management are responsible for
              protecting the confidentiality, integrity, and availability of these systems and data. The
              privacy risk combined with the funds transfer capability should cause these systems to
              rank high in all institutions’ information security risk assessments.
           o Logical access controls should permit access on a need-to-know basis and should assign
              access to retail payment applications and data based on functional job duties and
              requirements. Logical access controls should also protect network access.
           o An institution’s risk assessment should require protection of retail payment systems from
              unauthorized access through appropriate access controls, network and host configuration,
9/22/2010 3:17:17 PM                                                                                     26
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM

               operation, firewalls, and intrusion detection and monitoring. The risk assessment should
               also review the security of all third-party service providers. Some institutions accomplish
               this by isolating all payment-related applications and systems from other production
               applications.
           o   Retail payment systems should incorporate sufficient security procedures and controls to
               verify the integrity of the data, the confidentiality of the transmission, and the
               authenticity of the communication partners and data sources.

       Case Studies

       Case Study 1 – Information Vulnerable to Internet Theft and Misuse

       Company A keeps a database of customer debit information to process payments. Company A
       prides itself on having excellent customer service and has provided all of its employees with the
       ability to view all customer information, including routing and transit and account
       numbers. Company A consistently analyzes customer payment patterns and its systems produce a
       wealth of reports on customer behavior. These reports also contain customer information,
       including routing and transit and account numbers.

       Problems: 1) Employees can easily view customer information that is considered sensitive and 2)
       Employees can easily download reports that contain a wealth of customer information, creating a
       back door to view data housed within the system. This information is susceptible to malicious
       use.

       Preventative Measures: 1) Use access controls to limit access to data to employees who need it,
       2) Use account masking to hide key pieces of sensitive information, while still providing
       employees with information to provide good customer service, 3) Do not include sensitive data in
       reports, and 4) Use audit logging to record when sensitive information is accessed by employees
       who require access to perform their duties.

       Case Study No. 2 – Company Vulnerable to Corporate Account Takeover

       Company D utilizes its bank’s online banking functionality for all of its banking, thereby
       eliminating the need to physically visit the bank. Online banking is used to submit ACH files, for
       remote deposit capture check deposits and to generate wire transfer requests, etc. The company
       carefully trains employees on security matters related to its bank relationship and has never
       experienced any problems, although their bank has requested that they implement dual control
       procedures over certain processes such as wire requests. The company is small and sees no need
       for an additional approval process. Company D is confident in the trustworthiness of its
       employees and has declined the request for a second person to authorize wire transfers after
       initiation.

       An employee of Company D inadvertently downloaded a keylogger to their computer while
       surfing the internet. The employee continued to perform her job duties, but later experienced
       trouble connecting to the bank. The employee assumed the bank was having system problems and
       tried to connect again later.

       In this case, a fraudster has been monitoring the employee’s activity via the keystroke logger
       installed on her computer. When she entered the code from her token to log into the bank’s
       system, the fraudster created a loop, accessing the system prior to her. Since the session was
       already underway, she was denied access and could not log in. From the bank’s perspective, the
9/22/2010 3:17:17 PM                                                                                    27
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                                NACHA Business Ideas Submission Form
                                                                                                9/22/2010 3:17:17 PM

         login credentials were legitimate and it assumed it was doing business with an authorized
         employee of Company D. The fraudster initiated a very large outgoing wire transfer to a specific
         routing transit and deposit account number he controlled. Since the company did not require a
         secondary approval process for wires, this request was fulfilled by their bank, resulting in a very
         large loss of funds. The sensitive data this company failed to protect was its own.

         Problems: 1) Lack of dual control over key financial processes and transactions, 2) lack of
         adequate security on company computers, and 3) lack of understanding of risk issues related to
         internet activity.

         Preventative Measures: 1) Implement all financial controls offered through your bank’s online
         banking channel, 2) require dual controls over all financial activity, 3) install and maintain
         adequate security software on all company computers, 4) train employees to download updates to
         security software as soon as they become available.

    5. Deploy Fraud Management Systems

         Proposed Rule:

         ODFIs, Originators, and Third-Party Senders must deploy commercially reasonable Fraud
         Management Systems for all SEC Codes related to ACH Entries.

         Define Fraud Management System in the Rules.

         Suggestions for Language & Placement in the Rules:

         Include obligation in Article [One], Section 1.2 Participating DFIs Must Comply With Rules

         Suggested Definition of Fraud Management System for Article Eight, Section 2.4: A Fraud
         Management System is a comprised of policies, procedures, communication standards, systems
         and behavior expectations that provide adequate controls needed to minimize the potential for
         fraudulent activity related to ACH Entries.

         Suggest include obligation in Article One, Section 1.2.

         Rationale for Rule:

         Policies, procedures, communication standards, systems and behavior expectations can help
         reduce the risk of loss resulting from identity theft, fraudulent attacks, and data breach, thereby
         saving ACH Network participants against the alternative costly result of reputation loss, loss of
         customers, and litigation

         The Cendrowski Corporate Advisors (CCA) team of fraud professionals developed an in-depth
         methodology for fraud prevention, as published in The Handbook of Fraud Deterrence (Wiley,
         2006). In its 2010 Report to the Nations on Occupational Fraud and Abuse, the Association of
         Fraud Examiners (ACFE) cited the financial services industry as the largest victim of fraud. The
         current components of the Committee of Sponsoring Organizations of the Treadway Commission


 199 - Standards for Security Categorization of Federal Information and Information Systems, released in February 2004. FIPS
199 addresses one of the requirements specified in the Federal Information Security Management Act (FISMA).
9/22/2010 3:17:17 PM                                                                                                       28
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

       (COSO) Enterprise Risk Management (ERM) framework as they apply to an assessment of fraud
       risk. The constituent parts might include established fraud policies, fraud training, fraud-reporting
       mechanisms, and adequate internal controls. The COSO Internal Controls framework is very
       similar and can therefore be used as well.

       Coverage in Current Rules:
       Current Rules only address this concept for WEB transactions.

       Article Two – Rights and Responsibilities of ODFIS, Their Originators and Third-Party Senders.
       • Subsection 2.5.17.4 Additional ODFI Warranties for WEB Entries – (a) ODFI warrants that
           each Originator for which the ODFI transmits WEB entries has employed a commercially
           reasonable fraudulent transaction detection system to screen each entry.

       Proposed Guidelines:

       Chart – Examples of Fraud Management System by SEC Code

                                                      Paper
              SEC Code
                PPD              Utilize a commercial or internal database of consumer checking account
                                                                 information
                                                        Check positive/negative files
                                                        Address verification systems
                                                Check Conversion
                 ARC             Utilize a commercial or internal database of consumer checking account
                 BOC                                             information
                 POP                                    Address verification systems
                                                        Check positive/negative files
                                                  Internet/Mobile
            WEB/Mobile                                        Device recognition
                                           IP Intelligence, IP address and geolocation technology
                                                           Transaction monitoring
                                                               Neural networks
                                                             Behavioral forensics


                                                  Telephone
                 TEL             Utilize a commercial or internal database of consumer checking account
                                                               information
                                                      Address verification systems
                                                      Check positive/negative files

       •   Adopt current Guidelines language for WEB that would be applicable for this rules provision:
           • Examples of [Fraud Management System] are systems that track payment history,
              behavior, purchase type, delivery information, etc.
           • Factors to consider when choosing a [Fraud Management System] include the number of
              transactions processed, average dollar size of each transaction, relationship with the
              consumer (previously existing or new), and the type of goods or services being sold.
           • A [Fraud Management System] must be deployed no matter how small the transaction
              amount or type.
9/22/2010 3:17:17 PM                                                                                     29
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                    NACHA Business Ideas Submission Form
                                                                                    9/22/2010 3:17:17 PM

           •   ODFIs agreements with Originators and Third-Party Senders should address the
               procedures, practices and systems Originators are using to comply with their obligations
               for [Fraud Management System].
           •   To not deploy any method or procedure to detect transaction fraud is not considered
               commercially reasonable.
           •   ACH Network participants should also monitor for “red flags” as outlined under the 2008
               Red Flag Rule issued by the FTC and the federal financial institution regulatory agencies.
                    o Red flags are suspicious patterns or practices, or specific activities that indicate
                         the possibility of identity theft. For example, if a customer has to provide some
                         form of identification to open an account with your company, an ID that looks
                         like it might be fake would be a “red flag” for your business.
                    o The Red Flag Rule requires each financial institution and creditor that holds any
                         consumer account, or other account for which there is a reasonably foreseeable
                         risk of identity theft, to develop and implement an Identity Theft Prevention
                         Program (Program) for combating identity theft in connection with new and
                         existing accounts.
                    o The agencies also issued guidelines to assist financial institutions and creditors in
                         developing and implementing a Program, including a supplement that provides
                         examples of red flags. More information is available at
                         http://www.ftc.gov/bcp/edu/microsites/redflagsrule/index.shtml.
           •   A layered approach against fraud is highly recommended and uses multiple systems,
               practices and procedures in conjunction with each other may provide the best fraud
               protections because:
               • Authentication of a first-time customer, for example, may not be robust enough to
                    prevent fraud. Adding a process to perform checks on addresses and phone numbers
                    may provide additional verification of the original authentication and provide
                    additional comfort that the customer is legitimate.
               • Authentication tokens and credentials can be compromised, regardless of whether or
                    not the authentication process is successfully completed. Adding a fraud management
                    process may provide an additional safeguard to protect against a fraudster using
                    stolen authentication tokens.
               • Monitoring delivery addresses or using neural networks may help detect if there is a
                    change in the consumer’s purchasing behavior.
               • Internal databases
               • Commercial databases
               • Checking negative and positive files
               • Checks against previous transaction history (e.g., amounts and types of purchases and
                    credit checks).
               • Originators should distinguish between new and existing customers and establish
                    different procedures within their [Fraud Management System] for authenticating their
                    identity and monitoring their payment behavior.
               • Originators should not issue a PIN or password to a new consumer until that
                    customer has been either sufficiently authenticated, or the Originator has established
                    a relationship with the consumer.
               • Originators may want to compile or utilize a database of consumer checking account
                    information, with a focus on identifying consumers who have caused losses.
               • Originators may want to consider using an address verification service (AVS), which
                    allows the Originator to compare the address that is used by the customer as part of a
                    purchase against the address used for their billing statement. There are many reasons
                    for a consumer’s billing and shipping address to differ, so it is up to the Originator to
9/22/2010 3:17:17 PM                                                                                      30
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                   NACHA Business Ideas Submission Form
                                                                                   9/22/2010 3:17:17 PM

                   determine whether or not to accept a consumer’s payment when conflicting addresses
                   are verified.
               •   Originators may want to filter online transactions using software products that
                   identify several data elements, including location, anonymous proxies, domain name,
                   and other identifying attributes referred to as “IP Intelligence.”
               •   Geolocation technology is a technique that can be used to analyze the small bits of
                   time required for Internet communications to move through the network. This
                   software can be deployed to determine if a user’s location is reasonable and unlikely
                   to be fraudulent or if the location happens to originate in known fraudulent locations.
               •   Device recognition

   6. Annual Data Security Assessment

       Proposed Rule:

       ODFIs, Originators, and Third-Party Senders must conduct an annual data security assessment for
       ACH origination related to all SEC Codes.

       Suggestions for Language & Placement in the Rules:

       Suggest include into Article One – General Rules at Subsection 1.2.5.

               Annual Data Security Assessments:

               An ODFI must:

                   (a) Conduct, or have conducted an annual data security assessment to ensure that it
                       has deployed commercially reasonable policies and procedures to protect
                       sensitive ACH data and information;
                   (b) Implement or have implemented an information security and/or government
                       program based on this assessment; and
                   (c) Comply with the requirements of its regulator(s) with respect to such data
                       security assessment.

       Suggest include obligation in Article One, Section 1.2.5.

       Rationale for Rule:

       A critical first step in any data-driven security project is to conduct an assessment of the entire
       system and identify all the points and places where sensitive data is processed, transmitted and
       stored. This is an essential task because a company cannot protect data unless it knows where that
       data is. Assessments typically reveal sensitive personal data that resides in places that are
       unexpected such as applications and databases across the Network. In addition, an assessment
       holds organizations accountable to assess their overall information security risk, to deploy
       reasonable controls to manage that risk, and to monitor their practices over time. Furthermore, an
       assessment is required as a minimum security requirement under FIPS 200, ISO 27001/27002,
       OTS’s Regulatory Handbook, and the FFIEC’s 2010 IT Examination Handbook.

       Coverage in Current Rules:

       Current Rules only address this concept for WEB transactions.
9/22/2010 3:17:17 PM                                                                                     31
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc
                                                                 NACHA Business Ideas Submission Form
                                                                                 9/22/2010 3:17:17 PM


       Article Two - Rights and Responsibilities of ODFIS, Their Originators and Third-Party Senders
       • Subsection 2.5.17.3. WEB Annual Audit - The Originator of the WEB Entry must conduct,
           or have conducted on its behalf, annual audits to ensure that the financial information it
           obtains from Receivers is protected by security practices and procedures that include, at a
           minimum, adequate levels of: (a) physical security to protect against theft, tampering, or
           damage, (2) personnel and access controls to protect against unauthorized access and use, and
           (3) network security to ensure secure capture, storage, and distribution.”

    Proposed Guidelines:

   •   Provide a reference to the NACHA website for online resources including a self-assessment or
       checklist, and case studies. (NACHA 2007 - ACH Network Data Security Self-Assessment
       Workbook Available online at https://www.nacha.org/member-
       apps/index.cfm?action=store.product&ProductID=114&ProductCategoryID=33.
   •   Consider providing a reference to the NACHA website for a list of providers for an ACH security
       assessment.
   •   Include best practices for conducting more frequent assessments (quarterly or bi-annually)




9/22/2010 3:17:17 PM                                                                                  32
L:\TIC\WORKGRPS\ACH Security\Holistic Data Security\BIS Data Security Complete BIS for WG Review
9.22.10.doc

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:11/21/2012
language:Latin
pages:32