db-14: openedge ® database run-time security revealed michael jacobs architect, progress openedge

DB-14: OpenEdge® Database Run-time Security Revealed

Michael JacobsArchitect, Progress OpenEdge

Agenda

Run-time database security landscape OpenEdge 10 database security Comparing run-time and compile-time Configuring run-time database security

Database Run-time Security Drivers

Because you have to• Government regulations• Industry standards• Personal data privacy requirements

Legal liability• Imposed $$ penalties

It is all because of the hackers• They have tools• They have the knowledge• They have the motivation

Why motivates us to use run-time database security:

CSI/FBI Computer Crime & Security Survey

48% detected 1 – 6 security incidents• 68% reported losses due to insider attacks• Average loss ~$168,000

Top reasons for loss• Viruses• Unauthorized access to information• Laptop / mobile hardware theft• Theft of proprietary information

Top security issues • Data protection & application security• Policy & regulatory compliance• Identity theft & leakage of private information

2006 respondents reported :

(index blocks) OS Files (record blocks)

(cache files)

Database Security

Database UtilitiesDB Server

xDBC Driver

ApplicationA

In a perfect world, the application stack has no security holes:

OS/Network Security

xDBC Driver

ApplicationB

xDBC Driver

ApplicationC

(Black-hathacker)

(index blocks) OS Files (record blocks)

(cache files)

Database Security

Database UtilitiesDB Server

xDBC Driver

ApplicationA

In reality, the application stack has many vulnerabilities :

OS/Network Security

xDBC Driver

ApplicationB

xDBC Driver

ApplicationC

Database Run-time Security’s Role

SQL sets the standard for database run-time security• User authentication• Database administration• View, table & column access controls

Database vendors add security features• Multiple user authentication systems• User connection privileges• Role & user-group privileges

Block application-code attacks & inappropriate user access :

Agenda

OpenEdge Database Security

SQL PrivilegesSQL Privileges ABL PermissionsABL Permissions

One database – two security systems :SQL Server ABL Core

applicationCRUD

applicationISUD

userauthentication

user accountsuser accounts

userauthorization

Public TablesPublic Tables

SQL TablesSQL Tables

OpenEdge RDBMS

• Database storage engine performs no security operations

• SQL & ABL clients provide all database security

Comparing ABL & SQL Security Systems

ABL SQLSecurity model GRANT GRANT

Default DBA n/a <db-owner>SYSPROGRESS

Default security administrator

“*” n/a

Default table access “*” <none>

Default field access “*” <none>

OpenEdge Database Auditing

How do you know the security systems have not been compromised ?

SQL Server ABL Core

applicationCRUD

applicationISUD

userauthentication

userauthorization

Schema & data Tables

OpenEdge RDBMS

• No SQL or ABL database record operations can bypass auditing

Audit DataAudit Data

Audit subsystemAudit subsystem

Audit RulesAudit Rules policies.xml

User Authentication

Shared ABL & SQL User Accounts

Two required fields• user-id (_Userid)

– Maximum length: 12– Illegal characters: < 32 or “#*,!@”

• password (_Password) – ABL: Changed only by the account’s owner– SQL: Changed by DBA or the account’s owner

Password field: fixed-length CRC-16 hash

Beware of default SQL DBA account definitions• <db-owner> (DBA privileges)• SYSPROGRESS (DBA privileges)• PUB (table owner privileges)

_User table accounts :

ABL & SQL _User Account Behavior

• Without _User accounts– User-id: OS process id– Cannot use –U –P to

connect

• With _User accounts– Default user-id: “”– -U/-P must match _user

account– Can always CONNECT

as default user-id

• Without _User accounts– Default user-id: none– Connect with any user-id

except• “PUB”• “SYSPROGRESS”

(passwords ignored)

• With _User accounts– Default user-id: none– MUST authenticate to

_User account– PUB & SYSPROGRESS

accepted as user-ids

ABL SQL

ABL Prompting for User-id

ABL Core:run _edit.p.

_edit.prun _prostar.p.

_prostar.prun _login.p.

* Sources found in DLC/src & PSDN development tools download

It all happens inside ABL procedures :

ABL & SQL User Account Administration

ABL SQL

Create account

CREATE _userrecord statement

CREATE USER

Delete account

DELETE _userrecord statement

DROP USER

Change password

ASSIGN field statement

ALTER USER

Create password

ENCODE () N/A

Similar user account operations :

Alternative user authentication for ABL only applications :

user accounts( _user )

userauthentication

user logincredentials

connectionuser-id

SQL ServerABL Core

isvalid?

CLIENT-PRINCIPAL

userauthentication

ABL Application

ABL Core

AuthenticationConfiguration

isvalid?

ValidateCLIENT-

PRINCIPALY

Proof ofABL user

authentication

User Authorization

All Tables Have an Owner

“PUB” (SQL server & ABL user-id) • Data tables

– ABL clients: Create, Read, Update, & Delete– SQL clients: Insert, Select, Update, & Delete

• Meta schema tables– ABL clients: Create, Read, Update, & Delete– SQL clients: Select

“SYSPROGRESS” (private user-id for SQL server)• ABL clients: none• SQL clients: Select

“<sql-client>” (supported only by SQL server)• SQL clients: Insert, Select, Update, & Delete• ABL clients: none

Both ABL & SQL clients respect table “ownership” :

ABL Core Database Security

Administered via _schema record CRUD operations :

F1F1 F2F2 F3F3 F4F4 F5F5 F6F6 F7F7

Table DataTable Data

_File Permissions

_Field recordPermissions

_Can-create

_Can-write

_Can-read

_Can-delete

_Can-read

_Can-write

* Sometimes meta-schema table & field permissions lie

assign

findforcreatedelete

SQL Server Database Security

Administered via GRANT/REVOKE SQL statements :

_systabauth Privileges

_syscolauth Privileges

insert update select delete

updateupdate

Selective column update only

selectinsertupdatedelete

create update read delete

updateupdate

SQL Server Database Security

Wrapper for a mixture of selected rows & columns :

_systabauthPrivileges

_syscolauthPrivileges

insert update select delete

updateupdate

View Privileges

selectinsertupdatedelete

No read access by exclusion

Database Administration

SQL Standard Database Administration

DBA has all database privileges*

Table’s “owner” has all table & column privileges

A user must have a privilege before they can GRANT that privilege to others

The grantor of a privilege can REVOKE that privilege

A privilege may be GRANTED without the ability to grant it to any other user

* Except OpenEdge Auditing SoD (Separation of Duty)

ABL Security Administrator Revealed

ABL Security Administrator is NOT A DBA

ABL Security Administrator controls• Table & field access via _Can-* permissions

• User account creation & deletion

• ABL client & database security options

Security Administrator’s user-account list is replicated in many places• See PSDN open-source development tools

– src/prodict/user/_usradmn.p

Agenda

Compile-time Versus Run-time Security

LowerHigherSecurity risk from user impersonation & rogue r-code

NoYesApplication security context

> compile time< run-timeRun-time impact

DynamicFixedTable & column access

DynamicFixed Connection’s user-id

Run-timeCompile-time

OE DatabaseServer

ABL Corecompiler

Public Data

Permissions

ABL .r-code contains only the permitted CRUD operations :

dynamic buffer

static buffer

.rcode(RU)

useraccess?

connectionuser-id

userauthentication

.psource(CRUD)

(CRUD)

Permitted recordoperations

All record operations

Checks user-id to permitted operations

OE DatabaseServer

ABL Corerun-time

Public Data

Permissions

Default ABL Core run-time permission checking :

dynamic buffer

static buffer

.rcode(RU)

useraccess?

connectionuser-id

userauthentication

.rcode

(CRUD)

Not checkedat run-time

Checkedat run-time

OE DatabaseServer

ABL Corerun-time

Public Data

Permissions

ABL Core with optional run-time permission checking :

dynamic buffer

static buffer

.rcode(RU)

useraccess?

connectionuser-id

userauthentication

All operationschecked at run-time

.rcode

(CRUD)

Agenda

Run-time database security landscape OpenEdge database security Comparing run-time and compile-time Configuring run-time database security

Configuring Database Security

ABL & SQL application security(Adds contextual application security to the database’s built-in security features)

OpenEdge database run-time security(Protects database from rogue application-code and users)

OS file system permissions(Protects database’s utilities, configuration, and data files from other OS processes)

The best database security comes from multiple layers :

OpenEdge Database Security Options

1. Database administration2. Database user connection

3. Table & column/field access

4. Database auditing

Many security options available to fit your application :

Security Starts with User Accounts

A place to start“Database contain private or confidential data?”

YES: I should configure database user accounts 1 or more _user administrator accounts 1 or more _user accounts for data access Eliminate built-in default-user accounts

“_user accounts required for individual users?” If SQL server is used:

YES If SQL is not used:

can use application’s user accounts via the CLIENT-PRINCIPAL object

When are database user accounts required ?

Database Administration Security Steps

1. Connect SQL explorer as any user-id and find the database’s “db-owner”

SELECT * from SYSPROGRESS.SYSDBAUTH;

2. It is the user-id that is not “SYSPROGRESS”

3. Reconnect SQL explorer with the “db-owner” user-id

4. Create a common ABL/SQL DBA account

CREATE USER ‘MYDBA’, ‘dba-pwd’;

GRANT RESOURCE, DBA to MYDBA;

If SQL Server installed, configure it’s DBA security first :

1. Connect SQL Explorer as MYDBA

2. Create user accounts with known passwords

CREATE USER ‘SYSPROGRESS’, ‘pwd’;

CREATE USER ‘<db-owner>’, ‘pwd’;

CREATE USER ‘PUB’, ‘pwd’;

Lockout built-in SQL DBAs & table owners :

Use Data Administration tool to deny PUBLIC Security Administrator access

1. Define common ABL [ & SQL] administration user account [“MYDBA”] Admin->Security->Edit User list…

2. Set the security administrator list to“MYDBA” * Admin->Security->Security Administrators…

Define ABL Security Administrator :

* Best practices indicate two user accounts defined

Database Schema Administration

ABL client cannot change SQL user privileges

SQL client cannot change ABL user permissions

Define your own ABL-DBA by granting• Grant PUBLIC (“*”) to _File._Can-read • Grant _Can-create, _Can-write, _Can-delete

to ABL Security Administrator account list forschema security

“_File._File” “_File._sec-role”“_File._Field” “_File._sec-granted-role”“_File._Index” “_File._sec-authentication-domain“_File._Index-field” “_File._sec-authentication-system

Enable Advanced ABL Security Features

1. Update to release 10.1A+

2. If not creating a new 10.1B+ database, update security schema definitions

$ proutil db –C updateschema

OR enable OpenEdge auditing

$ prostrct add db audit-areas.st$ proutil db –C enableauditing area data-area-name indexarea index-area-name [disableindexes]

ABL Connection Security

Optionally block blank-user id connections Database Administration utility’s menu Admin->Database Options …

Disallow Blank UserID*(*Requires 1 _user account & -U/-P connection)

Pick your ABL access-control design• All database connections use the user’s login id

• Application connects to the database using– A single database user-id

(1 user w. all permissions for all data tables)– A role or group account

(each application user-id has exactly 1 role )

Binding R-code to the OpenEdge Database

Low level security option, but viable for some use-cases

Simple secret-key hash value• Embedded in database • Compiled into r-code• Checked by ABL core at run-time

Not recommended where:• ABL is customized at production site• Database’s used in multiple applications• Update application with subset of .r-code modules

DBAUTHKEY in case run-time security not achievable :

Two ABL Permissions Security Strategies

Use the application development defaults• On [schema] tables where data is PUBLIC • Deny user access to tables with restricted data *• Deny default blank user-id access to all tables & fields

Admin->Security->Disallow Blank Userid Access …

Use the industry recommended GRANT model• If your application uses SQL server security• Tables that contain restricted-access tables or fields• Default table/field access is System Administrators• Add (grant) & remove (revoke) selective user accounts

* Not an recommended security practice

Choose which suits your application the best :

Turn on run-time checking via the data administration tool’s dialog Admin->Database Options …

Use Runtime Permissions Checking

Update application’s code error checking (if required)

Tip: use ABL CAN-DO() to test permission list

find _File where _File._File-Name = “Customer”.if CAN-DO(_File._Can-Delete, user_id) then DELETE Customer.

ABL Run-time Database Security

Enabling ABL run-time permission checking :

Controlling Run-time Permission Checking

If permission denied, raises STOP event Enclose statement in a block with ON STOP

DO ON STOP UNDO , LEAVE : FIND customer WHERE CustNum = m_iCustNum NO-ERROR.END.IF ( ERROR-STATUS:ERROR AND INDEX(ERROR-STATUS:GET-MESSAGE(1), “permission denied”) <> 0) THEN RETURN ERROR “Customer table read access denied”.…

ABL Permission Secrets

A Security Administrator is NOT treated special• Table access• Field access• Granting/revoking other Security Administrators

Each _Can-* permission field must have one of• One Security Administrator account • PUBLIC (“*”)

Never, never, never leave a _Can-* permission list blank

Three Security Administrator rules you never forget :

ABL Permission Secrets

Order dependent, comma separated list of account names (no white-space!)

Add account name to grant access, remove account names to revoke access

Use “!” to explicitly deny access to an account

Use “*” for wild-card multiple user account match– PUBLIC access (all accounts)– Can use “xxx_*” or “*_xxxx” for account names

with the same prefix or suffix

ABL _Can-* permission list rules :

ABL Permission List Examples

Deny blank user grant access to no accounts

“!”

Deny blank user & fred, grant access to all other accounts

“!,!fred,*”

Grant access to blank user-id and all accounts

“*”

Pure GRANT model (denies blank user-id)

“fred,wilma,MYDBA”

Grant any accountstarting with “dba_”

“barney,dba_*,MYDBA”

List denieduser accounts

SQL equivalent GRANT model

Illegal, nobody has access!!!

Interesting use of account

name groups* More examples in Bonus slides

SQL equivalent PUBLIC access

ABL Permission Combinations

FIND, GET, FOR-EACH type statements• _File._Can-Read

EQ, GT, LT, … field access• _File._Can-Read, _Field._Can-Read

CREATE record statement• _File._Can-Read, _File._Can-Create,

_File._Can-Write, _Field._Can-Write (required fields)

ASSIGN record field values• _File._Can-Read, _File._Can-Write, _Field._Can-Write

DELETE record statement• _File._Can-Read, _File._Can-Delete

ABL permissions enforced at lower-level :

Keeping SQL and ABL in Sync

_Can-read _Can-write

(view)UPDATE

Column/field

_Can-create _Can-read

_Can-write _Can-delete

INSERTSELECTUPDATEDELETE

ABLSQL

Similar user access controls to PUB tables & columns :

Privilege & Permission WARNING!

Grant/revoke operations do not check account name presence

Account’s SQL privileges & ABL permissions are NOT removed when account is deleted(including DBA & Security Administrator)

• If new account created with same name, it inherits all the old account’s privileges & permissions(also can be used as a recovery tool)

Beware of orphan privileges and permissions:

In Summary

More pressures to include database run-time security as intrusions become more sophisticated

OpenEdge 10.1+ has added additional security features

OpenEdge 10.1+ RDBMS can meet your database’s run-time security needs

For More Information, go to…

PSDN• OpenEdge SQL Authorization

Documentation:• OpenEdge Database Management: Database

Administration• OpenEdge Database Management: SQL Reference• OpenEdge Development Collection: Progress 4GL

Referenced

Relevant Exchange Sessions

DEV-4: OpenEdge in an LDAP World COMP-7: Securing your Swiss Cheese

Environment DEV-8: A statefull application in a stateless

world DB-8: Jump-starting Your OpenEdge

Auditing Solution DB-19: OpenEdge Authentication without

the _User table

Questions?

Thank you foryour time

Bonus ABL Permission List Examples

Table “lock-out”, dump & load to recover

“”

Deny fred, grant access to all other accounts

“!fred,fred,*”

Grant access to fred and all accounts

“fred,!fred,*”

Pure GRANT model (denies blank user-id)

“fred,wilma,MYDBA”

Grant model, deny PUBLIC access

“fred,wilma,MYDBA,!*”

Grant model, grant blank user-id as middle account

“fred,,wilma,MYDBA”

Grant model, grant blank user-id as first account

“,fred,wilma,MYDBA”

db-14: openedge ® database run-time security revealed michael jacobs architect, progress openedge

progress software corporation

progress openedge

security holes

security incidents68

openedge database auditinghow

abl sql security systems

abl database record

password abl

Documents

openedge 10 platform & product availability...

dev-4: openedge ® in an ldap world michael jacobs...

openedge 10 platform & product availability...

manual openedge 4 gl

openedge ® architect

what’s new in openedge 11.4? -...

dev-29: a deep dive into the advanced gui openedge ® 10.2a...

progress developer studio for openedge to use progress...

openedge getting started: progress openedge studio · pdf...

openedge database best practices

progress openedge bpm: an application revolution...

ops-6: beginners guide to openedge ® sql via odbc or jdbc...

1 what’s new in openedge 10.2b openedge management...

progress openedge 10

openedge 11 platform & product availability...

openedge mobile an introduction shelley chase progress...

patterson eaglesoft and openedge...patterson eaglesoft and...

openedge™ john sadd progress fellow and openedge...

koufalis openedge management v2

dev-09: user authentication in an openedge™ 10.1...