Re: audit response

On Mon, 28 Jul 2003 14:36:51 GMT, Brian Peasland <dba_at_remove_spam.peasland.com> wrote:

>> I disagree with Brian, actually. Trust doesn't have to come into it, and
>> if
>> security is really needed, it shouldn't.
>
> Someone has to have the keys to the kingdom. But you don't just give
> those keys to anybody.
>
> There is some level of trust between the employer and the employee, no
> matter what the job entails. The shareholders trust that the board and
> the CEO will do the right things to make a profit.

No they don't. They get in auditors to make sure (let's not go there, OK!!) .

> The CEO trusts the
> VP's of the company to hire good managers.

Again, they don't "trust". They have annual or 6-monthly appraisals of performance to make sure they are good managers.

> The managers hire DBAs, etc
> and trust that they will do the right things for their company's
> databases. Etc, etc, etc.

I think this could be a matter of semantics. How about "trust but verify", then? What I don't agree with is the idea that you *just* "trust" someone is a decent guy. Even if you give the keys to the kingdom, you set up auditing and monitoring mechanisms, with appropriate disciplinary sanctions, to check on how the keys are used. You can't just say 'You are a decent guy; I have checked your background; Off you go; Be nice".

The most powerful user on the system can still be audited.

>
>> In other words, by separating the functions of sysadmins and DBAs, and
>> by
>> investing in the latest releases of the software, you *can* audit SYS
>> activity, reliably and securely.
>>
>> Sure, the DBA could modify the init.ora, and set the audit option to
>> false... but then you make that a disciplinary offence.
>
> Right there is one level of trust. You know that the DBA can modify the
> INIT.ORA. You know that they can take certain steps. If they bypass
> those steps that are in your company's policies, you take appropriate,
> maybe disciplinary, action. So even by your own words, you have placed a
> certain level of trust in your DBAs hands and if they violate that
> trust, you take appropriate action.

Not trust in that dewy-eyed sense. That init.ora parameter is static. Therefore setting it to false requires an instance re-start. Those things are audited in the alert log. A secure system should have the alert log checked every day for unauthorised or unexplained re-starts. Additionally, after every re-start, management demands that a complete listing of parameters and there values is obtained and compared with the previous one. Any changes will have a paper trail authorising them. If this one is changed, there'll be no authorisation, and you sack the DBA. That's not "trust"; that's verifiable integrity.

>
>
>> In this day and age, any secure system that relies ultimately on trust
>> isn't secure.
>
> I don't think that anyone said anything about relying ultimately on
> trust. We have passwords. If we relied ultimately on trust, everyone
> would be given the DBA account and allowed to roam freely. But we put
> our database servers behind locked doors so that Joe Employee can't come
> in and pull the plug. And as I said, "no system in our building does not
> have an entry point that has complete control over that system."

Obviously so. But that doesn't mean you say, 'you have the keys to the kingdom and there's nothing I can do, so I ultimately have to trust you'. Ultimately, you can verify and dismiss.

> So
> while an effort is made to make sure that the database is as secure as
> possible, there is always at least one entry point that can bypass those
> security measures. There is nothing to stop a DBA from deleting all of
> the company's data. So you trust that DBA to not delete data that is not
> supposed to be deleted. There is always a level of trust given to an
> employee for some aspect of their job, until they violate that trust.

I reallythink this is semantics, then. Your last sentence there indicates you obviously have a mechanism for detecting the violation of trust. And it was the (apparent) lack of that to which I was 'objecting'.... and although I wouldn't call having an auditable paper trail for unauthorised init.ora changes, or an un-deletable audit trail generated by the database itself, 'trust', so long as its verifiable, we can agree to disagree on what you *do* call it.

~QM

>
> Cheers,
> Brian
>
>
>
>

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/