Audit Trail Functionality in Progress OpenEdge 10.02 B

[cbsethna]

We have a statutory requirement of Audit trail functionality in QAD. I am aware that there is a audit functionality in the standard QAD which can be activated. Based on few expert opinions I found that it is not advisable to activate this feature. The reason behind is it will generate lot of data which will be difficult to manage.

My questions as below.
1. Is the access through progress editor to the database can be audited or anyone who has some workaround.
2. What are the merits and de-merits of activating the Audit functionality in the system and will it suffice the question no. 1 above that is will it also create an audit log of the tasks done using progress editor.
3. There is one standard feature like "Master Table Audit Detail Report". This contains auditing feature for a certain tables only. Can we add tables into this feature and if yes then how to .

Forum's views / suggestions are appreciated .

Thanks & Regards
Cyrus Sethna

 

[Rob Fitzpatrick]

It's not clear to me whether your questions are about OpenEdge Auditing capabilities in general, or about some QAD-specific implementation of it. If it is the latter, then this isn't the appropriate forum.

1. Is the access through progress editor to the database can be audited or anyone who has some workaround.

It depends on what you mean by "access". OpenEdge Auditing (OEA) can audit system events such as login and logout, as well as some record operations: creates, updates, and deletes. And it can audit custom application events, given the appropriate configuration and code changes. By design, OEA does not audit record read operations.
So you also need to think about your authentication system and your database configuration. Auditing without proper authentication is pointless. Can someone connect to your database as the blank user? If so, auditing their actions won't tell the auditor who did what.

2. What are the merits and de-merits of activating the Audit functionality in the system and will it suffice the question no. 1 above that is will it also create an audit log of the tasks done using progress editor.

If you audit, for example, delete operations in the Customer table, then the audit records are created regardless of how the user did it: via application code, ad hoc code run in the editor, or via a SQL connection.
As for pros and cons of "activating the Audit functionality in the system", that could be a wide-ranging discussion, and as I said it depends a lot on whether you mean OEA or something specific to QAD; this may not be the right audience for that conversation.

3. There is one standard feature like "Master Table Audit Detail Report". This contains auditing feature for a certain tables only. Can we add tables into this feature and if yes then how to .

I don't see anything like that in the canned OEA reports:


So I assume you're talking about QAD. I can't help you there.

I'll also add the obvious: OpenEdge 10.2B shipped in 2009 and was retired in 2019. It is woefully out of date to be running mission-critical software.

 

[TomBascom]

We have a statutory requirement of Audit trail functionality...

That is awfully vague.

Surely the "requirement" specifies what sorts of events you must audit. From the rest of your post it almost sounds like you only need to be keeping track of certain events like "access to the Progress editor". If that is true and the if number of events is fairly limited then this is not difficult to implement with OE Auditing and it doesn't have much of an impact.

On the other hand - if the requirement is "audit everything" then, yes, you are looking at a serious amount of extra work being done and if your current hardware is barely adequate you likely need to be strongly considering some upgrades before you go ahead and do so.

There is no "free lunch". If you need to audit then you are going to do additional work and that is going to have an impact. OpenEdge Auditing is a good choice for such purposes. It is "free" in that there is no additional license cost but there are operational costs (you need to manage the configuration and the generated audit data) as well as performance costs (obviously writing the audit log is going to result in an additional IO impact). How painful that is is going to be depends an awful lot on what, exactly, "statutory requirement of Audit trail functionality" means.

 

[cbsethna]

It's not clear to me whether your questions are about OpenEdge Auditing capabilities in general, or about some QAD-specific implementation of it. If it is the latter, then this isn't the appropriate forum.


It depends on what you mean by "access". OpenEdge Auditing (OEA) can audit system events such as login and logout, as well as some record operations: creates, updates, and deletes. And it can audit custom application events, given the appropriate configuration and code changes. By design, OEA does not audit record read operations.
So you also need to think about your authentication system and your database configuration. Auditing without proper authentication is pointless. Can someone connect to your database as the blank user? If so, auditing their actions won't tell the auditor who did what.


If you audit, for example, delete operations in the Customer table, then the audit records are created regardless of how the user did it: via application code, ad hoc code run in the editor, or via a SQL connection.
As for pros and cons of "activating the Audit functionality in the system", that could be a wide-ranging discussion, and as I said it depends a lot on whether you mean OEA or something specific to QAD; this may not be the right audience for that conversation.


I don't see anything like that in the canned OEA reports:
View attachment 2981

So I assume you're talking about QAD. I can't help you there.

I'll also add the obvious: OpenEdge 10.2B shipped in 2009 and was retired in 2019. It is woefully out of date to be running mission-critical software.

Hi Rob

Thanks for the quick reply. I understood that some of the points above relate to QAD too. So ignoring that we can use the OEA to have a audit at the progress level. So any data change in any ways possible ( via Application code from frontend or by an adhoc query in the backend ) on a table can be seen here in this way.

Regards
Cyrus Sethna

 

[cbsethna]

That is awfully vague.

Surely the "requirement" specifies what sorts of events you must audit. From the rest of your post it almost sounds like you only need to be keeping track of certain events like "access to the Progress editor". If that is true and the if number of events is fairly limited then this is not difficult to implement with OE Auditing and it doesn't have much of an impact.

On the other hand - if the requirement is "audit everything" then, yes, you are looking at a serious amount of extra work being done and if your current hardware is barely adequate you likely need to be strongly considering some upgrades before you go ahead and do so.

There is no "free lunch". If you need to audit then you are going to do additional work and that is going to have an impact. OpenEdge Auditing is a good choice for such purposes. It is "free" in that there is no additional license cost but there are operational costs (you need to manage the configuration and the generated audit data) as well as performance costs (obviously writing the audit log is going to result in an additional IO impact). How painful that is is going to be depends an awful lot on what, exactly, "statutory requirement of Audit trail functionality" means.

Hello Tom

Thanks for the quick reply. The latter stands true for me. I need to audit everything ( may be I can decide onto which tables i need auditing ) . Yes agree with your point on the resources. So we can create and enable this OEA feature and can be easily disabled whenever required .

Regards
Cyrus Sethna