A Sample Multi-Factor Authentication Risk Assessment
Updated 03/12/10.
For regulated financial institutions, it is becoming clear that the FFIEC Interagency Guidance on Multi-Factor Authentication is not current with the present threat landscape. Multi-Factor Authentication has long been understood to be an ineffective control against Man-In-The-Middle Attacks. The Guidance leads one to believe that true Multi-Factor Authentication is preferable over what the Guidance calls “Layered Security.” The latter includes such technologies as transaction monitoring for anomalous activity, IP address geolocation and other indicators of malicious activity. For details on the actual Interagency Guidance, see this page.
Small business banking customers usually maintain large account balances to support and operate their businesses, including payroll and accounts payable. Small business banking customers are a current favorite of online theives because of these large accounts. Further compounding the problem is the reality that small businesses are most likely to lack critical information security precautions and controls. As such, small-businesses are much more likely to suffer malware infections on company PCs.
Security blogger Brian Krebs has this to say about the Zeus trojan:
“In every case I have investigated, the crooks had installed malicious software — usually the ZeuS Trojan — on the victim’s PC. This allows the criminals to control what the victim sees in his or her browser. ZeuS will re-write the bank’s HTML on the fly, and inject HTML elements into the bank’s page. Mind you, they are not altering the bank’s real site — just what the victim/customer sees.”
Zeus infects an information security company.
In conducting Multi-Factor Authentication risk assessments, pursuant to the FFIEC Guidance, and as expected and enforced by financial regulators, we need to consider the current wave of successful attacks against small business customers. Where the assets at stake are particularly lucrative, the “Layered Security” components of the MFA Guidance will likely be more effective than the use of true Multi-factor authentication. The key will be implementing a near real-time response to transaction monitoring triggers to stop any anomalous transactions before the money leaves the financial institution.
Original Post regarding a Basic MFA Risk Assessment:
Hopefully you have some semblance of an application inventory.
Filter your apps on three criteria:
- Any application facing the Internet that is accessed by customers, AND one of the following:
- Can the customer access his or her own personal information (SSN, DOB, Acct #, Name, Address, etc.; these attributes should already be defined in your organization’s information security policy)? OR
- Can the customer initiate a movement of funds to another party?
This should give you the entire population of applications in scope for multi-factor authentication (MFA) analysis. Tier your results according to the following prioritization scale:
- Internet facing applications that allow both funds movement and access to personal information;
- Internet facing apps that do NOT move funds but still allow access to personal information;
- Further tier these apps according to the types and combinations of personal information available. For example, toxic combinations of multiple elements vs. single elements.
This is just a simple example, obviously your tiering could be more complex and varied. Once your tiering is complete, there is an imaginary line where all the apps above the line need to be brought into conformity with the MFA guidance and all the apps below can be justifiable excluded based on low asset value (low risk transactions).
The Interagency Guidance for MFA requires three outcomes:
- Implement true two-factor authentication
- Implement Layered controls
- Implement “other” compensating controls
For your higher risk apps, according to your tiering, you should do item 1 or 2. For lower risk apps, look at doing 2 or 3.
The “layered” controls approach can be interpreted (but it will depend partly on your examiners and their style) as a totality of control in place to protect customer information. If you already do a risk assessment for info sec or GLBA or something else, you can leverage that. Totality of controls, layered security would certainly include the SOX general computer controls, so leverage that documentation if you have to.
The “other” controls, in my opinion is the regulator’s response to push back from the industry to stop short of mandating MFA. In other words, if you can make a good argument why you don’t need MFA and that current controls exist that are effective enough, given the risk profile of the application (asset value, data at risk, type and number of transactions, etc.) you are good to go.
