ISACA - How Innovation can Bridge
the Gap between Privacy and
Regulations

Ulf Mattsson, CTO
Protegrity
ulf.mattsson AT pr...
Ulf Mattsson, CTO Protegrity
• 20 years with IBM
– Research & Development & Global Services
• Inventor
– Encryption, Token...
3
Bridging the gap between
privacy and regulations
Threats and regulations are
changing
How are international
regulations changing?
My Data used to be under
my control in my computer
within in my organization
My Data is NOT under my
control and NOT in my
computer and NOT within in
my organization
My Data is NOT under my
control and NOT in my
computer and NOT within in
my organization and NOT in
a known country/locati...
My Data is NOT known

My Data is NOT in a known
server/node/location
My Data is NOT in a
compliant country
My Data can be compliant to
international regulations
The Evolution of
Data Security
Methods
14
Evolution of Data Security Methods
• Coarse Grained Security
– Access Controls
– Volume Encryption
– File Encryption

• Fi...
Use of Enabling Technologies
Access controls

1%

Database activity monitoring

18%

Database encryption

30%

Backup / Ar...
Access Control
Risk

High –
Old and flawed:
Minimal access
levels so people
can only carry
out their jobs

Low –

17

I
Lo...
Applying the protection profile to
the content of data fields allows
for a wider range of authority
options

18
How the New Approach is Different
Risk

High –
Old:
Minimal access
levels – Least
Privilege to avoid
high risks

Low –

19...
Reduction of Pain with New Protection Techniques
Pain
& TCO
High

Input Value: 3872 3789 1620 3675

Strong Encryption Outp...
Fine Grained Security: Encryption of Fields
Production Systems

Encryption of fields
• Reversible
• Policy Control (author...
Fine Grained Security: Masking of Fields

Production Systems

Non-Production Systems

22

Masking of fields
• Not reversib...
Fine Grained Security: Tokenization of
Fields
Production Systems
Tokenization (Pseudonymization)
• No Complex Key Manageme...
Fine Grained Data Security Methods
Tokenization and Encryption are Different
Encryption

Used Approach
Cryptographic algor...
Fine Grained Data Security Methods
Vault-based vs. Vaultless Tokenization

Vault-based Tokenization

Vaultless Tokenizatio...
The Future of Tokenization
• PCI DSS 3.0
– Split knowledge and dual control

• PCI SSC Tokenization Task Force
– Tokenizat...
Security of Different Protection Methods
Security Level
High

Low

I

I

I

Basic

Format

AES CBC

Vaultless

Data

Prese...
Speed of Different Protection Methods
Transactions per second*
10 000 000 1 000 000 100 000 10 000 1 000 -

100 -

I

I

I...
Risk Adjusted Data Protection
There is always a trade-off between security and usability.
Data Security Methods

Performan...
Data
De-Identification

30
What is de-identification of identifiable
data?
• The solution to protecting Identifiable data is to properly deidentify i...
Identifiable Sensitive Information
Field

Real Data

Tokenized / Pseudonymized

Name

Joe Smith

csu wusoj

Address

100 M...
De-Identified Sensitive Data
Field

Real Data

Tokenized / Pseudonymized

Name

Joe Smith

csu wusoj

Address

100 Main St...
How Should I Secure Different Data?
Use
Case

Tokenization
of Fields

Encryption
of Files

Simple –

Card
Holder
Data

PII...
Research Brief
Tokenization Gets Traction

• Aberdeen has seen a steady increase in
enterprise use of tokenization for
pro...
Vaultless Tokenization & Data Insight
• The business intelligence exposed through Vaultless
Tokenization can allow many us...
Use Cases for
Coarse & Fine
Grained Security
37
Off-shoring &
Outsourcing
Privacy Impacts BPO & Offshore Business Solutions
• Business Process Outsourcing (BPO)
– Business Processes
• E.g. Loans, ...
Examples
• Major Bank in EU wants to centralise EDW
operations in a single country and therefore
send customer data from c...
Case Studies
Protegrity Use Case: UniCredit

CHALLENGES
The primary challenge was to protect PII – names and addresses, phone and email...
Case Study - Large US Chain Store
Reduced cost
50 % shorter PCI audit

Quick deployment
Minimal application changes

98 % ...
Case Study: Large Chain Store
Why? Reduce compliance cost by 50%
– 50 million Credit Cards, 700 million daily transactions...
Protegrity Summary
Proven enterprise data security
software and innovation leader
–
–

Sole focus on the protection of dat...
Please contact us for more information

Ulf.Mattsson@protegrity.com
Info@protegrity.com
Isaca   how innovation can bridge the gap between privacy and regulations
Upcoming SlideShare
Loading in …5
×

Isaca how innovation can bridge the gap between privacy and regulations

532 views

Published on

ISACA presentation on how Innovation can Bridge the Gap between Privacy and Regulations - HIPAA, PCI, Privacy Laws in different countries

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
532
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 20 years with IBM Research & Development & Global Services Inventor of patents - Encryption, Tokenization & Intrusion PreventionMember ofPCI Security Standards Council (PCI SSC)American National Standards Institute (ANSI) X9Encryption & TokenizationInternational Federation for Information ProcessingIFIP WG 11.3 Data and Application SecurityNYOUG, ISACA , ISSA and Cloud Security Alliance (CSA)
  • I added material fromMy article in ISACA JournalPresentation at the NA CACS in Orlando next weekeSymposium presentationMy view isTo address emerging and evolving IT Risk is to look atYour Data FlowChoosing the most appropriate data security solutions for an organization Understanding your options and strategies86 000 members in 160 countries
  • Least Privilege - Separation of Duties In any organization that requires the storage and use of sensitive data for operational functions, there will always be a tug of war between access and security.  In some cases, there may be difficulties in being unable to tell what information would be required to perform specific job functions, or being afraid of not giving employees enough information to do their jobs.  While some operating systems such as Windows or Linux now provide simpler privilege management for access controls, they are not an ideal overall solution for large, complicated organization structures.  The “all-or-nothing” security of access controls can create numerous problems in day to day operations, including roadblocks to benign data that happens to be stored next to highly sensitive data.  In many cases, this approach leads to granting unnecessary privileges beyond what the user actually needs to do their job. 40 "Risk management" is just another term for the cost-benefit tradeoff associated with any security decision.Protecting data according to risk enables organizations to determine their most significantsecurity exposures, target their budgets towards addressing the most critical issues,strengthen their security and compliance profile, and achieve the right balance betweenbusiness needs and security demands. As discussed earlier, a report by the Ponemon Institute, a privacy andinformation management research firm, found that data breach incidents cost $202 per compromisedrecord in 2008, with an average total per-incident costs of $6.65 million.All security spend figures produced by government and private research firms indicate that enterprisescan put strong security into place for about 10% the average cost of a breach. You can find the rightbalance between cost and security by doing a risk analysis.
  • One solution to this problem is utilizing fine-grained data security, such as encryption, masking, or tokenization.  Applying security to the data fields themselves allows for a wider range of authority options and levels than typical access controls.  Users without privileges to access sensitive data can still access non-sensitive data to perform job functions, even in files or tables that contain a mixture of both.  More flexible options, such as some forms of masking or tokenization, can also provide different levels of security that either generalize the data or expose certain parts of sensitive data without revealing it completely.However, these fine-grained data security options also require proper privilege management.  Step one in this process is usually assigning a security-specific role or team in the organization, if they don’t already have one.  Isolating security policy administration to a security team can provide a separation of duties between users or system administrators from security privilege assignments.  The security team must develop a comprehensive data security policy, preferably one that can be centrally managed and administrated across the enterprise, in line with the needs and expectations of the operations of the business, and the roles contained therein.  Often the simpler way of assigning policy privileges, or authority to access sensitive data, is by specifying the few people who have access, rather than those who don’t.  Finding a data security vendor that can provide easy policy management with push-button configuration can go a long way to assisting you in implementing this process.  
  • But obviously, there needs to be some sort of security.  The old adage, “it’s better to have it and not need it, than need it and not have it” applies well, in the sense that you are better off securing your data beyond requirements and adjusting if needed, than applying too little and being compromised before you can do anything about it.  The damage is limited when one person needs to request privileges to get at data, but could be massive if someone is abusing data without limitation.
  • Reduction of Pain with New Protection Techniques. Some security approach products might restricting functionality, or compromise essential big data characteristics, like search and analytics.A good solution should address a security threat to big data environments or data stored within the cluster
  • What are the key characteristics of encryption, tokenization and masking and how the can be used in production and test /dev?Encryption of fieldsReversiblePolicy Control (authorized / Unauthorized Access)Lacks Integration TransparencyComplex Key ManagementExample !@#$%a^.,mhu7///&*B()_+!@
  • What are the key characteristics of masking?Masking of fieldsNot reversibleNo Policy, Everyone can access the dataIntegrates TransparentlyNo Complex Key ManagementExample 0389 3778 3652 0038
  • What are the key characteristics of tokenization?No Complex Key ManagementBusiness IntelligenceProduction systemsReversible Policy Control (Authorized / Unauthorized Access)Test / devNot ReversibleIntegrates Transparently
  • PCI DSS 3.0 Change Highlights as a preview of the new version of the standards coming in November 2013.The changes will help companies make PCI DSS part of their business-as-usual activities by introducing more flexibility, and an increased focus on education, awareness and security as a shared responsibility.Changes to the standards are made based on feedback from the Council's global constituents per the PCI DSS and PA-DSS development lifecycle and in response to market needs. Key drivers for version 3.0 updates include: lack of education and awareness; weak passwords and authentication challenges; third party security challenges; slow self-detection in response to malware and other threats; inconsistency in assessments.Although the chip and pin standard for smart card payments has been good in driving down face-to-face fraud, it has begun to creep up again in the past year, said Jeremy King, European director of the PCI  Security Standards Council (PCI SSC), which administers the security standard.“The criminals are still stealing [card payment] terminals and inserting malware and card skimmers into them,” he said.In response, requirement 9 of version 3.0 of the PCI DSS has additional requirements for merchants to train staff around device security and to be able to identify and prevent terminal tampering.“We have also seen a lot of security breaches because of poor password use or poor password security,” said King.Version 3.0 consequently introduces additional requirements for training around passwords to help people in the retail industry realise why good security practices matter and how to choose and use good passwords.“We are also allowing merchants to use pass phrases instead of a password to try and improve security, but at the same time make it easier to remember without sticking notes on to the computer screen,” said King.In terms of the standard, version 3.0 includes several new sub-requirements for assessors to check the awareness of employees within an organisation and require merchants to produce records of security awareness training programmes.What about security as a shared responsibility?“Although PCI DSS involves a lot of IT and IT input, it is not only a job for the IT director. It does need the buy-in from everybody in the organisation,” said King.“If we can get the C-level staff involved and understand that this is a change of mind set, that will help improve the overall security,” he said.Merchants, especially those in e-commerce, are increasingly using the services of a third-party provider, and King said this can lead to a lack of understanding about who is responsible for what.As a result, V3.0 of the PCI DSS has improved requirements around ensuring that when merchants use a third-party provider, they understand what they should expect in terms of security and what individual responsibilities are to help improve overall security of payment card data.King said it is important to have a clear understanding of the responsibilities of the third-party provider and the merchant.“Although the payment page is being hosted by the third-party, and the merchant should not have any card holder data coming into their system, we are still seeing instances where criminals target the interface between the merchant and third-party provider to get to the data,” he said.How is version 3.0 more flexible from a merchant’s point of view?MORE ON PCI DSSPCI DSS review: Assessing the PCI standard nine years laterPodcast: What’s new in PCI-DSS and PA-DSS version 3.0?Using encryption technology to achieve PCI DSS compliance objectivesUnderstanding the PCI DSS prioritized approach to complianceCan predefined DLP rules help prevent HIPAA and PCI DSS violations?PCI DSS 3.0 preview highlights passwords, providers, payment data flowPCI validation: Requirements for merchants covered by PCI DSSAnalysis: Inside the new PCI DSS risk assessmentThe requirements have been improved, said King, to get away from PCI compliance being a tick box exercise to promoting understanding of the need to do proper risk assessments to help merchants prioritise what to tackle by identifying their own biggest risks and threats.“There is increased flexibility, for example, in allowing merchants to use pass phrases instead of passwords, and in allowing merchant to choose – in the event of a breach – how they manage the review of system logs to identify where the criminal came in or where the criminal activity took place,” he said.Where will merchants see the biggest changes from version 2.0 to version 3.0?The evolution of the standard from one version to the next is gradual, so there are never any major adjustments to be made, said King.“The demand has been for a lot more guidance and support in understanding the requirements, so in version 3.0 we have incorporated the previously separate guidance document into the requirements as an extra column to explain in more detail what is meant and required,” he said.Tackling weak passwords and improving security practices with third-party suppliers, said King, are the areas that most organisations will have to pay more attention to as they work to comply with version 3.0.Other challenging areas include the increased use of employee-owned devices in the workplace and new technology.“Organisations have to understand what this means in terms of securing their environment,” he said.Here, the changes in version 3.0 are aimed at ensuring that employee devices are segmented away from the card holder data environment.“Mobile data and mobile commerce is another key area we are working on for future iterations of the standard,” said King.For more than a year, the PCI SCC has had a task force working with relevant industry experts and organisations to understand how to secure mobile phones, particularly for accepting payments.While there are no requirements around mobile commerce in version 3.0, if merchants are using a mobile phone to accept payments, that device is part of the card holder data environment and must meet the requirements of the PCI DSS.Therefore, to help merchants and developers learn how to use mobile devices in a secure way, the PCI SCC has published separate guidance documents.According to King, version 3.0 is up to date with the latest trends in attacks because it has been compiled with input from penetration testing suppliers.Also, those suppliers now have a role to play in verifying that merchants have included all of their systems that touch payment card information.“In the past we have allowed merchants to set the scope of their payment environment, but we have seen cases where payment information is on more systems than the merchant has declared,” said King.By extending the range of penetration testing required, version 3.0 will mean more work, but that is going to be a positive in supporting what merchants claim in their submissions, he said.The update is also aimed at providing support and guidance in areas that are perennial security risks such as SQL injection, weak passwords and slow detection of breaches.Is version 3.0 clearer and easier to use?“Having the guidance as part of the standard to explain each of the requirements will be a huge help in ensuring that merchants and assessors have the same understanding of what each requirement means, which is one of the key areas of improvement in version 3.0,” said King.Most of the work in version 3.0, he said, was in looking at each requirement and how it could be reworded to make it easier to understand and implement, so little should come as a shock.Above all, he said, organisations should aim to make PCI DSS as part of business as usual because the standard provides the best set of requirements and processes for protecting data.
  • Example of Speed of Different Protection Methods (depend on configuration). Many vendors claim to offer big data security, but really just the same products they offer for other back-office systems and relational databases. Those Those products might function in a big data cluster by restricting performance. Security controls should be architecturally and environmentally consistent with the cluster architecture — not in conflict with the essential characteristics. It should scale in the same manner as the cluster.
  • Risk Adjusted Data Protection means that you should protect data based on the risk of the sensitive data. Risk can be assessed by acknowledging the value of the data (is the data valuable to the bad guys) and its exposure. So, valuable data that is widely exposed should be protected with strong protection like Strong encryption or tokenization while data that may have little or no value to the bad guys that is also widely exposed can be protected with a reduced protection approach like monitoring without encryption or Format Controlling Encryption.This chart shows several approaches to protect sensitive data along with a set of criteria that we have found useful when comparing the merits of each method.Performance is self describing, storage refers to the impact that a method has on storage. For example, strong encryption will require adding padding to the crypto text so that the final data will be larger than the original. When a data store is billions of records this can have an impact on the cost of the solution. Some methods are considered more secure than others. Format Controlling Encryption and Strong Encryption are both encryption approaches but FCE is not NIST approved and so it’s security properties are less secure than strong encryption. Some compliance requirements may require a method that is NIST approved. Finally, transparency refers to the degree to which a protection method effects systems and processes. A protection method that is not transparent will require remediation to systems that are being protected. This could translate to higher protection costs. Tokenization has been gaining popularity due to it’s high transparent characteristics that are seen to reduce protection costs.I then select one or two protection methods and mention something about them;Strong encryption and tokenization provide extreme protection while FCE, due to it’s non NIST approval and it’s performance issues may have limited use. (this is a landmine for Voltage that can be mentioned explicitly or implicitly – depending on the audience and the prospect)
  • De-identification is severing the link between the data and the person it relates to.Operational UseMonetization to 3rd parties (retailers, research, etc.)
  • Typical record holding identifiable data associated with Financial or Healthcare data, although in this example, we have healthcare data.This slide and the next are the basis for further mixing up the protection methods introduced in the previous slide. I use tokenization as a means of morphing into different forms of protection. In the next slide, I talk about specific examples of something called aggregation and masking.This is all part of the way I introduce tokenization to people who have never heard of it.
  • After tokenization, the identifiable data has been de-identified. Notice the red parts of the token that represent business intelligence that has been bled through from the original clear text data.As an example of the use of tokenization to deliver reversible de-identified data or masked (not reversible), let’s look at the address. Cant show the red here since this is a slide note so I placed it in brackets.Original: 100 Main Street, Pleasantville, CA Tokenized exposing the state: 476 srtacoetse, cysieondusbak, [CA]Token made into a mask by removing the token and only showing the state: CAIn the mask case, you lose information and you cant get back to the original address. You may want to use this when sending data to 3rd parties as part of de-identified data.
  • What are the key characteristics of encryption, tokenization and masking and how the can be used in production and test /dev?Encryption of fieldsReversiblePolicy Control (authorized / Unauthorized Access)Lacks Integration TransparencyComplex Key ManagementExample !@#$%a^.,mhu7///&*B()_+!@
  • Isaca how innovation can bridge the gap between privacy and regulations

    1. 1. ISACA - How Innovation can Bridge the Gap between Privacy and Regulations Ulf Mattsson, CTO Protegrity ulf.mattsson AT protegrity.com
    2. 2. Ulf Mattsson, CTO Protegrity • 20 years with IBM – Research & Development & Global Services • Inventor – Encryption, Tokenization & Intrusion Prevention • Involvement – PCI Security Standards Council (PCI SSC) – American National Standards Institute (ANSI) X9 • Encryption & Tokenization – International Federation for Information Processing • IFIP WG 11.3 Data and Application Security – ISACA New York Metro chapter 2
    3. 3. 3
    4. 4. Bridging the gap between privacy and regulations
    5. 5. Threats and regulations are changing
    6. 6. How are international regulations changing?
    7. 7. My Data used to be under my control in my computer within in my organization
    8. 8. My Data is NOT under my control and NOT in my computer and NOT within in my organization
    9. 9. My Data is NOT under my control and NOT in my computer and NOT within in my organization and NOT in a known country/location
    10. 10. My Data is NOT known My Data is NOT in a known server/node/location
    11. 11. My Data is NOT in a compliant country
    12. 12. My Data can be compliant to international regulations
    13. 13. The Evolution of Data Security Methods 14
    14. 14. Evolution of Data Security Methods • Coarse Grained Security – Access Controls – Volume Encryption – File Encryption • Fine Grained Security – – – – – 15 Access Controls Field Encryption (AES & ) Masking Tokenization Vaultless Tokenization Time
    15. 15. Use of Enabling Technologies Access controls 1% Database activity monitoring 18% Database encryption 30% Backup / Archive encryption 21% Data masking 28% 28% Application-level encryption 7% 29% Tokenization 22% 91% 47% 35% 39% 23% Evaluating 16
    16. 16. Access Control Risk High – Old and flawed: Minimal access levels so people can only carry out their jobs Low – 17 I Low I High Access Privilege Level
    17. 17. Applying the protection profile to the content of data fields allows for a wider range of authority options 18
    18. 18. How the New Approach is Different Risk High – Old: Minimal access levels – Least Privilege to avoid high risks Low – 19 I Low New: Much greater flexibility and lower risk in data accessibility I High Access Privilege Level
    19. 19. Reduction of Pain with New Protection Techniques Pain & TCO High Input Value: 3872 3789 1620 3675 Strong Encryption Output: !@#$%a^.,mhu7///&*B()_+!@ AES, 3DES Format Preserving Encryption DTP, FPE 8278 2789 2990 2789 Format Preserving Vault-based Tokenization 8278 2789 2990 2789 Greatly reduced Key Management Vaultless Tokenization Low No Vault 1970 20 2000 2005 2010 8278 2789 2990 2789
    20. 20. Fine Grained Security: Encryption of Fields Production Systems Encryption of fields • Reversible • Policy Control (authorized / Unauthorized Access) • Lacks Integration Transparency • Complex Key Management • Example: !@#$%a^.,mhu7///&*B()_+!@ Non-Production Systems 21
    21. 21. Fine Grained Security: Masking of Fields Production Systems Non-Production Systems 22 Masking of fields • Not reversible • No Policy, Everyone can access the data • Integrates Transparently • No Complex Key Management • Example: 0389 3778 3652 0038
    22. 22. Fine Grained Security: Tokenization of Fields Production Systems Tokenization (Pseudonymization) • No Complex Key Management • Business Intelligence • Example: 0389 3778 3652 0038 • Reversible • Policy Control (Authorized / Unauthorized Acces • Not Reversible • Integrates Transparently Non-Production Systems 23
    23. 23. Fine Grained Data Security Methods Tokenization and Encryption are Different Encryption Used Approach Cryptographic algorithms Cryptographic keys Code books Index tokens Source: McGraw-HILL ENCYPLOPEDIA OF SCIENCE & TECHNOLOGY 24 Tokenization Cipher System Code System
    24. 24. Fine Grained Data Security Methods Vault-based vs. Vaultless Tokenization Vault-based Tokenization Vaultless Tokenization Footprint Large, Expanding. Small, Static. High Availability, Disaster Recovery Complex, expensive replication required. No replication required. Distribution Practically impossible to distribute geographically. Easy to deploy at different geographically distributed locations. Reliability Prone to collisions. No collisions. Performance, Latency, and Scalability Will adversely impact performance & scalability. Little or no latency. Fastest industry tokenization. 25
    25. 25. The Future of Tokenization • PCI DSS 3.0 – Split knowledge and dual control • PCI SSC Tokenization Task Force – Tokenization and use of HSM • Card Brands – Visa, MC, AMEX … – Tokens with control vectors • ANSI X9 – Tokenization and use of HSM 26
    26. 26. Security of Different Protection Methods Security Level High Low I I I Basic Format AES CBC Vaultless Data Preserving Encryption Data Tokenization 27 I Encryption Standard Tokenization
    27. 27. Speed of Different Protection Methods Transactions per second* 10 000 000 1 000 000 100 000 10 000 1 000 - 100 - I I I I Vault-based Format AES CBC Vaultless Data Preserving Encryption Data Tokenization Encryption Standard Tokenization *: Speed will depend on the configuration 28
    28. 28. Risk Adjusted Data Protection There is always a trade-off between security and usability. Data Security Methods Performance Storage Security Transparency System without data protection Monitoring + Blocking + Obfuscation Data Type Preservation Encryption Strong Encryption Vaultless Tokenization Hashing Anonymisation Worst 29 Best
    29. 29. Data De-Identification 30
    30. 30. What is de-identification of identifiable data? • The solution to protecting Identifiable data is to properly deidentify it. Personally Identifiable Information Health Information / Financial Information Personally Identifiable Information  Health Information / Financial Information • Redact the information – remove it. • The identifiable portion of the record is de-identified with any number of protection methods such as masking, tokenization, encryption, redacting (removed), etc. • The method used will depend on your use case and the reason that you are de-identifying the data. 31
    31. 31. Identifiable Sensitive Information Field Real Data Tokenized / Pseudonymized Name Joe Smith csu wusoj Address 100 Main Street, Pleasantville, CA 476 srta coetse, cysieondusbak, CA Date of Birth 12/25/1966 01/02/1966 Telephone 760-278-3389 760-389-2289 E-Mail Address joe.smith@surferdude.org eoe.nwuer@beusorpdqo.org SSN 076-39-2778 937-28-3390 CC Number 3678 2289 3907 3378 3846 2290 3371 3378 Business URL www.surferdude.com www.sheyinctao.com Fingerprint Encrypted Photo Encrypted X-Ray Encrypted Healthcare / Financial Services 32 Dr. visits, prescriptions, hospital stays and discharges, clinical, billing, etc. Financial Services Consumer Products and activities Protection methods can be equally applied to the actual healthcare data, but not needed with de-identification
    32. 32. De-Identified Sensitive Data Field Real Data Tokenized / Pseudonymized Name Joe Smith csu wusoj Address 100 Main Street, Pleasantville, CA 476 srta coetse, cysieondusbak, CA Date of Birth 12/25/1966 01/02/1966 Telephone 760-278-3389 760-389-2289 E-Mail Address joe.smith@surferdude.org eoe.nwuer@beusorpdqo.org SSN 076-39-2778 076-28-3390 CC Number 3678 2289 3907 3378 3846 2290 3371 3378 Business URL www.surferdude.com www.sheyinctao.com Fingerprint Encrypted Photo Encrypted X-Ray Encrypted Healthcare / Financial Services 33 Dr. visits, prescriptions, hospital stays and discharges, clinical, billing, etc. Financial Services Consumer Products and activities Protection methods can be equally applied to the actual data, but not needed with deidentification
    33. 33. How Should I Secure Different Data? Use Case Tokenization of Fields Encryption of Files Simple – Card Holder Data PII PCI Personally Identifiable Information Complex – I Un-structured 34 Protected Health Information PHI I Structured Type of Data
    34. 34. Research Brief Tokenization Gets Traction • Aberdeen has seen a steady increase in enterprise use of tokenization for protecting sensitive data over encryption • Nearly half of the respondents (47%) are currently using tokenization for something other than cardholder data • Over the last 12 months, tokenization users had 50% fewer security-related incidents than tokenization non-users 35 Author: Derek Brink, VP and Research Fellow, IT Security and IT GRC
    35. 35. Vaultless Tokenization & Data Insight • The business intelligence exposed through Vaultless Tokenization can allow many users and processes to perform job functions on protected data • Extreme flexibility in data de-identification can allow responsible data monetization • Data remains secure throughout data flows, and can maintain a one-to-one relationship with the original data for analytic processes 36
    36. 36. Use Cases for Coarse & Fine Grained Security 37
    37. 37. Off-shoring & Outsourcing
    38. 38. Privacy Impacts BPO & Offshore Business Solutions • Business Process Outsourcing (BPO) – Business Processes • E.g. Loans, Mortgages, Call Centre, Claims Processing, ERP, etc. – Application Development • Need to de-identify Data for Testing and Development • Off-Shoring – Same as Outsourcing, but data is sent for business functions (like call center, etc.) off-shore. • Laws governing your ability to send real data to 3rd parties are already restrictive, and becoming more so • Penalties for infringement are growing more severe • Risk of data breaches and data theft is increased 39
    39. 39. Examples • Major Bank in EU wants to centralise EDW operations in a single country and therefore send customer data from country A to country B. Privacy Laws in country A prohibit this. • Private Bank in Europe wants to offshore Finance Operations. Privacy Law prohibits transfer of citizen data to India. • Retail Bank in Scandinavia wants to offshore Customer Services. Privacy law prevents transfer of citizen data to the Far East. 40
    40. 40. Case Studies
    41. 41. Protegrity Use Case: UniCredit CHALLENGES The primary challenge was to protect PII – names and addresses, phone and email, policy and account numbers, birth dates, etc. – to the satisfaction of EU Cross Border Data Security requirements. This included incoming source data from various European banking entities, and existing data within those systems, which would be consolidated at the Italian HQ.
    42. 42. Case Study - Large US Chain Store Reduced cost 50 % shorter PCI audit Quick deployment Minimal application changes 98 % application transparent Top performance Performance better than encryption Stronger security 43
    43. 43. Case Study: Large Chain Store Why? Reduce compliance cost by 50% – 50 million Credit Cards, 700 million daily transactions – Performance Challenge: 30 days with Basic to 90 minutes with Vaultless Tokenization – End-to-End Tokens: Started with the D/W and expanding to stores – Lower maintenance cost – don’t have to apply all 12 requirements – Better security – able to eliminate several business and daily reports – Quick deployment • Minimal application changes • 98 % application transparent 44
    44. 44. Protegrity Summary Proven enterprise data security software and innovation leader – – Sole focus on the protection of data Patented Technology, Continuing to Drive Innovation Cross-industry applicability – – – – – 45 Retail, Hospitality, Travel and Transportation Financial Services, Insurance, Banking Healthcare Telecommunications, Media and Entertainment Manufacturing and Government
    45. 45. Please contact us for more information Ulf.Mattsson@protegrity.com Info@protegrity.com

    ×