DEV-17: Effective Design and Deployment of
OpenEdge® Audit Policies
Michael Jacobs
Development Architect
Agenda
 Introduction to OpenEdge Auditing
 What is an Audit Policy
 Design Goals for Audit Policies
This presentation includes annotations with additional complementary information
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
2
© 2006 Progress Software Corporation
What is Auditing?
“Auditing is the process of evaluating an organization’s
practices for safeguarding electronic information from
loss, damage, unintended disclosure, or denial of
availability.”
The OpenEdge Auditing core service’s role is to gather,
record, and securely maintain the information necessary to
perform the auditing process:
• Who was the client
• What action took place
• When did it happen
• Where did it happen
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
3
© 2006 Progress Software Corporation
Archive
Daemon
Offline
Audit
Data
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
Policy
Data
Audit
Data
Application
Data
Security Subsystem
Reporting
Subsystem
Application
Code
App DB
Audit Data
Subsystem
Archiving
Subsystem
SQL Client
DB Utilities
Database
Application
Code
Audit Event
Subsystem
Internal
Open Tools
Audit Policy
Subsystem
API
Audit Policy
Tools (APM)
Application
ABL Client
OpenEdge 10.1 Auditing Core Service
Archive DB
Audit
Data
Audit
Report
4
© 2006 Progress Software Corporation
Agenda
 Introduction to OpenEdge Auditing
 What is an Audit Policy
 Where do I being
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
5
© 2006 Progress Software Corporation
What Is An Audit Policy?
“An Audit Policy is the configuration that controls the
recording of audit data into an OpenEdge database”
 Through Audit Policies you control
•
•
•
•
•
•
What audit information is recorded
Where to store audited information
How to store audited information
How much audited information to store
Context information to query audit information
Security of audit information
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
6
© 2006 Progress Software Corporation
Audit Policy Attributes
 Stored in audit-enabled OpenEdge databases
• Contain any number of policies
 Apply only to the database they are stored in
 Simultaneous active or inactive state ( on/off )


Active policies are merged at load-time
Can be changed and reloaded on-line
 Has a unique GUID identifier
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
7
© 2006 Progress Software Corporation
Audit Policy Contents
Each Audit Policy has
 Human readable name
 Audit policy description
 Security level settings for audit records
 Shared set of Audit Event definitions
 One or more sub-policies
• Event policies
• File [table] policies
• Field policies
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
8
© 2006 Progress Software Corporation
Audit Policy’s Purpose
“The primary responsibility of the Audit Policy
is to direct the OpenEdge run-time which
Audit Events to record.”
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
9
© 2006 Progress Software Corporation
Audit Policy Structure
Audit Policy
Defines A Policy
Events
Defines Audit
Events
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
10 © 2006 Progress Software Corporation
What is an OpenEdge Auditing Event?
“Audit Events represents the WHAT in auditing. ”

Each Event definition is a unique action or operation

Audit Events fall into three categories
• Database CUD
• Internal
• Application

( OpenEdge )
( OpenEdge )
( ABL or SQL )
Each Event definition has a
•
•
•
•
Unique positive integer values
“name”
“description”
“type”
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
( 1 – max integer )
( “customer.create” )
( “create customer record” )
( “table.customer”)
11 © 2006 Progress Software Corporation
Audit Event Types
Database Record Events
 Used for
• Record table’s row operations
– Create, Update, and Delete
• Optionally record selected field values
 Recorded only in the local database
 Query by table name OR table and selected
field values
 No “application context” relating the record
operation to application operation
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
12 © 2006 Progress Software Corporation
Audit Event Types
Default Database Record Events
Name
Event-id
Description
Type
_sys.db.rec.create
5100
“Create record”
“schema”
_sys.db.rec.update
5101
“Update record”
“schema”
_sys.db.rec.delete
5102
“Delete record”
“schema”
 Demonstration and development purposes
 Not recommended for Production auditing
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
13 © 2006 Progress Software Corporation
Audit Event Types
Application Audit Events

Used for
•
•
•
•

Events with no corresponding database operation
“Read auditing”
Applying “application context” to [record] audit events
Grouping related audit events for easy queries
Triggered by adding new language statements
• ABL or SQL application code

Code once into the application
• Event number
• Audit record’s Event Context format and content
• Audit record’s event detail format and content
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
14 © 2006 Progress Software Corporation
Audit Event Types
“Read” Audit Events
 Regulations audit the “human” data access
 OpenEdge reads many records in a query
 Filtered record set returned to application
 Only application knows the “human” access
 Read is not the only “human” access
• Printed reports
• Electronic copy to removable media
• Network transport to external application
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
15 © 2006 Progress Software Corporation
Application Context Events
Application-Context and Audit-event-group Events
 Are a form of application audit event
 Normalize applying “application context” to
• Database record audit events
• Other application audit events

Group related audit records across multiple databases
UUID
AB627H8
Event
31998
Application-context-id
Event context
“Record visit”
Application-Context event
UUID
Event
Application-context-id
Event context
G78456U
34600
AB627H8
“Visit OK Btn”
Application events
UUID
Event
Application-context-id
Event context
Q2395NL
34002
AB627H8
“PUB.T1:Jones”
Record events
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
16 © 2006 Progress Software Corporation
Application Events and Multiple Databases
What happens?

Application Events are sent to all databases
• Allows for immediate query of events in any database
• Same Audit record UUID primary index in each
database (duplicate)
• Duplicates removed by archive utility load operation

Minimize performance overhead
• Enable only one database’s policy to record the event
if immediate queries are not required
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
17 © 2006 Progress Software Corporation
Audit Event Types
Internal Audit Events



Are a form of application audit event
Could not be captured by your application’s auditing
Are triggered by internal OpenEdge operations
• ABL & SQL database clients
• Database utilities

Ids are predefined by OpenEdge
• In OpenEdge controlled event-id space [ 0 – 31,999 ]
_pvm.user.login.pass #10510
_sys.audit.data.dump #10310
_sys.tbl.create
#5000
_sql.dba.create
#210
_sys.area.truncate
#10209
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
18 © 2006 Progress Software Corporation
Audit Policy Structure
Audit Policy
(Has 0 to n)
Defines A Policy
Event Policy
Defines which Audit
Events to Record
Events
Defines Audit
Events
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
19 © 2006 Progress Software Corporation
Audit Sub-policies
Event Policy controls the creation of audit records
 Acts as a “master on/off switch”
• Database record events
• Application events
• Internal events
 Must be defined and “on” to create an audit
record
 Controls recording event detail information
• Application events
• Internal events
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
20 © 2006 Progress Software Corporation
Audit Policy Structure
Audit Policy
Defines A Policy
(Has 0 to n)
(Has 0 to n)
Event Policy
Defines which Audit
Events to Record
File [table] Policy
Defines Each Table
[Operation] to Record
Events
Defines Audit
Events
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
21 © 2006 Progress Software Corporation
Audit Sub-policies
File Policy controls the auditing of a database table
 Identifies the table to be audited
 Maps table CUD operations to Audit Events
 Controls the CUD and field auditing defaults
• Sets default On/off auditing of CUD operations
• Sets default amount of field data to record
• Sets default storage location of field data
 Sets the record event’s context data
• Default: Table’s primary index fields
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
22 © 2006 Progress Software Corporation
File Sub-policy
File Policy strategy

Use application defined events for CUD
• Use Event Policy to control NOT recording table CUD

Do not use default field auditing
• All record fields audited

Audit record created when
• Create & Delete: on record create or delete
• Update: when any audited field changed

Default UPDATE field value recording
• If recording < 50% of record’s field values
– Record row changes only
• If recording > 50% of record’s field values
– Record field values
• DO NOT set “1 record/field”
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
23 © 2006 Progress Software Corporation
Assigning Record Operation Audit Events
File Policy Event strategy



Each table has a block of 10 event numbers
Related tables occupy sequential blocks
Each table’s events
•
•
•
•
•
•
•
•
CREATE - record create
UPDATE - record update
DELETE - record delete
VIEW
- viewed by terminal user *
IMPORT - electronic transfer in *
EXPORT - electronic transfer out *
PRINT
- paper copy made *
REPLICA - electronic copy made *
Controlled in table policies
(table-base + 0)
(table-base + 1)
(table-base + 2)
(table-base + 3)
(table-base + 4)
(table-base + 5)
(table-base + 6)
(table-base + 7)
Controlled in event policies *
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
24 © 2006 Progress Software Corporation
Audit Policy Structure
Audit Policy
Defines A Policy
(Has 0 to n)
(Has 0 to n)
Event Policy
Defines which Audit
Events to Record
File [table] Policy
Defines Each Table
[Operation] to Record
Events
Defines Audit
Events
(Has 0 to n)
Field Policy
Defines Each Field specific
alteration to Table Policy
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
25 © 2006 Progress Software Corporation
Field Sub-policies
Field Policy controls the auditing of an individual table field
 Identifies the table’s field to be audited
 Overrides the table’s default settings
• Selects or deselects auditing the field
• Sets amount of field data to record
• Sets storage location of field data
– Streamed
– 1 record/field
 Includes field in Event Context identifying fields
• Deselects record’s primary index fields
• Sets the fields order in the context field
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
26 © 2006 Progress Software Corporation
Field Sub-policies
Field Policy strategy
 Use 1 field/record only when
• Queries require indexing by field name
 Audit field values when
• Reports require values
 Manually specify context identifying fields
• Queries require non-primary index field value
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
27 © 2006 Progress Software Corporation
Controlling the Storage of Audited Field Values
f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14
Database
Audit Event
Subsystem
Database record
Audit Policy
Subsystem
_aud-file-policy
_aud-field-policy
Audited Fields
f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14
“1 Field/Record”
(f2, f6, f9, f14) Audit Data
Subsystem
“Streamed Field Values”
“f1:old/new, f3:old/new, f10:old/new”
_aud-audit-data
_aud-audit-data
_aud-audit-data
_aud-audit-data
_aud-audit-data-value
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
_Event-detail
28 © 2006 Progress Software Corporation
What is Audit Event Context?
“Audit Event Context defines a specific instance of an
audit event”
 Event ID & Context are the primary query filters
 Used to simplify queries for specific
• Record changes
• Application operation or action
• OpenEdge operations or actions
 Avoid format changes at production sites
(or you make queries very complex)
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
29 © 2006 Progress Software Corporation
Event Context Strategy
Simplify queries for one or more instances of an Audit Event
 Record Event context
• Query table changes by [index] field values
“PUB.Customer”
“PUB.Customerpluto”
“PUB.Customerpluto•56 Bone Dr.”
 Application Event context
• Use multiple fields of context information
c1 [ .c2 [ .c3 … ] ]
– More context fields yields smaller record subsets
“print”
“print.audit”
“print.audit.users.dduck”
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
30 © 2006 Progress Software Corporation
Loading Audit Policies at Run-time
Only active policies are loaded

Merges all active policies to a single
•
•
•
•

_aud-audit-policy definition
_aud-event-policy definition for each event
_aud-file-policy definition for each table
_aud-field-policy definition for each audited table’s field
Built-in conflict resolution
• Chooses maximum level for
– Event policy
– Record CUD table operations and fields
– Audit record security and Custom detail

Tip: Use APM Effective Settings & Conflicts reports
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
31 © 2006 Progress Software Corporation
Agenda
 Introduction to OpenEdge Auditing
 What is an Audit Policy
 Design Goals for Audit Policies
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
32 © 2006 Progress Software Corporation
Auditing Policy Architectures
What type of policy design do I use?

Many possible designs


No single right design for ever application

The policy design is driven by
Every application has one best design
• Who generates and runs the reports
• Who generates and manages the policies
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
33 © 2006 Progress Software Corporation
Audit Policy Design Goals
My Audit Policy design needs to
1.
Record enough to generate the reports
2.
NOT abuse disk space & performance
3.
Simplify auditing administration
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
34 © 2006 Progress Software Corporation
Generating the required reports
The audit reports drive which

Tables need audit policies
• Which record operations need auditing
• Fields values need to be recorded
• Field values need to be indexed



Application events are needed and where
Application event context formats and values to use
Application-context and Audit-event-group to use
• Where in the application code
• Spanning which procedures
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
35 © 2006 Progress Software Corporation
Simplifying Audit Administration
To simplify audit administration for the end-user

Focus on who controls what to audit
• Their level of technical skills ?
• Their depth of application and database knowledge ?
• Your ability to do training and documentation ?
• Your ability to support detailed policy administration ?

Expose only what needs to be configurable
• Hide details inside built-in policies
• Use a management UI to activate & de-activate policies
• Automate easy switching to/from
– Auditing primary application “features”
– Maintenance versus production mode
– Different levels of auditing detail
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
36 © 2006 Progress Software Corporation
Choosing an Audit Policy Strategy
Which audit policy deployment strategy would be best ?

I do nothing
• Customer 100% responsible for generating policies

I can supply audit policies as templates
• Development supplies 80% knowledge in templates
• Customer customizes remaining 20% of templates
• Must I be aware of liability issues?

I can sell audit administration as a service
• Developer does remote policy creation and administration

I can supply turn-key audit policies
• Developer supplies 100% knowledge
• Customer site uses UI tool to manage auditing
• Must I be aware of liability issues ?
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
37 © 2006 Progress Software Corporation
Choosing the Audit Policy Architecture
 The “big-bang” policy
 The “application-feature” policy
 The “master-switch” policy
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
38 © 2006 Progress Software Corporation
The Big-Bang Policy

One policy includes all
• Table, Field, and Event policies


All auditing is either ON or OFF
Manage auditing by direct policy record manipulation
BigBangPolicy

Table:
Operations:
Fields:
customer
cust-num,…
delete: min
update: full
employee
emp-num,…
create: min
update: full
N/A
N/A
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
Event: On/Off:
40203
40201
ON
ON
40300
40301
32100
32900
ON
ON
OFF
ON
39 © 2006 Progress Software Corporation
The Application-Feature Policy


One policy audits one application feature
Each application feature policy contains
• All related Table, Field, and Event policies

Manage auditing by switching policies on/off
CustomerPolicy

Table:
Operations:
Fields:
Event: On/Off:
customer
cust-num,…
delete: min
40203 ON
update: full
40201 ON
EmployeePolicy 
Table:
Operations:
Fields:
Event: On/Off:
customer
cust-num,…
delete: min
40203
ON
update: full
40201
ON
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
AdminPolicy

Event: On/Off:
32300 ON
32901 ON
40 © 2006 Progress Software Corporation
The Master-Switch Policy



One policy for all tables and fields, always active
One policy audits one application feature (only events)
Manage auditing by switching policies on/off
CustomerPolicy 
Event: On/Off:
40202 ON
40201 ON
StdTablePolicy
EmployeePolicy 
Event: On/Off:
40300 ON
40301 ON
AdminPolicy

Event: On/Off:
32100 ON
32901 ON

Table:
Operations:
Fields:
customer
cust-num,…
delete: min
update: full
employee
emp-num,…
create: min
update: full
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
Event:
40202
40201
40300
40301
41 © 2006 Progress Software Corporation
What can OpenEdge Auditing Do Out of the Box?
Use the OpenEdge supplied policies and reports





ABL & SQL user login/logout
ABL & SQL database connections
OpenEdge DB schema changes
OpenEdge DB ABL & SQL security administration
OpenEdge Database administration
Audit policy administration
Application context events
Default OpenEdge database record events
OpenEdge database _User accounts administration
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
42 © 2006 Progress Software Corporation
In Summary
 OpenEdge Auditing is very


powerful and flexible
Audit Policies drive run-time
auditing
Good Audit Policy design
simplifies auditing
administration and tunes
performance
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
43 © 2006 Progress Software Corporation
Questions?
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
44 © 2006 Progress Software Corporation
Thank you for
your time
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
45 © 2006 Progress Software Corporation
DEV-17: Effective Design and Deployment of OpenEdge Audit Policies
46 © 2006 Progress Software Corporation