Mark Gurry

1
Database Security, A DBAs Experience
David Bergmeier Mark Gurry Associates
2
Database SecurityA DBAs ExperienceDavid
Bergmeier
3
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. _at_)

Please let us know if you have any questions or
concerns, Regards, Network Security Operations
4
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

5
Attitude towards the Users
6
Until

• AUDITORS

Thou shalt allow users to change their
passwords
7
Whoops!

• The management response
• Were moving to 3-tier architecture soon
• This will be a waste of time and money
• Well put our efforts into the rewrite
• In the meantime
• Lets change everyones password TO KEEP THE
  AUDITORS HAPPY!

8
Agenda

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

9
Objectives

• An appreciation for common Oracle security issues
• An overview of the security design challenges
• Recommendations for locking down your O/S
• Knowledge of Oracles authentication and its
  shortcomings and password recommendations
• Application security
• When, Why and What to audit
• A look at security as it relates to the change
  process
• Useful security resources

10
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

11
Examples of bad things
12
Loss of backup
13
SAN drive swapped out
14
Pod slurping
15
Examples of bad things
16
Definition

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

17
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

18
Password on a post-it note
19
People and Passwords

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

20
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

21
Security is mostly about people

• How do we stop people writing down their
  passwords?

22
(No Transcript)
23
Design for Security
Stages of the System Life Cycle
Database and Specifications
Application
24
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

25
Where most problems occur
26
How Difficult to Repair
27
How Expensive to repair

Plan Analyze Design Develop
Accept
28
Performance Design Problem

• SELECT col_security_check( project_no ),
• col_security_check( project_name ),
• ...
• FROM projects
• WHERE row_security_check( USER )
• Authorized

29
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

30
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

31
Operating System

• Who has access
• What to lockdown
• Things to watch out for

32
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

33
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

34
Operating System Controls

• Apply the Oracle security patcheshttp//www.oracl
  e.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

35
Operating System Controls

• Scrutinise all file permissions
• e.g. Sqlplus
• login.sql
• glogin.sql
• Backups
• export dump files
• rman backup pieces

Known hacks
Data theft impossible to detect
36
Operating System Controls

• You also need to protect the DBAs workstation
• Passwords stored in tools like
• Toad
• SQL Developer
• OEM
• Desktop shortcuts

Weak encryption?
37
Passwords

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

38
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

39
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

40
Oracle password Hash

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

41
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

42
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

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

44
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

45
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

46
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

47
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

48
Case Study

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

49
Case Study

• 3. Passwords not stored
• All users have their own account
• Developers dont have production access
• Easy to make changes outside the application
• Database upgraded to 8i

50
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

51
Secure Application Role

• Superseded in Oracle 9i by
• CREATE ROLE ltrolegt
• IDENTIFIED USING ltprocedure_namegt
• Flexible any procedure/function/package
• No password to be discovered
• Procedure cannot be bypassed
• Requires EXECUTE privilege on procedure

52
Change and Auditing

• Why audit?
• How much auditing?
• Auditing methods
• The change process
• Testing

53
Why Audit?

• The goal of auditing detection of bad things
• So we can respond
• Improve prevention methods
• Reduce detection time to limit damage

54
Why Audit?

• Track data changes
• Verify security policies
• Reporting
• When did James last login?
• Who created that index?
• Who posted that journal to the GL?
• Legal compliance
• Note Compliant ? Secure

55
How much is enough?

• Just audit CREATE SESSION
• Audit ALL DBA activity
• What about
• alter user dba identified by dba123
• Under certain conditions the auditor knows my
  password
• Audit everything
• Time to buy shares in your storage vendor

56
How to audit

• Build versus Buy
• LogMiner
• Beware of caveats
• Oracle standard auditing
• Trigger based auditing
• Populating separate audit tables
• Fine grained auditing
• Introduced in Oracle 9i for SELECT
• Column level auditing

57
Other Considerations

• Audit Trail
• Operating file system or database?
• Oracle audits startup, shutdown and connect as
  sysdba
• How to protect audit trail?
• AUDIT insert,update,delete ON SYS.AUD by
  access
• Move SYS.AUD to another tablespace
• Retention period
• Purge/archive policy

58
Another type of audit

• Periodic checks for
• Users with
• SELECT ANY TABLE
• SELECT ANY DICTIONARY
• ALTER USER
• EXECUTE ANY PROCEDURE
• Default passwords
• Active accounts for ex-employees
• Users logged on for more than X hours

Can become DBA
59
The change process

• Conflicting change goals
• OPERATIONS Goal high system availability
• Change is BAD
• We need to keep the environment stable
• Changes cause outages
• DEVELOPMENT Goal enhancing the system
• Change is GOOD
• I just need to fix this bug
• Add this new functionality

60
Testing typically not done

• What about security testing?
• Focus on what the system should NOT do
• Does this change impact security?
• Can a user now see data they are not supposed to?
• Does this change allow a new vulnerability?
• Has auditing been implemented correctly and
  consistently?

61
Case study

• Two sites both implementing SOX
• What is SOX?
• US Federal law - response to Enron, Worldcom
  etc.
• Named after sponsors Sarbanes Oxley
• Applies to all US public companies
• Section 302 controls over financial reporting
• Section 404 internal control report required in
  company annual report
• No single point of reference for how to implement
• Will be unique to a company, based on business
  risk

62
Case study

• Site 1
• Large US company
• Several offices in Australia
• IT department about 50 people
• Required to implement by parent company
• Consolidation of change systems down to just one
• Limited segregation of duties
• Annual internal review of changes for each team
  by team leader

63
Case study

• Site 2
• Large Australian company
• IT department several hundred people
• Doing business in US, chose to implement SOX
• Emphasis on auditing changes (authorised and
  unauthorised)
• Substantial segregation of duties
• No annual review
• Less emphasis on annual external audit

64
Useful Resources

• Oracle links
• http//www.oracle.com/technology/deploy/security/a
  lerts.htm
• http//www.oracle.com/technology/deploy/security/d
  b_security/index.html
• http//tahiti.oracle.com/

65
Useful Resources

• Useful sites for Oracle specific
• http//www.petefinnigan.com
• http//www.red-database-security.com/
• http//www.dizwell.com
• http//www.integrigy.com
• http//asktom.oracle.com
• http//www.orablogs.com/orablogs/
• http//www.oaktable.net

66
Useful Resources
Checklist URL
Project Lockdown, Arup Nanda http//www.oracle.com/technology/pub/articles/project_lockdown/index.html
Hardening Oracle Administration and Developer Workstations Alexander Kornbrust http//www.red-database-security.com/wp/hardening_admin_pc_us.pdf
The 60 Minute Network Security Guide, SNAC http//www.nsa.gov/snac/support/sixty_minutes.pdf
Oracle Database Security Checklist An Oracle Whitepaper http//www.oracle.com/technology/deploy/security/pdf/twp_security_checklist_db_database.pdf
Oracle Database Checklist Pete Finnigan http//www.sans.org/score/checklists/Oracle_Database_Checklist.pdf
67
Useful Resources

• Security related sites
• http//www.sans.org
• http//www.schneier.com/
• https//buildsecurityin.us-cert.gov/daisy/bsi/home
  .html
• http//www.securityfocus.com/
• http//insecure.org/
• http//www.kevinmitnick.com/
• http//hackernews.com/
• http//www.nsa.gov/snac/

68
Useful Resources

• Effective Oracle Database 10g Security by
  DesignDavid C. KnoxOracle PressISBN
  0-07-223130-0

69
A Good Read

• In CodeSarah Flannery, 2001Profile BooksISBN
  1-86197-271-7
• The Code BookSimon Singh, 1999Fourth
  EstateISBN 1-85702-889-9
• The Art of DeceptionControlling the Human
  Element of SecurityKevin Mitnick, 2002 Wiley
  PublishingISBN 0-471-23712-4

70
Conclusion

• Security is about managing risk
• Security is primarily about people
• Design security into systems from the start
• Use common sense use available resources
• Start thinking about replacing Oracle
  authentication (e.g. LDAP)
• Consider auditing
• Think about security testing for changes
• Security is not just for SOX

71
The End
Thank you for your attendance today
dbergmeier_at_mga-it.com http//www.mga.com.au