data€security requirements€in€the achaz9194.vo.msecnd.net/pdfs/110401/233.pdf ·...

© 2011 NACHA — The Electronic Payments Association. All rights reserved.No part of this material may be used without the prior written permission of NACHA. This materialis not intended to provide any warranties, legal advice, or professional assistance of any kind.

April 4, 20114:30 –5:30 p.m.

Eddie Ho, Chief Information Officer, OmniAmerican BankFred Laing, II, AAP, CCM, President & CEO, UMACHA

Susan Pandy, Senior Director,Internet & eCommerce, NACHA

Data SecurityRequirements in the

ACH

• Please turn off all cell phones or mobile devices.• Thank you to today’s sponsors!

– Breakfast Roundtables sponsored by SWACHA

– Live Simulcast Spotlight Session sponsored by IBM– 2011 NACHA Payments System Awards Luncheon

sponsored by TD Bank

– Exhibit Hall Refreshment Breaks sponsored by HSBC

• All conference attendees will have free access to PAYMENTS 2011 conferencesession recordings. Attendees that registered onsite will receive details to accessthe session recordings within 10 days.

• Please take a moment to complete session evaluations! Each evening attendeeswill receive an email link to access session evaluations that are offered each day.Attendees are automatically entered into a daily drawing for a chance to win a $50gift card.

• Register now for PAYMENTS 2012 –Receive the PAYMENTS 2011 EarlyBirdRates –Only available onsite –Visit the Registration Desk for more details.

Thanks to all of our Track Sponsors!

© 2011 NACHA — The Electronic Payments Association. All rights reserved. No part of this material may be used without the prior written permission of NACHA. This material is notintended to provide any warranties, legal advice, or professional assistance of any kind.

3


Agenda

• Introduction• Data Protection in the ACH Network –Why

Protect?• What data should be protected?• A holistic Rules framework• Best practices and resources• Q & A

4


Why Protect?

• Identity theft• Data breach / Corporate Account

Takeover• Reputation risk• Uncertainty and complexity• Compliance challenges• Regulatory requirements• Loss of customers• Monetary losses• Legal costs• Technology

5


Information Protection is Critical

• Number of consumer records compromisedsince January 2005 exceeds 345 million.

• Risks:–Fines or lawsuits by aggrieved parties–Reputation risk

• Compliance remains a challenge–47 states now have data breach laws –

though they are not all consistent.• Add in PCI DSS!

6


Data Loss Methods

7


Why Protect Again?

• Information has a lifecycle• Rapid pace of technology

change• More vulnerabilities in the

electronic paymentsenvironment

• Sophistication andprofessionalization offraudsters

8


What is Sensitive ACH Data?

• “CustomerLevel ACH Data”*:– A bank account number together with bank routing

number; or– The customer’s name together with the customer’s

Social Security Number.

* Currently defined in the NACHA Board of DirectorsInterim Policy Statement on ACH Data BreachNotification Requirements

9


But another way to look at this…

10


Each ACH Network Participant

Should askthemselves…• How I get it?• How do I transmit it?• How do I store it?

11


Start with Identifying Sensitive Data

• Develop a strategy to protect data–As part of a larger organizational information

security strategy and compliance effort.• Remember: compliance does not ensure

adequate protection of data.–Existing requirements can overlook the changing

nature of information and data as it is processedand flows through the enterprise.

12


Information/Data Risk Assessment

• Approach: Understand security as a PROCESS– Follow the data along the path that it takes

• Understanding the range of vulnerabilities of yoursystems that will “touch” the data along this path

13


Distinguish Information from Data

• Data is the electronic version.• Information is the paper or other nonelectronic

information.• Controls:

– Administrative controls are policies, procedures,training and signs.

– Physical controls can range from physical guards tobadges, doors, walls and fences.

– Electronic or technical controls are generally enforcedwithin or by a computer system.

14


ACH Network Participant Transaction Risks

Originator ODFI RDFI Receiver

Risks at Originator:§ Disclosure of consumer

account data in storage andin transit (confidentiality)§ Alteration of consumer

account data in storage andin transit (integrity)§ Impersonation of customer

(authentication)§ Interception and replay of

customer transaction

Risks at ODFI:§ Disclosure of transaction

(confidentiality)§ Alteration of transaction

(integrity)§ Replay of transaction§ Acceptance of unverified

transaction§ Alteration of audit records

Risks at RDFI:§ Disclosure of transaction

(confidentiality)§ Alteration of transaction

(integrity)§ Acceptance of unverified or

replayed transaction§ Alteration of audit records

Risks at Receiver:§ Misassociation of

payment and customeraccount§ Alteration of customer

payment§ Replay of transaction§ Validation of payment

acknowledgement§ Acceptance of unintended

payment§ Alteration of audit records

Notes:§ The data protection practices of the consumer, and thereby the associated risks and threats of such are not depicted in the above

diagram.§ Threats at this level also encompass disclosure of account data including compromise of login ID and PIN/password for

authenticated access.§ It is assumed that the consumer initiating the ACH transaction can be connected to either the Originator or a Receiver.

15


Data Protection under the Current NACHAOperating Rules

• Requirements vary by Standard Entry Class Code.• Requirements are not uniform and create ambiguity.• Examples:

– ARC and BOC have data storage and destructionrequirements whereas, WEB does not.

– WEB requires Secure Internet Session, 128bit RC4encryption, Fraudulent Transaction DetectionSystems, and Annual Data Security Audit.

• What about what other networks have done?

• The ACH is DIFFERENT…

16


17


Evolution Toward Holistic Security

1. Protect Sensitive ACH Data2. Deploy Access Controls3. Assess Data Security4. Verify the Receiver’s Identity5. Identify Third Party Senders

and Originators6. Deploy Fraud Management

Systems

18

Six Pillars of Data Security


The NACHA Six –Rules Recommendations

The NACHA Six Pillars of Security encompass uniform requirements thatapply, as appropriate, to ODFIs, RDFIs, Originators, ThirdParty ServiceProviders and ThirdParty Senders:

1. Protect Sensitive Data• ACH participants are responsible for protecting sensitive data• Define Sensitive Data in the Rules

2. Deploy Access Controls• ODFIs, Originators and ThirdParty Senders are responsible for deploying

Access Controls to protect Sensitive Data• Define Access Controls in the Rules

3. Assess Data Security• ODFIs, Originators and ThirdParty Senders are responsible for assessing their

data security related to ACH origination

19


The NACHA Six –Rules Recommendations(Continued)

4. Verify the Receiver’s Identity•Originators are responsible for verifying the identity of

Receivers

5. Identify ThirdParty Senders and Originators•ODFIs are responsible for verifying the identity of their

customers on whose behalf they originate ACH entries

6. Deploy Fraud Management Systems•ODFIs, Originators and ThirdParty Senders are

responsible for deploying Fraud Management Systems•Define Fraud Management Systems in the Rules

20


The NACHA Six – Guidelines Considerations

• Protecting sensitive ACH data– An overall strategy to protect sensitive data

•Retention, storage, destruction and disposal•Data masking and encryption•Firewalls•Consumer education

• Verifying the Receiver’s Identity– Initial verification of the Receiver’s identity and robust

authentication thereafter– Authentication method will differ based on several

factors21


The NACHA Six –GuidelinesConsiderations (Continued)• Identifying ThirdParty Senders and Originators

– Due diligence related to their customers both during the onboarding process and ona periodic basis throughout the business relationship

• Deploying Access Controls– Administrative controls –human factors of security– Physical controls –prevention of unauthorized personal from entering computing

facilities and protection against natural disasters– Technical controls –technology used to control access and usage of sensitive data

• Deploying Fraud Management Systems– A layered approach against fraud (multiple system, practices, and procedures)– Track payment history, behavior, purchase type, delivery information etc.– Are flexible depending on number of transactions, dollar size, relationship with

Receiver, type of goods or services sold, etc.– Look for “red flags” of identity theft

22


ACH Security Framework Action Plan

Anticipated Timeline for the Framework:– Rules

• Product Group formed in 2010• Request for Information (1Q 2011)• Request for Comment (2Q 2011)• Ballot (3Q 2011)• Proposed Rules Implementation Date (September

2012)– Guidelines

• Final Guidelines in tandem with rules proposal (2Q 3Q 2011)

23


Best Practices –Encryption

• Data at Rest and Data in Transit– Dataatrest: the state of data when in storage (e.g., any computing

environment).– Dataintransit: data that is in motion, being transferred from internal to

internal, and internal to external.

• Encrypted transfer protocols for protecting data duringthe file transfer– Secure Sockets Layer (SSL) protocol (a.k.a. FTPS or Secure FTP)– Secure Shell (SSH) protocol (a.k.a. SFTP or SSH File Transfer

Protocol).

• Encryption can also help businesses meet specificprivacy standards when sharing or transmittinginformation.

24


Best Practices –Data Destruction and Disposal

• Companies faced with competing laws, policies, and interests related toretention or destruction of records.

• But, some companies/individuals are legally required to destroy certaintypes of records that leave their possession and may be held liable fornot doing so.

• In 2005, the Federal Trade Commission (FTC) enacted the DisposalRule. That Rule is part of the Fair and Accurate Credit Transactions Act(FACTA) of 2003, which 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 fromthem, using “reasonable measures.”

• Best strategy = policies and plans for the safeguarding of PII atall touch points.

25


Best Practices –Data Leak Prevention

• Goal = prevent/minimize the loss of legally protected orvaluable data.

• Think of in terms of insurance for a company initial costcould offset the costs of an actual or potential loss of data.

• Not fullproof, but every ounce of protection is worthwhile inthe end.

• 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. Dataleakage tools can keep the person from sending the data out electronically, writing itto a USB drive or sending it to a printer. In this case, data leakage could prevent acustomer service representative from sharing large amounts of sensitive informationvia email whether intentionally or unintentionally.

26


Best Practices Mask Sensitive Data

• Identify data to be masked.• Effective data masking requires data to be altered in a way

that the actual values cannot be determined orreengineered yet the functional appearance is maintained.

• A credit card number “1234 5678 9012 3456” maskedappears as “1234 XXXX XXXX 3456.”

• Mask data when it is not absolutely necessary to validateall of the data.– For example, a call center representative only needs the last four

digits of an account number or Social Security number to verifythat account belongs to the customer on the other end of thephone.

27


Best Practices –Consumer Education

• General guidelines to assure the customer that their information is safe andsecure:

• Understand that customer expectations are that the transaction will occurseamlessly with no errors and in complete security and safety.

• At payment site or before 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.– 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, safetyand privacy should be reviewed by your legal department before publishing.

28


Checklist –Part OneUse robust authentication methods to add confidence to the entity on thetransmitting end of the interface, such as digital certificates and/or dedicatedlines.

Use 128bit RC4 (minimum) encryption of communication lines into the webserver.

The architecture of the interface should be threetiered with the web server ina DMZ. The application server should be behind an additional firewall. Thedatabase or server should be behind an additional firewall.

Manage firewalls according to industry best practices.

Use an intrusion prevention system that is monitored when the interface isactive.

29


Checklist –Part 2

All servers should meet the National Institute of Standards andTechnology (NIST) standards for hardening and include installation andmonitoring of a host intrusion detection system.

All devices (servers, switches, firewalls, etc.) should be scanned weeklyfor vulnerabilities and monitored for compliance with industry bestpractices.

Where possible the communication across this interface should be anapplicationtoapplication interface. This means that the sending andreceiving interfaces should be designed to speak to each other andprovide an expected handshake between the two systems.

Applications that face external applications or the web should beprotected by application security appliances or application firewalls toensure that requests of them are valid.

30


Checklist –Part 3

Each program in a secure interface should follow industry standardcoding practices and have passed a code review by a qualified evaluator.

Limit access to all devices to those individuals who are specificallyrequired to access the devices to perform operational support andensure the security of the interface.

Maintain tight control over access controls and audits of that access toall data (e.g., encryption at rest).

Use of data leak prevention services.

Conduct quarterly penetration testing and annual risk assessment.

31


Questions?

32


Thank You!

Eddie HoEVP, Chief Information OfficerOmniAmerican [email protected]

Fred Laing, II, AAP, CCMPresident & CEO, [email protected]

Susan PandySenior Director, Internet & eCommerceNACHA –The Electronic Payments [email protected]

33

mailto:[email protected]



data€security requirements€in€the achaz9194.vo.msecnd.net/pdfs/110401/233.pdf ·...

Documents