Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Protect your Database with Data Masking & Enforced Version Control

1,743 views

Published on

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.

Published in: Technology
  • Be the first to comment

Protect your Database with Data Masking & Enforced Version Control

  1. 1. Protect your Database With Data Masking & Enforced Change Processes Joseph Santangelo & Yaniv Yehuda
  2. 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
  3. 3. 3 Presenters Joseph Santangelo • SVP Sr. Security Consultant at DMsuite
  4. 4. 4 Presenters Yaniv Yehuda • CTO, Co-Founder at DBmaestro
  5. 5. About DMsuiteR • Axis Technology Founded in 2000 • DMsuite launched in 2005 • Headquarters in Boston
  6. 6. About DBmaestro • Founded in 2008, product launched in 2010 • Founded by Yariv Tabac and Yaniv Yehuda • Headquartered in Israel, Global Operations
  7. 7. 7 Protect your Database With Data Masking & Enforced Change Processes
  8. 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. 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. 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. 11 Where’s my Data ??? How does the data flow when it is received into the environment
  12. 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. 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. 14 • Silos exist… • Don’t always communicate effectively • Need to share knowledge • Need to follow same procedures & best practices Developers and DBAs
  15. 15. 15 Attacks are on the Rise !
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.)
  27. 27. AUTOMATE PRIVACY DATA MASKING / DE-IDENTIFICATION
  28. 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. 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. 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. 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. 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. 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
  34. 34. 34 Enforced Change Process
  35. 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
  36. 36. 36 Detailed log
  37. 37. 37 Audit & compliance Who? What? When? why?
  38. 38. 38 Controlling Roles & Responsibilities
  39. 39. 39 We need to leverage version control into deployment decisions…
  40. 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
  41. 41. 41 Simple Compare & Sync Safe to automate? No. Requires manual inspection…
  42. 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. 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. 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)
  45. 45. 45 Conflict Resolving – Database Code
  46. 46. 46 Impact Analysis not damage control...
  47. 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. 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
  49. 49. 49 Q & A

×