Re: Outsourcing Firewalls/Internet Security count

["Paul D. Robertson" <proberts () clark net>]

On Tue, 2 Dec 1997, Edward Cracknell wrote:

> All of us....and the general opinion is that this is a good thing.

I disagree with that quite heartily.  Sociology in IS departments tends to
show that outsourcing a function removes the burden of performing that 
function from the minds of those who should be responsible for it.

If even a portion of security is outsourced, then overworked IS people will 
think that they no longer have to worry about it.  Otherwise the 
economics don't make sense long-term.

> Certainly a trusted name is required. I don't feel any 'new' name could

A trusted name really doesn't mean a lot in the 'Net business, where the 
affordable talent hasn't had enough of a history to fail a background check,
show suceptability to compromise, etc.  Most of the time, you can't go back
past 18, and in a world where a good deal of the clue rests in the young, 
verification is a definite problem.

> start-up and offer this service successfully, but then, if all the
> remote management can do is take alerts and warnings, surely the customer
> can relax a little.

If they can't correct the problem, then they're of little more use than 
an SMNP based monitoring system.  And I'd argue that having my 
vulnerabilities known outside of my organization isn't as relaxing as it 
would seem.

> In my view, the client site will have a system filtering and identifying
> intrusion patterns. It will then generate a fairly 'cryptic' alert and
> pass that via an encrypted link (leased line). The managing authority
> won't usually have direct access to network traffic.

The costs of an out of band leased line connection won't fly in most 
places once the VPN folks get their act together.  If the managing 
authority is looking at something akin to SNMP alerts, and can't examine 
the traffic, the alerting software agent already has to know enough about 
the traffic to detect a problem.  At that point, a text pager for an 
employee probably comes much closer to the ideal answer than a remote 
agent over whom there is little or no control outside of contract law, 
and we've all seen the disclaimers on security services and devices.

If the software doesn't know enough to alarm with specific information, 
then the traffic pattern becomes necessary, at which point, you're 
opening all of your inbound and outbound traffic to an external entity.  
I don't know how a consultant's trust model works, but I doubt that my 
trust model will ever extend that far, especially if I'm passing internal 
traffic to other corporate locations through the same channel.  

There's also the problem of knowing when to escallate severely, and when 
to escallate routinely.  After all, if it's detected, it probably 
shouldn't be successful, no?

> There's obviously a long way to go before this technology becomes
> acceptable, but it could be extended to address the issues of;
>
> Remote Firewall Management
> System Administration
> Network Performance 
> Business Continuity
>
> All with the benefit of a team of experts managing your Internal network
> without the cost of employing individuals for that task. 

At which point the "You no longer have control of your business' key 
infrastructre and a 3rd party now has access to all your secrets, 
financials and data" alarm goes off.

> <ALARM>
>
> whoop whoop
>
> </ALARM>
>
> No, we've got to sell this to the people it might replace. 

No, we're quite happy not giving our businesses away, thanks.  Feel free 
to sell it to our competitors though ;)

> I've thought about this one long and hard. I see it as a way to free up
> these people from the mundane tasks, and take away the need for them to
> keep up to date with new vulnerabilities.

The *software* should keep up with new vulnerabilities, no need for 
outsourcing for that to happen.

I've been saying for a couple of years that tunneling attacks are going 
to be the problem (no, Pointcast doesn't count as an attack), and there's 
no reasonable way to detect tunneling to a trojan without having the wire 
available.  Add encryption for commerce, and it becomes damn near 
impossible.  IMNSHO, The ammount of information necessary to trend and 
detect tunnels far outweighs the ammount of information that most companies 
are willing to release to a 3rd party.  At that point, blinding at the 
operations level is pointless, so there really is no way to keep 
vulnerabilities, confidential information, competitive intel, etc. out of 
the hands of the monitors, and by extension out of the hands of folks 
you'd rather not see it in.    

At least in the US, that makes the Economic Espionage Act fertile ground 
for new and bold lawsuits against the monitors.  Intel vs. Schwartz will 
be nothing compared to that bomb hitting the ground.  Once DOJ stops 
handling those cases with kid gloves, anyone working for such a 
monitoring organization seems to be at _personal_ risk.  That means that 
the contracts will have to be so soundly written that a customer won't 
have *any* legal recourse in the event of a breach of the monitor.  

I don't know about you, but when I extend trust, it's insured by the fact 
that I have a recourse at hand if that trust is betrayed.  You won't get 
to 'very trusted' if there's absolutely nothing I can do if you betray 
the trust, no matter who you are.  For organizational trust, that's 
important, because the 'bad apple' syndrome (spoiling the bunch, not 
failing to be profitible in Cupertino) may protect you criminally, but 
probably won't protect you from a civil action.  Not to mention what a 
shareholder lawsuit could do to the customer who's suddenly given up 
control and understanding of their key infrastructure in the case of 
publicly held companies.     

If the government, with its ability to investigate far more places than a 
company, can't stop classified material from leaking to hostile 
countries, I'm not sure how it's expected that private companies will 
ensure anywhere near that level of trust for any significant ammount of 
time and not get burned. 

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280