Building your firewall, Part 1

By Carole Fennelly, Unix Insider |  Security

Authentication

Some sites require authentication for outbound sessions. If this is
the case, the firewall must support it in a manner that is easy to
maintain. Will users be able to change their password? Does the
firewall permit this? How is the user database stored? Can user
records be moved between firewalls easily? Would the technical staff
be able to write custom scripts to manipulate the user database?

Remote access

Will inbound sessions be required? If so, what are the requirements the for
authentication and encryption of those sessions? You may already
be using a token device, such as SecurID, for the authentication of
inbound sessions. There are many one-time password mechanisms
available; make sure the firewall supports yours. You may also want
to consider using a virtual private network (VPN) to encrypt the
session. Many firewalls come with a VPN rolled in. My preference is
to use a third-party VPN so that, if I decide to use a
different firewall later, I won't have to worry about changing the VPN and
all the client machines that use it. If you decide to use the
firewall vendor's VPN, be sure to determine if the VPN is tied into
the firewall software version. Otherwise, you may find yourself
trying to coordinate firewall upgrades with other sites just so the
VPN will work.

Architecture review

Whether you presently have a firewall or not, your current
architecture must be reviewed to determine if it is able to support
the new architecture, and vice versa. Some of the technical
considerations follow.

Performance requirements

Applying security to an architecture usually has an adverse effect
on performance. It is important to first determine the acceptable
trade-off between security and performance for the site. Many
security experts will tell you that security should never be
sacrificed for functionality, but the reality is that almost every
firewall evaluation test emphasizes performance.
Management needs to have a thorough assessment of the risks involved
in order to determine what is acceptable. For example, if a brokerage house
is performing trades, a significant slowdown in the execution of the
trade could cost more money than a minor security risk. However, it
should be noted that a misconfiguration that slows down performance
does not add to security! Performance issues will be discussed in
more detail next month. For now, just determine your requirements.

Application and network requirements

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question