Edward Maillet <maillet @
doc .
cs .
usm .
maine .
edu> writes:
> Sorry to step on the toes of you S/Key, Keberos, it's-only-safe-if-it's-
>encrypted types but it seems that there are other ways of defeating
>packet sniffers. Both active and passive. ....
>I realize that this is a rather specific topology but it is an interesting
>and rather simple solution.
This might be simple from a technical standpoint, the first time out
the chute. But it poses the same question addressed in Ian J-B's
recent testament on build vs buy in security. How much is the
lifecycle cost?
Moreover, there's a policy problem. Step back a minute and consider
the fundamental objective:
You're trying to protect information while transferring it across a
set of communications devices.
You have a policy statement that says the information must be
protected, and describe the general measures that must be used.
In this case, the security measures are properties of the specific
communications media being used. Thus, you can not change those
devices without revisiting and reevaluating your security policy, and
the measures by which the policy is achieved. If you can guarantee
that this evaluation and analysis will always occur, then the network
is already under pretty good security control. The real trouble is
with traffic outside your region of control.
These security measures depend on properties of external connections
("We have a direct feed to Sprint's backbone"), but the functional
behavior of the feed itself does _not_ depend on these properties.
Here's the rub. If a network manager somewhere in the path changes
the configuration, your traffic will still go through but your
security posture will have invisibly changed. Maybe you can produce
diagnostics or probe procedures to detect any such changes, but that
doesn't sound like the right allocation of analytical resources. It
becomes a losing race with patching a bad job.
Rick.
smith @
sctc .
com secure computing corporation
|
|
