网络研讨会：保护支付系统免受账户检测和欺诈性授权威胁.pdf

Protect the Payment System from Account Testing and Fraudulent Authorizations Stan Hui, Director, Fraud & Breach Investigations Ed Verdurmen, Director, VisaNet Processor Risk 9 August 2016 Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 1 Disclaimer The information or recommendations contained herein are provided "AS IS" and intended for informational purposes only and should not be relied upon for operational, marketing, legal, technical, tax, financial or other advice. When implementing any new strategy or practice, you should consult with your legal counsel to determine what laws and regulations may apply to your specific circumstances. The actual costs, savings and benefits of any recommendations or programs may vary based upon your specific business needs and program requirements. By their nature, recommendations are not guarantees of future performance or results and are subject to risks, uncertainties and assumptions that are difficult to predict or quantify. Assumptions were made by us in light of our experience and our perceptions of historical trends, current conditions and expected future developments and other factors that we believe are appropriate under the circumstance. Recommendations are subject to risks and uncertainties, which may cause actual and future results and trends to differ materially from the assumptions or recommendations. Visa is not responsible for your use of the information contained herein (including errors, omissions, inaccuracy or non-timeliness of any kind) or any assumptions or conclusions you might draw from its use. Visa makes no warranty, express or implied, and explicitly disclaims the warranties of merchantability and fitness for a particular purpose, any warranty of noninfringement of any third party's intellectual property rights, any warranty that the information will meet the requirements of a client, or any warranty that the information is updated and will be error free. To the extent permitted by applicable law, Visa shall not be liable to a client or any third party for any damages under any theory of law, including, without limitation, any special, consequential, incidental or punitive damages, nor any damages for loss of business profits, business interruption, loss of business information, or other monetary loss, even if advised of the possibility of such damages. Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 2 Agenda • What is Account Testing / Fraudulent Authorizations? • Testing Trends • Detecting, Responding and Reporting Testing Incidents • Key Takeaways Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 3 What is Account Testing / Fraudulent Authorizations? Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 4 Why Account Test? Threat actors test account numbers to validate cardholder information obtained through two main methods: 1. 2. Data Breaches (POS malware or system intrusion) Account Number Generators known as CreditMaster or CreditWizard Once an account number is validated with an approved authorization, the fraudsters are able to monetize the cardholder information by selling it on the Dark Web. Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public • Accounts produced by CreditMaster, or more often stolen from files or databases, lack expiration date and sensitive authentication data such as CVV or CVV2 • Accounts stolen from POS devices using memory-scraping malware lack CVV2 • 3 and 4 digit numbers may be derived by simply trying all possible combinations (brute force testing) • Brute force testing comes through acquirers in VE, LAC, AP, and CEMEA • Test authorizations are rarely posted • In a recent case, 40% of the test authorizations were reversed 5 Two Types of Testing BRUTE FORCE ACCOUNT TESTING Used to derive additional card data elements when a theft does not include a complete set Used to verify that stolen accounts are active, this is usually one authorization per account, rarely more than two, and never ten. Large batches of accounts are often tested together The smaller the data element, the more effective this type of test, so it is most often used for 3-digit Card Verification Values. Random values are declined until the right one is guessed Far more authorizations are approved during account testing, but it is still 15-30%, so velocity monitoring may be linked to the merchant , POS terminal, or e-comm portal, and set above a baseline for peak volume Many declined authorizations result in subsequent fraud, because the testers are also trying to determine whether an issuer has gaps in their risk model Almost always used to determine CVV2 and support e-comm fraud Easier to spot and impede than Account Testing by using velocity monitoring (limit declines, limit CVV2 per PAN) Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 One of the last steps before a stolen card is sold and used to commit fraud Visa Public 6 The Evolution of Testing Testing was done at payphones in an era when authorizations were verbal. 1980’s 1990’s Any computer with a valid terminal ID (8 digits) can run a script that sends authorization requests for stolen account numbers to a processor gateway. 2000’s 2010’s Now Authorizations were sent through stolen (“ghost”) terminals that dialed into a modem pool at the processor. The volume of stolen card data on the black market has kept testing alive. Testing is no longer the key to creating a counterfeit card, but to defining its value. Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 7 Testing Facilitated Through Fake Merchant IDs 11 % 66 % Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 8 Testing Trends Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 9 Brute Force Testing – U.S. Represents 60% Brute force alarms between January 2015 March 2016 Other U.S. • 58% came from the U.S. PROC U.S. PROC C • 18% from CEMEA 16% 5% • 11% from AP • 9% from VE U.S. PROC B • 4% from LAC LAC 4% 14% In the U.S. • 23% came from Processor A • 14% from Processor B • 5% from Processor C • 16% from Processor D-G combined Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public VE 9% AP 11% CEMEA 18% U.S. PROC A 23% 10 Brute Force Testing CVV2 Testing by Month May'15 Jun'15 Jul'15 Aug'15 Sep'15 Oct'15 Nov'15 Dec'15 Total Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Jan'16 Feb'16 Mar'16 Apr'16 May'16 Jun'16 Non-U.S. Visa Public 11 Detecting and Responding to Testing Incidents Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 12 What Testing Looks Like to Each Party Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 13 Issuer Mitigation Controls Test inappropriate Card Verification Values whenever products introduce new codes • • • Test transactions with missing values Track and analyze the behavior of tested cards before and after testing Integrate testing events into Cardholder Alerts programs Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 14 Additional Issuer Controls • • • • • • • Conduct real-time velocity monitoring and notify the acquirer and brands of account testing Monitor Card Verification Value and block unused channels (i.e. if you do not issue contactless cards, do not permit verification via POS entry mode 07) Validate expiration dates for all authorizations Monitor authorizations by BIN for anomalies Investigate rapid increases of authorizations without clearing messages Identify and research all credits without offsetting sales Monitor the rate of authorization reversals at each BIN, block reversals that exceed established thresholds Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 15 Acquirer Mitigation Controls Include merchant gateways in existing penetration testing efforts • • • • Have the pentester try to set up a fraudulent merchant terminal Segregate merchants, if possible, so merchant terminals and IDs can be changed without affecting other merchants Limit the legitimate volume a Point-of-Sale can support - especially e-commerce terminals (Black Monday) Include merchant and merchant terminal shutdowns in Incident Response testing Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 16 Additional Acquirer Controls • • • • • • • • • • Monitor merchants for anomalies in transactions Maintain strict inventory control of terminals Protect merchant credentials by issuing strong user IDs and passwords for payment gateway portals Do not print terminal or merchant ID on receipts Monitor velocity by account and merchant Investigate rapid increases of authorizations without clearing messages Confirm that incoming transaction data is delivered via the proper channel (e.g., dial-up versus SSL) Suspend and research credits without offsetting sales Monitor the rate of authorization reversals at each BIN, block reversals that exceed established thresholds Monitor testing of CVV and CVV2 thresholds to ensure individual accounts are not susceptible to brute force testing (e.g. over a handful of retries) Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 17 Communicate, Communicate, Communicate Issuers Develop operations contacts at acquirers that have been the targets of testing: • Share data on losses • Identify key resources • Agree upon thresholds for reporting and acceptable response times for taking action Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Acquirers Convene periodic meetings between systems, security, and operations staff to review extended merchant infrastructure. Plan to: • Plug security holes • Upgrade and replace old systems • If you have not been attacked, but the system is old, have a triage plan to manually identify and shut down compromised terminals Visa Public 18 Reporting Testing Incidents Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 19 How to Report Testing Incidents to Visa 1. Confirm the issue is actual account testing and not a Common Point of Purchase (CPP) identification or recurring transaction testing 2. Requests to address chargebacks or schemes involving smaller volumes of authorization requests should be handled through standard fraud reporting, reissuing, and chargeback processes. 3. The issuer should try to contact the acquirer of record directly by using the Visa Interchange Directory contact details 4. If the VID information is not current and the issuer cannot get in touch with the acquirer to report the issue, the issuer can submit a request to Visa to report the issue to the acquirer. 5. The issuer must complete the account testing form before Risk will contact the acquirer or acquiring processor (do not send account numbers). The account testing investigation request must meet the following thresholds to be investigated by Risk: a) The incident of testing activity must be within the past 3 months b) Incidents must have more than 50 transactions attempted c) Incidents must have more than 10 account numbers attempted Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 20 How to Report Testing Incidents to Visa (cont.) The account testing form must accompany an email providing all the following details: • Overall duration of event (start date, peaks, end date if applicable) • Overall number and value of fraudulent authorization attempts (assuming the file is a subset, please provide recent, monthly totals) • Overall number of accounts tested • Confirmed fraud losses, if any The account testing form must include all the following details: • • • • • • • • • Card Acceptor Terminal ID (aka merchant terminal ID, field 41) Card Acceptor ID (aka merchant ID, field 42) Transaction date and time Issuer BIN(s) Acquirer BIN POS Entry Mode CVV type CVV approval\decline Authorization approval\decline\reversal Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 21 Incident Report Form Forms should be submitted to USFraudControl@visa.com Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 22 Key Takeaways • Criminals use testing to establish the value of stolen cardholder data or randomly generated accounts • Two types of testing – Brute Force attacks, Account Testing • Weak merchant authentication or provisioning can be exploited • The majority of testing occurs with U.S. acquiring processors • Issuers can use real-time velocity monitoring to identify testing; review for authorization anomalies • Have stronger merchant / terminal provisioning processes in place; implement velocity monitoring by account and merchant, implement thresholds for CVV2 attempts • Issuers need to develop operations contacts with acquirers to quickly communicate testing incidents • If reporting testing incidents to Visa, ensure all thresholds are met and relevant details are provided Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 23 Upcoming Events and Resources Resources • 13 August 2015 VBN – Clients Must Actively Prevent Fraudulent Credits • 23 June 2016 VBN – How to Protect the Visa Payment System From Fraudulent Authorizations Visa Data Security Website – www.visa.com/cisp • Alerts, Bulletins • Best Practices, White Papers • Webinars PCI Security Standards Council Website – www.pcissc.org • Data Security Standards – PCI DSS, PA-DSS, PTS • Programs – ASV, ISA, PA-QSA, PFI, PTS, QSA, QIR, PCIP, and P2PE • Fact Sheets – ATM Security, Mobile Payments Acceptance, Tokenization, Cloud Computing, and many more… Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 24 Questions? Protect Against Account Testing and Fraudulent Authorizations I 9 August 2016 Visa Public 25