Follow These 10 Rules For Firewall Design and Help Secure Your Institution -- Secure Pipe


Site Map Our Sponsors Home

Lending Gurus
Operations Gurus
Security Gurus
Marketing Gurus
Technology Gurus
eBanking Gurus

Print Friendly!

Email This Article!

Discuss NOW!

Follow These 10 Rules For Firewall Design and Help Secure Your Institution

It amazes me how often I wake up to read the news and find that yet another security problem has managed to devastate the IT departments of companies around the world. It frustrates me how many of these problems would have been completely avoided if these companies had put forward even a modicum of appropriate security management. Alas � within a few weeks I find myself in a state of 'deja vu' when the next problem hits.

It is, of course, great for the security industry (I should know) but it would be better for everyone if rather than making quick buying decisions based on their own momentary panic, people took a few minutes to rationalize their security posture and got themselves into a position where they were able to avoid the problem rather than be forced to endure the next one. Many of these problems stem from improper firewall configuration.

A great example of this was the SQL Slammer worm that hit us last January. There would not have been anything material to report if firewalls around the world hadn�t had ports 1433 and/or 1434 open to arbitrary outsiders. Why was this? By and large it was because the companies that were hit either never thought to close those ports or they opened them specifically because of a need to communicate with a partner or remote employee.

In both cases basic security planning likely went out of the window in favor of a quick fix to a perceived problem. The writing is on the wall for the next one. With the recent announcement of serious vulnerabilities in RPC handling on many of the Microsoft Windows operating systems I fully expect a series of nasty problems to arise because of attacks on port 135. These are attacks that should never have been allowed to happen because no one should have had access to the port to begin with. Sure, it will be good for the security industry. Customers will flock in droves to by whatever �magic� is being sold at the moment. At the risk of hurting my own industry I wanted to put forward some specific guidelines that, if followed, might help avoid the next big attack.

Simple firewall design and management rules to live by.

Block everything.
Don�t trust any protocol/application you don�t have to. Just because you bought an application that is designed to run over IP doesn�t mean it was designed with security in mind. OWA users have learned this the hard way over and over again.
Plan properly if you have to allow inbound access. Know what IP address it is coming from and going to. Know what ports are required to be open to accomplish your goal. Allow ONLY that set of IPs on the specific port needed, i.e. Port 1434 from 192.168.100.1 to 10.10.100.1.
Use demilitarized zones. A DMZ can save you great pain when an attack is successful.
If you have roaming users who need to access a particular port, use some form of authentication at the firewall or a VPN client prior to allowing the IP access. This is the classic ounce of prevention. If you can get users to authenticate prior to allowing them access then you have limited the set of attackers to only those who could authenticate.
Double-check your work. Get outside your network and scan yourself. Self-assessment is better than cracker-assessment. Can you validate why every port that is open is open? If you can�t you should probably close it again.
Patch everything. In particular if you have a port open to a particular machine know what patch level that system is running at. Patch the OS, the application, everything that can be patched. Don�t get caught having to explain why you patched the application but the attacker breached the OS by using a known exploit.
Read your logs. Don�t just look at the outside logs but also the inside and DMZ logs. Denied packets on the inside of a network or in a DMZ are often early warning signs of a problem that has already happened. If you wait a week to look at your logs you will likely have more to digest than you can handle and will likely miss important bits because of the quantity of data you need to go through.
Have a formal incident response policy. When something is outside of policy know what you are going to do about it.
Go back and do it all over again every time there is a change in the security risk landscape (every day?).

Don�t forget that security products won�t keep you safe without appropriate, thoughtful, design and continual management and maintenance. As soon as you rely on the �product� rather than the �process� you are likely to find out the hard way why you shouldn�t. Don�t let your guard down. If you think you are secure, but you aren�t, you will behave like you think you are secure, but (you guessed it) you aren�t.

SecurePipe SecurePipe delivers a complete network security solution -- the expert staff, innovative technology and the examiner compliant processes you need to dramatically improve your security posture and reduce costs. SecurePipe makes strong network security affordable by delivering 24x7 managed network security at a fraction of the cost of doing it in-house. To learn more, contact us toll-free at 1-877-248-1632 or email sales@securepipe.com to arrange a FREE security assessment to learn how your financial institution can benefit from managed security services.

First published on BankersOnline.com 8/11/03

BOL Archives Privacy Policy Important Disclaimer Recommend This Site ! Contact Us

BankersOnline is a free service made possible by the generous support of our advertisers and sponsors. Advertisers and sponsors are not responsible for site content. Please help us keep BankersOnline FREE to all banking professionals. Support our advertisers and sponsors by clicking through to learn more about their products and services.