DEV-17: Effective Design and Deployment of OpenEdge® Audit Policies Michael Jacobs Development Architect

© 2006 Progress Software Corporation2 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Agenda  Introduction to OpenEdge Auditing  What is an Audit Policy  Design Goals for Audit Policies This presentation includes annotations with additional complementary information

© 2006 Progress Software Corporation3 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies 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

© 2006 Progress Software Corporation4 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies OpenEdge 10.1 Auditing Core Service ABL Client Audit Policy Tools (APM) Open Tools Application Code SQL Client Application Code Audit Data Application Data Policy Data App DB Audit Data Archive DB Audit Event Subsystem Audit Event Subsystem DatabaseInternalApplication Security Subsystem Audit Data Subsystem Audit Data Subsystem Offline Audit Data Audit Report Audit Policy Subsystem Audit Policy Subsystem API Archive Daemon Archiving Subsystem Archiving Subsystem Reporting Subsystem DB Utilities

© 2006 Progress Software Corporation5 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Agenda  Introduction to OpenEdge Auditing  What is an Audit Policy  Where do I being

© 2006 Progress Software Corporation6 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies What Is An Audit Policy?  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 “An Audit Policy is the configuration that controls the recording of audit data into an OpenEdge database”

© 2006 Progress Software Corporation7 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies 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

© 2006 Progress Software Corporation8 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Policy Contents  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 Each Audit Policy has

© 2006 Progress Software Corporation9 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Policy’s Purpose “The primary responsibility of the Audit Policy is to direct the OpenEdge run-time which Audit Events to record.”

© 2006 Progress Software Corporation10 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Policy Structure Audit Policy Defines A Policy Events Defines Audit Events

© 2006 Progress Software Corporation11 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies What is an OpenEdge Auditing Event?  Each Event definition is a unique action or operation  Audit Events fall into three categories Database CUD( OpenEdge ) Internal ( OpenEdge ) Application ( ABL or SQL )  Each Event definition has a Unique positive integer values( 1 – max integer ) “name”( “customer.create” ) “description”( “create customer record” ) “type”( “table.customer”) “Audit Events represents the WHAT in auditing. ”

© 2006 Progress Software Corporation12 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Event Types  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 Database Record Events

© 2006 Progress Software Corporation13 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Event Types Default Database Record Events  Demonstration and development purposes  Not recommended for Production auditing NameEvent-idDescriptionType _sys.db.rec.create5100“Create record”“schema” _sys.db.rec.update5101“Update record”“schema” _sys.db.rec.delete5102“Delete record”“schema”

© 2006 Progress Software Corporation14 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Event Types  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 Application Audit Events

© 2006 Progress Software Corporation15 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Event Types  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 “Read” Audit Events

© 2006 Progress Software Corporation16 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Application Context 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 Application-Context and Audit-event-group Events UUID AB627H8 Event Application-context-id Event context “Record visit” UUID G78456U Event Application-context-id AB627H8 Event context “Visit OK Btn” UUID Q2395NL Event Application-context-id AB627H8 Event context “PUB.T1:Jones” Application-Context event Application events Record events

© 2006 Progress Software Corporation17 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Application Events and Multiple Databases  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 What happens?

© 2006 Progress Software Corporation18 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Event Types  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 Internal Audit Events

© 2006 Progress Software Corporation19 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Policy Structure Audit Policy Defines A Policy Event Policy Defines which Audit Events to Record (Has 0 to n) Events Defines Audit Events

© 2006 Progress Software Corporation20 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Sub-policies  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 Event Policy controls the creation of audit records

© 2006 Progress Software Corporation21 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Policy Structure Audit Policy Defines A Policy Event Policy Defines which Audit Events to Record (Has 0 to n) File [table] Policy Defines Each Table [Operation] to Record (Has 0 to n) Events Defines Audit Events

© 2006 Progress Software Corporation22 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Sub-policies  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 File Policy controls the auditing of a database table

© 2006 Progress Software Corporation23 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies File Sub-policy  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” File Policy strategy

© 2006 Progress Software Corporation24 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Assigning Record Operation Audit Events  Each table has a block of 10 event numbers  Related tables occupy sequential blocks  Each table’s 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 policiesControlled in event policies * File Policy Event strategy

© 2006 Progress Software Corporation25 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Policy Structure Audit Policy Defines A Policy Event Policy Defines which Audit Events to Record (Has 0 to n) File [table] Policy Defines Each Table [Operation] to Record (Has 0 to n) Field Policy Defines Each Field specific alteration to Table Policy (Has 0 to n) Events Defines Audit Events

© 2006 Progress Software Corporation26 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Field Sub-policies  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 Field Policy controls the auditing of an individual table field

© 2006 Progress Software Corporation27 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Field Sub-policies  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 Field Policy strategy

© 2006 Progress Software Corporation28 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Controlling the Storage of Audited Field Values Audit Data Subsystem Audit Data Subsystem Audit Event Subsystem Audit Event Subsystem Database Audit Policy Subsystem Audit Policy Subsystem _aud-audit-data _aud-audit-data-value _Event-detail f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14 Database record “f1:old/new, f3:old/new, f10:old/new” “Streamed Field Values” (f2, f6, f9, f14) “1 Field/Record” _aud-file-policy _aud-field-policy f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14 Audited Fields

© 2006 Progress Software Corporation29 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies What is Audit Event Context?  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) “Audit Event Context defines a specific instance of an audit event”

© 2006 Progress Software Corporation30 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Event Context Strategy  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 subsets “print” “print.audit” “print.audit.users.dduck” Simplify queries for one or more instances of an Audit Event

© 2006 Progress Software Corporation31 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Loading Audit Policies at Run-time  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 Only active policies are loaded

© 2006 Progress Software Corporation32 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Agenda  Introduction to OpenEdge Auditing  What is an Audit Policy  Design Goals for Audit Policies

© 2006 Progress Software Corporation33 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Auditing Policy Architectures  Many possible designs  No single right design for ever 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 What type of policy design do I use?

© 2006 Progress Software Corporation34 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Audit Policy Design Goals 1. Record enough to generate the reports 2. NOT abuse disk space & performance 3. Simplify auditing administration My Audit Policy design needs to

© 2006 Progress Software Corporation35 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Generating the required reports  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 The audit reports drive which

© 2006 Progress Software Corporation36 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Simplifying Audit Administration  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 To simplify audit administration for the end-user

© 2006 Progress Software Corporation37 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Choosing an Audit Policy Strategy  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 ? Which audit policy deployment strategy would be best ?

© 2006 Progress Software Corporation38 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Choosing the Audit Policy Architecture  The “big-bang” policy  The “application-feature” policy  The “master-switch” policy

© 2006 Progress Software Corporation39 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies 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 Table: Operations: Fields: Event: On/Off: customer cust-num,… delete: min ON update: full ON employee emp-num,… create: min ON update: full ON N/A OFF N/A ON BigBangPolicy 

© 2006 Progress Software Corporation40 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies 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 Table: Operations: Fields: Event: On/Off: customer cust-num,… delete: min ON update: full ON CustomerPolicy  EmployeePolicy  Table: Operations: Fields: Event: On/Off: customer cust-num,… delete: min ON update: full ON AdminPolicy  Event: On/Off: ON ON

© 2006 Progress Software Corporation41 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies 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 Table: Operations: Fields: Event: customer cust-num,… delete: min update: full employee emp-num,… create: min update: full StdTablePolicy  CustomerPolicy  Event: On/Off: ON ON EmployeePolicy  Event: On/Off: ON ON AdminPolicy  Event: On/Off: ON ON

© 2006 Progress Software Corporation42 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies What can OpenEdge Auditing Do Out of the Box? 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 Use the OpenEdge supplied policies and reports

© 2006 Progress Software Corporation43 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies 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

© 2006 Progress Software Corporation44 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Questions?

© 2006 Progress Software Corporation45 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies Thank you for your time

© 2006 Progress Software Corporation46 DEV-17: Effective Design and Deployment of OpenEdge Audit Policies