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.

Making the case for Single Sign On (SSO) and Biometric authentication

May 15, 2008

I started to discuss Enterprise Single Sign On (ESSO) with credit unions three years ago, and since then I have been to Burton Group to learn about Identity Management from the inside out. I learned about how I could integrate identity management with existing security practices for “budget constrained” credit unions. The key that I was looking for was a simple, easy, and properly built solution that could be integrated into medium-to-large credit union environments for less than $25,000-$35,000 — including services. I was looking for non-script based and non-programmed solutions since I knew that cost escalation would kill SSO efforts for credit unions very quickly.


Enterprise Single Sign On (ESSO) – ESSO is simple since it is a non-programmed way to handle SSO, thus making it much easier and less complex.

Single Sign On (SSO) SSO is a programmed method of performing SSO with the key difference of having the added functionality to handle forced role-based authentication directly into applications themselves from the network. This is the Holy Grail – for the big boys and serious budgets!

I look at ESSO as “the poor man’s single sign on”, however don’t be fooled into thinking ESSO is of lesser quality to SSO. ESSO is incredibly powerful and quite a compelling approach to what I would call “Reduced Sign On” versus “Single Sign On”. Credit Unions should consider ESSO/SSO options when experiencing the following problems or increased needs:
1) The help desk is having to handle too many password reset requests. I once worked with a credit union that justified costs due to this issue alone.
2) IT (believe it or not) is handling an extraordinary number of passwords.
3) The desire exists to integrate physical and network security (very cool and doable these days).
4) Compliance Drivers, meaning you have a desire to monitor, track and perform forensics on network and application access.
5) A need for increased security due to IT being unable to enforce a demanding password policy.
6) A need for increased security that will not see employees leaving passwords lying around their office on notepads.
In summary there is the coolness factor to SSO and ESSO, but for me the credit union winning punch here is the compliance win and the ability to integrate biometric authentication with the solution. I am not sure I believe entirely in the concept of SSO and this is why I like ESSO since the application still drives the final layer of security.

ESSO has the ability to layer biometrics on top of the authentication, making it an appealing solution since one gains the compliance uplift, plus the added “I know who you are” factor from the biometric stand point. Ultimately, my vision has always been to concentrate on the directory security needs in an organization. For my credit union clients this is usually accomplished via Microsoft’s Active Directory. From a de-provisioning perspective, it is quite appealing that once a user account is killed in AD then they are in effect “locked out” of the network. It is very nice indeed to have all devices on the network just as directory-aware. Furthermore, if you are allowing Citrix or another remote access, this centralized AD security approach works well since once an employee or contractor is terminated then all IT must do is terminate the account in AD and the remote access is terminated as well. For credit unions with overburdened IT personnel this makes for simple, effective and clean security.

SIP Strategy: Part Two – Intelligent Perimeters

April 24, 2008

Part one (client integrity) is here.

The following are some questions to ask yourself as you develop the second step of your Security, Identity and Privacy (SIP) Strategy.

Identity-Aware Perimeters

1. What is this? What does it mean to me?

2. What external systems need access to my network? What rights, permissions, and privileges do they need? How do I protect myself if they are compromised?

3. Are interfacing DMZs deployed for network segmentation with Internet customers, partners, employees or partners?

4. Has a detailed cable trace been done to validate the DMZ?

5. What firewall is used?

6. Do the firewall rules properly accommodate your DMZ?

7. Is the version level up-to-date with what the manufacturer is offering?

8. Does a higher version give you a higher level of protection against organized crime?

9. Are services like e-commerce, home banking, and other systems hosted in the DMZ?

10. Should there be any concerns regarding the architecture? 

11. On a scale of 1-10 how does your DMZ meet security policy at the organization?

12. Where does standard VPN access terminate? Has this been reviewed?

13. What about client PC to site access? Site-to-site? Partner-to-site?

14. Is there adequate Avian Flu readiness?

15. Are Proxy Servers used? Why?

16. Are application firewalls used? Why?

17. How are viruses, malware, spyware, and content management handled at the perimeter?

18. Are you using the perimeter to enforce email policy? This would likely be for outbound email hygene, like protecting against phishing. Is your perimeter AD directory aware?

19. How is your messaging system deployed as it relates to the DMZ? What about the front-end and back-end design? SMTP Gateway? OWA?

20. Where do you scan for viruses? You will want to consider e-mail encryption, proxies, and SharePoint.

21. Has the organization developed a philosophy regarding the deployment of appliance UTM (unified threat management) boxes?

22. Is there a proliferation of seemingly overlapping devices on the network edge?

23. Has the network edge become difficult to manage?

24. Do you prefer appliance strategies or software with perimeter defenses?

25. Where do your organizational skills lie? Microsoft/ Linux/ Other?

26. Can the DMZ be replicated at the DR site? If not, what aspects of it are needed? How manual will it be?

27. What is the philosophy regarding a PC anti-spyware program versus an “in-line” approach to anti-spyware?

28. Do you outsource any aspects of perimeter defense (Firewalls, SPAM, AV)?

29. How are IDP/ IDS/ IPS deployed?

30. Where are IDP/IDS/IPS deployed? Inside or outside the network?

31. Do you outsource these services? Why?

32. How are logging, monitoring, and forensics/reporting handled?

33. Is management of security devices centralized?

34. What about remote site firewalls?

35. Have you considered VPN client end-points? SSL VPN clients?

Stay tuned for part three: Identity Access Control.[C1] 

 [C1]Here you can link to part three

Remote Access, Compliance, Security, and Disaster Recovery all in ONE!

April 21, 2008

This week was interesting. In the latter half of 2007, I worked with a $400 million credit union to develop a 2-year road map for budgeting and IT strategy. I’d worked closely with the credit union EVP to formulate and solidify his thoughts in strategic areas for the executive team and board. Business optimization was the goal for each and every IT decision.

Together we had made the shift from direct integration support to blending integration with a more proactive planning approach, including an IT roadmap to development for the next two years.

What made this remote access decision interesting was to observe how the credit union turned a seeming tactical/technical decision into a brilliant strategic decision. Here’s a summary of the situation.

Overview of the problem:

* 25 remote access users need remote access to the credit union network.
* SSL certificates are expiring.
* Simplicity and security are paramount at the network edge.
* The edge device has to be an intelligent perimeter to aid the inspection engine.
* Avian Flu remote access support is needed.
* There is a DR bump license requirement.
* Legacy Citrix remote access technologies are in place (including CSG, NFuse, and cert server) and there is no desire to move to a newer weak Citrix remote access product.
* 3 quotes are needed from 3 quality vendors
* Integration with two-factor authentication is needed
* DR site integration.
* Tight Citrix integration.
* Ease of management.
* Full client integrity and security policy enforcement is needed at the end points.

So I arranged for 2 new SSL VPN product demonstrations. The credit union IT team reviewed product demos from Citrix, F5 Firepass and Sonicwall/Aventail.

How can an SSL VPN be strategic?

In a previous blog entry I spoke about the importance of client integrity for credit unions as they develop their security strategy. My company and I have been recommending and integrating SSL VPNs for about 6 years now and have seen the client integrity aspects of these products morph and change quite a lot. Read my previous blog on SIP and client integrity to get a list of questions that you need to ask when reviewing solution sets in this security category.

When it comes to strategy, however, make sure you look at SSL VPNs from the “end game” perspective. You need to ask yourself:

1. Do I need to have a remote access plan in the event of a disaster?

2. How do these devices communicate with one another from HQ to the DR site, and how do they keep their access policies in sync?

3. Which one is most maintainable and supportable by your internal staff?

4. Do they have a virtual appliance strategy?

5. Can I incorporate this technology into my virtualization strategy?

6. How far can you stretch $1.00 of spending in regards to your roadmap for Security, Disaster Recovery, and Infrastructure?

7. What does the management interface look like?

8. How do you set up a security policy? For example, what will be the security policy for remote access users at a conference, on a trusted laptop versus un-trusted device like a kiosk?

9. How will you enforce security hitting Exchange OWA versus Exchange using Citrix?

I hope that that helps. My point as always is to never, ever, make an IT decision on technology alone. Always make the business a partner.

SIP Strategy: Part One – Client Integrity

April 2, 2008

The quickest way to develop an enterprise-wide Security, Identity and Privacy (SIP) strategy is for a credit union senior executive to lose one of the following: PC, laptop, cell phone, or blackberry.

That may seem a bit sarcastic, but I think that many credit union senior executives think that perimeter security is a firewall and maybe an IDS/IPD/IDP system. The notion of security through a solid perimeter around a well-defined protected network has disappeared: the walled medieval castle concept is dead.

The perimeter has not disappeared – it has expanded to include mobile devices used in today’s credit unions. Perimeter security is now a combination of traditional perimeter mechanisms and end-point security.

So how do you take control of end-point security? My opinion is that you can’t — at least not with the credit union security and networking budgets that I see. You can, however, take control by developing a plan to control end-point device security.

Start developing your client integrity plan by asking the following questions:

1. Who will be the users? This includes internal employees as well as external employees from homes, other officers, kiosks, hotels, and Starbucks. In addition, thought should be made about remote partners including LAN and remote accessing by consultants.

2. What is your philosophy for desktop/laptop management? This would encompass antivirus and anti-spyware software, patches, version updates and upgrades, backups, and firewalls.

3. How do you extend applications to these users? This means connectivity, such as cable, WAN, web, and DSL.

4. Can we trust the individual? You need to set out grounds for enforcing trust, such as through biometrics or Two-factor authentication (T-FA).

5. How can we trust the machine? Does it have anti-spyware and antivirus protection from key-loggers, malware, and trojans? Is the operating system up-to-date, including the latest patches, versions, upgrades? Is there a remediation process for when a user tries to access the network using incorrect anti-virus versions?

6. Is security management centralized? This means PC anti-spyware and anti-virus, as well as personal firewalls.

7. How do you know if a contractor meets security policy? Are there products being used for this?

8. How are patch distributions handled? Packages might include SUS (software update services) or WSUS (Windows server update services).

9. How are version updates to an application handled?

10. How is the cache cleared from un-trusted public access points? An example might be a conference.

11. How is an un-trusted LAN user’s machine checked before accessing the network?

12. Are firewalls used on client machines? If yes, why? If no, why?

13. What are your plans to consolidate end-point security into one centralized management console? Centralization might need to occur for home users or remote sites via VPN.

14. Do you prefer diversity in defense security-wise or a single vendor’s throat to choke when things go wrong? I know that sounds harsh, but there is no humor in headlines like this.

15. How is AD (active directory) used to lock down the desktop? Group policy needs to be discussed, as well as permissions.

16. How advanced would you rate your administrators in this area?

I’ll go over the remaining steps involved in developing and executing your Security, Identity and Privacy (SIP) strategy in future posts on this blog.

Blueprint for a Multi-Year Security, Identity, and Privacy (SIP) Strategy for your Credit Union

April 2, 2008
When I visit credit unions one of the biggest challenges is that the current IT diagrams don’t match reality. Why would this happen? I’ve observed that most credit unions have inherited their IT foundations from years and years ago, and through the years many hands have touched, moved, re-routed, and re-booted products and systems so many times that there is little confidence left in the network.
                                                                                                                     So here, as promised, is a blueprint for developing a multi-year Security, Identity, and Privacy (SIP) strategy for your credit union.
SIPS Blueprint
SIPS Strategy
The first question is the obvious one: can you adhere to the IT security policy of the NCUA without breaking your budget? What if you don’t have an IT strategist on staff? Can you ensure IT security alignment is strategic and planned rather than reactive? Remember that security is about design and architecture not product selection. A CEO and the board of directors should be able to see that decisions are not merely based on the latest media threat but are being made based on a strategic security framework.

It is my belief that you can use architecture alone to accomplish 75% of NCUA regulatory requirements. How is this possible?

A lot can be accomplished through the proper positioning and correct usage of current networking and security devices. Oftentimes proper redeployment of pre-existing software and hardware can accomplish the job quite easily.

A credit union must consider all aspects of security architecture before acquiring products. Simple questions asked up-front can drive product decisions for years (see August’s postings on “Questions to Ask”). Similar to building a home, an executive should expect an organization to apply principles of architecture and design, especially in regards to security architecture, when developing a multi-year security program.

My intent is that you will gain the following wisdom from the blueprint shown above:

1. Require your IT staff to communicate business alignment purchasing decisions.                                                                                                               2. Develop a multi-year plan.
3. Follow the multi-year plan.
4. Set budget milestones.
5. Communicate the vision for what you want to accomplish.
6. Get out of fire-fighting mode and into strategic management.
7. Purchase products as part of your strategy, not as a reaction to a problem.

In my next post, I’ll cover the topic of client integrity – the first item in the blueprint diagram above.