Title: DEV17: Effective Design and Deployment of OpenEdge Audit Policies
1DEV-17 Effective Design and Deployment of
OpenEdge Audit Policies
Michael Jacobs
Development Architect
2Agenda
- Introduction to OpenEdge Auditing
- What is an Audit Policy
- Where do I being
This presentation includes annotations with
additional complementary information
3What is Auditing?
- Auditing is the process of evaluating an
organizations practices for safeguarding
electronic information from loss, damage,
unintended disclosure, or denial of
availability.
- The OpenEdge Auditing core services 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
4OpenEdge 10.1 Auditing Core Service
Audit Policy Tools (APM)
Audit Policy Subsystem
API
App DB
Open Tools
ABL Client
Policy Data
Audit Event Subsystem
Audit Data Subsystem
Application Data
Application Code
Audit Data
Security Subsystem
Database
Internal
Application
DB Utilities
Archive DB
Application Code
Archiving Subsystem
Reporting Subsystem
Archive Daemon
Audit Data
SQL Client
OfflineAuditData
AuditReport
5Agenda
- Introduction to OpenEdge Auditing
- What is an Audit Policy
- Where do I being
6What 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
7Audit 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
8Audit 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
9Audit Policy Structure
10What is an OpenEdge Auditing Event?
Audit Events represent the WHAT in auditing.
- Each Event definition is a unique action or
operation - Audit Events fall into three types
- Database CUD ( OpenEdge )
- Internal ( OpenEdge )
- Application ( ABL or SQL )
- Each Event definition has a
- Unique positive integer value ( 1 to max integer
) - name ( customer.create )
- description ( create customer record )
- group ( table.customer)
11Audit Event Types
Database Record Events
- Used for
- Record tables row operations
- Create, Update, and Delete
- Optionally recording selected field values
- Recorded only in the local database
- Query by table name OR table and selected field
values - No automatic application context relating the
record operation to application operation
12Audit Event Types
Default Database Record Events
- Demonstration and development purposes
- Recommend using application defined event IDs for
Production auditing
13Audit Event Types
Application Audit Events
- Used for
- Recording business level, coarse grained, events
- 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
- Coded into the application
- Event number
- Audit records Event Context format and content
- Audit records event detail format and content
14Audit 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
15Application 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 G78456UEvent
34600Application-context-id AB627H8Event
context Visit OK Btn
Application events
Application-Context event
UUID Q2395NLEvent
34002Application-context-id AB627H8Event
context PUB.T1Jones
Record events
16Application 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 databases Event policy to record
the event if immediate queries are not required
17Audit Event Types
Internal Audit Events
- Are a form of application audit event
- Could not be captured by your applications
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.da
ta.dump 10310_sys.tbl.create 5000_sql.dba.cre
ate 210_sys.area.truncate 10209
18Audit Policy Structure
(Has 0 to n)
Event Policy
Defines which Audit Events to Record
19Audit 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
20Audit Policy Structure
(Has 0 to n)
File table Policy
Defines Each Table Operation to Record
21Audit 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 events context data
- Default Tables primary index fields
22File 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 lt 50 of records field values
- Record row changes only
- If recording gt 50 of records field values
- Record field values
- DO NOT set 1 record/field
23Assigning Record Operation Audit Events
File Policy Event strategy
- Each table has a block of 10 event numbers
- Related tables occupy sequential blocks
- Each tables events
- CREATE - record create (table-base 0)
- UPDATE - record update (table-base 1)
- DELETE - record delete (table-base 2)
- VIEW - viewed by terminal user
(table-base 3) - IMPORT - electronic transfer in (table-base
4) - EXPORT - electronic transfer out (table-base
5) - PRINT - paper copy made (table-base 6)
- REPLICA - electronic copy made (table-base
7)
Controlled in table policies
Controlled in event policies
24Audit Policy Structure
25Field Sub-policies
Field Policy controls the auditing of an
individual table field
- Identifies the tables field to be audited
- Overrides the tables 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 records primary index fields
- Sets the fields order in the context field
26Field 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
27Controlling the Storage of Audited Field Values
Audit Event Subsystem
Audit Policy Subsystem
Database
_aud-file-policy
_aud-field-policy
Audit Data Subsystem
_aud-audit-data
_Event-detail
28What 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
- WARNING avoid format changes at production
sites (or you make queries very complex)
29Event 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?pluto56 Bone Dr. - Application Event context
- Use multiple fields of context information c1
.c2 .c3 - More context fields yields smaller record
subsetsprintprint.auditprint.audit.users.d
duck
30Loading 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
tables 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
31Agenda
- Introduction to OpenEdge Auditing
- What is an Audit Policy
- Where do I begin
32Auditing Policy Architectures
What type of policy design do I use?
- Many possible designs
- No single right design for every application
- Every application has one best design
- The policy design is driven by
- Who generates and runs the reports
- Who generates and manages the policies
33Audit Policy Design Goals
My Audit Policy design needs to
- Record enough to generate the reports
- NOT abuse disk space performance
- Simplify auditing administration
34Generating 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 and classes
35Simplifying 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
36Choosing 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 ?
37Choosing the Audit Policy Architecture
- The big-bang policy
- The application-feature policy
- The master-switch policy
38The 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
Event On/Off customer
cust-num, delete min
40203 ON update
full 40201 ON employee
emp-num, create min
40300 ON update full
40301 ON N/A
32100 OFF N/A
32900 ON
39The 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
?
AdminPolicy
Event On/Off 32300 ON 32901 ON
?
EmployeePolicy
Table Operations Fields
Event On/Off customer
cust-num, delete min
40203 ON update full
40201 ON
40The 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
?
?
?
AdminPolicy
CustomerPolicy
EmployeePolicy
Event On/Off 32100 ON 32901 ON
Event On/Off 40202 ON 40201 ON
Event On/Off 40300 ON 40301 ON
?
StdTablePolicy
Table Operations Fields
Event customer
cust-num, delete min
40202 update full
40201 employee
emp-num, create min
40300 update full
40301
41What can OpenEdge Auditing Do Out of the Box?
Use the OpenEdge supplied policies and reports
?
- ABL SQL user login/logout (needs 10.1A
security) - 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
?
?
?
?
42Audit Policy Deployment
What are your options?
- Dictionary Audit Event Policy dump / load
- APM Audit Event Policy export / import
- APMs ABL-API Dictionary data dump / load
- procopy db with populated policy tables
- ABL EXPORT / IMPORT statements
- ABL CREATE
- proutil binary dump / load (prohibited)
- Dictionary data dump / load (prohibited)
43In Summary
- OpenEdge Auditing is very powerful and flexible
- Audit Policies drive run-time auditing
- Good Audit Policy design simplifies auditing
administration and tunes performance
44Questions?
45Thank you foryour time
46(No Transcript)