From: Mike Shaw (mike@shawnuff.net)
Date: Thu Mar 18 2004 - 16:27:57 EST
I've been involved in bank/credit union networking and security for about
7 years now on the "core processing" vendor end. I've seen this firewalling
recommended and it never makes a whole lot of sense, although I don't
necessarily discourage it. Usually it takes care of itself.
Here's the issue. A processor has complete and total access to everything
a financial institution does. As such, there is typically little or
no risk to an FI coming from the processor's end. The risk comes from
other FIs and vendors that may be on the processor's WAN. As such, a
quick and easy way to deal with this is to make the processor document,
sign off, and show evidence on a policy that the processor will configure
network devices such that they do not route between other FIs and Vendors.
You *can* go the route of putting in an FI controlled firewall. You
can even go the route of assuming the processor is evil/incompetent and
put in a 3rd party (or otherwise independently managed) firewall. However,
if this firewall interferes with business...that's a bad bad thing.
Problems between the core processor and the FI are not pretty at all.
Imagine a lobby (or many lobbies) full of individuals and business owners
while the system is down. I've seen many 3rd parties' equipment sitting
by the door waiting for pickup because they caused this situation. Many
times you don't get a second chance.
Then there's the whole notion of proper network design. Many of these
networks have grown unrestricted for 20 years. You really wanna plop
a firewall in there and tweak a ruleset? 90% of the time the firewall
becomes worthless due to rulesets or it breaks something.
So, you have to balance the security risk of an open line to a completely
trusted processor with the risk of putting devices in place that may
cause problems and may not be necessary.
In reality, it's processors who should be firewalling off the FIs. I
don't know which is harder, defending the win95 486 boxes from viruses
or convincing them to upgrade.
My advice: spend the resources auditing the processor. It's much more
effective risk mitigation.
-Mike
On Wed, 17 Mar 2004 06:06:34 -0800 Dante Mercurio <Dante@webcti.com>
wrote:
>I'm looking for some feedback from other people who conduct security
>audits and penetration tests on banks.
>
>One of the network aspects I come across a lot is a direct line
>to their
>transaction processor. This is often in the form of a point-to-point
>or
>frame line that is dropped onsite with a router controlled by the
>processor, not the bank. I always point out that this is a network
>security risk, as there is no control from the bank side regarding
>the
>access provided through that line, and recommend an ACL or departmental
>firewall at that point.
---------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off
any course! All of our class sizes are guaranteed to be 10 students or less
to facilitate one-on-one interaction with one of our expert instructors.
Attend a course taught by an expert instructor with years of in-the-field
pen testing experience in our state of the art hacking lab. Master the skills
of an Ethical Hacker to better assess the security of your organization.
Visit us at:
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:50 EDT