Re: Tough question for oracle DBAs/Solaris Admins. Log shipping.

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 Received on Sat Sep 02 2006 - 04:51:46 CDT