I guess to try and get something half useful out of all this we should
recap.
There are three sets of problems.
At the log generator(s): verification, log authenticity and log
continuity. Ideally we want records that we can say are genuine, and
haven't been added to or elided. We can't do that against an internal
attacker without some sort of "tamper evident" solution, and I can't see
how that can be accomplished purely in software. I'll cede Mr Robertson
a point and say that with very specialised and expensive hardware it may
be possible to provide a "strong enough" solution. If we assume only
external attackers, we can probably do OK in software with mechanisms
like the Cyberguard guy was describing, using capability-based MAC ("B
level") and a tamper-evident log auditor. [1] For other OS's - we need
to have indelible log generation. Simply sending those messages out as
they occur to a syslog server may be enough for some people, although we
risk someone killing the syslog process as their first action. Some
folks attach line printers to serial ports for this reason. Self
contained logs on most general purpose OS's must obviously be taken with
a pinch of salt, and ditto any system that uses batched or on-demand
transfers.
At the transport: These are our network problems, and we had a good talk
about things like secure syslog (IETF style), syslog TCP over TLS, that
sort of thing. Standard syslog has problems with reliable delivery,
packet authentication, you name it. Attackers will mainly be trying to
kill the wire (DoS) and inject false messages in a variety of ways.
At the collector: The collector needs to be as secure as possible,
obviously. I guess that would mean it should be single purpose. Denial
of Service, which is often only an annoyance against "normal" systems
can be a critical security issue against a log collector, so collectors
need to be as robust as possible in that regard. Unfortunately the
addition of crypto into protocols, especially with PKI, often opens up
new doors for DoS. Third party admin, as Bernd suggests, may be good,
but unless we're up to scratch on the other two fronts we still don't
win against an internal attacker, and if it's only maintaining complete
logs against an external attack that worries us then we probably don't
need to go that far. Is there any value here to "stealth" collectors,
which aren't IP addressable (they are basically sniffers with big
disks)? Maybe, but the lack of interactivity may cause problems with
some of our nice secure transport protocols.
Unless we address all three of these issues we may be more exposed than
we think, and protecting ourselves against our own employees is _much_
harder than it appears on the surface.
And I _still_ say that this is not one of the nuts that is best turned
by the PKI monkey-wrench.
Cheers,
[1] We can also build these free, if we want, using various linux /
other distros which are designed for it.
--
Ben Nagy
Network Security Specialist
Mb: TBA PGP Key ID: 0x1A86E304
> The idea is, to have the log server physically protected from
> insiders. It is a log sink and not more. Administration of
> that machine could be done by trusted third party, the
> controlling department or by 4-eye principle.
>
> Greetings
> Bernd
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
