Re: Tripwire question

From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Mon, 17 Jun 2013 18:30:44 +0100
Message-ID: <CABe10sbNq8jRi9fv+hBpN1uRbAmHR8XjEoCKN-4mV=5xi1odDQ_at_mail.gmail.com>



That must come down to how you classify what constitutes a "change". I'd argue that in your example *not* creating/dropping the expected partition was a change, in that behaviour necessary for application operations had changed. You (corporately rather than individually) ought to be able to define that.
It strikes me that teams generally aren't motivated to reduce work for other teams unless they perceive that reduction as meeting corporate goals as communicated to them. If you can't redefine what "change" means to meet their understanding, perhaps it is possible to align their goals with yours , say by mailing them proactively a list of expected changes for them to reconcile with their records. This has the security advantage of ensuring that the team that has the power to make these changes (yours) doesn't get the power to account for/hide them. It also has the economic advantage of ensuring that the cost of checking falls where the benefit of checking is felt (in security).
On Jun 17, 2013 6:05 PM, "daniel koehne" <koehned_at_gmail.com> wrote:

> My company's security team uses the Tripwire product (tripwire.com, not
> sure what version) to monitor Oracle databases for changes. The current
> Tripwire configuration means that most of the daily changes detected by
> tripwire are changes like automatic partition maintenance that can be
> classified by an algorithm as an expected change.
> Our security team do not seem to be motivated to address the issue of
> doing unnecessary work and the Tripwire product docs etc... seem to be
> behind a gated wall so I can't do any research.
>
> My question is, if you are using the Tripwire product do you know of a way
> of automatically classifying and promoting changes?
>
> Thanks
> Daniel
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Jun 17 2013 - 19:30:44 CEST

Original text of this message