Outsourcing firewalls & InfoSec Ops - Part I/II

[Frank Willoughby <frankw () in net>]

Todd Bennett & Paul Robertson wrote some rather astute observations 
on this subject.  I happen to agree with both of them.  8^)

Companies should make informed decisions when it comes to an issues
as critical (and complex) as outsourcing information security operations 
(InfoSec Ops).  I would like to raise some issues which should be 
considered when one is weighing the pros & cons of outsourcing InfoSec 
Ops.  Given the amount of material covered in this document, I decided 
to split it into two (10K) byte-size mails.  8^)

OUTSOURCING VIOLATES ALL FUNDAMENTAL INFOSEC PRINCIPLES
As you may be aware, the four pillars of Information Security are 
ICAN (tm): Integrity, Confidentiality, Availability, & Non-Repudiation

In the single act of outsourcing InfoSec Ops, a company places all four
of these components at risk.

As the vendor has access to internal systems & networks (by managing 
the firewall, etc), it is trivial for them to gain access to internal 
systems.  The vendor would then have the capability of modifying files 
on the system (INTEGRITY), reading sensitive personal or confidential 
files on the systems (CONFIDENTIALITY), crippling the systems by 
removing critical O/S files, (AVAILABILITY), and obtaining the users' 
Key Rings, Digital Signatures, etc. (NON-REPUDIATION).

OUTSOURCING PROVIDES EVIDENCE THAT A COMPANY IS PERFORMING DUE DILIGENCE
Actually, the opposite is true.  Outsourcing provides a 3rd party with 
full access to the company's business data, proprietary information and 
trade secrets.  In most cases, the loss or compromise of this vital 
strategic data could result in significant financial difficulties for the 
company.  In some cases this may result in civil or criminal litigation 
against the company or its corporate officers (who are charged with the 
fiduciary responsibility of protecting the company's assets).  Permitting 
external entities access to the business-critical data could result in 
the company losing its competitive edge and, in worst case, filing for
bankruptcy.


COST ISSUES
IMO, if a company can afford to outsource infosec ops, then they can
certainly afford to have a consultant come in to teach them how to do 
it themselves (which should also be MUCH cheaper).  I also think that 
whoever teaches them about managing InfoSec Ops should be skilled as 
an ISO (Information Security Officer).

FWIW, I think (vendors & consulting companies) *should* be teaching 
companies how to manage security themselves - and not provide an 
outsourcing service - as this helps the customer become self-sufficient.
Granted this may present a conflict-of-interest to some consulting 
companies whose income depends on solving the same problem over and
over for the same customers.

Also, even small mom & pop shops need security.  (The smallest company 
we ever consulted for was a 7-man shop.)  If they can afford to have a 
security consulting company help them get squared away, other companies 
should be able to afford this also.  


MANPOWER ISSUES - VENDOR
There are several manpower issues that need to be addressed:
o Does the vendor have sufficient personnel to manage/monitor 
   all of the customers' equipment?
o What is the technical expertise of those managing/monitoring 
   the customers' equipment?
o Are background checks performed on all vendor's personnel?
o Are all NDAs signed? (employees, customer, vendor)
o How will the vendor ensure that someone is *always* manning the 
   management/monitoring station - with no gaps in service?


MANPOWER ISSUES - COMPANY
Some small to medium companies (less than 500 employees) can't afford 
to have a dedicated ISO (Information Security Officer).  In these cases,
they can add the functions of an ISO as additional duties to one or more
existing employee's job description (with proper training of course).  
It is important that the employer provide enough support, time, & 
resources for them to accomplish these additional duties.  Companies
over 500 employees really should have a dedicated ISO working for them.


IMPLEMENTATION ISSUES - Single Point-of-Failure
Assuming the vendor is providing 7x24 service, we need to assume 
that at least 3 individuals will be performing the monitoring.  
Since the costs of monitoring (3 individual's annual salary) 
are too high to pass on to one customer, the vendor will want 
to spread these costs across multiple customers.  (The more 
customers that are being monitored, the more profit the company 
makes.)  The above scenario assumes that all connections are 
terminating at the same point at the vendor.  IOW, multiple 
sites are being managed from one location.  

If the vendor's system which is used to monitor/manage the 
security of their customers' firewalls is cracked (compromised), 
then every customer the vendor is managing (from that system) 
will probably also be compromised before the damage is contained 
& cleaned up.


IMPLEMENTATION ISSUES - Security of the connection from the vendor 
to the customer
o How secure is the connection from the vendor to the customer?  
o Is it possible to hijack the session - or monitor the network traffic?
o How strong is the encryption being used?  How are the keys exchanged?
o How often are the keys changed?  

The risks of someone hijacking the sessions are obvious.  Someone 
monitoring the network (or telephone) traffic would be able to 
determine which attacks trigger alarms & which ones don't & then 
use this info in mapping out their attack strategy.  


IMPLEMENTATION ISSUES - How secure is the vendor's site?
If unauthorized personnel can gain access to the system which 
manages multiple customer's firewalls, IDS, or other systems,
then it may be fairly easy for them to gain access to the 
customers' systems and networks.


IMPLEMENTATION ISSUES - Vendor notifies wrong customer of a problem.  
If the vendor's monitoring staff see a problem, they may, 
inadvertently, notify the wrong customer of a problem. 
(accidents do happen) It is within the realm of possibility 
for the incorrectly notified customer to make these results 
public - particularly if the compromised customer is a competitor.
Authentication measures need to be in place to cover this.


IMPLEMENTATION ISSUES - Maintaining Confidentiality
The greater the number of individuals who know a secret, the 
greater the probability that this secret will be revealed to 
unauthorized entities.  Confidentiality is also based on a 
"need-to-know".  IMO, the vendor doesn't have a "need-to-know" 
the customer's day-to-day level of security, the company's 
trade secrets or other sensitive, business-critical information.  

Further, one huge, nationwide ISP who remotely manages firewalls
disclosed the customer's firewall configuration & rules to me
over the phone - just because I said I was a security consultant
and had the company's permission to obtain this info.  This vendor
also managed the firewall by TELNETing into the firewall over the
Internet - in cleartext.  Anyone on the Internet along the path
from the ISP to the customer could have sniffed the connection
to find out the password and reconfigure the firewall.  

The potential exists for a vendor which remotely manages/monitors
the security of a company to inadvertently disclose sensitive
info to an unauthorized person - or even worse, permit an 
unauthorized individual to ask the vendor to reconfigure the
security settings of the firewall or other InfoSec equipment.

Also, what happens when a vendor's employees leaves and goes to 
one of the customer's competitors?  NDAs won't help very much 
to prevent this problem.  How will the victimized company even
be aware that the vendor's employee went to a competitor & took
their secrets with them?

A few more thoughts.
o What controls are in place to prevent a vendor's employees 
   from stealing & reselling the company's secrets?  
o Will the vendor permit an unannounced on-site inspection by 
   their customers?
o What controls are in place which would permit the customer
   to verify for themselves that the firewall or other security 
   product is configured correctly?  Most vendors won't permit
   their customers to access the equipment that they manage.
   If you can't verify that the vendor's configuration of
   the product is correct, how do you really know things are
   working as they should be?
o Will the vendor permit a 3rd party to monitor their systems 
   or firewall's security remotely?  If not, why not?  Examine 
   their reasons closely to see if they may apply to your 
   company.  If they aren't willing to have a 3rd party manage 
   or monitor their security, then maybe it isn't such a good 
   idea after all.  After, what's good for the goose, is also 
   good for the gander.  

   Isn't asking a vendor to manage a company's security (and 
   protect their customer's business-critical data) roughly
   analogous to asking the fox to guard the hen house?  IOW,
   if the guards are watching the crown jewels, who's watching
   the guards?


IMPLEMENTATION ISSUES - Reliability of data
The product being remotely managed (firewall, Intrustion Detection 
System, etc.) is providing data to the vendor (and hopefully to the
customer as well), concerning attacks in progress.  How does the 
software differentiate between a blatant attack, a subtle attack
(stealth mode), and an innocent mistake caused by a typo or someone
thought they were connecting to System A when they were actually 
connected to System B?  Is someone going to launch a full-scale
investigation based solely on what a piece of software says?
I would hope not.  The software may highlight what it deems to
be significant events, but an investigation should only be 
launched when there is independent corroboration of an actual 
incident in progress.  This corroboration should be performed by 
the customer, not the vendor.  The decision to investigate the 
incident (and all resulting decisions such as to prosecute the
offender) should be made by the customer - not the vendor.


IMPLEMENTATION ISSUES - Dynamic reconfiguration & response
Given the frequency of new services, protocols, and attacks,
it becomes necessary to frequently review (and perhaps modify),
one's current configuration, and tailor an appropriate response.  

It is important to note that what is deemed as an appropriate
response for one organization may not be appropriate for another
organization.  The vendor won't have the ability to accurately
make this determination as they don't understand the customer's 
business as well as the customer does.  Also, decisions to 
investigate or prosecute should be decided by the customer - 
not the vendor.

Continued in Part II/II

(c) 1997 Fortified Networks, Inc.
The opinions of the author of this mail may not necessarily be 
representative of the opinions of Fortifed Networks, Inc.

Fortified Networks, Inc. - http://www.fortified.com/
Expert (vendor-neutral) Computer and Network Security Solutions
Phone: (317) 573-0800     Fax: (317) 573-0817