In a discussion from the trenches, on the Firewalls List, Brian
Moore <[EMAIL PROTECTED]> wrote:
>> The standard way, run the checker frequently from cron off a CD that you
>> burned, that includes the fingerprints of the files you want to check.
>> And verify by hand every once in a while that a hacker hasn't unmounted
>> the CD and replaced it with his modified checker and fingerprint files in
>> the filesystem where the CD is normally mounted. But a really good hacker
>> could install a modified kernel to redirect filesystem requests from your
>> CD to his own hidden modified checker and fingerprints. There's no perfect
>> solution if someone gets root on your machine, they can do anything. The
>> last resort is to rebuild your machine every once in a while from scratch,
>> but that just means they have to re-hack you every once in a while.
Another Yank ducking hot lead on the front lines in Lower Manhattan,
Bennett Todd <[EMAIL PROTECTED]>, responded:
>My favourite is to audit backups periodically. Still doesn't catch a
>sufficiently thoroughly hacked system. The only way to catch one of those is
>an offline analysis: boot an offline, known-good copy of the OS; run an
>offline, known-good copy of the checker executable with offline libs against
>and offline database.
>
>Turns out if you install your system with a good software packaging tool like
>e.g. RPM, and you keep your installation media archived, and keep archival
>copies of packages of all software you add or update on the system, you can
>perform precisely the needed analysis. Plus of course you're set to rebuild
>the system if e.g. it throws a disk.
>
>I don't like re-installing; if they got in before they can get in again, and
>computers let things like this be automated. If I think someone might have
>gotten in, I want to know how they got in.
I like Mr. Todd's heavy-duty (off-line audit) approach, but I have
a slightly less burdensome alternative (or complement) to suggest. I've
been urging my clients to consider crypto-enhanced audit logs: irreversible
updating to log files with a one-way function, at a minimum.... Maybe with
an option to write logs to a WORM drive? Maybe with a timestamp in the digest?
Anyone got any comments? Cautions or suggestions for
implementation? Hashed digests or digital signatures?
Isn't it about time for OS, NOS, and PKI vendors (all who sell or
install access control systems?) to finally offer something in audit that
can perhaps withstand Mr. Moore's threat scenario: "[If] someone gets root
on your machine, they can do anything."
"Irreversible" updates for audit logs may not withstand all attacks
unless the records are stored offline -- and access controls without strong
two-factor authentication is a joke -- but done right, I presume this sort
of audit files could only be destroyed, not faked.
Traditionally, of course, records made in the normal course of
business are admissible as forensic evidence in courts throughout the world.
Testimony is usually required to show that these records meet this test. I
fear, however, that even with strong user authentication, and relatively
weak controls over many types of computerized records may allow them to be
legitimately called into question if they are used as evidence in court, or
as the justification for punitive action within the firm or organization.
If the vendors, and the professional communities, do not get their
act together on this, it is also a likely target for government regulation
(particularly as various governments polish legislation around digital
signatures and CAs.) In most management systems, of course, it is the
promise and threat of accountability after the fact -- not an impermeable
defense or universal surveillance -- that is the basis for business
practice.
(In the UK, in the aftermath of the Munden Case, case law will
allow -- if not urge! -- that the defendant's expert witnesses be allowed to
challenge the relative security and integrity of computerized records, if
they are crucial to the prosecution's case. Is there a parallel US
convention? See one of Ross Anderson's reports on the Munden travesty at:
<http://x37.deja.com/[ST_rn=ps]/getdoc.xp?AN=167673819&CONTEXT=934826781.119
6228647&hitnum=0>)
When I suggested this elsewhere, William Hugh Murray
<[EMAIL PROTECTED]> of Deloitte & Touche responded:
|>For years, we recorded the event or content on paper, transcribed it to
|>machine-readable media, processed it and printed it to paper. It was the
|>paper manifestation of the records that the courts really relied upon.
|>
|>However, in the modern world, we often record the event directly on a
|>key-board and display it on a screen. In the routine course of things, no
|>paper record is ever made. Therefore, the only real record is on
re-writable |>media. This record is intrinsically easier to falsify and
should be suspect. |>(In fact, it may be harder to falsify than it looks
but, in practice, such
|>records usually are not questioned and because, "the computer says...,"
may |>actually be given more weight than paper records. )
|>
|>Note that in civil litigation the parties usually stipulate to the
|>records and then argue the meaning and intent. Therefore, the
|>reliability of the records is more likely to be an issue in criminal
|>litigation.
|>
|>There are really three issues. Was the record made by person it appears
to |>have been made by? Was it made when it appears to have been made? Has
|> it been altered since it was made? Routine use of strong authentication
|>coupled with digital signatures can easily address the first and last.
Routine |>use of digital time stamps can address the second.
|>
|>The key word here, as it was in paper, is "routine" but "coupled" is
|>also important.
Bill Murray has made a career out of being a few years ahead of most
professionals in both IT security and audit procedures.
Suerte,
_Vin
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
