Data Security – Problems and
Approaches
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
Business Requirements for Data Security
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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?
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
Application Tier Approaches
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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 / nonadministrator access
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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?
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
Infrastructure Approaches
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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.
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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.
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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, EndUsers)
– 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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
Oracle Transparent Data Encryption
Data
Dictionary
Master Key
Encrypted
Table Key
Wallet(outside of
the Oracle
Database)
Decrypted
Decrypted
Table Key
Column1
<Clear Data>
<Clear Data>
Column2
<Encrypted Data>
<Encrypted Data>
Column 3
<Encrypted Data>
<Encrypted Data>
Column 4
<Clear Data>
<Clear Data>
Oracle Database
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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.
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
Oracle Advanced Security and Label Security
DoITT UNIX Oracle Shared Server Security Options
Various Applications i.e. Access NYC, City Share, Portal, GIS,
GEO, IW, Datashare, etc... that can utilize these security features
Clients
Clients
Clients
Oracle Advanced Security
Network Encryption
Cluster Servers
Oracle Advanced
Security
Transparent Data
Encryption
Based on Label
Security
Users will see the data
according to their
Security Level
Highly
Sensitive
Data
Classification
With
Oracle Label
Security
Sensitive
Public
User
Security
Clearance
Data Automatically
Decrypted Through
SQL Interface
Data Written To
Disk Automatically
Encrypted
Shared Disk
Storage
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
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.
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
Q&A
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017
Contact Information
IT Security:
Daniel Srebnick
[email protected]
(718) 403-8610
UNIX Oracle Databases:
Eugene Panicali
[email protected]
(718) 403-8602
Secure Applications:
Michael Hayes
[email protected]
(212) 232-1044
Cisco:
Richard Puckett
[email protected]
(919) 392-8203
Prepared by Dept. of Information Technology & Telecommunication, July 13, 2017