prepared by dept. of information technology & telecommunication, june 2, 2015 data security –...

Prepared by Dept. of Information Technology & Telecommunication, April 18, 2023

Data Security – Problems and Approaches


DoITT Overview

DoITT introduction• Daniel Srebnick – DoITT – Chief Information Security Officer,

Associate Commissioner, IT Security

Presenters• Michael Hayes – DoITT - Program Manager, Secure

Applications• Eugene Panicali – DoITT - Oracle Database Manager, UNIX

Systems

• Richard Puckett – Cisco - Manager of IT Security, Global Information Security Group


Business Requirements for Data Security


What Data Needs to be Protected?

• Include Security Requirements in your SDLC– All initiatives should explicitly deal with security issues

– For systems that deal with confidential or sensitive information, consider a security assessment

• Start with data classification– Business owners of the data are responsible for this step

– What kinds of data are managed in the system?

• Public

• Internal

• City-Confidential

• Constituent / Business Confidential

– Are there any legal or regulatory requirements associated with any of these data

• Are you collecting / storing any personally identifiable information (PII)?

• Are there any breach notification requirements?


From Whom / What does the Data Need to be Protected?

• Who should have access to the data, and under what circumstances? – Authorized users– Authorized external systems– Production support, system administrators

• Who should not? – Developers– Unauthorized users– Unauthenticated users– Outsiders

• How should the data be protected as it enters and resides in your system?– Data transport– Storage– Backup


Weigh Approaches for Data Security

• Transport– SSL vs clear text; between browser & web server,

and/or across tiers

• Application Tier– Secure development practices always important

• See the OWASP Guide for details– Encryption at this layer can be done

• High risk• May not scale well

• Database / Storage– Various levels of protection available– Can be more or less “transparent” to applications


Application Tier Approaches


Design Principles

• Design for least privilege and to avoid privilege escalation– If possible, use separate applications and database

schemas to enforce access control. Lesser privilege apps should use lesser privilege database user accounts. Examples:

• Create separate administration and end user applications, each using separate schemas. Minimize touch-points between apps / dbs

• User separate apps / dbs for systems with both public facing and internal user components

– Require applications to run under non-root / non-administrator access


Secure Development Practices

• Tie user sessions to their specific data– Avoid generic user accounts – always prefer named

user accounts for web applications– Forcible browsing and parameter tampering can allow

users access to other information. This is not always intentional or malicious

• Prevent SQL injection attacks– Where possible, prefer stored procedures or prepared

statements.– If you must pass user input into queries, employ

rigorous type checking on user inputs– O/R mapping frameworks (e.g., Hibernate) can

reduce exposure to SQL injection, but are not wholly sufficient


Proceed with CAUTION: Application Tier Encryption

• Some situations may warrant application tier encryption implementations– Where infrastructure solutions are unavailable– When trusted roles managing the infrastructure are

unacceptable

• Options:– Sun JCE, MSCAPI– Database vendor libraries, e.g., Oracle Obfuscation

Toolkit


Application Tier Encryption Issues

• Encryption at the application tier is difficult:– Implementation of encryption algorithms requires a

good deal of knowledge & expertise– Key handling is critical

• How are the encryption / decryption keys handled?• If stored in the application or database, how are

they protected?• If using external certificates:

– How are users provisioned with certs?– How do users present the certs to the app?

• If using password based encryption (PBE):– How is password recovery handled?– Can you ensure strong enough passwords?


COIB Example

• COIB’s Electronic Financial Disclosures required application level encryption– In process filings use PBE

• Users were encouraged to select strong passwords, but for a usability tradeoff we only enforce 8 chars w/ mix of alpha & numeric

• Passwords backed up doubly encrypted to allow for password reset

– Completed filings use Public Key Cryptography– Upcoming reporting phase adds infrastructure data

security controls to allow for querying an analysis


Infrastructure Approaches


Database Security Topics

• DoITT’s UNIX Oracle Database Security Environment

• Database security aspects of the Access NYC project

• General Database Security Setup/Guidelines

• Reasons for Data Encryption

• Oracle Transparent Data Encryption(TDE)

• Oracle Label Security with VPD

• Oracle Data Vault


DoITT’s UNIX Oracle Database Security Environment

• One of our goals is make information available to other city agencies as well as to the public. The challenge we face is to ensure that the data is secure.

• Our Oracle Database Security Environment is administered through the use of database security roles, application and web security interfaces including firewalls. We make use of access control lists to further protect our environment.

• We use Netbackup encryption to encrypt database backups for sensitive data as needed.

• We are deploying Oracle Advanced Security Option for encryption over the wire and Oracle Label Security Option for our Access NYC project and as needed for other database applications.


Database Security Aspects of the Access NYC Project

• The Access NYC System works with very sensitive data provided by citizens requesting NYC services. As a result it has security requirements that need to be provided and we are using and deploying a number of Oracle Security products to do this:

1. Oracle Advanced Security for network and database encryption from the application server to the database server is currently deployed. Oracle advanced security encrypts data “on-the-wire” when leaving the database server (Oracle*Net Server) and decrypts data “off-the-wire” when arriving at the client application server(Oracle*Net Client).

2. Oracle Label security built on the Virtual private database to prevent outside access to internal data.

3. Oracle Advanced Security Encryption/Decryption of data when inserted/updated/selected from the database. We are looking at the approach of using this software to address the data encryption needs of the organization at an Enterprise level with the plan to use it for the Access NYC System project first and the possibility of using it for future project needs on the Shared UNIX Server Environment.


General Database Security Setup/Guidelines – part 1

• Set up Oracle accounts and change all default passwords• Define Roles/Responsibilities to manage authorizations to access

data• Ensure that only the required access and privileges are granted• Limit Database Administrator privileges as appropriate• Periodically review user accounts and remove accounts no longer in

use• Secure executables by using prepared SQL Statements to prevent

SQL Injection vulnerability• When stored procedures are used they should be called by

prepared statements to prevent SQL Injection vulnerability• Ensure that error messages are generic and do not include any

sensitive information that can be used to breach security


General Database Security Setup/Guidelines – part 2

• Run penetration testing against the database to ensure the environment is secure.

• Review all database security patches and apply as appropriate.

• Monitor listener log for attempted break-ins - simple scripts can be written to do this.

• Audit user access to sensitive data - be careful to measure the system overhead with any approach as it will affect performance. It can be turned on and off as necessary.

• Work on different techniques to remove passwords from batch scripts. If a solution to remove them is not apparent they can be set up in such a way as to prevent intruders from accessing them. Use the dbms_scheduler in Oracle 10g to avoid using passwords.

Oracle DB Security Reference Information: DB Security "Best Practices":

http://www.oracle.com/technology/pub/articles/project_lockdown/index.html


Reasons for Data Encryption

• Protect Data At-Rest– Prevent unauthorized viewing of data due to accident or intentional

miss-use

– Prevent data access from unauthorized Internal users (DBAs, End-Users)

– Prevent data access from unauthorized External Hackers

• Protect Data In-Transit– Data “on-the-wire” is just as easily (or more easily compromised) than

data on disk

– More than 70% of all Data Theft is internal

– Encryption is only 1 mechanism

– Proper Authentication, Authorization, & Audit Controls are also critical elements of Information Assurance


Oracle Transparent Data Encryption (with 10gR2)

• Introduced with Oracle 10gR2

• Additional AES Key Lengths (128, 192, 256 bit)

• Additional Data Types (All except binary_*, LOB, Objects)

• Automatic Key Management

• DB Master Key Stored in Oracle Wallet

• Applied with simple command

• ALTER TABLE xxx modify (attrib_y encrypt)

• All DML automatically encrypted during insert/update

• SELECT statements automatically decrypted

• Attribute Encryption Preserved in Backup

• No changes necessary to application

• Licensed with Oracle Advanced Security Option


Oracle Transparent Data Encryption

Oracle Database

Column1<Clear Data><Clear Data>

Column2<Encrypted Data><Encrypted Data>

Column 3<Encrypted Data><Encrypted Data>

Column 4<Clear Data><Clear Data>

Data

Dictionary

Encrypted

Table Key

Decrypted Table Key

Decrypted

Master Key

Wallet(outside of

the Oracle

Database)


Oracle Label Security with VPD

• Oracle Label Security built on the Virtual Private Database platform provides the ability to customize label-based access control policies to ensure that customers see only the data they are authorized to see.

• With Label Security a VPD database can be deployed transparently on the database and does not require application changes. It comes with a data dictionary and administrative tools.

• As an example data can be labeled for “opt out” provisions for users who do

not want their data to be used for marketing campaigns.


Oracle Advanced Security and Label Security

ClientsClients Clients

Oracle Advanced SecurityNetwork Encryption

Data Written To Disk Automatically Encrypted Data Automatically

Decrypted Through SQL Interface

Oracle Advanced

Security Transparent Data

Encryption

Storage Group

Shared Disk Storage

DoITT UNIX Oracle Shared Server Security Options

Cluster Servers

Highly Sensitive Sensitive Public

Data Classification

With Oracle Label

Security

User Security

Clearance

Based on Label Security

Users will see the data according to their

Security Level

Various Applications i.e. Access NYC, City Share, Portal, GIS, GEO, IW, Datashare, etc... that can utilize these security features


Oracle Data Vault

• Data Vault - Oracle’s new product is designed to be configured to restrict Database Administrators and other privileged users from accessing application data thereby preventing insider threats.

• Allows ability for a DBA to administer/maintain a database without the ability to access the data.

• Provides better controls over who, when, and where a database application can be accessed.


Q & A


Contact Information

IT Security:Daniel [email protected](718) 403-8610

UNIX Oracle Databases:Eugene [email protected](718) 403-8602

Secure Applications: Michael [email protected](212) 232-1044

Cisco:Richard [email protected](919) 392-8203

prepared by dept. of information technology & telecommunication, june 2, 2015 data security –...

Documents

data security slide

data security problems

security requirements

sensitive information

kinds of data

data needs

security assessment

security issues