Session S311342: Do you have a Database Security Plan? Roxana Bradescu Sr. Director, Database Security Oracle Noel Yuhanna Principal Analyst Forrester

Session S311342: Do you have a Database Security Plan?Roxana BradescuSr. Director, Database Security Oracle

Noel YuhannaPrincipal AnalystForrester Research

WithGuest Speaker:

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions.The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

Safe Harbor Statement

Oracle Confidential4

Agenda

• Introduction• Your Database Security Plan• Oracle Database Security Solutions• Q&A

5

Why Enterprises Need a Plan

Data Growing 3x Yearly

Data Security #1 Priority

Over 500M Data Records

Breached

Over 150 Global Data RegulationsInsiders Now

Pose Greatest Risk

2009 IT Security Budgets Flat or Reduced

6Entire contents © 2009 Forrester Research, Inc. All rights reserved.

Do You Have A Database Security Plan?

Noel YuhannaPrincipal AnalystForrester Research


Agenda

• Database Security Drivers And Trends

• Enterprise Database Security Strategy

• Building A Comprehensive Database Security Plan

• Recommendations


Database security drivers and trends

• Most organizations still have “gaps” in security approaches, especially in databases, leaving back-door open for attacks.

• Increasing sophisticated attacks seen and is likely to continue in near-future, with Internal threat remains high.

• Regulatory compliance pressure continues — PCI, SOX, HIPAA, GLBA, and EU, with many still behind.

• Security group becoming more prominent across industries – new Database Security Analyst role seen in large companies.

• Most organizations looking for a broader security framework, focusing on single vendor solutions that cover all bases.


75% of threats come from insiders60% of internal threats are undetected

Insider threats a concern:

1. External users2. Internal users3. Files/Web servers 4. Administrators/DBAs/developers5. Database vulnerability6. Data backup

Type of threat

Internal users Privileged users

ERP

Web server

Backups

App server

Loadbalancer

Databases

File serverF

irew

all File

server

External users

1

2

4

3

5

6

Databases remain vulnerable


Security measures taken by organizations are improving but most still behind


Database security challenges continue to grow

• Lack of understanding of business data/private data.

• Lack of understanding of what needs to be done and where to start.

• Lack of expertise in database security.

• No clear separation of duties – among security group, DBA and architects.

• Privileged users have access to all data

• Lack of strong security process and procedures

• Weak data security policies – inconsistent and ad-hoc

• Lack of resources and time spent on database security


Your Enterprise Database Security Strategy 2010


Three Key Pillars Essential For Any Enterprise Database Security

Information Security Policies & Standards

Common Database Security Policies & Standards

Regulatory Compliances – PCI, SOX, HIPAA, EU

Role Separation

Reporting

Foundation Preventive Detection

Aut

hent

icat

ion,

Aut

horiz

atio

nA

cces

s C

ontr

ol

Dis

cove

ry &

Cla

ssifi

catio

n

Ne

two

rk &

Da

ta-a

t-R

est

En

cryp

tion

Da

ta M

aski

ng

Pa

tch

Ma

nag

emen

t

Vu

lne

rab

ility

Ass

ess

men

t

Se

curi

ty M

on

itorin

g

Da

tab

ase

Aud

itin

g

Ch

ang

e M

ana

gem

ent

Availability


Foundation

Au

the

ntic

atio

n, A

uth

ori

zatio

nA

cce

ss C

ont

rol

Dis

cove

ry &

Cla

ssifi

catio

n

Pa

tch

Ma

nag

emen

t

Building a strong foundation is critical

• Discovery and classification

– Know your databases

• Authentication, Authorization and Access control

– Make the foundation as strong as possible..

• Patch management

– Other measures are not effective until patches are deployed


Preventive builds on top of the foundation

• Network and Data-at-rest Encryption

– Protects production databases

• Data masking

– Protects your non-production databases

• Change management

– Protects critical structures of your database

Preventive

Ne

two

rk &

Da

ta-a

t-R

est

En

cryp

tion

Da

ta M

aski

ng

Ch

ang

e M

ana

gem

ent


Detection completes your strategy

• Database auditing

– Alerts on data anomalies

• Security monitoring

– Defends against real-time threats

• Vulnerability assessment

– Checks integrity and configuration of your database

Detection

Vu

lne

rab

ility

Ass

ess

men

t

Se

curi

ty M

on

itorin

g

Da

tab

ase

Aud

itin

g


Policies, Role Separation and Availability are part of the Strategy

Information Security Policies & Standards

Common Database Security Policies & Standards

Regulatory Compliances – PCI, SOX, HIPAA, EU

Role Separation

Reporting

Foundation Preventive Detection

Aut

hent

icat

ion,

Aut

horiz

atio

nA

cces

s C

ontr

ol

Dis

cove

ry &

Cla

ssifi

catio

n

Ne

two

rk &

Da

ta-a

t-R

est

En

cryp

tion

Da

ta M

aski

ng

Pa

tch

Ma

nag

emen

t

Vu

lne

rab

ility

Ass

ess

men

t

Se

curi

ty M

on

itorin

g

Da

tab

ase

Aud

itin

g

Ch

ang

e M

ana

gem

ent

Availability


Taking Your Strategy Into Action:

Database Security Plan


Database security plan

“Although, most enterprises have a data security or information security

plan, but only 20 percent have a database security plan” – Forrester

Research


Top five reasons why most don’t have a database security plan

1. Most organizations don’t know how to create one - the content, structure or format.

2. Security group don’t have the expertise to build one.

3. DBAs don’t have the time.

4. Many organizations feel that data security plan alone is good enough, so why bother.

5. Many don’t have budget or resources available to build one.


Without a database security plan – you are running a high-risk environment!!

• Basic level database security is not good enough any more!

• Without a database security plan:

– Gaps are likely to exist, making your environment highly vulnerable

– Likely to spend more time and efforts on piecemeal approaches that creates inconsistent environment

– End-to-end security implementations are often weak.


Database security plan workflow

DatabaseSecurity

Plan

<Company>policies

DBA ManagerDSA, Security Officer

Data/InformationSecurity Policies

Database Environment

Compliances


Seven steps in building a successful database security plan

Step 1. Establishing a team Step 1. Establishing a team

Step 2. Understanding data security policies and compliances Step 2. Understanding data security policies and compliances

Step 3. Understanding your database environment Step 3. Understanding your database environment

Step 5. Training and accountability Step 5. Training and accountability

Step 6. Baseline and risk assessment Step 6. Baseline and risk assessment

Step 7. Refining security plan Step 7. Refining security plan

Step 4. Establishing security policies Step 4. Establishing security policies


Step 1. Establishing a team

• Without a team, security planning is likely to fail, since it requires collaboration amongst various roles and groups.

• The team should comprise of the following:

– Security: CISO or Security Director/Officer

– Database: DBA Manager or Data Management Manager

– Application: Apps Manager (optional)

– Architecture: Enterprise or Data Architect (optional)

– Infrastructure: Infrastructure or Systems Mgr (optional)


Step 2. Understanding data security policies and compliance requirements

• Organizations should leverage data security/information security policies to build a database security plan.

• Understand data security policies and only use those that are applicable to databases or your environment– such as changing passwords every quarterly.

• Understand the impact of various compliances such as PCI, HIPAA, GLBA, SOX and EU on databases, but act on all, not one at a time.

• Get security group involved in data security and compliance discussions.


Step 3. Understanding database environment – Discovery & Classification

• Understand which DBMSes and releases are deployed.

• Take a full inventory of all databases deployed including production and non-production - test, development, Q&A, staging, HA and DR.

• Understand platforms used by databases – Operating system, hardware and virtualized environments.

• Understand which databases contain sensitive data, classify them, based on classification policies.

• Classification categories: #1 – highly sensitive (E.g. credit card numbers), #2 sensitive (E.g. Names and addresses) and #3- not sensitive.


Step 4. Establishing security policies

• Develop security policies over time focusing on key areas such as:

– Authentication and Authorization

– Data access – users, privileged users and DBAs

– Database administration procedures

– Encryption and data masking

– Non-production database security

– Installations, upgrades and migrations

– Security patches

– Detecting and recovering from attacks

– Etc.


Security policies: Database backup

• Typical security policies for database backups for critical databases containing sensitive data would include:

– Backup procedure policy: How database backups should be taken? Who should take backups? What is the frequency of backups? How is the backup moved to tape? Where should the tapes be stored?

– Backup encryption policy: Which databases should be encrypted? And what are the levels of encryption to be used?

– Backup retention policy: How long should backups be stored? When and how should data on tapes be removed?


Security policies: Data-at-rest database encryption

• Typical security policies for database encryption for critical databases containing sensitive data would include:

– Keys management: How are keys generated? Where are the keys stored in the database or external – such as an appliance or file? How many keys are required? What encryption level is used?

– Approach: What encryption approach needs to be taken column-level, table-level, tablespace-level, or file-level? Which databases should implement encryption?


Security Policies: Data Masking

• Typical security policies for data masking for critical databases containing sensitive data would include:

– Approach: Extract mask and load (EML) or Extract load and mask (ELM) approach to take.

– Masking algorithm: What algorithm to use – shuffling, randomize, new data generation, increment, decrement, look-up, etc.

– Columns to mask: What category columns to mask?


Security Policies: Auditing

• Typical security policies for Auditing for critical databases containing sensitive data would include:

– Approach: How will the data be audited? What all things need to be audited? Frequency of auditing? Should logs be centralized in a repository?

– Databases: Which databases should be audited? Which columns, users, tables to audit?

– Reports: What reports to generate? Frequency? Alerts to be generated?


Step 5. Training and accountability

• All DBAs and privileged users that access critical databases should be given training on how to protect data and databases, and measures that are being taken in the database security plan to limit data access, restrict certain processes and other measures.

• Take suggestions from DBAs, developers, testers, and others on how to improve security.

• Individuals should be held accountable for any unauthorized usage or access.


Step 6. Establishing baseline with risk assessment

• Without baseline, its difficult to measure success or failure of your database security plan.

• Each of the security policies should have a threat level assigned – High, medium or low based depending on the assessment of the environment.

• Risk assessment should be performed on a regular basis – weekly or even daily for high-risk databases depending on the classification level.


Step 7. Refine database security plan on a regular basis

• Database security is an ongoing initiative not a one time process, it requires refining database security plan on a regular basis – monthly or quarterly to adapt to new technologies, compliances and business requirements.

• The database security team should meet on a regularly basis at least weekly if not more to determine risk levels, and improving database security policies and procedures.


Database Security Plan Template


Sample database security plan template• Executive Summary: Overview and vision.

• Team involved: List personnel involved

• Database classifications and alerts: How to classify them, alert levels, what data is sensitive..

• Database security policies: This is the core of the plan

• Risk Assessment and baseline: How to assess risk and develop a baseline, reporting and alerting.

• Recovering from attack: Process and procedures to follow

• Best practices: Typically not covered as a policy

• Exceptions: Override on security policy xxx based on approval from xxx


Typical database security policy template:

Policy: Database password change control• DSP control number:…. DSP 34…

• Ref number (Data/Info Security): IT849

• Date created:…..<date>….

• Data modified:…<date>

• Summary: ….. <info>

• Risk level: ….<High/Medium/Low>

• Implementation:

– Applies to Databases: …<certain groups/category>

– Approach to take: … <run script… or tool etc>

– Frequency to run: …. < daily, weekly…>

. . . . .


Security policy example:Policy: Database password change control

• DSP control # DSP 34… Ref #(Data/Info Security): IT849

• Date created: 8/1/2009 Data modified: 8/1/2009

• Description: All user passwords should be triggered to change every quarter, including administrator level passwords. This is a corporate level security requirement …..

• Risk level: Medium

• Implementation:

– Applies to Databases: All Category-1 databases on Oracle, SQL Server and DB2

– Approach to take: For Oracle, change parameter to trigger password change, to be done by DBA.

– Frequency to run: For every new account created, parameter needs to be set.’

– Assessment: Run weekly reports on Category-1 databases…


Recommendations

• Database security strategy is essential for all enterprises, start out with the foundation and build with preventive and detection layers.

• Start out building a database security plan with few polices, refining and expanding over time.

• Build enterprise-wide database security plan, not just for a department or region.

• Remember the best database security plan is one that’s unique, create one that’s relevant to your organization.

• Database security plan cannot be successful without security group being involved or without incorporating data security policies.


Thank you

Noel Yuhanna Principal AnalystForrester Research

Oracle Confidential 41

Oracle Database Security Solutions

Detection

• Advanced Security

• Secure Backup

• Data Masking

Encryption & Masking

Access Control

• Database Vault

• Label Security

Monitoring

• Configuration Management

• Audit Vault

• Total Recall

42

Oracle Advanced Security

• Efficient encryption of all application data

• Standard-based encryption for data in transit

• Standard-based encryption for data in transit

• No application changes required

DiskDisk

BackupsBackups

ExportsExports

Off-SiteFacilitiesOff-SiteFacilities

43

Oracle Data Masking

• Remove sensitive data from non-production databases

• Referential integrity preserved so applications continue to work

• Sensitive data never leaves the database

• Extensible template library and policies for automation

LAST_NAME SSN SALARY

ANSKEKSL 111—23-1111 60,000

BKJHHEIEDK 222-34-1345 40,000

LAST_NAME SSN SALARY

AGUILAR 203-33-3234 40,000

BENSON 323-22-2943 60,000

Production Non-Production

44

Oracle Database Vault

• Limit powers of privileged users – enforce Separation of Duties

• Enforce who, where, when, and how using rules and factors

• Protect application data by preventing application by-pass

• Out-of-the box policies for Oracle applications

Procurement

HR

Finance

Application

select * from finance.customers

DBA

Oracle Audit Vault

• Consolidate audit data into secure repository

• Detect and alert on suspicious activities

• Out-of-the box compliance reporting

• Centralized audit policy management

CRM Data

ERP Data

Databases

HR Data

Audit Data

Audit Data

PoliciesPolicies

Built-inReportsBuilt-inReports

AlertsAlerts

CustomReportsCustomReports

!

AuditorAuditor


Oracle Total Recall

select salary from emp AS OF TIMESTAMP

'02-MAY-09 12.00 AM‘ where emp.title = ‘admin’

• Transparently track data changes

• Efficient, tamper-resistant storage of archives

• Real-time access to historical data

• Simplified forensics and error correction


Oracle Configuration Management

• Database discovery

• Continuous scanning against 375+ best practices and industry standards, extensible

• Detect and prevent unauthorized configuration changes

• Change management compliance reports

Monitor

ConfigurationManagement

& Audit

VulnerabilityManagement

Fix

Analysis &Analytics

Prioritize

PolicyManagement

AssessClassify MonitorDiscover

AssetManagement


Oracle Solutions Key to Your Database Security Plan

• Comprehensive• Integrated• Transparent• Cost-Effective

Monitoring

Access Control

Encryption & Masking


Q&A

Oracle Database Security Learn More At These Oracle Sessions

S311340 Classify, Label, and Protect: Data Classification and Security with Oracle Label Security

Monday 14:30 - 15:30 Moscone South Room 307

S308113 Oracle Data Masking Pack: The Ultimate DBA Survival Tool in the Modern World

Tuesday 11:30 - 12:30 Moscone South Room 102

S311338 All About Data Security and Privacy: An Industry Panel Tuesday 13:00 - 14:00 Moscone South Room 103

S311455 Tips/Tricks for Auditing PeopleSoft and Oracle E-Business Suite Applications from the Database


S311339 Meet the Database Security Development Managers: Ask Your Questions


S311345 Database Auditing Demystified: The What, the How, and the Why


S311342 Do You Have a Database Security Plan? Wednesday 11:45 - 12:45 Moscone South Room 102

S311332 Encrypt Your Sensitive Data Transparently in 30 Minutes or Less

Wednesday 13:00 - 13:30 Moscone South Room 103

S311337 Secure Your Existing Application Transparently in 30 Minutes or Less

Wednesday 13:45 - 14:15 Moscone South Room 103

S311344 Securing Your Oracle Database: The Top 10 List Wednesday 17:00 - 18:00 Moscone South Room 308

S311343 Building an Application? Think Data Security First Thursday 13:30 - 14:30 Moscone South Room 104

For More Information

oracle.com/database/security

search.oracle.com

or

database securitydatabase security

Documents

Session S311342: Do you have a Database Security Plan? Roxana Bradescu Sr. Director, Database Security Oracle Noel Yuhanna Principal Analyst Forrester