Download Lecture 19

23/3/15



Why is database security important?
General Strategies and Tactics for
Hardening Databases
Oracle



Databases often store data which is
sensitive in nature
Incorrect data or loss of data could
negatively affect business operations
Databases can be used as bases to attack
other systems from








Principle of Least Privilege!
Stay up-to-date on patches
Remove/disable unneeded default
accounts
Firewalling/Access Control
Running Database processes under
dedicated non-privileged account
Password Security
Disable unneeded components
Stored Procedures and Triggers

If X service doesn’t need access to all tables
in Y database… then don’t give it access to
all tables.
◦ Example: A web application that reads a list of
people from a database and lists them on a
website. The database also contains sensitive
information about those people. The account used
by the web application should not be allowed to
read the table that contains sensitive non-public
information.

Do not give accounts privileges that aren’t
needed
◦ Unneeded privileges to accounts allow more
opportunity for privilege escalation attacks.

Throttling connections – make it harder
for the bad guys to brute-force or guess
passwords
◦ Use firewall software
◦ It’s possible that throttling could deny access
to applications which make a large amount of
connections legitimately

Reducing the surface area of attack with
firewall rules
◦ Don’t let the world connect to your database
server.

Strong passwords are a must
◦ Constant brute-force attacks are happening
across campus. Esp. against SQL Server

Built in password policy control seems
rare
◦ How can we enforce password policy?


Stored Procedures and Triggers can lead
to privilege escalation and compromise.
Be sure to be thinking about security
implications when allowing the creation
of, and creating these.

Just like disabling unneeded services for
an operating system is a good idea
disabling unneeded components for
databases is a good idea.
If [the] Oracle could see into the future...
the “Unbreakable” marketing campaign
may have not been a good idea.

A search on milw0rm’s exploit catalogue
returns
◦ 27 exploits dated from 11/16/2000 –
07/19/2007
Data and quote from The Oracle Hacker’s
Handbook:
“[…] 2003 and beyond […] the numbers went through the roof […]”
TNS Listener - “The TNS Listener is the
hub of all communications in Oracle. […]
When a client wishes to access the
database server, the client connects first
to the Listener. […] In versions of Oracle
prior to 10g, the TNS Listener could be
administered remotely What makes this
particularly dangerous is the fact that by
default the Listener is installed without a
password […]”
– The Database Hacker’s Handbook

The TNS listener allows clients (tools and
applications) to connect to a given Oracle
database. When the listener is running on the
database server, it is opening a port on the
host system to listen for communications
request with the specified database.

Decent amount of default accounts
◦ Be aware what they are
◦ Ensure the passwords do in fact get changed
appropriatly

10g forces admin to set passwords for
many default accounts on install and
may lock or expire them.

Set a password for TNS Listener
Administration
◦ listener.ora file
 PASSWORDS_listenername = somepass
◦ Use the lsnrctl utility
 LSNRCTL> change_password
Discovery and
Classification
Authentication,
authorization and
access control
Patch Management
FOUNDAT ION
Auditing
Encryption
Monitoring
Data Masking
Vulnerability
Assessment
Database Firewall
DET ECTION
PREVENTION
Figure Pillars of Database Security
16




The foundation pillar stresses discovery and classification
of sensitive data and having a robust authentication,
authorization, and access control framework
All critical databases should be patched on a regular basis
to eliminate known vulnerabilities
Understanding which databases contain sensitive data is a
key requirement for any database security strategy.
Enterprises should take a complete and ongoing inventory
of all databases, including production and nonproduction,
and ensure authentication, authorization, and access
control is enabled for all critical databases.
17




All changes to sensitive data should be logged to provide
the ability to answer audit questions. Auditing and
monitoring offer compensating controls when preventive
measures are not enabled.
To support regulatory compliance standards, such as PCI,
HIPAA, SOX, and EU, and improve data security,
enterprises should track all access and changes to
sensitive data
Data and metadata in databases can be accessed,
changed, or even deleted in seconds.
Detection pillar provides a detailed audit trail of database
activities and provides details on vulnerabilities
18


This pillar focuses on preventing unauthorized
access and protecting against attacks
Preventive security measures
1) network and data-at-rest encryption;
2) data masking for nonproduction databases to prevent
data exposure to non-production users;
3) database firewall to prevent threats such as SQL
injection attacks or privilege escalation from even
reaching databases;
4) 4) change management to enable a formal procedure
to manage changes in production.
19

Transparent data encryption (TDE) enables you to encrypt individual
table columns or an entire tablespace.
◦ When a user inserts data into an encrypted column, transparent data encryption
automatically encrypts the data.
◦ When users select the column, the data is automatically decrypted.
◦ After the selection, the data is reencrypted.



Transparent data encryption helps protect data stored on media in the
event that the storage media or data file gets stolen, because it stores
the encryption keys in a security module (that is, a wallet) external to the
database.
Protecting data from this type of theft is required for most compliance
regulations.
The benefit to using transparent data encryption is that it requires little
coding and is quick and easy to implement.
20


data masking, the format of data remains the
same; only the values are changed.
The data may be altered in a number of ways,
including encryption, character shuffling, and
character or word substitution.



Sensitive information, such as credit card or
social security numbers, can be replaced with
realistic values
Production data can be safely used for
development, testing, or sharing with out-source
or off-shore partners
Helps comply with data privacy mandates such as
Sarbanes-Oxley, Payment Card Industry (PCI)
Data Security Standard (DSS) and Health
Insurance Portability and Accountability Act
(HIPAA)
22



Oracle Database Firewall prevents illegal access
to databases, stops SQL injection, enforces
security policies accurately, and generates realtime alerts.
It prevents internal data policy breaches - even
by trusted insiders and privileged users.
You can enforce how activity will be controlled by
allowing the SQL to pass through to the
database, block and substitute the SQL so no
database results are returned to the user, or alert
on the activity.
23



SQL injection is a basic attack used to either gain
unauthorized access to a database or to retrieve
information directly from the database
The principles behind a SQL injection are simple
and these types of attacks are easy to execute
and master
Vulnerability of application development Applications can be developed using many
methods for connecting to an Oracle database –
some of these methods are more vulnerable to
SQL Injection attacks than others
24

Database 12c delivers security enhancements and
new features including:
◦ conditional auditing

The new policy based syntax simplifies management of auditing within the database and provides
the ability to accelerate auditing based on conditions.
◦ privilege analysis
◦ data redaction

Oracle Data Redaction enables you to mask (redact) data that is returned from queries issued by
applications.
◦ enhanced encryption key management

Oracle Key Vault (OKV) enables customers to quickly deploy encryption and other security
solutions by centrally managing encryption keys

Deployment Fail
◦ Predeployment assessment

Broken Databases
◦ Patch databases

Leaked Data
◦ Reduce availability of ad hoc connections

Stolen Backups
◦ TDE and automatic encryption facilities

Database Feature Abuse
◦ Recoding and patches

Lack of Segregations

Hopscotch

SQL Injections

Poor key Management

Inconsistencies
◦ Segregation of administrative duties
◦ Networks, applications (incl databases, servers have
separate admin accounts)
◦ Testing input variables for SQL injection
◦ Implement appropriate encryption key management
systems
◦ Common theme – Need for consistency

The Database
Hacker’s Handbook – Defending Database
Servers, Indianapolis: Wiley Publishing Inc., 2005.
D.Litchfield, C.Anley, J. Heasman, B. Grindlay,
◦

The Oracle® Hacker’s Handbook: Hacking
and Defending Oracle, Indianapolis: Wiley Publishing Inc., 2007.
D.Litchfield,
◦



Available on Books 24x7
Available on Books 24x7
http://www.cgisecurity.com
http://www.oracle.com/technetwork/database/s
ecurity/security-compliance-wp-12c1896112.pdf
http://www.cnet.com/uk/news/oracleunbreakable-no-more/