On Friday, December 27, 1996 3:33 PM, Saunders,
>With the cost involved in acquiring/providing firewall technology, I would
>assume that many of you had to go through the process of creating an RFP
>a means to communicate your needs with vendors.
>Can anyone provide me with a copy of an firewall RFP that you used? I
>to reinvent the wheel. I also assume that many of you have probably done
>much better job than I would ever do in creating such a document.
I'd imagine that any RFP would have to be specifically tailored to the
requirements of the customer. For example, some RFPs we've responded to by
banks call for very strict security measures, whereas RFPs put out by say
educational institutions are lax in comparison. These reflect the thought
processes that went behind constructing the exact security policy which the
firewall is to enforce. In fact, your RFP may also be as broad as to
solicit security consulting services, and a firewall product or service may
just be a natural outcome of such work.
Having said that, there are common issues which all RFPs (not just Firewall
RFPs) address. These are things like:
Support & Serviceability: what support structures are in place in the event
of questions or problems? how extensive is documentation? is there a 1-800
line? is it 7X24? are there resources on-line? What are the terms of
support for backlevel SW or old HW? Can we get support for our system x
years from now? who services the system in the event of a failure? What are
the guaranteed response times like? A day? 6 hours? 1 hour?
Reliability: Can the vendor cite MTBF rates for the proposed system? In the
event of a failure, what systems are in place to provide a redundant
service? How intrusive is the switch to backup systems? What notification
processes are there to signal impending failure?
Upgradeability: what is needed to upgrade the system in the event that
traffic becomes too much of a burden on the systems proposed, or there are
new versions of OS or code? Total HW/SW replacement? (A FW-specific
question here would be - can you use the same config files for new versions
of the FW code? if not, are there conversion utilities?) Addition or
replacement is the key issue here. How intrusive is this service? What
impact will it have on my downtime? What are the availability of parts on
Manageability: what management/monitoring/diagnostics systems are in place?
Can this be done remotely? Will it tie into existing management systems
(NetView, etc)? Can the system support "lights out" operation through
automated tasks? How much intervention is required on behalf of the system
to ensure smooth operation? (obviously this doesn't apply to checking FW
logs religiously) Can we outsource the management of the system? What kind
of reports on performance can we expect from this?
Skills transfer: what education programs are in place to train our people
if these are new systems unfamiliar to the existing staff?
Cost: can the vendor list one-time and recurring expenses (normally include
an estimated three-year cost of ownership)? Is leasing an option? What does
the equivalent service out-sourced cost if the proposed in-house system is
Vendor profile: what is the history and track record of the vendor? can the
vendor cite any reference accounts where the proposed systems are installed
and in use?
Note that I haven't included anything firewall-specific in the above (I
figure there will be plenty of people responding to your note about this),
so I'm not sure if the above is helpful, I'm just relaying a base point of
view which tends to get overlooked in most technology RFPs.
Hope this helps.