| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.misc -> Re: Tough question for oracle DBAs/Solaris Admins. Log shipping.
DA Morgan wrote:
> Vladimir M. Zakharychev wrote:
> > DA Morgan wrote:
> >> Au contraire. It is a challenging problem but not insoluble.
> >>
> >> Rule 1: Store everything inside the database.
> >> Rule 2: Encrypt the audit trail using DBMS_CRYPTO.ENCRYPT
> >> Rule 3: Autogenerate the key using DBMS_CRYPTO.RANDOMBYTES
> >> Rule 4: Autogenerate inside a PL/SQL procedure or function created using
> >> DBMS_DDL.CREATE_WRAPPED so no unwrapped source ever exists.
> >>
> >> If you've got a Cray and few weeks or months to kill you might figure
> >> out enough to alter the audit trail. But if you are that good I would
> >> expect you'd have better things to do with your time.
> >> --
> >
> > A few major pitfalls with this approach:
> >
> > 1. Rule 4 doesn't help a bit - you can unwrap a wrapped SP using APIs
> > built into Oracle itself as Pete Finnigan brilliantly demoed at Black
> > Hat Las Vegas '06. Even if you can't do it using built-in tools (DIANA
> > for package bodies is not stored in the db, so you can't unwrap package
> > bodies right inside Oracle,) you can resort to external tools, which
> > are not publicly available, but do exist.
> >
> > 2. The whole method relies on symmetric encryption. Eventually, you
> > might need to decrypt the audit trail (for example, to verify it,) so
> > the key should be recoverable (using an unrecoverable key for
> > encryption is essentially the same as sending the data right to
> > /dev/null.) And if you have the key, you can decrypt, alter and
> > re-encrypt.
> >
> > Symmetric encryption is not of much help here. You need to employ
> > asymmetric encryption and digital signatures, and even this implies
> > that the signing key is stored in the db and can be recovered, and once
> > you have it, you can sign forged trail records and make them look
> > authentic. A copy of the audit trail should be immediately shipped off
> > site so that a person with SYSDBA privileges can't alter the trail in
> > the db as this can be easily detected by comparing it to the offsite
> > copy. Ideally, that copy should be immediately written to a WORM device
> > so that it's physically protected from modifications, and ideally there
> > should be more than one copy created at the same time at different
> > locations so that at any time and in event of (almost) any disaster at
> > least two offsite copies are available (single copy is not enough as
> > its authenticity can't be verified and thus it can't be trusted.) Of
> > course, you can keep another audit trail on audit trail itself, but in
> > the end it all boils down to the classic problem - who will guard the
> > guards? I believe I've read something in Bruce Schneier's Applied
> > Cryptography about zero-trust schemes where nobody trusts nobody and
> > still everything is verifiable, but don't have the book handy, so can't
> > tell for sure.
> >
> > Regards,
> > Vladimir M. Zakharychev
> > N-Networks, makers of Dynamic PSP(tm)
> > http://www.dynamicpsp.com
> >
>
>
Well, that's exactly the problem I tried to highlight - if you have single source for the audit trail, and this source is read-write, there is no way to tell if it was modified after the fact, encrypted or not. That's exactly the issue with voting machines in use in several states: they generate no paper trail, so their own internal log is not verifiable and can't be trusted - someone with enough privileges could forge the voting results, alter the log and get away with it because there's no second read-only source to verify against. If there are several copies, and some of them never existed in physically modifiable form (for example, they are written to DVD-R or printed on paper,) proof of authenticity is much easier. Of course, one may also need prove that these copies were not intercepted and modified while they were shipped for writing to the WORM device, but human factor lends big help here: it's very improbable that someone will intercept and mangle the audit trail on the fly - usually people want to alter it long after the offending action took place to cover their tracks, which is not possible with physical read-only devices.
> Keep in mind the issue is a good faith effort to comply with the law.
> Not can I defeat the world's number one Oracle security expert.
Hope you were not referring me with this remark for I'm neither Oracle nor security expert. :)
Regards,
Vladimir M. Zakharychev
N-Networks, makers of Dynamic PSP(tm)
http://www.dynamicpsp.com
Received on Sun Sep 03 2006 - 04:04:29 CDT
 |
 |