Transcript David Bergmeier - Mark Gurry & Associates

Database Security, A DBA’s Experience
David Bergmeier – Mark Gurry & Associates
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
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
Attitude towards the Users
Until
AUDITORS
“Thou shalt allow users to change their passwords”
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!”
Agenda







What do we mean by security?
Design – where do we start?
Operating System Controls
Passwords
Auditing
The Change Process
Useful Resources
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:
1. Lowering the probability of something
bad happening
2. Reducing the impact of bad things when
they do happen
Examples of bad things…
Loss of backup
SAN drive swapped out
Pod slurping
Examples of bad things…
Definition
Security is all about managing risk.
One of our biggest risks, is people.
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
Password on a post-it note
People and Passwords
Passwords can be attacked by:
•
Spyware
•
Cracking tools
•
Brute force guessing
•
Social engineering
•
Phishing
•
Shoulder surfing
•
Acoustic cryptanalysis
•
Keystroke loggers
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
Security is mostly about people
How do we stop people
writing down their passwords?
Design for Security
Stages of the System Life Cycle
Database
and
Specifications
Application
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
Where most problems occur
Design
20.0%
Program Code
60.0%
Database
17.5%
System
2.5%
How Difficult to Repair
Design
65%
Program Code
15%
System
5%
Database
15%
How Expensive to repair
$
Plan
Analyze
Design
Develop
Accept
Performance Design Problem
SELECT col_security_check( project_no ),
col_security_check( project_name ),
...
FROM projects
WHERE row_security_check( USER ) =
‘Authorized’
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
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
Operating System

Who has access

What to lockdown

Things to watch out for
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
Recommendations
Get the basics right
•
Disable telnet and ftp
•
Use SSH
•
•
Includes scp and sftp
•
Consider controlled use of rcp for performance
rcp 8.5 times faster than scp
Lock the oracle account and prevent logins
mask password in /etc/shadow
•
Become oracle via SSH or SUDO
Operating System Controls
•
Apply the Oracle security patches
http://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
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
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?
Passwords

Background

The Oracle hashing algorithm

How safe are oracle passwords?

Good and bad examples
Passwords
Kerckhoffs’ Principle:
The security of a cryptographic system
must 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
Oracle password hashing
The current hashing algorithm was released in
Oracle 6 (1988)
Design Goals:
1. Must work on all terminals
Some terminals did not have lower case
So must be case insensitive
2. Must support non ASCII characters
16 bits per character – high byte zeroed
3. Different users with the same password must have
different hashes
4. Long passwords are supported
Maximum is 30 characters
Oracle password Hash
•
Username and plaintext password are
concatenated
•
Converted to upper case
•
Hashed with a modified DES encryption
algorithm (a one way function)
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
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
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?
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
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
Observation
Standalone passwords obsolete in 10 years
Instead will have multiple types of authentication
For example:
1. Something only you know
e.g. a password or a PIN
2. Something only you have
e.g. a smartcard or a token
3. Something only you are
e.g. biometrics
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
Case Study
2. Password stored encrypted in INI file on client
•
Still single application user
•
Developers can login to production
•
Non application auditing impossible
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
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
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
Change and Auditing
•
Why audit?
•
How much auditing?
•
Auditing methods
•
The change process
•
Testing
Why Audit?
The goal of auditing = detection of bad things
So we can respond:
1. Improve prevention methods
2. Reduce detection time to limit damage
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
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
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
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
Another type of audit
Periodic checks for
•
Users with
•
SELECT ANY TABLE
•
SELECT ANY DICTIONARY
•
ALTER USER
•
EXECUTE ANY PROCEDURE
Can
become
DBA
•
Default passwords
•
Active accounts for ex-employees
•
Users logged on for more than X hours
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
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?
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
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
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
Useful Resources
Oracle links
http://www.oracle.com/technology/deploy/security/alerts.htm
http://www.oracle.com/technology/deploy/security/db_security/index.html
http://tahiti.oracle.com/
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
Useful Resources
Checklist
URL
Project Lockdown,
Arup Nanda
http://www.oracle.com/technology/pu
b/articles/project_lockdown/index.ht
ml
Hardening Oracle Administration and
Developer Workstations
Alexander Kornbrust
http://www.red-databasesecurity.com/wp/hardening_admin_pc
_us.pdf
The 60 Minute Network Security
Guide, SNAC
http://www.nsa.gov/snac/support/sixt
y_minutes.pdf
Oracle Database Security Checklist
An Oracle Whitepaper
http://www.oracle.com/technology/de
ploy/security/pdf/twp_security_checkl
ist_db_database.pdf
Oracle Database Checklist
Pete Finnigan
http://www.sans.org/score/checklists/
Oracle_Database_Checklist.pdf
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/
Useful Resources
•
Effective Oracle Database 10g Security by Design
David C. Knox
Oracle Press
ISBN: 0-07-223130-0
A Good Read
•
In Code
Sarah Flannery, 2001
Profile Books
ISBN: 1-86197-271-7
•
The Code Book
Simon Singh, 1999
Fourth Estate
ISBN: 1-85702-889-9
•
The Art of Deception:
Controlling the Human Element of Security
Kevin Mitnick, 2002
Wiley Publishing
ISBN: 0-471-23712-4
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
The End
Thank you for your attendance today
[email protected]
http://www.mga.com.au