Re: draft-ietf-opsec-logging-caps-03

["George Jones" <eludom@gmail.com>]

On 6/28/07, Ron Bonica <rbonica@juniper.net> wrote:
> Folks,
>
> The following are a few comments from AD review:
>
> - In Section 2.16, all sensitive configuration information needs to be
> protected. This includes thinks like cryptographic keys as well as
> passwords.

All that req was intended to say (I think, Pat wrote it) was "don't
log passwords".
This could happen 2 ways.  One: some bozo coder thinks it's a good idea
to log it and does so.  Two: the user fat-fingers login attempt and types
password in place of username and a failed login attempt by user "MyPassword"
is logged.    There's not much to be done about the second case.    All we can
do about the first case is say "Don't do it".


> - Do we need another requirement that says that it should be difficult,
> if not impossible, to alter the local copy of a log?
>
> - How should the system behave if some components spews 1,000,000
> instances of the same log message in a 5 second period?

Syslog style reduction at the sender:

  Login attempt failure from XXX
  Login attempt failure from XXX
  Login attempt failure from XXX
  ...
  Last message repeated N times in last T seconds

or some such.

Might want to provide tuning paramters for N and T.

The other issue this raises from the implementers side is the need to keep
a list of the last N messages sent, or possibly a list of all the
unique messages
sent in time T, with counts.

And what is Unique ?   are

  Failed login attempt from user "John"
  Failed login attempt from user "Bob"

the same message or different ?

Nothing is as simple as it seems.   Even in trying to reduce network spew
for repeating events, you're going to impose resource usage (memory, CPU)
on the sending device.


> - How should the system behave if some component spews 1,000,000
> different messages in a 5 second period.

Try to send them all ?

> - How should the system behave when all of the space for local logging
> is exhausted. Drop oldest messages? Tail drop?

I would say drop oldest (so what you have is a circular buffer where new
overwrites oldest if buffer is full).

Then there are the paranoid environments that want to fail closed, i.e.
STOP if you can't log.

Sorry, Pat/Ron I'm full of more questions than answers this morning.

---George Jones