We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byNicholas Burns
Modified over 2 years ago
Securing Your Swiss Cheese Environment PAUL KOUFALIS PRESIDENT PROGRESSWIZ CONSULTING
© 2010 Progresswiz Consulting 2 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 Consulting 3 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 Consulting 4 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 Consulting 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
© 2010 Progresswiz Consulting 6 Securing Your Swiss Cheese Environment Security Overview Think of security as a castle with walls, moats and gates
© 2010 Progresswiz Consulting 7 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 Consulting 8 Securing Your Swiss Cheese Environment Security Overview – Walls D ata (TDE) AVM File system Server Network
© 2010 Progresswiz Consulting 9 Securing Your Swiss Cheese Environment Security Overview – Gates AVM Files Servers ABL/SQL Executables Server login Network access
© 2010 Progresswiz Consulting 10 Securing Your Swiss Cheese Environment Out of scope Internet -> LAN Hack shell on server These are important but theres only so much we can talk about in one hour!
© 2010 Progresswiz Consulting 11 Securing Your Swiss Cheese Environment Network Gates Common services ftp, scp, Samba… OpenEdge services ABL/SQL servers AppServers WebSpeed, etc…
© 2010 Progresswiz Consulting 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 Dont start Appserver etc… But but but I NEED SQL/ABL/scp/Apsv… Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 13 Locking the Gate – ABL Server Access No full dev licenses on user PCs 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 Consulting 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
© 2010 Progresswiz Consulting 15 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 Consulting 16 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 Consulting 17 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 Consulting 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
© 2010 Progresswiz Consulting 19 Securing Your Swiss Cheese Environment Webspeed Default:
© 2010 Progresswiz Consulting 20 Securing Your Swiss Cheese Environment Locking the Gate – Webspeed Easy to secure:
© 2010 Progresswiz Consulting 21 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 Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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 Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 25 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 Consulting 26 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 Consulting 27 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 Consulting 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
© 2010 Progresswiz Consulting 29 Securing Your Swiss Cheese Environment AVM Access Dont leave break-in tools lying around!!
© 2010 Progresswiz Consulting 30 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 Consulting 31 Securing Your Swiss Cheese Environment Locking the Gates – AVM Access Secure what runtime users dont 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 Consulting 32 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 Consulting 33 AVM to Data Gates ABL is PUBLIC by default Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 35 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 Consulting 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
© 2010 Progresswiz Consulting 37 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 Consulting 38 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 Consulting 39 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 Consulting 40 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 Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 44 OpenEdge 10 Implementation Three hierarchical levels: Authentication System Authentication Domain –CLIENT-PRINCIPLE() authentication token Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 45 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 Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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 */ Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 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. Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 56 Ideal Authentication System Architecture Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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
© 2010 Progresswiz Consulting 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 Arent you proud of yourself? Wait a minute… Securing Your Swiss Cheese Environment
© 2010 Progresswiz Consulting 60 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 youre guilty of this one
© 2010 Progresswiz Consulting 61 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 Consulting 62 Securing Your Swiss Cheese Environment Remember our Castle Walls
© 2010 Progresswiz Consulting 63 Securing Your Swiss Cheese Environment Credits An extra special thanks to Michael Jacobs
© 2010 Progresswiz Consulting 64 Securing Your Swiss Cheese Environment Questions?
© 2010 Progresswiz Consulting 65 More Questions or Comments? me at Presentations, tools and more available at
Database Controls 2012 National State Auditors Association Information Technology Conference September 2012.
10 th Anniversary Many-to-One: Managing Multiple APEX Applications Scott Spendolini, Sumner Technologies.
The ESC-QuickBooks Integration For Use with ESC Version 12.
© 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Command View XP 2.0 HP Restricted.
1. Oracle Enterprise Manager Security Best Practices Huaqing Wang, Senior Product Manager, Oracle Ravi Pinnamaneni, Consulting Member of Technical Staff,
PrevNext | Slide 1 Michigan Electronic Grants System MEGS MEGS Overview and Updates for DLEG Adult Education.
State of Connecticut Core-CT Project Query 8 hrs Updated 4/14/2003.
1 GREY BOX TESTING Web Apps & Networking Session 3 Boris Grinberg
SWE 681 / ISA 681 Secure Software Design & Programming Lecture 1: Introduction Dr. David A. Wheeler
PrevNext | Slide 1 Michigan Electronic Grants System MEGS Career Initiatives Office of Career and Technical Preparation.
PrevNext | Slide 1 Welcome to MEGS The Michigan Electronic Grants System Comprehensive School Reform Application Last.
November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #25-1 Chapter 25: User Security Policy Access Files, devices Processes Electronic.
Performance Evaluation HR Training Sessions May , 2013.
1 The Attack and Defense of Computers Dr.. 2 BackDoors.
1 GREY BOX TESTING Web Apps & Networking Session 1 Boris Grinberg
PrevNext | Slide 1 Last Updated: 4/14/2003 SPECIAL EDUCATION MEGS Update for School Year The Michigan Electronic.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 2: Operating-System Structures.
SharePoint Governance Questions January 2014 ©2014 SUSAN HANLEY LLC.
2 Agenda l Database Overview l Oracle Audit/Security/Control.
PrevNext | Slide 1 Michigan Electronic Grants System MEGS MEGS Overview and Updates for Last Updated: 7/26/2007.
DASL/EMIS Salt Fork Presentation 2009 Brenda Hartley, Presenter Omeresa Student Services/EMIS.
PrevNext | Slide 1 MEGS Updates for School Year The Michigan Electronic Grants System Last Updated: 5/27/2004.
SpiderAlert Software Training June This list covers the basic steps to follow when designing a new project: Install Software Install new DLLs.
The Server Management Tool (SMT). All Rights Reserved © Alcatel-Lucent | SMT Module Objectives SMT Overview and architecture How to start the SMT.
©Silberschatz, Korth and Sudarshan8.1Database System Concepts, 5 th Ed, slide version 5.0, August Chapter 8: Application Design and Development.
1 Hardening Windows 2003 Web Servers. © Ezenta A/S Agenda Physical Security OS Installation Account Policies Local Policies Services User Accounts.
Slide 1 FastFacts Feature Presentation February 21 st, 2008 We are using audio during this session, so please dial in to our conference line… Phone number:
Introduction Purpose of Session: - Provide Overview Web Application Security Threats and Defense Using the Open Web Application Security Project (OWASP)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
© 2016 SlidePlayer.com Inc. All rights reserved.