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

On Sat, 02 Sep 2006 11:51:01 GMT
Ningi <ningi_at_EGGSANDSPAMblueyonder.co.uk> wrote:

> Stefaan A Eeckels wrote:
> > On Sat, 02 Sep 2006 00:35:13 GMT
> > Ningi <ningi_at_EGGSANDSPAMblueyonder.co.uk> wrote:
> >
> >> Frank Cusack wrote:
> >> <snip>
> >>
> >> m UNTRUSTED employees, not eliminating trust from the system.
> >>> No auditor will balk at not having immutable files as long as only
> >>> trusted employees are in the position to undetectably alter data.
> >> Yes they will. You stand no chance of meeting SEC 17a-4 if ANYBODY
> >> can alter the data.
> >
> > Then SEC 17a-4 cannot be met, unless the data is placed on a
> > write-once medium and said medium is stored in an inviolable
> > location (or has such characteristics that it cannot be
> > substituted).
>
> I should have been clearer. The point I was trying to make is that
> SEC rules assume untrusted employees. You have to demonstrate to the
> satisfaction of the SEC that your data is stored on WORM media that
> can't be tampered with by employees - for example on the order of the
> CFO.
That's a lot more reasonable - it doesn't assume what is technically impossible.

> > But wait - how do you(*) know that the program that writes the data
> > to the write-once medium doesn't alter it whilst writing?
>
> By auditing the software. That will have to include the whole
> software stack from application to OS to storage. This is one of the
> reasons there's such a big consultancy industry around SOX compliance.

So _you_ still don't _know_ the software is OK. You _trust_ an outside organisation with a vested interest in gaining consultancy contracts when it says the software is OK.

<aside>
It is funny to notice that a manager will believe a report made by someone working for another company, but would not believe the exact same report written by an employee. Sad. </aside>

And then you still don't know whether the software that was audited is the software that's running. Surely these consultants don't get full and unfettered access to the production systems. You still need to trust the sysadmins.

> > As usual, the law is an ass.
> >
> > (*) you = an auditor who cannot read program source code and
> > compile it himself, and execute on a system he has built from the
> > ground up so that he knows it's trusted. And even if the auditor
> > could do all this, why trust the auditor?
> >
> The SEC don't approve & test technology. It is up to the financial
> institution to demonstrate that they've made reasonable endeavours to
> comply.

And "reasonable" here means that a particular SEC employee trusts a particular employee of the financial institution, who trusts a particular employee of a SOX consultancy. Did the latter _really_ understand the code he was auditing?

> The real motivation is the massive fines the SEC will levy if you
> can't retrieve data quickly and demonstrate it hasn't been tampered
> with in the event of an investigation. This has happened a number of
> times.

Since when is retrieving data "quickly" an indication that it hasn't been tampered with? (Don't bother, I know the rationale :).

Oh well, it pays the bills.

-- 
Stefaan A Eeckels
-- 
Never explain by malice what can be adequately explained by stupidity.
However:
Sufficiently advanced stupidity is indistinguishable from malice.