Disaster Recovery Are you thinking about it ? Are you planning for the worst? If not, you should be! - Part 3

Let us look at the final hypothetical in our three-part series on dealing with disaster and most importantly, how to recover from them!

Your organisation engages the services of a reputable, American based, payment gateway provider for the transacting of credit card transactions. Around 50 percent of your organisation’s revenues are processed via credit card.

The website, hosted by a third party, is the primary collection point, which includes several webforms, collecting confidential information. (names and addresses, dates of birth etc). The website uses JotForm forms, which are “plug and play” forms, hosted on a shared platform in the United States.

Additionally, several IT staff had left the organisation in recent times.

Situation: You receive an email from  your payment gateway provider, through a shared email account (the email account of a staff member who has left over 6 months prior), that that your account has been flagged as a result of ta verification attack.

Hi Fred,

Your account flagged because of a ‘verifications attack’ that is taking place against your website. Yesterday, many verifications took place on your merchant gateway in quick succession. In our experience, this activity is consistent with unauthorised individuals trying to use your website to test large numbers of credit cards to check their validity.

Due to the severity of the attack, we are requesting your immediate action to resolve this issue. Please provide us with the steps you are taking to address this activity and prevent it from recurring in the future.

Please let me know if I can be of any aid or if you have any questions. I look forward to your response.

Regards

Alexa

Here is what I would do – Would you do the same?

Short-term

·  Verify the information / the sender with a phone call – could this  be an attempt at fraud to learn the company security protocols

·  Verify the actions the payment gateway/ website provider has already undertaken or should be undertaking as per the supply agreement (blocking IP addresses, blocking transactions over a threshold, CCV verification, blocking transactions from blacklist countries etc)

·  Verify information about the attacks including the number of attacks. Were any attempts successful and if data has been compromised?

·  If there is a breach, then enact the Disaster Recovery Plan (DRP) and start cyber insurance protocols, if held.

·  Figure out the size of the breach and plan accordingly for contacting customers etc.

Medium-term

I’d then want to undertake serious perform post-incident reviews with recommendations along the lines of:

o Review agreed protocols in supply agreement with payment gateway to figure out if amendments need review

o Ensure that no payment data is stored on servers, and that once payment is completed, it is removed

o Review off-boarding procedures for employees

o Instigate compliance checks of the website and payment gateway to ensure they are PCI and PII, PCI DSS level 1 compliant

o Instigate checks of security protocols and SSL to ensure they are active on the website and that data is encrypted both at rest and when active

o Review JotForm security protocols

Update DRP with any learnings

Strategic (Longer Term planning and thought starters)

1.     Move the website and hosting of the payment gateway to Australian-owned companies so that they fall under Australian law

2.     Utilise a gateway associated with the company’s banking organisation with payer authentication (Beagle from eWay, Falcon from ANZ etc.)

3.     Institute data protection and cyber event insurance if not already active

4.     Further consider:

a.     Device Finger Printing – e.g. can the device the request is being made from, verify the card based on Finger Printing

b.     Verify card against known blocked lists

c.     Fraud Scoring Models

d.     Block transactions from known countries where fraud occurs

e.     Block large transactions or introduce further verification steps

f.      Block multiple cards tries in X period X number of tries from an IP Blocking velocity checks

I am keen to hear your thoughts.  Have you been in a comparable situation? What did you do? Have I missed something here?

We hope that the situations have never happened to you. If you have never thought about disaster recovery for IT in particular or for you company in general perhaps it is time to content with me here on LinkedIn or via the MR&A website www.matthewryanandassociates.com.au