Database & Technology 1 _ Barbara Rabinowicz _ Database Security Methoda and Techniques.pdf

Database Security – Methods
• 

and Techniques
Barbara Rabinowicz – Oracle Lead DBA
IBM
16/08/2011

The most comprehensive Oracle applications & technology content under one roof

Introduc)on

•  Originally
from
Israel

•  Started
my
IT
career
in
the
Israeli
Army
(Programming
Course
-‐
School
of

Mamram),
and
then
served
in
the
Navy
as
a
programmer

•  Worked
in
Amdocs
(Israel)
on
Yellow
&
White
pages
accounts
overseas
(U.S.A,

Australia
and
Mexico)

•  Living
in
Australia
for
the
last
12
years

•  Worked
for
Sensis/NAB
and
currently
in
IBM
for
the
last
12
years

•  OCM
cer)ﬁed
for
Oracle
10g
-‐
April
2009

•  State
president
of
the
Victorian
Oracle
User
Group

•  Prac)ce
Bikram
Yoga
5
days
a
week


Why
Implement
Database
Security?

•  In
2001,
Biblioﬁnd,
a
division
of
Amazon.com,
that
specialized
in
rare
and

out
of
print
books,
was
aXacked
and
details
for
almost
100,000
credit

cards
were
stolen

•  In
March
2001,
the
FBI
reported
that
almost
50
banks
and
retail
Websites

were
aXacked
and
compromised
by
Russian
and
Ukrainian
hackers

•  Study
conducted
by
Evans
Data
in
2002,
that
40%
of
banking
and
ﬁnancial

services
reported
“Incident
of
unauthorized
access
and
data

corrup)on”


Trends
in
the
IT
industry

•  E-‐commerce
and
e-‐business
becoming
very
popular.
We
buy
from

online
retailers,
pay
our
u)lity
bills
using
online
banking
websites

•  New
Technologies
to
use
the
databases,
such
as
storing
XML
and

running
web
services
within
the
database,
which
open
up
the

database
to
more
types
of
aXack

•  Increase
awareness
among
the
hackers
community

•  Widespread
regula)on
have
risen
in
the
IT
industry
(Sarbanes-‐
Oxley,
HIPAA),
have
ﬁnancial
and
criminal
penal)es
associated
with

noncompliance


Hardening
Your
Oracle
environment

•  Secure
the
physical
loca)on
of
the
database
server

•  On
Unix

–  Do
not
install
oracle
as
root

–  Set
Unmask
is
022

–  Do
not
use
/tmp
as
the
temporary
install,
use
a
directory
with
700
permissions

–  Create
an
account
for
each
DBA
which
will
access
the
server,
do
not
have
all
DBA’s

accessing
the
same
server
with
the
same
username

•  Lock
the
socware
owner
account,
do
not
use
it
to
administer
the
database

•  Conﬁrm
the
Oracle
user
owns
all
the
ﬁles
on
$ORACLE_HOME/bin.
File
permission

should
be
0750
or
less


Hardening
Your
Oracle
environment
-‐
cont

•  Install
the
database
op)ons
that
you
really
need

•  Ensure
limited
ﬁle
permission
on
init.ora

•  Verify
limited
access
to
sqlnet.ora,
tnsnames.ora

•  Set
HTTP
passwords

•  Disable
iSQL*Plus
for
produc)on
servers

•  Remove
default
accounts
which
are
not
used

•  Check
default
passwords
(i.e
“change
on
install)

•  Check
users
have
strong
passwords
especially
for
SYS
and
SYSTEM

•  Use
Oracle
proﬁles
to
implement
strong
passwords

•  Close
ports
which
are
not
needed


Hardening
Your
Oracle
environment
-‐
cont

•  Ensure
that
the
following
values
are
set
in
the
init.ora
ﬁle

–  _trace_ﬁles_public=FALSE

–  global_names=TRUE

–  Remote_os_authent=FALSE

–  Remote_os_roles=FALSE

–  Remote_listener=“”

–  Sql92_security=TRUE

•  Remove
completely
or
limit
privileges
that
include
ANY

•  Limit
or
disallow
privileges
for
ALTER
SESSION,
ALTER
SYSTEM
and

BECOME
USER

•  Don’t
set
default
tablespace
or
temporary
tablespace
to
SYSTEM

for
user
accounts

•  Limit
users
who
have
a
“DBA”
granted
role


Hardening
Your
Oracle
environment
-‐
cont

•  Don’t
collapse
OSDBA/SYSDBA,
OSOPER/SYSOPER
and
DBA
into
one

role.
Group
mapping
to
OSOPER,
OSDBA
and
DBA
(socware
owner)
should

be
unique

•  Limit
users
who
have
“WITH
ADMIN”
privileges

•  Limit
users
who
have
“WITH
GRANT”
op)ons

•  Understand
fully,
monitor
and
review
the
system
privileges
op)ons
that

are
stored
in
DBA_SYS_PRIVS

•  Do
not
set
utl_ﬁle_dir
to
‘*’
or
a
directory
where
the
ORACLE_HOME

resides

•  Limit
access
to
SGA
tables
and
views,
such
as
X$
tables,
DBA_
views
or
V$

views,
these
objects
would
be
paradise
for
hackers

•  Limit
access
to
“ALL_%%
views

•  Limit
access
to
SYS.AUD$,
SYS.USER_HISTORY$,
SYS.LINKS$

•  Secure
access
to
catalog
roles
and
dba
roles
views


Hardening
Your
Oracle
environment
-‐
cont

•  Revoke
public
execute
from
UTL_FILE,
UTL_TCP,
UTL_HTTP,

DBMS_RANDOM,
DBMS_LOB,
DBMS_JOB,
DBMS_SCHEDULER,
OWA_UTIL,

DBMS_SQL
and
DBMS_SYS_SQL

•  Revoke
CONNECT
and
RESOURCE
role
from
all
users

•  Check
all
database
links
and
make
sure
you
are
not
storing
passwords
in

clear
text

•  Set
password
for
the
listener

•  Remove
EXTPROC
entry
from
listener.ora

•  Use
PRODUCT_PROFILE
to
secure
SQL*Plus

•  Set
TCP.VALIDNODE_CHECKING,
TCP.INVITE_NODES
and

TCP.INCLUDE_NODES

•  Revoke
as
many
packages
from
PUBLIC
as
possible

•  Audit
that
developers
cannot
access
produc)on
instances

•  Enable
audi)ng


Patch
the
database

•  Socware
bugs
are
ocen
exploited
for
launching
an
aXack

•  Patches
help
to
address
threats
that
are
launched
against
known

problems

•  Patching
can
be
diﬃcult
and
have
some
)me
delay
which
can

expose
the
database
to
an
aXack,
due
to
tes)ng
schedules
or

vendor
schedules
who
do
not
release
the
patches
quickly

•  Oracle
Security
alert
page
–
www.oracle.com/technetwork/topics/security/alerts-‐086861.html

•  To
subscribe
to
alerts:

www.oracle.com/technetwork/topics/security/
securityemail-‐090378.html


Defense-‐in-‐depth

•  This
strategy
uses
mul)ple
layers
of
security
rather
then
trying

to
build
and
ul)mate
security
layer

•  Database
security
needs
to
be
part
of
network
security,
host

security,
security
processes
and
procedures
including
a
good

database
security
layer

•  Security
socware
landscape:

–  Authen)ca)on
&
authorisa)on
(token,
SSO)

–  Firewalls

–  Virtual
Private
Networks
(VPN)

–  Intrusion
Detec)on
and
Preven)on

–
Iden)fy
malicious
event,
or

crea)ng
base
lines
and
inspec)ng

change
from
the
norm

–  Vulnerabili)es
and
patch
assessment

–  Security
Management

–  An)virus


Vulnerability
Management

•  Why
there
are
so
many
vulnerabili)es?

–  Socware
defects
such
as
Design
flaws
and
Coding
errors

(buffer
flow)

–  Configura)on
errors
–
unnecessary
services,
access

administra)on
errors
(65%
of
vulnerabili)es)


Patch
Management

•  Be
tenta)ve
in
installing
patches
in
produc)on
environment,
without
ﬁrst

installing
them
in
a
test
environment

•  Patch
Management

–  Map
your
assets

–  Classify
your
assets
(mission
cri)cal,
business
cri)cal
and
business

opera)ons)

–  Harden
your
environment

–  Build
and
maintain
a
test
environment
which
mirrors
produc)on

–  Ensure
a
back
out
plan
exists
and
tested

–  Automate
the
process
of
patch
distribu)on
and
installa)on

–  Create
detailed
project
plan
for
implemen)ng
patches

–  Document
and
set
up
procedures
and
policies
to
that
the
process
becomes

repeatable
and
sustainable


Incident
Management

•  Part
of
the
security
process
which
is
responsible
for
inves)ga)on
and
resolu)on
of

security
incidents

•  There
is
no
point
in
being
able
to
uncover
problems
and
aXacks
if
you
do
nothing

about
it

•  One
of
the
most
expensive
parts,
because
the
resource
cost
tends
to
be
high

•  Typically
diﬃcult
to
staﬀ,
as
the
team
needs
to
have
good
understanding
in
every

IT
discipline
needs
to
have
a
good
depth
of
understanding
the
systems
and
be
able

to
think
as
both
the
inves)gator
and
aXacker


Leave
the
database
at
the
core
of
the
network

•  The
database
is
probably
the
most
valuable
piece
of
your
infrastructure

•  Database
should
live
inside
data
centres

•  If
database
is
accessed
via
a
web
server,
then
use
demilitarized
zone

(DMZ)
architecture
in
which
there
are
2
ﬁrewalls
between
the
database

and
the
internet

•  Use
a
VPN
for
client-‐server
applica)on,
when
the
applica)on
is
accessed

outside
of
the
cooperate
network


Database
Environment
–
Network

access
Map

•  Become
aware
of
which
network
nodes
are
connec)ng
to
the
database
(review

data
access
diagram)

•  What
you
do
not
know
can
“hurt”
you


Tools
and
applica)ons
which
access
your

database

•  Tracking
tools
and
applica)ons
that
are
used
to
ini)ate
database

connec)ons
is
one
of
the
most
over
looked
areas
in
the
database
security

select
machine,terminal,program,logon_)me,username
from
v$session
where
username
is
not
null

MACHINE

TERMINAL

PROGRAM

LOGON_TIM
USERNAME

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

ABCDEFXG10

pts/4

sqlplus@ABCDEFX10
(TNS
V1-‐V3)
31-‐JUL-‐11
BARB

ABCDEFXG01

unknown

JDBC
Thin
Client

25-‐JUL-‐11
JIR

ABCDEFXG01

unknown

JDBC
Thin
Client

25-‐JUL-‐11
JIR

•  Polling
is
required,
because
triggers
cannot
be
set
on
these
types
of
tables

•  The
other
op)on
is
to
extract
informa)on
from
packets
(such
as

tcpdumps)


Minimize
networking
layers

•  If
you
do
not
need
a
certain
network
op)on,
you
should
disable
it

•  Unless
there
is
an
unconven)onal
environment,
disable
all

protocols
except
for
TCP/IP
(to
conﬁrm
other
protocols
are
not
in

use,
such
as
NAMED
PIPES)

•  Shutdown
unnecessary
network
services
and
ports

•  To
display
ports
in
use,
use
netstat
(display
current
TCP/IP

connec)ons)
or
nmap
(popular
port
scanner)

ABCDEFX10:/oracle>
netstat
-‐a
|
grep
-‐i
1521

tcp

0

0
db1_str:1521
*:*

LISTEN

tcp

0

0
db2_str:1521
*:*

LISTEN

tcp

0

0
db3_str:1521
*:*

LISTEN

tcp

0

0
db4_str:1521
*:*

LISTEN


Use
Firewalls

•  Firewalls
can
help
you
limit
access
to
your
database

•  Conven)onal
ﬁrewall
–
Filter
IP
addresses
and
ports
that
exist
in
the
TCP/IP
header

•  SQL
Firewall
–
enables
to
set
policies
on
SQL
commands,
database
users,

applica)on
types
and
database
objects

•  If
you
do
not
have
ﬁrewall
in
place,
the
following
built
in
feature
can
be
used
in
the

sqlnet.ora:

–  TCP.INVITED_NODES
=(client-‐ip1,
client-‐ip2)

–  TCP.EXCLUDED_NODES=(client-‐ip3,
client-‐ip4)

–  TCP.VALIDNODE_CHECKING=yes


Authen)ca)on
and
password
Security

•  Authen)ca)on
–
the
process
of
confirming
the
correctedness
of
the

claimed
iden)ty

•  When
understanding
how
to
configure
strong
authen)ca)on,
the
next

step
is
to
learn
what
ac)vi)es
to
be
performed
on
ongoing
basis
to
ensure

authen)ca)on
and
iden)fica)on
remain
secure


Oracle
Authen)ca)ons
Op)ons

•  Na)ve
Oracle
Authen)ca)on
–
Oracle
uses
tables
to
maintain
password

•  Example

–  Client
asks
for
User
and
Password
on
OCI
layer

–  TNS
makes
a
network
call
to
the
server
and
passes
client
informa)on
(hostname,
and
OS
name)

–  TNS
invokes
a
system
call
to
the
OS
to
retrieve
OS
user

–  TNS
nego)ates
authen)ca)on
protocol
with
the
database

–  When
authen)ca)on
method
is
agreed
client
sends
login
name
and
password
to
the
database

using
Oracle
Password
protocol
(O3LOGON)
using
DES
encryp)on

•  See
authen)ca)on
informa)on
in
V$SESSION_CONNECT_INFO

select
*
from
v$session_connect_info;

SID
AUTHENTICATION_
OSUSER

NETWORK_SERVICE_BANNER

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

21
INTERNAL

oracle

TCP/IP
NT
Protocol
Adapter
for
Linux:
Ve

rsion
10.2.0.4.0
–
Produc)on

30
DATABASE

oracle

Oracle
Advanced
Security:
crypto-‐checksu

mming
service
for
Linux:
Version
10.2.0.

4.0
–
Produc)on

Opera)ng
System
Authen)ca)on


Parameters
relevant
to
OS
Authen)ca)on

•  Init.ora
parameters

–  Remote_os_authent
–
using
client
authen)ca)on,
should
always
be

set
to
FALSE

–  Remote_os_roles
–
Allows
client
authen)ca)on
to
remotely
enable

OS
roles,
should
be
set
to
FALSE

–  Os_authent_preﬁx
–
Should
not
be
NULL,
otherwise,
can
create
an

OS
account
which
can
connect
to
the
database

–  Os_roles
–
allows
to
control
which
roles
are
granted
through
the
OS

rather
then
through
the
database

•  SQLNET.ORA
parameters

–  SQLNET.AUTHENTICATION_SERVICES=(NTS)
–
Oracle
server
to

perform
ﬁrst
Windows
authen)ca)on,
and
if
not
possible
fall
back
to

na)ve
authen)ca)on


Sending
passwords
over
the
network

•  Vulnerability
to
be
protected
by
encryp)ng
the
communica)on
stream

–  ALTER
USER
scoX
IDENTIFIED
BY
)ger;

•  This
can
be
avoided
by
using
OS
authen)ca)on

–  CREATE
USER
barb
IDENTIFIED
EXTERNALLY;


Using
Password
Profiles

•  Password
profiles
parameters

–  PASSWORD_LIFE_TIME

–  PASSWORD_REUSE_TIME

–  PASSWORD_REUSE_MAX

–  PASSWORD_GRACE_TIME

–  PASSWORD_VERIFY_FUCTION
–
enables
verify
strong
passwords

•  Example:

–  CREATE
PROFILE
app_profile
LIMIT
FAILED_LOGIN_ATTEMPTS
5

–  ALTER
USER
scoX
PROFILE
app_profile;

•  Be
aware
of
account
lockout
acer
a
number
of
failed
logins,
this
can
be
a

formed
of
denial-‐of-‐service(DoS
aXack)
–
Hacker
equivalent
of
vandalism

–
This
can
be
overcome
by
external
security
system
such
as
database

firewall


Placing
a
password
on
the
Oracle
Listener

•  Update
my
listener.ora
on
my
PC,
to
include
an
alias
to
a
remote

server,
then
fire
up
the
lsnrctl
u)lity,
if
the
remove
server
is
not

protected
with
password,
I
can
connect
to
it
remotely

•  This
enables
to:

–  Stop
the
listener,
making
the
database
unreachable

–  Can
get
informa)on
from
the
listener
(i.e.
Services
command
can

provide
services
running
on
the
server
including
path
and

environment
variables)

–  Cause
log
files
to
be
wriXen
to
disk,
can
write
to
any
loca)on
the

oracle
OS
account
can
write
to
(replace
.profile),
can
place
files
under

the
root
of
a
Web
server
and
then
download
the
file
using
a
browser

•  To
add
a
password
to
your
listener,
add
the
following
line
to

listener.ora:

–  PASSWORDS_LISTENER_LISTENER
=
listener_password


Database
to
database
communica)on
Security

•  Database
communica)ons
need
to
be
monitored

–  Between
which
databases
there
are
data
transfers

–  What
contents
is
the
communica)on

•  CREATE
DATABASE
LINK
DB2_LNK1
CONNECT
TO
SYSTEM
IDENTIFIED
BY
MANAGER
USING

‘DB2’;

–  Access
to
DB_LNK1
provides
access
to
SYSTEM
access
to
database
DB2

•  CREATE
DATABASE
LINK
DB3_LNK1
USING
‘DB3’;

–  There
are
no
security
issues

–  More
maintenance
required
to
synchronise
users
and
password
on
source
and
target

databases


Database
to
database
communica)on

Security
-‐
cont

•  Database
links
monitoring

–  Always
monitor
and
alert
upon
crea)on/modiﬁca)on
of
database
links

–  Monitor
usage
of
database
links

•  Database
Replica)on

–  Most
common
advanced
feature
in
many
types
of
databases

–  Secure
communica)on
and
ﬁles
that
are
used
by
the
replica)on

–  Secure
the
en)re
replica)on
architecture
is
secure
and
auditable


Types
of
Replica)on

•  Snapshot
Replica)on

–  Data
is
fairly
sta)c

–  Amount
of
data
to
be
replicated
is
small

–  Monitor
DDL
statements
(CREATE
MATERIALIZED
VIEW/CREATE
MATERIALIZED
VIEW
LOG/
DBMS_REPCAT/DBMS_DEFER_SYS/DBMS_REPUTIL

•  Transac)on
Replica)on

–  Replica)on
on
opera)onal
level

–  Data
Guard
-‐
Require
to
secure
folder
and
replica)on
ﬁles

–  Advance
Queuing

•  All
queues
are
stored
within
the
database
–
no
requirement
to
secure
external
ﬁles

•  Separate
accounts
Replica)on
Administrator/Propagator/Reciever
–
will
require
more
to
monitor

and
adminster,
but
can
beXer
track
the
data
movements

•  Merge
Replica)on

–  Merging
replica)on
between
master
and
replica

–  Oracle
Advanced
Replica)on

–  Monitoring
of
DDL
statements


Types
of
Database
Trojan

•  Category
I
-‐
An
aXack
that
both
injects
the
Trojan
and
calls
it

–  Least
sophis)cated,
the
aXacker
can
be
traced
back

–  The
aXack
occurs
at
two
dis)nct
)mes
and
requires
more
)me
to
inves)gate

to
relate
the
two
aXacks
as
forming
a
single
aXack

–  Monitor
execu)on
of
stored
procedures

–  Stored
procedures
baselines
would
be
most
eﬀec)ve
to
detect
execu)on
of
a

stored
procedures
outside
of
the
norm

•  Category
II
-‐
An
aXack
the
uses
and
oblivious
user
or
process
to
inject
the

Trojan
and
then
calls
it
to
extract
the
informa)on
or
perform
an
ac)on

within
the
database

–  Oblivious
user
or
process
to
inject
the
Trojan
–
developer
using
code
he/she

do
not
know

–  Monitor
execu)on
of
stored
procedures

–  Stored
procedures
baselines
would
be
most
eﬀec)ve

to
detect
execu)on
of
a
stored
procedures
outside

of
the
norm


Types
of
Database
Trojan
-‐
cont

•  Category
III
-‐
An
aXack
that
injects
the
Trojan
and
then
uses
an

oblivious
user
or
process
to
call
the
Trojan

–  Oblivious
user
or
process
to
call
the
Trojan
–
a
stored
procedure

which
runs
as
part
of
the
batch
schedule

–  Monitor
crea)on
and
modiﬁca)on
of
stored
procedures
such
as

CREATE
PROCEDURE
or
ALTER
TRIGGER

–  Monitor
ALL/Par)al
execu)on
of
built
in
system
stored
procedures

•  Category
IV
-‐
An
aXack
that
uses
oblivious
user
or
process
to
inject

the
Trojan
and
also
uses
and
oblivious
process
to
call
the
Trojan

–  Monitor
crea)on
and
modiﬁca)on
of
stored
procedures

–  Monitor
ALL/Patrial
execu)on
of
built
in
system
stored
procedures


Oracle’s
–
PARSE_AS_USER

BEGIN

AC
=
DBMS_SQL.OPEN_CURSOR;

SYS.DBMS_SYS_SQL.PARSE_AS_USER(AC,’ALTER
USER
SYS
IDENTIFIED
BY

CHANGE_ON_INSTALL’,’DBMS_SQL.V7);

END;

•  When
unsuspec)ng
DBA
calls
this
procedure,
the
SYS
password
is
changed

to
CHANGE_ON_INSTALL


Monitoring
Developers
Ac)vity
on

Produc)on
environment

•  Monitor
access
to
produc)on
databases
except
for
the
ones
coming
from

the
applica)on
server

•  AUDIT
data

–  What
form
will
it
be
maintained

–  Detail
to
which
you
need
to
keep
the
data

•  INSERT
INTO
CREDIT
CARD
VALUES
(1,’123456789123456’,’0101’)

versus

•  INSERT
INTO
CREDIT_CARD
VALUES
(?,?,?)

•  Scrubbed
data
will
be
usually
more
than
enough
to
alert
on
divergence

•  Scrubbed
data
is
insuﬃcient
for
row
level
security

•  Scrubbed
data
does
not
create
addi)onal
poten)al
security

vulnerability

•  To
detect
data
which
may
have
been

inserted
maliciously
or
mistakenly
by
developers,

all
values
will
need
to
be
monitored
versus
a
scrubbed
format

• 


Monitoring
of
crea)on
of
Traces
and

Events

•  Database
event
and
monitoring
traces
can
con)nually
tell
the
aXacker

many
things
about
the
database
such
as
username,
terminal
informa)on,

applica)on
informa)on

•  ALTER
SESSION
SET
EVENTS
‘10046
TRACE
NAME
CONTEXT
FOREVER,

LEVEL
12’;

•  DBMS_SYSTEM.SET_EV(sid,serial#,event,level,name)

•  The
event
writes
informa)on
to
the
trace
ﬁles

•  Using
undocumented
features
make
it
more
appropriate
for
aXackers
to

use,
however,
these
features
are
seldom
used

•  Monitor
or
audit
that
are
currently
scheduled
in
the
database,
that
create

new
job


Implementa)on
Op)ons
to
Monitor

Events

•  Op)on
I
-‐
Con)nuously
monitor
and
alert
on
each
command
that
creates
or

modiﬁes
events
or
traces

•  Op)on
II
–
Periodically
extract
all
event
and
traces
for
review


Why
Encryp)on?

•  Confiden)ally
is
the
key
to
maintaining
secure
informa)on

•  Companies
that
cannot
ensure
security
for
confiden)al
informa)on
risk

embracement,
financial
penal)es
or
risk
the
business

•  Would
you
do
business
with
a
bank
if
other
customer
account
informa)on
is

leaked
out
and
used
by
criminals

•  Leakage
of
data
is
poten)ally
from
ra)onal
databases
is
a
poten)al
disaster
when

it
comes
to
iden)ty
thec

•  The
number
of
data
privacy
regula)on
have
been
forced
on
many
companies

around
the
globe
(HIPPA
–
U.S.
Health
Informa)on
Portability
and
Accountability

Act,
The
VISA
Interna)onal
Account
Informa)on
Security
(AIS))


Encryp)on

•  Two
techniques
will
be
discussed

–  Encryp)on
of
data
in
transit

•  All
communica)ons
between
the
client
and
the
server
are

encrypted

•  The
Encryp)on
occurs
at
the
endpoints
(one
side
encrypts
the

data
being
passed
over
the
network
and
the
other
will
decrypt

the
data.
The
data
itself
is
not
encrypted)

–  Encryp)on
of
data
at
rest


Sniﬃng
Data

•  For
a
hacker
to
steal
data,
the
following
must
occur:

–  The
hacker
must
be
able
to
physically
tap
into
the
communica)on
between

the
database
clients
and
database
servers
(i.e,
Install
network
sniﬀers
on
the

client
or
server,
or
use
SPAN
ports
on
a
switch)

–  The
hacker
must
be
able
to
understand
the
communica)on
stream

•  When
the
underlying
network
is
TCP/IP
networks,
there
are
numeros

tools
available
for
inspec)ng
headers
and
payloads
of
TCP/IP
packets,
if

packets
are
not
encrypted,
the
hacker
can
preXy
much
see
everything

i.e.
tcpdump


Tcpdump

•  Tcpdump
allows
you
to
dump
TCP/IP
packets
based
on

certain
filters
(headers,
en)re
packets
or
stream
of
files)

•  Downloaded
from
www.tcpdump.org

•  tcpdump
-‐s
0
-‐w
/tmp/output.txt
host
{machine_name}

and
port
1521

•  tcpdump
-‐A
-‐r
/tmp/output.txt

•  ...

•  .

•  ...............@....................................................B.........................X)alter
user
barb
iden)fied

by
newpassword................

•  16:03:23.700777
IP
xxx.global.zzz.com.33003
>
app.yyy.com.1521:
.
ack
5999
win
33330

•  E..(2.@.?.+;


Encryp)on
op)ons
for
data-‐in-‐transit

•  Encryp)on
Techniques
op)ons

–  Database
speciﬁc
features
–
Oracle
Advanced
Security

–  Connec)on
based
methods
(Secure
Sockets
Layer
–
SSL)

–  Secure
tunnels
(Secure
Shell
[SSH]
tunnels)

•  The
more
generic
the
method
the
less
work
you
need
to
do


Oracle
Advanced
Security
–
Network

Data
Encryp)on

•  This
op)on
is
available
with
Enterprise
Edi)on
only
with
extra
cost

•  This
op)on
may
be
expensive,
in
compare
to
the
other
op)ons
being
free

•  The
way
it
works:

–  The
listener
ini)ates
and
encryp)on
nego)a)on
sequence
during
the
handshake
phase

when
a
clients
asks
for
a
connec)on

–  During
the
nego)a)on,
the
client
tells
the
server,
which
encryp)on
method
it
supports

–  The
server
compares
this
with
the
encryp)on
methods
available

–  If
available,
the
server
picks
a
method
based
on
the
preferred
method
deﬁned
by
its

conﬁgura)on

–  If
the
server
cannot
support
an
encrypted
conversa)on,
then
the
server
rejects
the

clients
requests
to
open
a
new
connec)on

•  See
the
following
parameters
in
SQLNET.ORA

•  On
the
server:

•  SQLNET.CRYPTO_CHECKSUM_SERVER
=
[accepted
|
rejected
|
requested
|
required]

•  SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER
=
(valid_crypto_checksum_algorithm

[,valid_crypto_checksum_algorithm])

•  On
the
client:

•  SQLNET.CRYPTO_CHECKSUM_CLIENT
=
[accepted
|
rejected
|
requested
|
required]

•  SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT
=
(valid_crypto_checksum_algorithm

[,valid_crypto_checksum_algorithm])


Using
SSL
to
secure
database

connec)ons

•  How
SSL
works
in
Oracle

–  The
client
and
server
establish
which
cipher
suites
to
use

–  The
server
sends
its
cer)ficate
to
the
client,
and
the
client
verifies

that
the
server
cer)ficate
was
signed
by
a
trusted
CA.
This
steps

iden)fies
the
iden)fy
of
the
server

–  If
the
client
authen)ca)on
is
required,
the
client
send
its
own

cer)ficate
to
the
server,
and
the
server
verifies
the
client
cer)ficate

was
signed
by
a
trusted
CA

–  The
client
and
server
exchange
key
informa)on
using
public
key

cryptography,
based
on
this
informa)on,
all
communica)ons
are

encrypted/decrypted
using
the
session
key

•  SSL
is
part
of
the
Oracle
Advanced
Security
Op)on
when
in
used

with
Oracle
Wallets


Encrypt
data-‐at-‐rest

•  This
addi)onal
layer
of
security
is
ocen
used
for
sensi)ve
data,
which
can

be
highly
confiden)al

•  Examples
for
such
data
(pa)ent
data,
high
value
account
informa)on,

Social
Security
numbers)

•  How
can
the
data
become
vulnerable:

–  Database
users
are
looking
at
data
they
should
not
be
able
to
see

–  Steal
or
copy
of
files
(datafiles/dumps/backups)

•  MIT
students
in
2003
analysed
158
disk
drives
that
were
purchased
from

e-‐bay
and
other
sources,
74%
of
the
drives
had
sensi)ve
data
such
as

credit
card
numbers
and
medical
records


Implemen)ng
Encryp)on
Op)ons
for

data-‐at-‐rest

•  The
main
decision
will
be
to
choose
which
layer
will
the
implementa)on
op)on

will
occur

–  Applica)on
Layer

•  Transparent
to
the
database

•  It
will
not
be
possible
to
view
the
data
using
SQL
editor
or
database
tools

–  File
system
Layer

–  Database

•  Most
prac)cal
op)on

•  Examples
include
-‐
Datapump
encryp)on,
RMAN
backups

and
tablespace

encryp)on


Considera)on
when
selec)ng

implementa)on
op)ons

•  Key
management
–
which
keys
are
used
for
encryp)on/decryp)on
and

where
the
reside

•  Recovery
–
what
happens
when
you
loose
the
keys

•  Integra)on
with
Public
Key
Infrastructure(PKI)
systems

•  Backup
and
Restore
–
How
does
the
encryp)on
aﬀect
your
backup,
are

the
backups
encrypted?
What
happens
if
the
keys
are
periodically

changed

•  Clustering
–
How
does
the
encryp)on
aﬀect
your
clustering
op)ons?

•  Replica)on
–
Are
you
replica)ng
encrypted
data?
If
so
how
do
you

replicate
keys?


Considera)on
when
selec)ng

implementa)on
op)ons
-‐
cont

•  Performance
–
how
will
encryp)on
aﬀect
database
performance?
(On
Oracle
9i,

UPDATEs
using
DES
encryp)on
were
more
than
4
)mes
slower
then
an

unencrypted
data),
therefore,
important
guidelines
are:

–  Encrypt
selec)vity

–  Never
encrypt
columns
that
are
used
as
keys
or
indexes

–  Allow
)me,
before
star)ng
such
project
to
do
some
benchmarking
before
the

start
of
implementa)on
and
tuning
during
the
advance
stages
of
the

implementa)on

•  Disk
space
–
Encrypted
data
always
takes
more
space
than
unencrypted
data

because
of
the
metadata
overhead,
to
be
safe
assume
50%
more
space
required

for
the
encrypted
data

•  Audit
trail
–
Is
there
a
visible
and
independent
audit
trail
on
the
usage
of
keys
and

passwords?


Regula)ons

•  Some
people
point
to
the
fact
that
security
does
not
always
display
a
clear

RIO
but
neither
does
an
alarm
system
you
may
install
at
home
or

insurance
you
pay
every
year

•  Leading
companies
understand
that
in
the
same
way
that
people
con)nue

to
protect
and
insure
house
or
cars,
they
con)nually
invest
in
protec)ng

valuable
informa)on,
in
the
same
way
a
serious
incident
can
cripple
a

company
for
life

•  Regula)ons
such
as
HIPAA
for
health
care,
Sarbanes-‐Oxley
for
public

companies,
include
stringent
requirements
dealing
with
informa)on

security/privacy
and
all
of
them
implement
puni)ve
consequences
if

compliance
is
not
maintained


Regula)on
Examples

•  HIPAA
–
Health
Insurance
Portability
and
Accountability
Act
of
1996

–  Passed
by
the
US
congress

–  Guarantee
health
insurance
coverage
of
employees

–  Reduce
health
care
fraud
and
abuse

–  Implement
administra)on
simplifica)on
to
increase
effec)veness
and

efficiency
of
health
care
systems

–  Protect
the
health
informa)on
of
individual
against
access
without
consent

or
authorisa)on

–  HIPAA
sets
penal)es
for
informa)on
leakage
–
up
to
$250,000
per
incident

and
up
to
10
years
imprisonment
of
execu)ve
in
charge!

–  HIPAA
tends
to
be
more
specific
and
define
the
types
of
technologies
that

should
be
implemented


Sarbanes-‐Oxley
Act
(SOX)

•  Passed
by
the
U.S.
Senate
and
U.S.
House
of
representa)ve
is
signed
into
Law
on

Jul
2002

•  It
came
to
answer
increasing
concern
and
heighten
awareness
of
corporate

governance,
conflict
of
interest
and
lack
of
financial
repor)ng
transparency
which

has
caused
damaged
to
investors

•  SOX
applies
to
public
companies
over
$75
million
of
revenues

•  SOX
addresses
many
areas,
the
related
area
to
security
is
“Cer)fica)on
of

financial
statements”

•  CEOs
and
CFOs
are
required
to
personally
sign
and
cer)fy
the
correctedness
of

financial
reports

•  Sec)on
404
–
requirements
management
to
report
on
the
effec)veness
of
the

company
internal
control
over
financial
repor)ng

•  Interpreta)on
of
SOX
regarding
what
type
of
technical
provisions
should
be

implemented
can
range
widely


Role
of
Audi)ng

•  Audi)ng
as
a
func)on
needs
to
play
a
central
role
in
ensuring
compliance
–

there
is
not
security
without
audit

•  For
this
to
be
possible,
data
must
be
available
and
transparent
so
that
an

audit
can
be
performed

•  There
are
two
types
of
data
required
to
ensure
compliance
of
the
database

environment

–  Audi)ng
Informa)on
–
audit
trails
and
other
logs

• 
Login/logouts
of
the
database

• 
HIPAA
–
account
record
for
protected
discloser
of
health
informa)on

(who
connected

to
the
database
maintaining
the
protected
health
informa)on
and
selected
records

about
the
individual
–
keeping
this
record
for
6
years)

–  Security
Audits
–
assessment,
penetra)on
tests
or
vulnerability
scans.

•  Focuses
on
the
current
state
of
the
database
environment
rather
than
audi)ng
data.

These
audits
are
typically
performed
periodically
(e.g.
Once
a
year)
as
part
of
a
larger

audit,
compliance,
or
governance
schedule.
Are
aimed
to
ensure
that
the
database

environment
con)nually
complies
with
set
of
regula)ons
and
policies

•  Vulnerabili)es
assessment
include
checking
the
conﬁgura)on
of
the
database,
patches

installed,
using
trivial
passwords,
same
login
used
to
connect
to
a
large
number
of

environments.
Applica)on
using
dynamic
SQL
versus
bind
variables,
as
dynamic
SQL

have
more
poten)al
risk,
for
SQL
injec)ons


Segrega)on's
of
du)es

•  All
regula)ons
deal
with
human
behaviours
such
as,
untruthfulness,
greed,

sloppiness,
laziness
and
so
forth

•  Regula)ons
use
two
main
techniques

–  Guidelines
so
people
cannot
loosely
interpret
the
regula)ons
to
their
benefit

–  Segrega)on
of
du)es

•  Segrega)on
of
du)es
and
the
use
of
mul)ple
audit
layers
is
the
main
and
most

effec)ve
way
to
ensure
compliance
–
you
cannot
trust
the
process
to
a
single

individual
or
a
single
group,
but
to
build
the
process
in
a
way
so
that
you
have

mul)ple
layers
of
audit

•  These
refinements
are
all
related
to
the
most
fundamental
requirements
in
SOX

and
all
other
regula)ons

•  DBA
should
not
be
responsible
for
defining
the
audit
trails,
monitoring
the
results

or
modifying
the
results
(This
removes
the
work
from
the
DBA
who
is
overburden

with
other
tasks)


Audit
as
a
sustainable
solu)on

•  Audit
tools
which
will
do
most
of
the
work
for
you

–  Be
able
to
get
the
informa)on
quickly,
at
mul)ple
levels

–  High
level
such
as
a
scorecard

–  Lower
level
such
as
the
SQL
details

•  Solu)on
that
will
sustain
change

•  Self
contained
solu)on
that
address
all
the
issues
–
well
packaged
and
self

maintaining
(no
addi)onal
maintenance
in
case
the
data
is
stored
in
a

database
such
as
archiving,
backup
or
tuning)


Audit
Categories
-‐
login/logoff
into
the
database

•  In
a
login
event,
you
will
want
to
know
the:

–  Login
name

–  Timestamp

–  IP
address
for
the
client
ini)a)ng
the
connec)on
(know
which
hosts
usually
connect
to
the

database)

–  Program
used
to
ini)ate
the
connec)on
(SQL*Plus/Toad/
or
a
J2EE
server)

•  Logoff
event
–
same
informa)on
as
login
event

•  All
failed
login
aXempts

–  Required
for
audi)ng
purposes

–  Used
a
basis
for
alerts
for
account
lockouts

–  Use
password
policy
to
lockout
accounts
acer
mul)ple
failed
logging
using
profiles

•  Audit
op)ons
include:

–  AUDIT
SESSION

–  Database
triggers
(AFTER
LOGON
ON
DATABASE/BEFORE
LOGOFF
ON
DATABASE)


Audit
DDL
ac)vity

•  DDL
commands
are
poten)ally
the
most
damaging
commands
that
exist
and
can
certainly
be

used
by
an
aXacker
to
compromise
any
system

•  Stealing
informa)on
may
ocen
involve
DDL
commands
through
the
crea)on
of
an
addi)onal

table
into
which
data
can
be
copied
before
extrac)on

•  Many
regula)on
require
to
audit
any
modiﬁca)on
to
data
structure
such
as
tables
and
views

•  Audi)ng
of
DDL
ac)vity
is
done
to
eliminate
errors
that
developers
and
DBAs
may
introduce

and
can
have
catastrophic
eﬀects
(i.e.
Execute
development
ac)vity
on
produc)on

databases)

•  There
are
3
main
methods
to
audit
schema
changes

–  Use
database
audit
features

–  Use
external
audi)ng
system

–  Compare
schema
snapshots

•  i.e.
User
“AFTER
DDL
ON
DATABASE”
trigger


Audi)ng
Database
Errors

•  Audi)ng
errors
returned
by
the
database
is
important
and
is
one
of
the
first
audit

trails
that
is
important
to
implement

•  AXackers
will
make
many
aXempts
un)l
they
get
it
right
(running

a
SQL
with
UNION
to
guess
number
of
columns
in
a
table)

•  Failed
logins
need
to
be
logged
an
monitored

•  Failed
aXempts
to
elevate
privileges
is
a
strong
indicator
that
an
aXack
may
be
in

progress

•  Produc)on
applica)ons
that
are
causing
errors
because
of
bugs
and
applica)on

issues
should
be
iden)fied
by
and
fixed

-‐
providing
this
informa)on
to
the

applica)on
will
make
you
a
hero,
because
no
one
likes
running
code
that
s)ll
has

issues
and
can
be
easily
resolved

•  Use
database
trigger
“AFTER
SERVERERROR
ON
DATABASE”
or
AUDIT

statements
WHENEVER
UNSUCCESSFUL


Audit
changes
to
privileges
and
user

permissions

•  Any
changes
to
the
security
model
must
be
audited

•  Examples
of
such
changes
are:

–  Addi)on
and
dele)on
of
users
and
roles

–  Changes
to
the
mapping
between
users
and
roles

–  Privileges
changes
–
to
a
user
or
a
role

–  Password
changes

–  Changes
to
security
aXributes
at
the
database,
statement
or
object
level

•  AXackers
will
ocen
try
to
raise
their
privileges
level,
and
mistakes
are
ocen
made

when
grants
are
inappropriately
provided

•  Security
permissions
can
be
hazardous
to
the
database,
and
therefore
it
is
advise

have
real-‐)me
no)fica)on
of
changes
that
are
not
planned
in
a
produc)on

environment
(once
a
day
no)fica)on
will
be
insufficient),
using
external
audi)ng

systems
or
via
built-‐in
database
mechanism

•  Example
for
statements
to
audit:
GRANT,
CREATE
USER,
ALTER
USER,
DROP
USER,

REVOKE,
CREATE
ROLE,
ALTER
PROFILE,
CREATE
PROFILE,ALTER
ROLE


Audit
changes
to
sensi)ve
data

•  Audi)ng
DML
ac)vity
is
another
common
requirement,
i.e.
Accuracy
of
ﬁnancial

informa)on

•  Requirement
I
-‐
Such
audit
will
include:

–  Record
values

–  User
who
performed
the
change

–  Client
used

–  Applica)on

–  Timestamp
of
the
change

–  SQL
statement

•  Requirement
II
-‐
Full
record
of
old
and
new
values
per
DML
may
be
required

•  Such
audits
need
to
be
performed
selec)vely
to
minimize
the
amount
of
audit

data
produced

•  Use
Oracle
log
minor
to
implement
audit
trails
for
DML

•  For
privacy
requirements
audit
SELECT
statements
(i.e.
To
ensure
customers
or

employees
that
their
conﬁden)al
informa)on
does
not
leak
from
the
database)


Audit
changes
to
Audit
deﬁni)on

•  An
aXacker
can
either
change
the
deﬁni)on
of
what
is
being

audited
or
can
come
acer
the
fact
and
change
the
audit
trail

•  This
requires
addi)onal
audit
trail
and
the
other
part
includes

the
no)on
of
segrega)on
of
du)es

•  This
can
be
achieved
using
the
AUDIT
statements
or
external

database
security
and
audi)ng
system


Audi)ng
architecture
Overview

•  The
purpose
of
audi)ng
is
to
elevate
security
and
to
bring
the
environment
to

closer
compliance
with
various
security
policies

•  Having
an
audit
trail
does
not
elevate
security,
unless
it
is
used.
In
fact,
it
creates
a

false
sense
of
security
and
in
doing
so,
makes
the
environment
less
secure

•  Audi)ng
must
allow
to
mine
the
informa)on
to
expose
anomalies,
intrusions,

mistakes,
bad
prac)ces,
policy
viola)ons
and
so
on,
if
you
cannot
explain
how

these
goals
can
be
achieved
using
audit
trails,
then
your
implementa)on
becomes

part
of
the
problem

•  An
independent
audit
trail
is
more
valuable
than
an
audit
trail
that
is
created
by

the
database

•  An
independent
audit
trail
can
be
used
in
tandem
with
a
database
audit
trail
to

support
environments
with
stringent
security
and
compliance
requirements


Architectural
categories
for
Audit

Systems

•  Inspec)on
of
internal
database
data
structures
using
an
Audit
System

–  Example
-‐
Audit
of
V$
tables

•  Inspec)on
of
all
communica)ons
with
the
database

–  Use
network
capabili)es
and
devices
such
as
network
taps,
or
switch
port

mirroring
that
create
a
mirror
packets
for
every
packet
that
is
delivered

•  Inspec)on
of
elements
created
by
the
database
in
the
process
of
normal

opera)on

–  Inspect
transac)on
logs
(archive
logs)
for
all
DDL
and
DML
statements

–  Database
audit
tables
or
OS
audit
ﬁles


Audit
Architecture
–
points
to

• 
consider

Archive
of
Audit
informa)on

–  Allow
flexible
rules
to
define
what
to
archive,
when
and
where
to
archive

–  Schedule
archiving
in
a
way
that
ensures
online
data
is
sufficient
for
repor)ng
ac)vi)es

–  Archive
reports
and
deliverables

–  Ensure
minimum
indexing
is
available
to
bring
back
the
data

•  Secure
Audi)ng
Informa)on
using
Encryp)on
and
are
digitally
signed

–  The
main
repository
where
the
audit
informa)on
resides

–  Archive
files
within
the
audit
server

–  Archive
files
in
transit

–  Archive
files
at
storage
loca)on

•  Audit
the
audit
System

–  Ensure
full
audit
trail
to
any
access
and
changes
made
to
the
audi)ng
informa)on

•  Automate
audit
by
genera)ng
reports
–
Ensure
people
are
reviewing
and
signing

of
the
data,
and
receive
alerts
when
someone
is
holding
up
the
process
and
not

reviewing
the
audit
deliverables


Audit
Architecture
–
points
to
consider
-‐
cont

•  Ensure
the
audi)ng
system
has
sufficient
capacity
(such
as
a
data
warehouse

applica)on)

•  Implement
good
mining
tools
and
security
applica)ons
–
avoid
the
exercise
of

looking
for
a
needle
in
a
haystack.
Use
generic
tools
such
as
Business
Objects
or

OLAP
solu)ons

•  Interpreta)ons
of
regula)ons
map
directly
to
beXer
control
on
the
database

access

–  Auditors
and
informa)on
security
professionals
have
seldom
the
same
skill
and
knowledge

that
the
DBAs
have,
The
result
is
seman)c
gap
that
exists
between
the
requirements
that

are
set
by
the
policy
and
those
who
implement
the
solu)on.

•  Prefer
an
audi)ng
architecture
that
is
also
able
to
support
remedia)on
–
Enable

audits
to
not
only
define
and
enforce
policy,
but
also
helps
to
resolve
problems

that
are
iden)fied
through
audi)ng
ac)vi)es


Summary

•  Harden
your
database
environment

•  Understand
the
network
landscape
the
database
is
part
of

•  Implement
authen)ca)on
and
password
security
using
strong
passwords

and
password
proﬁle

•  Include
security
of
database
replica)on
environments

•  The
four
types
of
database
Trojans

•  Use
Encryp)on
of
data-‐in-‐transit
and
data-‐at-‐rest

•  The
need
for
regula)ons
and
requirements

•  Audi)ng
categories

•  Aspects
of
Audit
architecture


References

•  Implemen?ng
Database
Security
and
Audi?ng
–
Ron
Ben
Natan

•  Oracle®
Database
Advanced
Security
Administrator's
Guide

11g
Release
2
(11.2)


In
Closing
…

•  You
are
most
welcome
to
join
me
at
the
IBM
Booth
acer
this
session
to

discuss
this
presenta)on
or
your
speciﬁc
ques)ons
or
requirements

•  We’d
appreciate
if
you
can
complete
the
evalua)on
form
on
your
seat

and
deposit
in
the
box
at
the
IBM
Booth

….
you’ll
also
have
a
chance
to

win
one
of

iPads!

•  All
IBM
InSync
presenta)on
sessions
are
noted
in
the
ﬂyer
on
your
seat
to

help
plan
your
par)cipa)on
…
we’d
love
to
see
you
at
some
more
of
our

sessions!

•  Break
Free
at
our
next
IBM
event
…
see
the
invita)on
envelope
on
your

seat
for
details.


Database & Technology 1 _ Barbara Rabinowicz _ Database Security Methoda and Techniques.pdf

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Database & Technology 1 _ Barbara Rabinowicz _ Database Security Methoda and Techniques.pdf

Similar a Database & Technology 1 _ Barbara Rabinowicz _ Database Security Methoda and Techniques.pdf (20)

Más de InSync2011

Más de InSync2011 (20)

Database & Technology 1 _ Barbara Rabinowicz _ Database Security Methoda and Techniques.pdf