I agree social problems like that are only cured before birth !-:)
On Tue, 29 Mar 1994, Marcus J Ranum wrote:
> >> the alternative being real authentication (eg
> >> SecurId) for every outbound connexion as well as every inbound
> >Actually, it occurs that in this second scenario -- a confederate of the
> >baddies, perhaps a disaffected employee inside your network -- even
> >authentication of outbound connections wouldn't help you:
> [...scenario deleted...]
> >..even if she has to supply the connect authentication manually (eg
> >SecurId) to set the connection up. So even things like TIS's
> >authentication hooks don't seem to prevent this kind of thing?
> You can't solve social problems with software. :)
> Disaffected employees and confederates of baddies are a
> problem that most firewalls can't solve. This is why, for example,
> intelligence and defense computing agencies do background checks
> and require clearances, etc, etc. That kind of thing works to a
> fair extent, but obviously there are some well-publicised lapses.
> After all, if you're worried about a disaffected employee,
> then you have to worry about him leaving all sorts of digital time
> bombs around your internal network, leaving the building with a DAT
> filled with proprietary data, or telephoning your competitors and
> giving away the store.
> Authentication (like in the TIS toolkit) isn't going to
> help you much, unless your perpetrator leaves clear tracks in
> the firewall's audit trail.
> This is why risk assessments and security policies are
> important. They force you to consider whether what you're worrying
> about makes any sense. You need to consider:
> + What bad things might happen to you
> + How much they will hurt you if they do
> Then assign some likelihoods to the threats and start to
> decide what's the acceptable level of risk you're willing to operate
> under. If your list of potential bad things contains the threat
> that you're afraid of nazi paratroopers attacking your computer
> room, and it has a fairly low likelihood then perhaps it's better
> to worry about your use of plaintext passwords over the internet,
> because even though the damage is likely to be less severe, the
> attack is more likely to occur.
> If your data is so important that you are worried about
> moles and insiders, then perhaps you should consider a secure
> facility for that information, background checks for your staff,
> and so forth. There *are* some environments where such measures
> are completely justified. Most of them would never dream of
> connecting to the Internet, and we should be glad of it.