[unisog] IDS vs. Privacy

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Tue Feb 3 01:38:40 GMT 2004


On Mon, 02 Feb 2004 14:33:10 CST, "E. Larry Lidz" <ellidz at uchicago.edu>  said:

> I was asked, as moderator, to pose this question to the group from
> someone at an institution who wished to remain anonymous. They fear that
> if this message was public their institution might be the target of
> unwanted attention from the underground.

I'd worry about the derision of their peers more. :)

> IT management then changed. The IDS system was shut off with no advance
> notice over the concern that it might lead to a compromise of privacy
> policies. The new management believes that people having access raw
> packets is an unacceptable risk.

1) Do people have access to the switch rooms? In that case, they
have access to the raw packets.  It's a lot simpler to tap a fiberoptic
than you think. :)

2) Did the previous management whoops when they wrote the AUP for the
network?  They should have added a "our traffic may be monitored for
security" type of disclaimer, at which point it's moot.

3) What they intend to do if they get blindsided by an attack that
they would have detected?  And what happens if the attack results in
the disclosure of private information?  That's a BIG liability case
waiting to happen.  Do they *really* want to say "We're so afraid our
own staff will misbehave that we won't let them watch out for miscreants
that we *know* will misbehave"?

3a) Have they considered the morale implications on their techs, that they
aren't to be trusted?  Where will they be if their senior techs become
flight risks? (I know *our* CIRT would get pretty deserted pretty fast
if management said we couldn't be trusted with packets...)

4) There's an interesting legal facet about logs when trying to use them
as evidence - logs that you have been keeping for a long time, and making
business/planning decisions based on them, will be given greater weight than
logs you suddenly started keeping in the middle of an incident. (I wish
I had a citation for this one).  So if you go into court and say "We've been
keeping these IDS logs for 3 years, and using them to analyze the attack
rates on our system and how many staff we need to devote to security", that
demonstrates that the logs are "trusted business records" that you've
presumably taken care to make sure they're kept correctly. "Joe thought
something was odd so we fired up an IDS" isn't going to hold up as well...

5) It's almost certainly a legal non-issue anyhow.

http://www4.law.cornell.edu/uscode/18/2511.html

18 USC 2511 (2)(a)(i):

"It shall not be unlawful under this chapter for an operator of a switchboard,
or an officer, employee, or agent of a provider of wire or electronic
communication service, whose facilities are used in the transmission of a wire
or electronic communication, to intercept, disclose, or use that communication
in the normal course of his employment while engaged in any activity which is a
necessary incident to the rendition of his service or to the protection of the
rights or property of the provider of that service, except that a provider of
wire communication service to the public shall not utilize service observing or
random monitoring except for mechanical or service quality control checks."

I think an IDS would qualify as a service quality control check.  Also,
that clause applies to providers of service "to the public".  You have
a restricted list of customers, you don't offer service to Joe Q Random
who comes in off the street and picks up the phone.  So you're left with
the bigger chunk of the section which basically says "the employees are
allowed to see packets if it's needed to protect the *PROVIDER's* rights
or property".  Note that - the provider, not the user.

That's all that comes to mind immediately,...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/unisog/attachments/20040202/8b47e674/attachment-0003.bin


More information about the unisog mailing list