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

The most comprehensive Oracle applications & technology content under one roof The most comprehensive Oracle applications & technology content under one roof

• 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)fied for Oracle 10g -‐ April 2009 •  State president of the Victorian Oracle User Group •  Prac)ce Bikram Yoga 5 days a week


•  In 2001, Bibliofind, 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 financial

services reported “Incident of unauthorized access and data corrup)on”

Why Implement Database Security?


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 financial 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

•  Confirm the Oracle user owns all the files 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 file 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 profiles 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 file

–  _trace_files_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_file_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 difficult 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


•  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

Defense-‐in-‐depth


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 first

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 difficult to staff, 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 firewalls 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 confirm 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 firewall – 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 firewall 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 – 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

Authen)ca)on and password Security


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_prefix – 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 first Windows authen)ca)on, and if not possible fall back to na)ve authen)ca)on


•  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;

Sending passwords over the network


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/modifica)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 files 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 files –  Advance Queuing

•  All queues are stored within the database – no requirement to secure external files •  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 effec)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 effec)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 modifica)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 modifica)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 insufficient 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 files •  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 modifies 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


Sniffing 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 sniffers 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 specific 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 defined by its

configura)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 affect your backup, are

the backups encrypted? What happens if the keys are periodically changed

•  Clustering – How does the encryp)on affect 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 affect 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 configura)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 modifica)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 effects (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 financial

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 confiden)al informa)on does not leak from the database)


Audit changes to Audit defini)on •  An aXacker can either change the defini)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 files


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 profile •  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 specific 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 flyer 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

Documents

independent audit trail

audit architecture points

ple layers

ng ac

audit trail

ng system

failed logins

audit trails