Data Risk Governance

Exploring the intersection between information security, privacy, technology and the law.

  • Categories

  • Copyright 2009-2013, Matt Sorensen, All Rights Reserved

    Site Launched March 2009

    DISCLAIMER: The opinions expressed here represent those of Matt Sorensen and not those of Matt Sorensen Law or its clients. Similarly, the opinions expressed by those providing comments are theirs alone, and do not reflect the opinions of Matt Sorensen, Matt Sorensen Law, or its clients. All of the data and information provided on this site is for informational purposes only. It is not legal advice nor should it be relied on as legal advice.
  • Major Works

  • Archives

  • Meta

Multi-Factor Authentication: Satisfying the Interagency Guidance (Financial Institutions)

Posted by Matt on August 25, 2009

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:

  1. Any application facing the Internet that is accessed by customers, AND one of the following:
  2. 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
  3. 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:

  1. Internet facing applications that allow both funds movement and access to personal information;
  2. Internet facing apps that do NOT move funds but still allow access to personal information;
  3. Further tier these apps according to the types and combinations of personal information available. For example, toxic combinations of multiple elements vs. single elements.
a. SSN + DOB + Name + Address + Mother’s Maiden Name
b. Name + Address + Account #
c. Name + Account #
d. Name only

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:

  1. Implement true two-factor authentication
  2. Implement Layered controls
  3. 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.

Leave a comment