David Bergmeier – Mark Gurry & Associates

1. Database Security, A DBA’s Experience David Bergmeier – Mark Gurry & Associates

2. How would you react? Email from your IT department • Time for the annual password change • Please reply with your new password • Must be exactly 8 characters • Must not contain special characters (e.g. $ @) Please let us know if you have any questions or concerns, Regards, Network Security & Operations

3. A Security Nightmare • Weak passwords – so users will remember them • No ability for users to change their password • Cost cutting: • Reduced coding • No resetting passwords by the helpdesk • Users not “inconvenienced” by password expiring

4. Attitude towards the Users

5. Until AUDITORS “Thou shalt allow users to change their passwords”

6. Whoops! The management response: • We’re moving to 3-tier architecture soon • This will be a waste of time and money • We’ll put our efforts into the rewrite In the meantime… “Let’s change everyone’s password TO KEEP THE AUDITORS HAPPY!”

7. Agenda • What do we mean by security? • Design – where do we start? • Operating System Controls • Passwords • Auditing • The Change Process • Useful Resources

8. Definition • What is security? • What about security is so important? • What are we trying to achieve? • Why do we care about security? The goals of security: • Lowering the probability of something bad happening • Reducing the impact of bad things when they do happen

9. Examples of bad things…

10. Loss of backup

11. SAN drive swapped out

12. Pod slurping

13. Examples of bad things…

14. Definition Security is all about managing risk. One of our biggest risks, is people.

15. Case Study Steve Stasiukonis (security expert) • Medical facility security check • Key card system – entry with grocery card • Dressed up as doctors • Conference room with network access • Steve went looking for more vulnerabilities

16. Password on a post-it note

17. People and Passwords Passwords can be attacked by: • Spyware • Cracking tools • Brute force guessing • Social engineering • Phishing • Shoulder surfing • Acoustic cryptanalysis • Keystroke loggers

18. People and Passwords These risks can be mitigated by: • Anti spyware • Enforcing complex passwords • Enforcing long passwords • Regular password changes • Limited grace logins • User education • Good processes and policies • Password masking ******* • Good physical security of assets

19. Security is mostly about people How do we stop people writing down their passwords?

21. Design for Security Stages of the System Life Cycle Database and Specifications Application

22. Design for Security • Security MUST be considered from the outset • Security is not an optional extra • Security problems are easier to fix in the design phase • All stages of the development life cycle must consider security • Adding security later on may break business processes

23. Where most problems occur

24. How Difficult to Repair

25. How Expensive to repair $ Plan Analyze Design Develop Accept

26. Performance Design Problem SELECT col_security_check( project_no ), col_security_check( project_name ), ... FROM projects WHERE row_security_check( USER ) = ‘Authorized’

27. Common Design Problems • Security design does not consider performance • Inadequate data model • Building security into the client, not the database • Lack of standards or an inconsistent way of doing security

28. Schema Design • Start with a fully normalised data model • Denormalise for performance AND security • Natural versus Synthetic keys • Last updated by columns • Username • Timestamp • Module or Program

29. Operating System • Who has access • What to lockdown • Things to watch out for

30. Things auditors should know 1. Root access equals full database access 2. Oracle access equals full database access Note: This will change with Oracle Data Vault

31. Recommendations Get the basics right • Disable telnet and ftp • Use SSH • Includes scp and sftp • Consider controlled use of rcp for performancercp 8.5 times faster than scp • Lock the oracle account and prevent logins mask password in /etc/shadow • Become oracle via SSH or SUDO

32. Operating System Controls • Apply the Oracle security patcheshttp://www.oracle.com/technology/deploy/security/alerts.htm • Work through an Oracle security checklist (See links later in this presentation) • Consider externally authenticated users for cron jobs but make sure OS_REMOTE_AUTHENT is set to FALSE

33. Operating System Controls Known hacks Scrutinise all file permissions e.g. Sqlplus • login.sql • glogin.sql Backups • export dump files • rman backup pieces Data theft impossible to detect

34. Operating System Controls You also need to protect the DBA’s workstation Passwords stored in tools like • Toad • SQL Developer • OEM Desktop shortcuts Weak encryption?

35. Passwords • Background • The Oracle hashing algorithm • How safe are oracle passwords? • Good and bad examples

36. Passwords Kerckhoffs’ Principle: The security of a cryptographic systemmust not depend on keeping the cryptographic algorithm secret Users of a cryptographic system should assume the encryption algorithm is public knowledge The Oracle password hashing algorithm is known

37. Oracle password hashing The current hashing algorithm was released in Oracle 6 (1988) Design Goals: • Must work on all terminalsSome terminals did not have lower caseSo must be case insensitive • Must support non ASCII characters16 bits per character – high byte zeroed • Different users with the same password must have different hashes • Long passwords are supportedMaximum is 30 characters

38. Oracle password Hash • Username and plaintext password are concatenated • Converted to upper case • Hashed with a modified DES encryption algorithm (a one way function)

39. Oracle logins • Login requires username and password • They are concatenated, upper cased and hashed • The resulting hash is compared to the stored hash It is theoretically impossible to recover the plaintext from the hashes

40. Computationally Infeasible What does computationally infeasible mean? • We know the hashing algorithm • We cannot reverse the process and generate plaintext from the hashes However: • We can attempt brute force cracking by sequentially hashing all possible plaintext values until we get a match

41. Computationally Infeasible 1988 = Intel 80386SX • 25 MHz CPU • 4 MB RAM • MS-DOS 3.3 • 40 MB Hard drive • $3000 approx Estimate of time to crack 6 char alphanumeric passwords • = 36 ^ 6 passwords to check • = 2,176,782,336 passwords to check • Weeks?

42. Computationally Infeasible 2006 = Intel Pentium 4 • 2 GHz CPU • 1 GB RAM • MS-Windows XP • 30 GB Hard drive • $3000 approx Estimate of time to crack 6 char alphanumeric passwords • Less than 1 hour 7 alphanumeric = 1.5 days 8 alphanumeric = 53 days 9 alphanumeric = over 5 years

43. Recommendation If using Oracle authentication • Require longer passwords • Require complex passwords • Require regular password changes Balance this with human tendency to write down passwords Change ALL default passwords

44. Observation Standalone passwords obsolete in 10 years Instead will have multiple types of authentication For example: • Something only you knowe.g. a password or a PIN • Something only you havee.g. a smartcard or a token • Something only you aree.g. biometrics

45. Case Study Client/Server system in VB and Oracle 8.0 1. Password stored in plaintext in INI file on client • Single application user • Any user can login to production • Auditing impossible • Not very secure

46. Case Study 2. Password stored encrypted in INI file on client • Still single application user • Developers can login to production • Non application auditing impossible

47. Case Study 3. Passwords not stored • All users have their own account • Developers don’t have production access • Easy to make changes outside the application • Database upgraded to 8i

48. Case Study 4. The complex Solution • All users granted a password protected role • The app calls a wrapped stored proc to identify itself • The stored proc returns password to unlock the role • SQLNET.ORA tracing reveals the password

49. Secure Application Role Superseded in Oracle 9i by CREATE ROLE <role> IDENTIFIED USING <procedure_name> • Flexible – any procedure/function/package • No password to be discovered • Procedure cannot be bypassed • Requires EXECUTE privilege on procedure

50. Change and Auditing • Why audit? • How much auditing? • Auditing methods • The change process • Testing