Securing Big Data and the Grid

© Copyright 2013, Cardinal Health. All rights reserved. CARDINAL HEALTH, the Cardinal Health LOGO and
ESSENTIAL TO CARE are trademarks or registered trademarks of Cardinal Health.
Securing Big Data and the Grid
Dan Houser, CISSP-ISSAP-ISSMP CSSLP
@SecWonk
Principal Security & Identity Architect
24-Sept-2013

AGENDA
Drivers for Big Data
Cardboard Bicycles
Challenging the Status Quo
Cardinal Big Data Security Model
Access Model
Lessons Learned
2

Cardinal Health
30,000
plus employees
with direct
operations in 10
countries
60,000
sites delivered
to daily
3
*An estimate of the pro forma revenue for fiscal 2012 in accordance with generally accepted accounting principles
with adjustments expected to reflect each company as a stand-alone entity. The estimate is based on assumptions
that management currently believes are reasonable, but actual revenue may vary materially from the estimate.
Leading provider of products and services across the healthcare
supply chain with an extensive footprint across multiple channels
$108B
FY12 pro forma
revenue*
#21
on Fortune 500
list
86%
of hospitals in the
U.S. use our
products and
services

Essential purpose
We are more than 30,000 people applying our
deep understanding of healthcare to deliver inventive
and meaningful solutions that help improve the
cost-effectiveness and quality of healthcare so our
customers can focus on patients.
4

Essential role
We are the business behind healthcare
5

6
Hadoop Vision
Background
Cardinal Health is increasingly emphasizing the importance of advanced analytics
due to the financial benefits, competitive advantage and organizational effectiveness
enabled by the growing # of successes from our analytics initiatives.
Business Needs
To further advance Cardinal Health into a transformed company with analytics
prescribed actions*, increased ROI, reduced complexity, and improve our overall
efficiency, we need to optimize existing assets, accelerate adoption of learning
from existing success stories (and failures) and enable an affordable, scalable and
agile platform to meet business need of increased decision velocity as well as
trusted data attainability & usability.
* Transformed Company is defined in MIT/IBM Sloan 2012 research on Analytics as companies with rigorously data
driven decision making culture and with daily critical data insights and analytics prescribed actions

7
Hadoop Business Opportunity
• Provide the most cost effective capability to quickly react
to the changing business needs
• Leverage machine learning, pattern-recognition
capabilities across disparate datasets for deep data
analytics
• Support Cardinal Health’s Master Data Management plan
• Securely manage analytical data required for our clinical
analytics applications (including HIPAA data)

8
High-level Hadoop at Cardinal

Cardboard Bicycles
Our Hadoop architecture is radical, and based on the
premise of the Cardboard Bicycle
Innovative
Consumable IT
Low-cost
Zero-touch model
Image courtesy: Cardboard Technologies http://goo.gl/ztWvR

Internal use only
Criteria Conventional Hadoop
Fault Domain Server
(Toyota Camry)
Rack of servers
(Paper Bicycle)
Server repair Hours Days
Server Cost 19%
Storage Cost 3%
Cost/Analytical GB 1% of SAS 4% of Teradata
Performance Server Across Grid
Management Server Server Type
Admins/Server 100/1 1000/1
Uniqueness Every server unique All servers alike
Lifecycle 3 years Till it dies
Troubleshooting By Server (App) As a whole
Ability to Evolve Quarterly Daily (if needed)
Operating System Locally Installed Network Bootable In Memory
Unique Ideas

11
Risks & Mitigating Strategies
• Rapidly Evolving Open
Source Project
• Open model by default
• Massive data repository
• Inference can lead to
de-anonymization
• Data corruption
• Delayed adoption of new
features until vetted
• Data access controlled by
data owners group
• Adhoc access limited
• Not allowing any private,
HIPAA, or other controlled
data into the environment
without encryption/masking
• Creating replica of production
onto a backup cluster
Risk Mitigation

12
Hadoop Architecture

Access
Nodes
13
Role-based Access Model
• Segmented access control to access/ control/ data nodes
• Active Directory groups
• Secure groups for data segmentation where sensitive
• Vintella Authentication using Kerberos
• Access Nodes can talk to Control Nodes, Control Nodes can talk to Data Nodes, User
restricted to Access Layer
Datameer
Admin
Data
Nodes
Users
Power Users
AD
MySQL
Sqoop
Hive
Flume
Control
Nodes
Developers
Data Owners

14
Security Model
• EA and Hadoop project team have implemented world-class
Hadoop security model
• Host-based firewalls on control & data nodes
– Locked down using iptables
– Block connections from unauthorized hosts
• Gold-image boot for data nodes
– No persistent OS / config data - continuous fresh, secure image
– Ease of security patching

15
Security Model
• Segregated VLAN on dedicated network switches
• Supported open source via Hortonworks
• Backup environment for data integrity (not DR)
• Segregated Prod, Tek, Integration, Backup environments
• Transaction, security and event logging
• Host-based file integrity monitoring

16
Security Challenges
• Information Classification continues to be difficult for IT
and business teams, particularly when otherwise
innocuous data is made sensitive in context.
• Anonymization patterns emergent – differing patterns
applied in source repositories
• No enterprise-wide cryptographic solution providing
format-preserving or context encryption
• Detection & Prevention of de-anonymization is a
problem for the industry, and also for us
• Data Governance within Hadoop team going 100mph

ESSENTIAL TO CARE are trademarks or registered trademarks of Cardinal Health.17
Decision Tree
Start
1.0
Input in
Cleartext?
Y
1.1
Can it be
Redacted?
Y
1.1.1
Redact/scrub the
data
SSN:111-22-3333 Ê
xxx-xx-3333
1.2
Can it be
tokenized?
N
Y
1.2.1
Tokenize the Data
SSN:123-45-6789 Ê
987-31-4929
2.0
Output in
Cleartext?
1.3
Must encrypt
N
N
3.0
Does data always
remain encrypted?
N
Y
Y
3.1
No cryptography
needed for data at
rest
3.2
Need to decrypt
and encrypt
within solution
Go to 1.1
N
1.3.1
Is Data shared
Externally?
Y
1.3.1.1
Use File / Folder
Level Encryption
(e.g. PGP, PKZipAES)
N
4.0
Is all private data in the
solution protected?
Private Data Remains that requires additional protection solution(s) Continue Looping through until all data protected --- N
End
Y
1.3.2.1
Is the Private Data broadly
accessible to most
authorized users
Push Cryptography
out of Application
into infrastructure
stack
( file/volume/disk )
Y
1.3.2.2
Is Database-Level
Encryption
Available/supported by
Db Vendor?
1.3.2.3
Encrypt using
Database-Level
Encryption
(e.g. Oracle TDE,
MSSQL TDE)
Y
1.3.2.4
Is Volume Level
Encryption
Available?
N
1.3.2.5
Encrypt using
Volume-Level
Encryption
(e.g. Vormetric, efs,
Bitlocker)
Y
1.3.2.6
Is Hardware-based
Storage
Encryption
Available?
N
1.3.2.7
Encrypt using
Hardware-based
Storage Encryption
(e.g. encrypted hard
drives, SAN crypto)
Y
1.3.3.2
Is Integrated Database
Encryption Available (e.g.
Column-level encryption)
N
1.4
Application-based
Crypto
N
Y
1.3.2.11
Does the Private Data
comprise a large part of
the total database?
N
Y
1.3.2.12
Does the Private Data have
a high rate of update or
very-high rate of read?
Y
N
1.3.3.1
Must the Private Data be a
keyed or indexed field in a
database?
N
N
Y
1.3.3.3
Encrypt using Integrated
Database Encryption
(e.g. Column-Level
Encryption)
1.4.3
Encrypt using Application
based API (e.g. MS-CAPI)
1.4.1
Do all Application
Points support a SOA
model?
N
1.4.2
Is an API
available for the
Application?
Y
1.4.5
Custom Cryptography
1.4.4
Use/Create Encryption
Web Services/SOA
Model
1.3.2.2a
Is this a Batch Process? Y
N
Y
N
Decision Tree: Encryption of Data at RestDecision Tree: Encryption of Data at Rest Dan Houser 4/2/2013 ver3.2Dan Houser 4/2/2013 ver3.2
Cardinal Public – Internal Use OnlyCardinal Public – Internal Use Only
Preferences:
Eliminate
Reduce
Redact/ Scrub
Anonymize/De-Identify
Tokenize
Platform Encryption
SOA-based Encryption
API Encryption
Custom Encryption

Risk-based model to drive protection
Method Pros Cons
Eliminate
Copies
Permits data to be
deleted
Requires app
change
Scrub Data Minimizes private
data propagation
May constrain
business
Anonymize Protects privacy
while permitting
analytics
Impact to the
business
Tokenize Protects data without
schema change
Impact to the
business
Encrypt Most useful format Likely code
changes
18
Risk
Disruption
Has to map to realities of BigData analytics

Anonymize / De-Identify Segregation Model
Private Data without Identity is no longer Private*
Segregation Model:
1. Private Identity Data – Identity data which is itself
private – e.g. Social Security Number
2. Identity Data – Data to identify the subject of the
associated data – e.g. Name, Passport ID
3. Private Attributes – Data only sensitive when
associated with an identity – e.g. blood type
*Except in rare cases where the Law decides it’s private without Identity.
19

Tokenization Must Support Analytics
Transform private data into non-sensitive data
 Complete Tokenization
 Context Tokenization
20
Address Tokenized Address
1313 Mockingbird Ln 1234 Flurhtyto
1700 Pennsylvania Ave 810 Trivnignh
1411 N. Park Ave 0909 Sefpoijefiu
1313 Mockingbird Ln 1313 Flurhtyto
1700 Pennsylvania Ave 1700 Trivnignh
1411 N. Park Ave 1411 Sefpoijefiu
Note: Example only. Address is one of the 18 protected HIPAA ePHI identifiers.
For discussion purposes only.

Encryption Must Support Analytics
Transform private data into non-sensitive data
 Complete Encryption
 Context Encryption
21
1313 Mockingbird Ln A76a39daf6e83363372d326
1700 Pennsylvania Ave 9eeb8dc55d37388b18c12b4
1411 N. Park Ave 0f2ef91d336d38b4db3be54
1313 Mockingbird Ln 1313 1fe3f0301b6ef39343c
1700 Pennsylvania Ave 1700 4bf1ded189e438ce11f
1411 N. Park Ave 1411 6b39cba99a3d8c47921
Note: Example only. Address is one of the 18 protected HIPAA ePHI
identifiers. For discussion purposes only.

Lessons Learned: Information Classification
• Governance not able to keep pace with projects
– Analytics teams experiencing very rapid build-out
– Staffing model creates challenge
– Had to develop new checkpoints to match project pacing
• Gaps in knowledge based on context
– Name is always, obviously, privacy data
– When is IP address? Ship-to address? Payer Address?
• Education & Awareness Key
– HIPAA awareness training, particularly 18 ePHI fields
– Privacy awareness training
– Information Classification training

Lessons Learned: Data Governance
• Strategy relied on zero confidential data, but that didn’t
always map to reality.
• BigData wants all the data, Data Security would prefer
none is duplicated or copied, creating opposing goals
• Phased approach to data protection successful
• Cannot slow down the business and velocity of big
data analytics to revamp data governance, so data
governance velocity must match business imperatives

Application
24
• Ensure the right players are at the table: Legal, Privacy,
Compliance, Analytics team, Data Architect, Business Data
Owner, Data Steward, Security Architect, etc.
• Consider nimble approaches to governing and managing
the security models in BigData
• Don’t be afraid to challenge the status quo and take risks to
develop innovative solutions
• Sometimes you can do more with less, without sacrificing
security
• Get engaged with security, legal and architects day one

Q&A

Discuss…
• What is your top concern?
• What has been your experience?
• How are you addressing the access model in big data?
• Has a data stratification approach worked, or are you
relying on isolated environments?
• How has cloud integration effected ability to support
Big Data Security?

Securing Big Data and the Grid

More Related Content

What's hot (18)

Similar to Securing Big Data and the Grid (20)

More from Dan Houser (20)

Recently uploaded (20)

Securing Big Data and the Grid

Editor's Notes