Is anyone using FISERV as their service processor for all applications along with providing internet access?

The institution I work for uses them and their security features. However, there is no firewall installed at the institution itself, they rely on the firewalls at FISERV and the router configurtions maintained by FISERV for the institution's facility servers. I am trying to convince managment that a firewalls are needed at this institution. I have tried to explain it from an auditor's point of view, but need more technical specifications and information to convince. Additionally, this institution is planning to use FISERV's internet banking shortly.

Please help!

It sounds like the configuration you describe is FiServ's MSSP(managed security services provider) which means that internal and external Internet and e-mail transmissions are routed first through FiServ's controllers and firewall, checked for viruses, and routed from FiServ to your receiving server (acting as a contol router). If FiServ ISN'T providing the MSSP process, then perhaps you have another ISP -- in which case you'll need to gain a better understanding of your architecture.

Yes it is the Managed network. Are any firewalls needed on our end?

It is likely that you are already set up as a FiServ "node", essentially as if you were in the FiServ network. You would not need to have the FiServ host transmitting data from FiServ's network through a firewall to create a "handshake" with another firewall, then back into the same network. It's hard to diagnose your risk condition without truly understanding your architecture, but if you truly have an MSSP structure in place -- in this case through the FiServ product -- then, in effect, all entrance into your network is actually routed first to FiServ's MSSP location, then sent encrypted or SSL to you over dial-up lines and into a receiving server at your bank. There must be an MSSP representative who you can consult with. Moreover, it wouldn't hurt to conduct a site visit to the MSSP site, since they are a technology service provider.

Why not just ask the representative at fiserv, as the previous poster suggests. The original poster is trying to understand if a firewall is needed to stand between the bank and its connection to fiserv. Why engage a professional services consultant to answer a question that fiserv can surely answer for free. That's why we BOL!

We are with Fiserv, including on-line banking. We were also just examined by the FDIC in IT. Fiserv maintains the firewall, both covering the primary system and to on-line banking. We maintain a firewall between users that have access to the internet and the internet, including virus protection that is loaded on each PC. The internet firewall in mandatory, according to the FDIC.

Optionally, you can maintain a firewall between Fiserv and your institution to manage access by Fiserv. We've choosen not to go that route. If you cannot trust Fiserv, under contract, you are lost anyway as they probably can rip through your entire system before you know what's happening.

By the way, we passed the FDIC IT exam with no exceptions.

Yes, the paranoid standard, again, is now posted. Go with that standard and no one, nothing, is safe - regardless of how the analysis comes out as you will never feel "safe" and you had better not go home or go to sleep at night. If you are targeted by someone inside your oursource entity, you will loss in the short run, but win in the long run, regardless of what type of firewall you maintain.

Incandescant,
I'm interested to know why my opinion invokes such passion from you? There is always more than one way to look at a particular situation. Just because you don't necessarily agree with my point of view, which happens to be conservative, doesn't mean you should try to dissuade others from hearing what the other side of the coin looks like.

-g

No passion here, but like a lot of things in banking there is the staffing, ability, cost/return of doing everything and doing what you can - given staffing, ability, cost/return and one can always cite the absolute, but the difficult part is determining how far you need to go, given staffing, ability, cost/return - especially in a small bank environment.

And I think that is what I am advocating, "determining how far you need to go, given staffing, ability, cost/return [I'd also include vulnerabilities, threats, impacts]- especially in a small bank environment" also otherwise known as a Risk Assessment. I've worked for small and large banks and the common theme among all of them is budget sensitivity - but that still doesn't negate your responsibility for vulnerability awareness.

I think it is prudent that an organization understand all of the risk they are or could be subject to - then implement controls based on how far and at what cost mgmt. wants to mitigate. In order to understand and identify risk you have to take a very discerning view of everything involved.

-g

Apparently FISERV does actually provide the controlled access point, so I won't need information to convince management.

Anon, I concur with everything -g has said. A number of issues have been brought up...here are a few thoughts and suggestions...

I would start with Fiserv. Get all the information from them that you can...topologies, narrative descriptions, etc. Also get a copy of their SAS 70 audit of internal controls, disaster recovery tests, etc. This is all part of due diligence / vendor management.

Do a thorough risk assessment. I can tell you that electronic banking, Internet connectivity, information security, etc., are going to be high risk no matter how you slice it (potential head shots, as we like to call them)...it's not about being paranoid...it's reality. If you don't have the technical expertise to completely document and assess the situation, get outside help (consultant, IT auditor, etc.) like -g suggested. If you don't understand it thoroughly, you can't audit it.

You can't rely solely on Fiserv's response since they are obviously not independent...again, get outside help if needed. Further, BOL is great, but, as -g suggested, you can't rely on someone here to give a definitive answer to a complex, technical question...it's too risky since we don't have all the details.

To revisit this post and topic - please read the following article regarding security, service providers, trust, agreements, etc.

I think it sheds some light on the point I was making above.

Article Here

-g