Penetration Testing mailing list archives
RE: Bank Audit Best practices
From: "Mike Shaw" <mike () shawnuff net>
Date: Tue, 23 Mar 2004 08:19:36 -0800
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 ----------------------------------------------------------------------------
Current thread:
- Re: Bank Audit Best practices, (continued)
- Re: Bank Audit Best practices Clint Bodungen (Mar 19)
- Re: Bank Audit Best practices Jeff Lumley (Mar 19)
- Re: [security] Bank Audit Best practices rsh (Mar 19)
- Re: Bank Audit Best practices wirepair (Mar 19)
- RE: Bank Audit Best practices Michael Bitow (Mar 19)
- Re: Bank Audit Best practices Mike Shaw (Mar 19)
- RE: Bank Audit Best practices Michael Iseyemi (Mar 19)
- RE: Bank Audit Best practices Keith Pachulski (Mar 22)
- RE: Bank Audit Best practices Mike Shaw (Mar 22)
- RE: Bank Audit Best practices Gault, Brian (Mar 23)
- RE: Bank Audit Best practices Mike Shaw (Mar 23)
- RE: Bank Audit Best practices Frank Knobbe (Mar 24)
- RE: Bank Audit Best practices Roman Draconus <roman (Mar 24)
- RE: Bank Audit Best practices Gault, Brian (Mar 24)