Presentation is loading. Please wait.

Presentation is loading. Please wait.

Securing Your Swiss Cheese Environment PAUL KOUFALIS PRESIDENT PROGRESSWIZ CONSULTING.

Similar presentations


Presentation on theme: "Securing Your Swiss Cheese Environment PAUL KOUFALIS PRESIDENT PROGRESSWIZ CONSULTING."— Presentation transcript:

1 Securing Your Swiss Cheese Environment PAUL KOUFALIS PRESIDENT PROGRESSWIZ CONSULTING

2 © 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

3 © 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?

4 © 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

5 © 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

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

7 © 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

8 © 2010 Progresswiz Consulting 8 Securing Your Swiss Cheese Environment Security Overview – Walls D ata (TDE) AVM File system Server Network

9 © 2010 Progresswiz Consulting 9 Securing Your Swiss Cheese Environment Security Overview – Gates AVM Files Servers ABL/SQL Executables Server login Network access

10 © 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!

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

12 © 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

13 © 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

14 © 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

15 © 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?

16 © 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

17 © 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

18 © 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

19 © 2010 Progresswiz Consulting 19 Securing Your Swiss Cheese Environment Webspeed Default:

20 © 2010 Progresswiz Consulting 20 Securing Your Swiss Cheese Environment Locking the Gate – Webspeed Easy to secure:

21 © 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

22 © 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

23 © 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

24 © 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

25 © 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

26 © 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

27 © 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

28 © 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

29 © 2010 Progresswiz Consulting 29 Securing Your Swiss Cheese Environment AVM Access Dont leave break-in tools lying around!!

30 © 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

31 © 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

32 © 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

33 © 2010 Progresswiz Consulting 33 AVM to Data Gates ABL is PUBLIC by default Securing Your Swiss Cheese Environment

34 © 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

35 © 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…

36 © 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

37 © 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

38 © 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

39 © 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

40 © 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

41 © 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

42 © 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

43 © 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

44 © 2010 Progresswiz Consulting 44 OpenEdge 10 Implementation Three hierarchical levels: Authentication System Authentication Domain –CLIENT-PRINCIPLE() authentication token Securing Your Swiss Cheese Environment

45 © 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

46 © 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

47 © 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

48 © 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

49 © 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

50 © 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

51 © 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

52 © 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

53 © 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

54 © 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

55 © 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

56 © 2010 Progresswiz Consulting 56 Ideal Authentication System Architecture Securing Your Swiss Cheese Environment

57 © 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

58 © 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

59 © 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

60 © 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

61 © 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

62 © 2010 Progresswiz Consulting 62 Securing Your Swiss Cheese Environment Remember our Castle Walls

63 © 2010 Progresswiz Consulting 63 Securing Your Swiss Cheese Environment Credits An extra special thanks to Michael Jacobs

64 © 2010 Progresswiz Consulting 64 Securing Your Swiss Cheese Environment Questions?

65 © 2010 Progresswiz Consulting 65 More Questions or Comments? me at Presentations, tools and more available at


Download ppt "Securing Your Swiss Cheese Environment PAUL KOUFALIS PRESIDENT PROGRESSWIZ CONSULTING."

Similar presentations


Ads by Google