Hi, we are using Guardium to monitor Oracle databases. We monitor sensitive data by defining them as specific Object/Fields in the rule conditions.

However, if a DBA were to CREATE a VIEW or SYNONYM that references the Column and Table being monitored, then the user would have the ability to query that view without triggering the rule conditions. If that's the case, how do Guardium resolve this circumvention?

Comments and recommendations will be much appreciated.
Thank you!

------------------------------
Joseph Conrad Isidro
------------------------------

​You would need to periodically run an Oracle query to find all the view columns and synonyms for the tables, column or both that you are interested in monitoring.  Then add those results to your sensitive data Guardium group(s).

------------------------------
Frank Bates
Guardium Admin
KeyBank N.A.
Brooklyn OH
+1 (216) 471-2740
------------------------------

Original Message:
Sent: 07-26-2018 16:51
From: Joseph Conrad Isidro
Subject: How does Guardium Data Protection deal with Views and Synonyms

Hi, we are using Guardium to monitor Oracle databases. We monitor sensitive data by defining them as specific Object/Fields in the rule conditions.

However, if a DBA were to CREATE a VIEW or SYNONYM that references the Column and Table being monitored, then the user would have the ability to query that view without triggering the rule conditions. If that's the case, how do Guardium resolve this circumvention?

Comments and recommendations will be much appreciated.
Thank you!

------------------------------
Joseph Conrad Isidro
------------------------------

But this will not be effective for ad-hoc queries right?

------------------------------
Joseph Conrad Isidro
------------------------------

Original Message:
Sent: 07-27-2018 08:05
From: Frank Bates
Subject: How does Guardium Data Protection deal with Views and Synonyms

​You would need to periodically run an Oracle query to find all the view columns and synonyms for the tables, column or both that you are interested in monitoring.  Then add those results to your sensitive data Guardium group(s).

------------------------------
Frank Bates
Guardium Admin
KeyBank N.A.
Brooklyn OH
+1 (216) 471-2740

Original Message:
Sent: 07-26-2018 16:51
From: Joseph Conrad Isidro
Subject: How does Guardium Data Protection deal with Views and Synonyms

Hi, we are using Guardium to monitor Oracle databases. We monitor sensitive data by defining them as specific Object/Fields in the rule conditions.

However, if a DBA were to CREATE a VIEW or SYNONYM that references the Column and Table being monitored, then the user would have the ability to query that view without triggering the rule conditions. If that's the case, how do Guardium resolve this circumvention?

Comments and recommendations will be much appreciated.
Thank you!

------------------------------
Joseph Conrad Isidro
------------------------------

------------------------------
KATHRYN ZEIDENSTEIN
------------------------------

Original Message:
Sent: 07-26-2018 16:51
From: Joseph Conrad Isidro
Subject: How does Guardium Data Protection deal with Views and Synonyms

Hi, we are using Guardium to monitor Oracle databases. We monitor sensitive data by defining them as specific Object/Fields in the rule conditions.

However, if a DBA were to CREATE a VIEW or SYNONYM that references the Column and Table being monitored, then the user would have the ability to query that view without triggering the rule conditions. If that's the case, how do Guardium resolve this circumvention?

Comments and recommendations will be much appreciated.
Thank you!

------------------------------
Joseph Conrad Isidro
------------------------------

We are monitoring DDL and DCL, but only on passive alerts, instead of blocking through S-GATE. Therefore an admin can just create a synonym then the following statements evade the rule.

The conditions for our access rules usually consist of DDL/DML commands against Objects. For example, an admin executes the following to a sensitive table "cards" :


select * from cards
insert into cards (recid, cardno) values('1','<a>4123143435422244</a>')
---the above triggers the rule

create view user.cards_temp as select * from cards
---this will trigger the rule, but afterwards, the admin will be able to evade the rule and see everything in his new view. This defeats the objective of the rule.

create synonym user.cards_syn for cards
---this will trigger the rule, but afterwards, the admin will be free to do queries using the synonym instead of that defined in the Guardium rule.


Any suggestions?

------------------------------
Joseph Conrad Isidro
------------------------------

Original Message:
Sent: 07-28-2018 10:36
From: KATHRYN ZEIDENSTEIN
Subject: How does Guardium Data Protection deal with Views and Synonyms

It's probably a good idea to monitor ddl from those priveleged users if you aren't already. And DCL, too, of course.

------------------------------
KATHRYN ZEIDENSTEIN

Original Message:
Sent: 07-26-2018 16:51
From: Joseph Conrad Isidro
Subject: How does Guardium Data Protection deal with Views and Synonyms

Hi, we are using Guardium to monitor Oracle databases. We monitor sensitive data by defining them as specific Object/Fields in the rule conditions.

However, if a DBA were to CREATE a VIEW or SYNONYM that references the Column and Table being monitored, then the user would have the ability to query that view without triggering the rule conditions. If that's the case, how do Guardium resolve this circumvention?

Comments and recommendations will be much appreciated.
Thank you!

------------------------------
Joseph Conrad Isidro
------------------------------

Just following up on this: I understand you have opened a case with Support. That is what is recommended.

------------------------------
Leila Johannesen
------------------------------

Original Message:
Sent: 08-07-2018 14:04
From: Joseph Conrad Isidro
Subject: How does Guardium Data Protection deal with Views and Synonyms

We are monitoring DDL and DCL, but only on passive alerts, instead of blocking through S-GATE. Therefore an admin can just create a synonym then the following statements evade the rule.

The conditions for our access rules usually consist of DDL/DML commands against Objects. For example, an admin executes the following to a sensitive table "cards" :


select * from cards
insert into cards (recid, cardno) values('1','<a>4123143435422244</a>')
---the above triggers the rule

create view user.cards_temp as select * from cards
---this will trigger the rule, but afterwards, the admin will be able to evade the rule and see everything in his new view. This defeats the objective of the rule.

create synonym user.cards_syn for cards
---this will trigger the rule, but afterwards, the admin will be free to do queries using the synonym instead of that defined in the Guardium rule.


Any suggestions?

------------------------------
Joseph Conrad Isidro

Original Message:
Sent: 07-28-2018 10:36
From: KATHRYN ZEIDENSTEIN
Subject: How does Guardium Data Protection deal with Views and Synonyms

It's probably a good idea to monitor ddl from those priveleged users if you aren't already. And DCL, too, of course.

------------------------------
KATHRYN ZEIDENSTEIN

Original Message:
Sent: 07-26-2018 16:51
From: Joseph Conrad Isidro
Subject: How does Guardium Data Protection deal with Views and Synonyms

Hi, we are using Guardium to monitor Oracle databases. We monitor sensitive data by defining them as specific Object/Fields in the rule conditions.

However, if a DBA were to CREATE a VIEW or SYNONYM that references the Column and Table being monitored, then the user would have the ability to query that view without triggering the rule conditions. If that's the case, how do Guardium resolve this circumvention?

Comments and recommendations will be much appreciated.
Thank you!

------------------------------
Joseph Conrad Isidro
------------------------------