Can anyone help point me to some guidelines on either present or future regulations for WAN connections. Things that talk about security and encryption. What I am specifically looking for, are there going to be any encryption requirements for data traveling across frame connections? These lines may be "private" frame connections, but they still travel through a public telephone infrastructure. Or can anyone share their thoughts and what they are doing. Any help is greatly appriciated.

We leave the whole thing to our outsource entity, Fiserv - they maintain the firewall and all the other security required to assure that access is by authorized people. We use Sonicwall to connect to the internet.

According the FFIEC, there are no "specific" guidelines as to whether Frame Relay telecomm should be encrypted. What they do imply is that you should use encryption consistent with your own information security risk analysis and within the limits of your budget.

Although Frame Relay is considered to running on the Telco's network - it is a switched packet service so there is a chance for your data to be mixed with another's - my opinion is encrypt it all of your WAN connections.

FFIEC link to InfoSec - go to "Encryption"
http://www.ffiec.gov/ffiecinfobase/booklets/information_secruity/information_security_low_res.pdf

Use a point to point circuit.

HERE is an excellent FDIC document (19 pages) that provides an overview of the client/server environment with the last few pages providing insight into risk issues that need to be considered and addressed.

This is one of my favourite topics....

Here's my forecast: it's only a matter of time before the regulators FORCE everyone to encrypt ALL internal bank traffic that goes through public space (which will include frame-relay as well as T-1 type connections).

How dare I say that!

It only makes sense. Let's look at the facts of the matter.

1) Frame connections and "private lines" (or T1's or whatever) all go through a variety of telco facilities; central offices, switching stations, relays, etc. These facilities can be accessed by a wide variety of people that have not undergone ANY specific background checks. In addition in most cases these same facilities are accessible by not only personel of 'your' telco but also of other CLEC's etc. that are sharing the space. Clearly this physical safeguard problem is not going away.

2) Encryption is CHEAP. It didn't used to be but it sure is now.

3) It's very easy to compromise any of these connections if you have physical access and the right equipment. Ok, so your run of the mill teenage hacker might not have this stuff but who says criminals won't spend some cash to get a "return on investment"?

Nuff said..... It's simple. Low cost of repelling a materially dangerous attack. So why am I so confident it's going to regulated that way?

1) We've already got it in place for ATM networks. (as an aside.... We're on our second iteration of encryption on the ATM networks - why? Because there is a REAL risk and it's not fairly easy to mitigate materially against it.
2) HIPAA already does it to the health industry.
3) Regulators like stuff like this.

For what it's worth there is no material security increase in a T1 (private line) vs. a frame connection. The real risk is access to the infrastructure where either can be compromised easily.

I really like to 'think' through the attacks. Here are some things to think about.

Q) Your connection (T1 or Frame or whatever) goes down at 3:30am for 4 minutes then comes back up clean. What happens?

A) You thank your higher power for the connection coming back up and go back to sleep. - Of course you now have an uninvited guest on your network infrastructure.

Q) A van that 'looks' like your local telco van parks in front of a nearby roadside exchange box (those silver things on the side of the road). Someone puts out cones, etc. A police car drives by. Another telco van drives by. What happens?

A) Nothing... they don't know everyone that works for the telco, nor do they care... oh... and you've got an uninvited guest on your network infrastructure again.

It's just way to easy to pull of the attack NOT to encrypt everything given the minimal cost of doing so.

Just my 2 cents. (btw - it's 12:30am so I'm not sure how coherent the above was...)

Perfectly coherent. BTW, I am the 1st anon poster above. What I have found in my practice, and Ipso alluded to it above, is that many banks place their faith in the capabilities of their core providers to provide security solutions for the IT infra/extra structure. I have not only found extreme negligence on behalf of these service providers, but also complete disregard for industry best practices for IT/Info Security.

One case in point, I advised one of our clients to encrypt the branch to HQ and HQ to the core provider's data center links. The technical chief for the core provider told me and the bank that our design was overkill - this provider was responsible for design and support of the bank's network. It turns out the core provider had not engineered and wasn't prepared to offer an encryption solution to their clients - they do now. This is a well known, national, core provider with hundreds of bank clients.

Bottom line, banks must be aware and must demand these improved security services from their provider if they are not handling in house.

Don't get me started on what the regulators should be doing to address this through the MDPS (Multiregional Data Processing) exams.

-g

Hi, I'm a newbie. Just had to throw my two cents in. You might want to check out www.x9.org for the ansi standards for Financial Institutions.

“Accredited by the American National Standards Institute (ANSI), X9 develops and publishes voluntary, consensus technical standards for the financial services industry. X9's inter-industry voting membership includes over 300 organizations representing investment managers, banks, software and equipment manufacturers, printers, credit unions, depositories, government regulators, associations, consultants, and others.
X9 develops Standards for check processing, electronic check exchange, PIN management and security, financial industry use of data encryption, and wholesale funds transfer, among others. Standards under development include electronic payments on the internet, financial image interchange, home banking security requirements, institutional trade messages, and electronic benefits transfer.”

Hope this helps.
MJ

I dwell on those "things" for a living.

-g

In a former life I managed the IT for a large regional bank - and I was also responsible for over 230 WAN comm circuits of all flavors - and if it is any consolation, it sure CAN be confusing.

Getting to my point, I've found that either knowing how yourself or having someone on your side that knows how "things" work, can make the management of the WAN comm (and particularly the finger pointers/phone companies) much easier and mitigate a bunch of the risk and angst.

-g

No really... The actual technology needed for encrypting a link (up to say a T1's worth of bandwidth) can be sourced for under $400 for reasonable stuff. You can even do it for free from a technology perspective if you know how. The only catch is managing it and keeping up with updates, changes, etc. It's slightly more expensive than managing the connection itself but only just slightly and I don't think $200-$400/site is a whole lot to spend.

Yep... I'll stick with cheap.

Your right on with saying a hacker can identify what you are using. It's trivial and very precise. There are some great tools that will even allow a fingerprint of an OS/Device to be made based on it's timing, sequencing and response paterns.

As to the device(s) in question. I disagree that the 'regulators love' any product. If they do they are missing the point. It's process and management that matters. Function is FAR more important than form on this one. A well managed security device which might be less feature rich is MUCH more likely to be effective than even the most feature rich security device managed poorly.

I see this all the time with people saying "but I already own an X". How are you using that X? Who is reading it's logs? Patching it? Configuring it? Testing it? etc. etc. etc.

To reiterate the mantra: Security is a Process, not a Product.

I'm really not speaking as a vendor on this one. Yes - we will get involved in this stuff but I've told clients over and over again that when it comes to the encryption of WAN links they are far better off doing 'something' than doing nothing. Point being that price shouldn't be a valid reason for not encrypting those links. Ok.. so maybe you won't be doing everything the 'best' way but at least you are materially adding to the effectiveness of your layered security model.

A well designed and well managed layered security profile is the best 'hacker control' you can have.

I'm frustrated when I see people selling 'hacker control' products that lead people to believe that 'any' product can really do the job without the right people and process behind it. The most whole IPS market has a lot of snake oil in it (not to disparage any products in particular). It's easy to make an IPS product - just don't deal with the attacks that are more typically false positives and you can pretend that you've got something that will save the world.

Ok... I'm ranting...

For what it's worth, I spend almost all of my time helping banks look at how they are set up from a security design perspective at no charge. Some of them become customers others don't. In either case I've been able to help them get a better security model in place. Enough become customers that it's worth while so I keep doing it and hopefully helping the community at large in the process.

O.K., but direct your thoughts to the original poster, as I'm out of here.

I would first like to thank everyone for taking the time to share their thoughts on this topic. It is greatly appriciated and there was very good information in the posts.

I think everyone agrees that encryption on any WAN connection is a good idea. If that is the case, then why not get away from the high costs of private WAN connections for connecting sites. Especially those sites with long distances between them or that are in different telco territories, and just use a VPN connection through the internet for WAN connections. The cost of the equipment up front is more expensive, but with the lower cost of the lines it would quickly make up for it. I can't find, in my looking at least, anything that says the regulators wouldn't like this approach, but there are inherent risks with taking this approach. Any other ideas on this?

Thanks again for all the comments.

Funny... I just posted (seconds ago) on a quite similar topic -
http://www.bankersonline.com/ubbthreads/showflat.php?Cat=&Board=UBB3&Number=85287&Main=85253#Post85287

Short version - Yes - VPN's can be great but be carefull about QOS issues when involving ISP peering arrangements.

I recently helped a bank prepare for their IT audit and during the subsequent examination one issue brought up by the FDIC was the encryption of the bank's T1 leased lines. This was a shocker. The examiners recommended that the bank encrypt a point to point connection. I performed an analysis for the bank on the cost to perform encryption and it came out to be more than the bank was willing to pay. Therefore, the bank did a risk analysis and rated the risk vs the cost and decided to do nothing. We will see how the FDIC responds to the bank's decision. ji.lee@nstnet.com