securing your swiss cheese environment paul koufalis president progresswiz consulting
TRANSCRIPT
Securing Your Swiss Cheese Environment
PAUL KOUFALISPRESIDENT
PROGRESSWIZ CONSULTING
© 2010 Progresswiz Consulting2 Securing Your Swiss Cheese Environment
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
Progresswiz Consulting
© 2010 Progresswiz Consulting3 Securing Your Swiss Cheese Environment
Who Are You?
Executive, Manager or techie? End-user? End-user that develops? VAR? Your application
• ChUI ?
• GUI client/server?
• N-tier?
© 2010 Progresswiz Consulting4 Securing Your Swiss Cheese Environment
Agenda
Security Overview Layer by layer from the outside-in
• Network, server, O.S., AVM, DB…
Q&A
© 2010 Progresswiz Consulting5
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
© 2010 Progresswiz Consulting6 Securing Your Swiss Cheese Environment
Security Overview
Think of security as a castle with walls, moats and gates
© 2010 Progresswiz Consulting7 Securing Your Swiss Cheese Environment
Security Overview
Each wall is a layer of security
BUT…the wall has to have gates• each gate is a potential risk
© 2010 Progresswiz Consulting8 Securing Your Swiss Cheese Environment
Security Overview – Walls
Data (TDE) AVM File system Server Network
© 2010 Progresswiz Consulting9 Securing Your Swiss Cheese Environment
Security Overview – Gates
AVM Files Servers
• ABL/SQL
Executables Server login Network
access
© 2010 Progresswiz Consulting10 Securing Your Swiss Cheese Environment
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!
© 2010 Progresswiz Consulting11 Securing Your Swiss Cheese Environment
Network Gates
Common services• ftp, scp, Samba…
OpenEdge services• ABL/SQL servers
• AppServers
• WebSpeed, etc…
© 2010 Progresswiz Consulting12
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…
Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting13
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
Securing Your Swiss Cheese Environment
€ € €
© 2010 Progresswiz Consulting14
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
€ € €
© 2010 Progresswiz Consulting15 Securing Your Swiss Cheese Environment
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?
€ € €
© 2010 Progresswiz Consulting16 Securing Your Swiss Cheese Environment
Locking the Gate – AdminServer
Non-root absolutely critical with OpenEdge Management• Can run jobs
Use –admingroup parameter if still using Progress Explorer Tool
€ € €
© 2010 Progresswiz Consulting17 Securing Your Swiss Cheese Environment
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
€ € €
© 2010 Progresswiz Consulting18
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
€ € €
© 2010 Progresswiz Consulting19 Securing Your Swiss Cheese Environment
Webspeed
Default:
© 2010 Progresswiz Consulting20 Securing Your Swiss Cheese Environment
Locking the Gate – Webspeed
Easy to secure:
€ € €
© 2010 Progresswiz Consulting21
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
€ € €
© 2010 Progresswiz Consulting22
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
€ € €
© 2010 Progresswiz Consulting23
Operating System Gates
Users logging in to same server as DB
The closer the user, the greater the danger
Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting24
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
Securing Your Swiss Cheese Environment
€ € €
© 2010 Progresswiz Consulting25 Securing Your Swiss Cheese Environment
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
© 2010 Progresswiz Consulting26 Securing Your Swiss Cheese Environment
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
€ € €
© 2010 Progresswiz Consulting27 Securing Your Swiss Cheese Environment
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
© 2010 Progresswiz Consulting28
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
© 2010 Progresswiz Consulting29 Securing Your Swiss Cheese Environment
AVM Access
Don’t leave break-in tools lying around!!
© 2010 Progresswiz Consulting30 Securing Your Swiss Cheese Environment
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€ € €
© 2010 Progresswiz Consulting31 Securing Your Swiss Cheese Environment
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
€ € €
© 2010 Progresswiz Consulting32 Securing Your Swiss Cheese Environment
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
€ € €
© 2010 Progresswiz Consulting33
AVM to Data Gates
ABL is “PUBLIC” by default
Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting34
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
© 2010 Progresswiz Consulting35 Securing Your Swiss Cheese Environment
Usernames and Passwords
First level of defense: username/password• OpenEdge uses the _USER table
The default implementation is weak• No complex passwords, aging, etc…
© 2010 Progresswiz Consulting36
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
€ € €
© 2010 Progresswiz Consulting37 Securing Your Swiss Cheese Environment
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
© 2010 Progresswiz Consulting38 Securing Your Swiss Cheese Environment
Security Administrator
Only SecAdmins can modify _CAN* fields Only SecAdmins can add/delete _USER
records Normal users can modify their own _USER
data
© 2010 Progresswiz Consulting39 Securing Your Swiss Cheese Environment
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
© 2010 Progresswiz Consulting40 Securing Your Swiss Cheese Environment
DB Options
Disable Blank UserID• Very simple: need –U –P at connection
• Could be difficult to implement
Runtime security• _CAN-* access validated at runtime
• As of 10.1A
© 2010 Progresswiz Consulting41
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
€ € €
© 2010 Progresswiz Consulting42
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
© 2010 Progresswiz Consulting43
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
© 2010 Progresswiz Consulting44
OpenEdge 10 Implementation
Three hierarchical levels:
Authentication System• Authentication Domain
– CLIENT-PRINCIPLE() authentication token
Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting45
Authentication Systems
Securing Your Swiss Cheese Environment
User defined “types” of external authentication
Can be anything Probably more specific
uses in OE 11
© 2010 Progresswiz Consulting46
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
© 2010 Progresswiz Consulting47
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
© 2010 Progresswiz Consulting48
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
© 2010 Progresswiz Consulting49
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
© 2010 Progresswiz Consulting50
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 */
Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting51
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.
Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting52
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
© 2010 Progresswiz Consulting53
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
© 2010 Progresswiz Consulting54
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
© 2010 Progresswiz Consulting55
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
© 2010 Progresswiz Consulting56
Ideal Authentication System Architecture
Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting57
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
€ € €
© 2010 Progresswiz Consulting58
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
© 2010 Progresswiz Consulting59
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
© 2010 Progresswiz Consulting60 Securing Your Swiss Cheese Environment
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
€ € €
© 2010 Progresswiz Consulting61 Securing Your Swiss Cheese Environment
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
€ € €
© 2010 Progresswiz Consulting62 Securing Your Swiss Cheese Environment
Remember our Castle Walls
© 2010 Progresswiz Consulting63 Securing Your Swiss Cheese Environment
Credits
An extra special thanks to Michael Jacobs
© 2010 Progresswiz Consulting64 Securing Your Swiss Cheese Environment
Questions?
© 2010 Progresswiz Consulting65
More Questions or Comments?
Email me at [email protected]
Presentations, tools and more available at
www.progresswiz.com