This document discusses data security best practices for financial technology companies. It recommends using encryption techniques like RSA DUKPT and ECC to encrypt sensitive data during transmission and storage. Hardware-based true random number generation and tamper detection/proofing is advised. Logs should be kept of all actions, APIs should have authentication, and systems must be monitored for anomalies or attacks. Inside attacks are more difficult to detect than outside attacks, so special precautions are needed to guard against insiders compromising data.
2014: Target Corporation was hacked and 40m cards were stolen. http://www.bloomberg.com/news/articles/2014-03-13/target-missed-warnings-in-epic-hack-of-credit-card-data
6 months of warning ignored
40m cards were stolen
$61m spent
46% down in sales
For moto transactions, just two fields are enough. Care to give out your card to a waiter? At least in India, these don’t work. Do a favor and call your bank to block non-2FA on your card.
Copyright: John David Guerra; http://pre09.deviantart.net/e4fa/th/pre/i/2011/158/6/1/severus_snape_sketch_3_by_jondavidguerra-d3ia0p9.jpg
Defence against dark arts
Where all we need to protect? Device level; don’t trust transmission at all; Store only what you need.
Strong encryption. Do not trust anything in between. PPK, UKPT/DUKPT etc. Multiple KeK/DeK for data storage
While designing a system that you expect to last for more than a decade, be aware that quantum computers will become a reality in a decade or so (atleast to national level organizations) which will render RSA and many schemes obsolete. Have a protocol that you can specify the encryption standard so that one can switch to quantum computer attack resistant schemes.
1. Any sensitive material in hardware/device encrypt with a random key (generated inside the device to which you have no access) and store the random key in a tamper responsive location
2. Make sure your random number generator generates a truly random number (there are well understood open source test suites, such as the one by NIST). Most random number generators have a entropy rampup (numbers are not truly random initially), compensate for that.
Do not save these! Every customer’s data is kept separated. Customer “owns” the data; we host it. Usual means of authentication, authorization, auditing.
Set auto thresholds, alerts etc. Not just for suspicious activity, spikes in CPU, Mem, network utilization etc.
Internal breaches are more costly
When a sensitive function is called assume that the function might not have executed. In addition to return values have flags or other signalling mechanisms which proves within a certain guarantee that the function was executed as intended
While doing encryption keep the input and output buffers separate. So if accidentally or maliciously encryption was skipped it sends out junk
Make sure that the code that was typed in (especially code that clears buffers which might be optimized away) is in the final object code. There have been cases wherein for loops that were used for zeroing memory would be optimized out. There are other subtler cases too. Have the discipline to check object code against source code.
DPA attacks, future proofing strength of encryption