1. Securing Your Swiss Cheese Environment
PAUL KOUFALIS
PRESIDENT
PROGRESSWIZ CONSULTING

2. Progresswiz Consulting
Based in Montréal, Québec, Canada
Providing technical consulting in Progress®, UNIX, Windows, MFG/PRO and more
Specialized in performance tuning, system availability and business continuity planning
…and security of Progress-based systems
Securing Your Swiss Cheese Environment

3. Who Are You? Executive, Manager or techie?
End-user? End-user that develops? VAR?
Your application
ChUI ?
GUI client/server?
N-tier?
Securing Your Swiss Cheese Environment

4. Agenda Security Overview Layer by layer from the outside-in Q&A
Network, server, O.S., AVM, DB…
Q&A
Securing Your Swiss Cheese Environment

5. Theme of the day: ROI Focus on cost-benefit What are you protecting?
What will it cost you to protect it?
What will it cost you if it gets stolen?
Not just € - consider reputation, trust…
Quick and easy solutions cost almost nothing and provide biggest bang for your buck (or €)
Securing Your Swiss Cheese Environment

6. Security Overview
Think of security as a castle with walls, moats and gates
Securing Your Swiss Cheese Environment

7. Security Overview Each wall is a layer of security
BUT…the wall has to have gates
each gate is a potential risk
Securing Your Swiss Cheese Environment

8. Security Overview – Walls
Data (TDE)
AVM
File system
Server
Network
Reminder: Non-exhaustive list of walls
Securing Your Swiss Cheese Environment

9. Security Overview – Gates
AVM
Files
Servers
ABL/SQL
Executables
Server login
Network access
Reminder: Non-exhaustive list of gates
Securing Your Swiss Cheese Environment

10. Out of scope Internet -> LAN Hack shell on server
These are important but there’s only so much we can talk about in one hour!
Securing Your Swiss Cheese Environment

11. Network Gates Common services OpenEdge services ftp, scp, Samba…
ABL/SQL servers
AppServers
WebSpeed, etc…
Securing Your Swiss Cheese Environment

12. Locking the Gate – Easy Fixes
Turn it all off!
ftp, etc: force users to stay in their $HOME
SQL access: -ServerType 4GL
ABL C/S access: no “-S” startup parameter
Don’t start Appserver etc…
But but but I need SQL/ABL/scp/Apsv…
Of course not always feasible!
Securing Your Swiss Cheese Environment

13. Locking the Gate – ABL Server Access
No full dev licenses on user PC’s
Easy for PC support to take green sheet and install Provision, C/N, Q/R, etc… on user PC
In fact – no ad hoc access
You need Query/Report?
Strip out the editor, data admin, etc from Progress installation
Put Provision on a strictly controlled Terminal Server or VM.
Securing Your Swiss Cheese Environment

14. Non-trivial Fixes OE client on Windows Terminal Server
Run application at login
Logout at exit
Could be lots of €€
Securing Your Swiss Cheese Environment

15. Locking the Gate – SQL Server Access
Real usernames and passwords with real grants
More on usernames/passwords later
No generic “odbcuser”
Do you really want everyone to have read access to all data?
Securing Your Swiss Cheese Environment

16. Locking the Gate – AdminServer
Non-root absolutely critical with OpenEdge Management
Can run jobs
Use –admingroup parameter if still using Progress Explorer Tool
Securing Your Swiss Cheese Environment

17. Locking the Gate – AppServer
Separate server
Not accessible except by Apsv ports
Use SESSION:EXPORT()
List of programs that can be executed by Apsv
Can use wildcards
Use “apsv” service-type userid
Not root
"s_sales_*,s_admin_*" use a naming convention for your different service interface modules. It'll shorten the list, make it more maintainable, and make it faster.
Securing Your Swiss Cheese Environment

18. Locking the Gate – AppServer + Database
Consider putting DB and Apsv on same box
Disable C/S access to DB
Only local Apsv can make shared memory connections
DB protected from remote attack
Must first break through operating system
Securing Your Swiss Cheese Environment

19. Webspeed Default: Thanks to Nectarios Daloglou of Dalo Consulting
Securing Your Swiss Cheese Environment

20. Locking the Gate – Webspeed
Easy to secure:
Securing Your Swiss Cheese Environment

21. Secure Communications with
Non-Trivial Fixes
Enable SSL for all network connections
Shameless Plug - Come to my session tomorrow:
Secure Communications with
OpenEdge and SSL
Securing Your Swiss Cheese Environment

22. Non-Trivial Fixes VLAN segregation €€€
Users with ad hoc privileges have no access to PROD
Strictly control open ports between user vLANs and server vLAN
€€€
Checkpoint Firewall is expensive!
Cost of maintenance is high
Securing Your Swiss Cheese Environment

23. Operating System Gates
Users logging in to same server as DB
The closer the user, the greater the danger
Securing Your Swiss Cheese Environment

24. Locking the Gate – Operating System
Lock down the shell
Use restricted shell
Use “exec” in the .profile
Cannot CTRL-C out to shell
Put users on a different server even in ChUI
Client/server connection
Security versus performance trade-off
Can use batch submits to run big jobs in shared mem on server
Securing Your Swiss Cheese Environment

25. DB Files Data security useless without physical security
With write access to the physical files:
Copy DB
Dump the blocks containing _CAN*
Physically change the data values:
“!,*” becomes “*,*”
Load the blocks back in to the DB
Securing Your Swiss Cheese Environment

26. Locking the Gate – DB Files
Owned by “prodba” in group “dba”
Permissions = 660 (rw-rw----)
Also directory permissions
Reminder: deleting a file is a directory action, not a file action
Directory permissions apply
Dir security allows delete even if file security does not allow mod
Securing Your Swiss Cheese Environment

27. Locking the Gate – DB Files
Raison-d’être of the setuid bit on the Progress executables
Down side: No on-the-fly shared memory connections
AGAIN: dir write = delete file priv even if no file write priv.
Securing Your Swiss Cheese Environment

28. O.S. to AVM Gates
Control access to OpenEdge executables and configuration files
Only authorized users should be able to
D&L
Backup
Query (ad hoc)
Securing Your Swiss Cheese Environment

29. AVM Access Don’t leave break-in tools lying around!!
Securing Your Swiss Cheese Environment

30. AVM Access
Primary example: Full Dev key in production $DLC/progress.cfg
Everyone is running with a full dev license!
Your progress.cfg should be runtime only
Maybe Query/Results if absolutely necessary
Create a separate full.cfg for compile
Ask me later how to separate CFG components in progress.cfg
Securing Your Swiss Cheese Environment

31. Locking the Gates – AVM Access
Secure what runtime users don’t need
Many of the $DLC procedure libraries
Example: adecomm.pl, prodict.pl
Contain _edit.p, _admin.p, etc…
Executables: $DLC/bin/_proutil, etc…
$DLC/properties/*
Only give the DBA group access via sudo
Securing Your Swiss Cheese Environment

32. Locking the Gates – PROPATH
Every file and directory in the PROPATH should only be readable by the masses
Only deployment people should have write access
Create a deploy group to manage code changes
-rw-rw-r–– koup deploy start.r
-rwxrwxr–x deploy deploy .
Automate if you can
Securing Your Swiss Cheese Environment

33. AVM to Data Gates ABL is “PUBLIC” by default
Securing Your Swiss Cheese Environment

34. Locking the Gates – DB Security
Security options
Usernames/passwords
Data Security
Security Administrators
Disable Blank Userid
DB options
Disallow Blank UserID
Use Runtime Permission Checking
Securing Your Swiss Cheese Environment

35. Usernames and Passwords
First level of defense: username/password
OpenEdge uses the _USER table
The default implementation is weak
No complex passwords, aging, etc…
Securing Your Swiss Cheese Environment

36. Locking the Gates – _USER
SQL DBA = sysprogress and OpSys user that created DB
Make sure to create both users in _USER
Can also de-authorize DBA privileges with REVOKE
Securing Your Swiss Cheese Environment

37. Data Security
ABL access managed by _CAN-* fields in _FILE and _FIELD records
Ex.: _CAN-READ = “!,Paul,Bob”
By default all _CAN-* fields = “*”
SQL access controlled via GRANT
Very difficult to manage data to application to user security
FILE: _can-read, _can-write, _can-create, _can-delete
FIE:D: _can-read, _can-write
it requires a lot of application work to coordinate run-time table/field database security with an application's own concept of user and fine-grained security.
Most app developers just use ON/OFF security. If you are authenticated you get access to the full DB except maybe a few very sensitive tables that are managed individually.
Securing Your Swiss Cheese Environment

38. Security Administrator
Only SecAdmins can modify _CAN* fields
Only SecAdmins can add/delete _USER records
Normal users can modify their own _USER data
Password field rules are hard coded into core, so the _password's _Can-write permission lies.
Securing Your Swiss Cheese Environment

39. Security – Disable Blank UserID
Changes default _CAN-* values from “*” to “!,*”
I.e. blank user cannot read/write any data
BUT new tables/fields will get all “*”
Do not confuse with DB Options – Disable Blank UserID
Securing Your Swiss Cheese Environment

40. DB Options Disable Blank UserID Runtime security
Very simple: need –U –P at connection
Could be difficult to implement
Runtime security
_CAN-* access validated at runtime
As of 10.1A
On the fly connect with secure DB files implies C/S connection only
Can have everyone connect with a no-access generic account via –U –P and switch
Securing Your Swiss Cheese Environment

41. Locking the Gates – DB Security
Manage complex passwords and aging in your application
Or better yet replace it with a real authentication mgmt system (ex.: LDAP)
Access external auth with CLIENT-PRINCIPLE object
Explained in detail in next few slides…
Enable runtime security
Use security administrators and _CAN* fields
Securing Your Swiss Cheese Environment

42. Authentication Domains
Data Administration - Security options - Authentication Domains
Access via CLIENT-PRINCIPLE object
Transition from _USER to C-P a must
I strongly expect Authentication Domains and CLIENT-PRINCIPLE use to be significantly enhanced and expanded in OE 11
Securing Your Swiss Cheese Environment

43. Authentication Domains
A trusted “external” authentication system
Example: LDAP/Active Directory
But could still be an external _USER
Use instead of SETUSERID() for ABL connections
SQL still requires _USER in OE10
Who is using CLIENT-PRINCIPLE now?
Securing Your Swiss Cheese Environment

44. OpenEdge 10 Implementation
Three hierarchical levels:
Authentication System
Authentication Domain
CLIENT-PRINCIPLE() authentication token
Securing Your Swiss Cheese Environment

45. Authentication Systems
User defined “types” of external authentication
Can be anything
Probably more specific uses in OE 11
Securing Your Swiss Cheese Environment

46. Authentication Domains
Defines how you can authenticate a user
Must be of defined “Authentication System” type
Secret access code is the key
Securing Your Swiss Cheese Environment

47. Authentication System and Domain
In OE 10 these are strictly user defined and have no intrinsic meaning
Do not use “windows”, “windowsid”, “unix”, “unixid”, “OpenEdge” and “oeusertable”
OpenEdge may want to use them in a broader scope in the future
Securing Your Swiss Cheese Environment

48. Authentication Process
Prepare your authentication domain(s)
Application Domain
Create Authentication Domains on the fly
SECURITY-POLICY:REGISTER-DOMAIN()
Not ideal – security risk
Load Authentication from one database
SECURITY-POLICY:LOAD-DOMAINS()
Better
Securing Your Swiss Cheese Environment

49. Authentication Token CLIENT-PRINCIPLE() object Usage procedure:
Create object
Assign required and optional attributes
Authenticate (ex.: validate password with AD)
Seal C-P with domain access code
Securing Your Swiss Cheese Environment

50. Authentication Token
CREATE CLIENT-PRINCIPAL hpk. ASSIGN hpk:USER-ID = "pk" hpk:DOMAIN-NAME = "PK_1" hpk:DOMAIN-TYPE = "PKTEST" hpk:DOMAIN-DESCRIPTION = "PK Auth" hpk:SESSION-ID = SUBSTRING ( BASE64-ENCODE(GENERATE-UUID), 1, 22) hpk:ROLES = "user,finance". /* Password verification code here */
If you make C-P available to entire application then you can use the ROLES function for application authorization. That’s what it’s there for.
You can sync ROLES with something like Active Directory so your application authorization is managed centrally in AD
Securing Your Swiss Cheese Environment

51. Authentication Token
/* Seal token with the encrypted access code */ IF NOT hpk:SEAL(“34gd798080a") THEN DO: MESSAGE "SEAL FAILED WITH detail" hpk:STATE-DETAIL VIEW-AS ALERT-BOX. END.
What’s wrong with this picture?
Access code is in ABL code – make sure this is ultra-secure!
Securing Your Swiss Cheese Environment

52. Token Validation Validate the token SECURITY-POLICY:SET-CLIENT()
Validate sealed C-P against current application context
SET-DB-CLIENT()
Validate sealed C-P against one or more specific databases
Securing Your Swiss Cheese Environment

53. Token Validation
/* Load security domains from DB 1 */ SECURITY-POLICY:LOAD-DOMAINS(1) NO-ERROR. IF NOT SECURITY-POLICY:SET-CLIENT(hpk) THEN DO: MESSAGE "SET-CLIENT failed" VIEW-AS ALERT-BOX. hpk:LOGOUT. DELETE OBJECT hpk. END.
Securing Your Swiss Cheese Environment

54. Token Validation
Any DB already connected at SECURITY-POLICY:SET-CLIENT() automatically gets a SET-DB-CLIENT()
If you connect another DB you must SET-DB-CLIENT(hpk,dbalias) in your connection code
Securing Your Swiss Cheese Environment

55. Authentication System Architecture
Think “weakest link”
Potentially C-P:SEAL(“access code”)
Solution:
Do not let the client code SEAL the token
Farm out to AppServer on strongly secured server
Securing Your Swiss Cheese Environment

56. Ideal Authentication System Architecture
User signs in (username/pwd)
Authentication AppServer validates password and seals C-P
Auth ApSv returns sealed C-P token to user
User sends sealed C-P token to Appl Apsv to run DB queries on his behalf
Appl Apsv validates sealed C-P token against DB and runs queries
Appl Apsv returns data to user
Securing Your Swiss Cheese Environment

57. Locking the Gates – External Authentication
Obviously not trivial but not overly difficult either
Start with a simple solution
Local SEAL()
Still using _USER
Implement plug-and-play authentication architecture
Some customers will want LDAP
Ready for new future auth systems
Securing Your Swiss Cheese Environment

58. Final Remarks – External Authentication
More stuff to look into:
Trusted Application Authentication Domains
Using LDAP for role-based authorization
This is to authorize access to functions in your application
A number of white papers on Communities
LDAP example from Michael Jacobs
Securing Your Swiss Cheese Environment

59. Aerial Attacks! Wow – everything is soooo secure from the ground
Firewalls in place
No p-code anywhere
No full.cfg
Super LDAP C-P security
Aren’t you proud of yourself?
Wait a minute…
Securing Your Swiss Cheese Environment

60. Locking the Gates – Aerial Attacks
Stop refreshing your TEST environment with PROD data!
Scramble the data first
Control and limit generic usernames
User “qad” password “qad”
SQL “odbcuser”
No developers in PROD DB
I know you’re guilty of this one
Don’t know how many millions of times I’ve seen this!
Dev system security is typically non-existent
Securing Your Swiss Cheese Environment

61. Locking the Gates – Segregate Roles
How segregated are your roles?
DBA
Developer QA
No one person should be able to write, compile and promote code
Need to invest some time to develop S.O.P.’s
Securing Your Swiss Cheese Environment

62. Remember our Castle Walls
Securing Your Swiss Cheese Environment

63. Credits An extra special thanks to Michael Jacobs
Securing Your Swiss Cheese Environment

64. Questions?
Securing Your Swiss Cheese Environment

65. More Questions or Comments?
me at
Presentations, tools and more available at