Red Flag Identity Theft Alert – Not Such a Big Deal to Solve

July 1, 2008

The Deadline for compliance of 12 CFR part 717 is November 1, 2008.

A very good client of mine brought this to my attention recently. I see very little forward momentum within my clients in terms of implementing solutions that satisfy compliance requirements. The following is a passage taken from

Section .90(b)(9) Red Flag. The proposed regulations defined “Red Flag” as a pattern, practice, or specific activity that indicates the possible risk of identity theft. The preamble to the proposed rules explained that indicators of a “possible risk” of identity theft would include precursors to identity theft such as phishing,\21\ and security breaches involving the theft of personal information, which often are a means to acquire the information of another person for use in committing identity theft. The preamble explained that the Agencies included such precursors to identity theft as “Red Flags” to better position financial institutions and creditors to stop identity theft at its inception.

As I mentioned in a previous posting, e-mail encryption solutions will suffice. The solution needs to incorporate the following components:

  • Be located at the network’s choke point
  • Be able to integrate with identity sources within the credit union via a tap 
  • Have a financial lexicon engine that automatically blocks and/or encrypts sensitive personally identifiable information.
  • Have the ability to discriminate between a social security number in context and a random set of numbers.


Believe me, all solutions are not created equally. I have seen several solutions, and I love one of them, but I have also seen others fail. 

If there is enough interest I will delve into product specifics but for now I will let my comments above stand.


Ensure Encryption Compliance with NCUA and FFIEC

July 1, 2008

Developing a business case for email encryption? Does e-mail encryption compliance seem like a constant battle?

The guidelines are very specific and I have cited them below. I captured the following bullets from the IS&T Checklist for IT titled Security Program:

  • Is sensitive data encrypted during member sessions and when it is transmitted or received via the Internet and over the credit union’s network?
  • Are policies and procedures in place that describe how and when encryption should be used to protect transmitted and stored information?
  • Are password files stored in encrypted format on a server that’s securely separated from Internet-facing servers?
  • Is encryption methodology tailored to specifically protect data deemed sensitive?
  • Are the locations of assets (servers, telecommunications equipment) analyzed to ensure that security is appropriate based on the sensitivity of the information stored on the asset?

From the FFIEC Information Security Booklet the following expectations are stated:

“Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include:

1) Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk.

2) Effective key management practices.

3) Robust reliability and appropriate protection of the encrypted communication’s endpoints.”

I find very little consistency with regulators in mandating e-mail encryption. I have heard small credit union clients say to me, “Bill I need e-mail encryption, what do you recommend? I need it now.” I have heard from my larger credit unions, “well we are going to wait and see what the auditors say to us.” It might seem odd, but this kind of inconsistency is nothing new.

My general recommendation is that the following criteria should apply when choosing an e-mail encryption solution:

1) The solution should be the choice of Federal FFIEC regulators. The FDIC, OTS, OCC and NCUA all use ZixCorp to secure their email.

2) The solution should have over 400 financial institutions as customers.

3) The Email Encryption Service should allow seamless, secure email communication with partners and customers who are members of a master directory hosted in a SAS 70 Type II facility. Translated into plain English, this means instant secure communications with your federal regulators.

Risk Management and Increased Security

States continue to introduce security legislation to help protect consumer privacy.  The e-mail encryption should help protect this data with email encryption solutions that also help you benefit from: 

  • Risk management;
  • Security best practices;
  • Reduced liability;
  • Avoidance of fines and bad publicity;
  • Customer loyalty retention

Automatic Content Scanning is both accurate and convenient. The Email Encryption Service should have built-in lexicons that automatically detect and encrypt messages that contain personally identifiable information. It’s invisible to end users and helps prevent accidental transmission of confidential data, including: 

 Personal financial information

  • Social security numbers
  • Account numbers
  • Credit card numbers
  • Financial terms

 Purchase Options

 I believe that any credit union worth less than $150 million in assets should be considering a managed e-mail encryption system versus owning and buying the technology itself. Smaller credit unions can simply buy the encryption as a service and not have to pay for hardware to support the solution. Once a credit union exceeds $150-$200 million or 50 to 75 employees, then owning the e-mail encryption devices and placing them on its own network makes the most sense. There are a variety of reasons for this that I will get into another time if there is enough interest.