RE: Bank Audit Best practices

From: Mike Shaw (mike@shawnuff.net)
Date: Tue Mar 23 2004 - 11:19:36 EST


On Tue, 23 Mar 2004 06:43:24 -0800 "Gault, Brian" <brian.gault@greenwichtech.com>
wrote:
>Mike, please don't take offense to this response, but with all due
>respect,

No offense taken...as long as you keep my mom out of it it's all totally
professional! ;)

>you are sincerely and totally wrong. If the processor gets nailed
>with SQL
>Slammer, or anything else nasty and fast spreading, and there are
>no
>controls as to what traffic is limited from their network back to
>the bank's
>network, BAM!! (a little Emerald humor)- they have just infected
>the bank's

This shows a fundamental misunderstanding of where the perimeter is in
the small bank/cu and processor environment. If a worm takes down your
processor, then the losses dwarf a workstation cleanup. I've effectively
shut down virus infected teller workstations, and the CEO's first question
was "This didn't infect y'all did it?".

In most cases the risk of worms can be mitigated in ways that don't risk
the connection between processor and FI like firewalls and other inline
things do.

The *real* perimeter in the small bank/cu environment resides between
your core processor and the other banks and/or credit unions. That's
where the untrusted network is (From an FI standpoint). Putting the
perimeter there addresses your concerns about virus cleanup AND the real
issue of staying in business and protecting customer/member data.

Sure, if an FI can handle the overhead associated with a firewall, then
go for it. 95% of the time they can't, and it causes more financial
loss than a worm infecting all 15 or so workstations ever could.

I'll just wrap my point up with the following summaries:

 * It's about *risk*management*. FI's don't understand many technical
things, but they understand this. Thus, many consultants end up looking
pretty silly to FI's when they can't tie technical benefit to risk reduction.
 * Traffic control for traffic control's sake is a displacement of that
goal and can actually lead to worse situations from a risk management
POV
 * An FI that utilizes a processor and focuses primarily on their link
between the processor and the FI location has gravely misplaced their
concern.
 * The proper place of concern is the perimiter between the processor
and other FI's. If that's addressed, then you can move on to these other
issues. I think you'll find (and indeed, I know of about 160 FIs that
have come to this conclusion) that once that original concern is mitigated,
 another box with blinking lights gives you a very small increment of
benefit...and that increment may just be negative.

-Mike
CISSP, CCNA, YADDA, YADDA

---------------------------------------------------------------------------
You're a pen tester, but is google.com still your R&D team?
Now you can get trustworthy commercial-grade exploits and the latest
techniques from a world-class research group.
www.coresecurity.com/promos/sf_ept1
----------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:51 EDT