For details on the actual Interagency Guidance, see this page.
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.
