Your database holds your company's most sensitive and important assets- your data. All those customers' personal details, credit card numbers, social security numbers- you can't afford leaving them vulnerable to any- outside or inside- breaches.
2. 2
• You will be on mute for the duration of the event
• We are now talking so please type a message
in the Questions box in the Control Panel if you can’t
hear us (please check your speakers and
GoToWebinar audio settings first)
• If you have questions during the session, please submit
them on the Q&A bar on your gotowebinar dashboard
and we will address them at the end
• A recording of the full webinar will be put up online
Before We Begin
8. 8
Your database holds your company's most
sensitive and important assets - your data!
Customer personal details, credit card numbers, social
security numbers- you can't afford leaving them vulnerable
to any- outside or inside- breaches.
9. 9
• Many Types
• Client / Patient / Credit Card
• Employee
• Intellectual Property
• At Risk
• Where is it?
• How many copies are targets?
• Are changes controlled?
Sensitive Data is a Major Asset
10. Internal and External Vulnerabilities
Non-Standard
SSL Traffic
10
Drive By Attacks
Watering
Hole Attacks
Bot Nets
Social Engineering
Attacks
Spear Phishing
11. 11
Where’s my Data ???
How does
the data
flow when it
is received
into the
environment
12. 12
• Dealing with Challenges from the inside…
• Controlling change process
• Knowing Who was making changes
• Audit & compliance
• Who should be allowed to make changes?
• Controlling roles & responsibilities
• => Deploying changes
Due Process
13. 13
• The database holds your essential information
• Any changes can impact the entire system
• Need to be synchronized with other changes
• Often overlooked
Database is a Key Component
14. 14
• Silos exist…
• Don’t always communicate effectively
• Need to share knowledge
• Need to follow same procedures & best
practices
Developers and DBAs
16. Breaches Happen
In the event of a breach, full cost to an organization
can include one or more of the following:
Notifying customers / patients,
Investigating and controlling the breach,
Potential litigation and fines,
Intangible costs associated with:
Damage to your brand,
Loss of customers,
Decline in value, and
Reputation Management
FULL
COST
of a
Breach
16
17. Sensitive Data Concerns
Industry regulations such as HIPAA, PCI
DSS, PIPEDA, DDP, GLBA, Safe Harbor and
corporate data governance standards
that require the protection of sensitive
data such as social security numbers,
personal, financial, and healthcare
information.
Many of these concerns become even
more challenging to address when
testing is outsourced to a third party.
18. Some Options…
Organizations have many, many copies of
data in different data stores around their
organization.
Each of these locations is a potential target
from external sources and needs to be
protected.
The Verizon Data Breach Study
recommends that organizations eliminate
unnecessary data.
Once you understand where your data is
you can determine if:
It is needed and controls are in place around it
It is needed at all and can be deleted
It is needed for test purposes, analytics or sharing
and should be masked
18
18
19. What is Data Masking?
Data masking is also known as data obfuscation,
data privacy, data redaction, data sanitization, data
scrambling, data deidentification, data anonymization
and data deauthentication.
Potential abusers, can be employees or employees
of outsourcing firms, such as users of test databases
(programmers, testers and database administrators)
or users of analytical and training databases
(analysts, researchers and trainees).
Masked data should be realistic and quasi-real so
that it can ensure that the application running against
masked data performs as if the masked data is real.
20. Data Masking and the Cloud
Replace sensitive data with fictitious but realistic data to facilitate
testing of analysis while eliminating the risk of exposure to
unauthorized parties in a multi-tenant environment.
21. Data Masking and Big Data
Mask Data in three scenarios:
1. While being fed into Big Data Repository
2. In the Big Data Repository using Map-Reduce techniques
3. As it is being fed from Big Data Repository
Data In Data Out
1 2 3
22. How Does DMsuite Mask Data?
Data Masking* — Replace sensitive data with fictitious but realistic data to
eliminate the risk of exposure to unauthorized parties.
The Axis DMsuite solution is completely automated and designed to be rapidly
implemented and institutionalized. Our unique approach is to break the association
between unique identifiers and personally identifiable data.
* Data Masking = redaction, de-identification, depersonalization, anonymization, obfuscation
23. Masked / De-Identified / Anonymized
Field Production Value Masked Value
First Name Christopher Romanth
Address 123 Stone Street 62 Main Street
Phone 703-891-2426 703-555-1287
Date of Birth 07/11/82 07/24/82
SSN 621-02-4579 805-23-1290
DMsuite masked values are
realistic but fictitious.
DMsuite does not store or
make copies of production
data.
You cannot use DMsuite to
view any production data.
24. DMsuite Masks
Applications
• Oracle E-
Business
• Salesforce
• PeopleSoft
• Trizetto
• SAP
• MS CRM
• Lawson
• AMISYS
Databases
•Oracle
•MSSQL
Server
•Informix
•DB2
•Teradata
•MS Access
•MySQL
•Netezza
•Cache
•Sybase
•Ingres
•Vertica
•Greenplum
•PostgreSQL
Files
• XML
• CVS
• Multi-
record
• Word
• Excel
• PPT
• RSS
• Un-
structured
• EDI
Mainframe
• DB2
• IMS
• ADABAS
• QSAM
• VSAM
Big Data
• Cloudera
• Hortonworks
• Hadoop
NoSQL
• MongoDB
• Cassandra
…and keeps referential integrity across all of them
25. What to Look for
Easy to Use
Ability to find Sensitive Data on databases
Automate Masking process
Referential Integrity Across Platforms
Map-Reduce capabilities
Role based access
Irreversible algorithms
No visibility to production data
Tokenization
No production data is persists outside of production environment
No staging environment is required to mask the data
26. DMsuite: Masked Data
Secure Your Data Easy To Use Any Data
• Instead of Prod data
• Realistic but fictitious
• Patented Algorithms
• Irreversible
• Regulatory compliance
(HIPAA, PCI DSS)
• Locate sensitive data
• Mask without programming
• Mask data in any language
• Nothing to install on your DBs
• Any OS, Virtual or Physical
• Interface: Web Services & CLI
• Private, Public or Hybrid Cloud
• In-Place or On-The-Fly
• Or create DBs then mask data
• ERP (SAP, PeopleSoft, EBS, e
• MSSQL, Oracle, etc.
• ASCII Files
• EBCDIC Files
• MS Office Files
• XML, EDI, X12
• Unstructured Data
• Big Data (Hadoop etc.)
• No SQL (MongoDB etc.)
28. 28
• Old adage but true
• The database is often neglected and therefore can
become the weakest link
• Essential from a compliance and business point of
view
• Ensure that changes are not made without
authorization
• Ensure no out-of-process changes
• Should be the strongest link
The Weakest Link In DevOps Chain
29. 29
Lets talk about Challenges…
“it was difficult to track who made a change to a database object and
what change they made.”
(working-around file based version control)
“it took hours to get releases working. some changes were not
documented and left out…”
(manual and error prone releases)
“We had multiple releases to production every day. That is one release
a week with multiple follow up fixes, and yet more fixes”
(code overrides, partial versions, wrong versions – all pushed to production)
“We recently had a disaster - the script in the version control was not
updated and when executed in production, ran the wrong revision. That
cost tens of thousands of $”
(an out-of-process update to QA that was not properly tracked)
30. 30
• Root Causes for issues:
• Manual script based version control process
• Lack of control – who was making changes
• Deployment tools making assumptions
• No release automation red-flags…
31. 31
• Challenges from the inside
• Controlling change process
• Who was making changes?
• Audit & compliance
• Who should be allowed to make changes?
• Controlling roles & responsibilities
• => Deploying changes
The need to follow Due Process
32. 32
Tracking change process
Version Control Process
(file based)
Development Process
Check-Out
Script
Modify Script
Get updated
Script from DB
Check-In
Script
Compile
Script
in DB
Debug Script
in DB
?
?
?
?
A
A’
33. 33
Scripts & Version Control
Challenges…
• Code-overrides
• Working on the wrong revisions
• Scripts do not always find their way to the version control solution
• Out of process updates go unnoticed
• Hard to locate outdated update scripts
Playing safe? what we really need:
• The actual code of the object
• The upgrade script
• A roll-back script
Scripts
• Hard to test in their entirely (holistically)
• Hard to test due to colliding dependencies
• Need to run in a specific order…
• Much harder to deal with project scope changes
35. 35
Due process benefits…
Integrated Database Version Control process
• Leverage proven version control best practices
• Forcing check in & out for changes
• Labels
• etc..
• No code-overrides
• Always working with the correct revision
• All changes are documented
• No out-of-process changes
• Correlate each database change with a change request
• Always know who did what, when, why and from where
• Supporting structure, code and content
No time spent on manual coding of the change scripts
39. 39
We need to leverage version control
into deployment decisions…
40. 40
1.11.21.31.41.51.61.7
Build & Deploy On Demand
*
Int QA Stage Prod
Database Deploy Script
Environment* Execute the same script
being executed at the
Stage environment
Re-Base (due to defects)
Dev
Dev
Dev
Model
1.1 1.2
1.2 1.3
1.3 1.4
1.4 1.5
1.5 1.6
1.6 1.7
1.1 1.4
1.4 1.7
1.1.1 1.7
1.1 1.1 1.11.41.7
File Based
Version Control
Out of Process
Change
1.1.11.7 1.1.11.7
42. Safety Net For Deployment Automation
Source vs.
Target
Action
= No Action
≠
?
Source vs.
Baseline
Target vs.
Baseline
Action
= = No Action
≠ = Deploy Changes
= ≠ Protect Target
≠ ≠ Merge Changes
You do not have all
of the information
With Baselines and 3 way
analysis the unknown is
now known
Simple Compare & Sync Baseline aware Analysis
43. 43
Deploying Changes if Needed
Development Baseline
Previous Label /
Production Golden Copy
Production
If we had the index in the baseline =>
we should take it down from production…
(Deploy Change)
44. 44
Or Protecting Target Environment…
Development Baseline
Previous Label /
Production Golden Copy
Production
BUT… If no index in baseline =>
we should protect the NEW index on production!!!
(Protect Target)
47. 47
Safety Net For Deployment Automation
Database Safe Deployment Automation:
• Leverages version control (baselines & previous revisions)
• Has a flexible scope (deploy multi schema to single task or work item)
• Can be run as a batch process (repeatable & consistent)
• Integrates to ALM (labels, CRs, Continuous Integration & Delivery)
• Deals with conflicts & merges to match code agility
Can raise red flags to stop the line…
if requires human intervention
48. Summary - What is DBmaestro TeamWork?
• Database Enforced Change Management solution
+ Database version control
+ Enforce best practices
+ Plugs into the ALM (change request, tickets & work items)
+ Database merge & change impact analysis
+ Know who can do what, where, when & why
• DevOps Solution for databases
+ Baseline aware deployment automation, rollback &
recovery
+ Reduce database deployment issues
+ Plugs into release management & Continuous Delivery