Secure Software Design for Data Privacy

Secure Software Design
For Data Privacy
Narudom Roongsiriwong, CISSP
OWASP Thailand Chapter Meeting, July 25, 2019

WhoAmI
● Lazy Blogger
– Japan, Security, FOSS, Politics, Christian
– http://narudomr.blogspot.com
● Information Security since 1995
● Web Application Development since 1998
● SVP, Head of IT Security, Kiatnakin Bank PLC (KKP)
● Committee Member, Thailand Banking Sector CERT (TB-CERT)
● Consultant, OWASP Thailand Chapter
● Committee Member, Cloud Security Alliance (CSA), Thailand Chapter
● Committee Member, National Digital ID Project, Technical Team
● Contact: narudom@owasp.org

How can we survive from dataHow can we survive from data
protection regulation’s penaltiesprotection regulation’s penalties
if your systems are compromisedif your systems are compromised
or data are breached?or data are breached?

Privacy By Design
The 7 Foundational Principles
● Proactive not Reactive; Preventative not Remedial
● Privacy as the Default
● Privacy Embedded into Design
● Full Functionality – Positive-Sum, not Zero-Sum
● End-to-End Security – Lifecycle Protection
● Visibility and Transparency
● Respect for User Privacy
Source: Privacy By Design – The 7 Foundational Principles, Ann Cavoukian, Ph.D. ,
Information & Privacy Commissioner, Ontario, Canada

Data Privacy Ground Rules
● If you don’t need it, don’t collect it.
● If you need to collect it for processing only, collect it only
after you have informed the user that you are collecting their
information and they have consented, but don’t store it
● If you have the need to collect it for processing and storage,
then collect it, with user consent, and store it only for an
explicit retention period that is compliant with organizational
policy and/or regulatory requirements
● If you have the need to collect it and store it, then don’t
archive it, if the data has outlived its usefulness and there is
no retention requirement.

Fundamental Security Concepts
Design
Core
Confidentiality Integrity Availability
Authentication Authorization Accountability
Authentication Authorization AccountabilityNeed to Know Least Privilege
Separation of
Duties
Defense in Depth
Fail Safe /
Fail Secure
Economy of
Mechanisms
Complete
Mediation
Open Design
Least Common
Mechanisms
Psychological
Acceptability
Weakest Link
Leveraging Existing
Components

Security in Privacy Design
Design
Core
Confidentiality IntegrityIntegrity Availability
Authentication Authorization Accountability
Authentication Authorization AccountabilityNeed to Know Least Privilege
Separation of
Duties
Defense in Depth
Fail Safe /
Fail Secure
Economy of
Mechanisms
Complete
Mediation
Open Design
Least Common
Mechanisms
Psychological
Acceptability
Weakest Link
Leveraging Existing
Components

Privacy vs Integrity
● In most of data protection acts (such as GDPR) said that
“organizations must take necessary and reasonable steps to
ensure the accuracy of personal data collected from data
subjects”
● Some privacy design approaches using referential integrity
across datasets
● But some privacy design approaches using data distortion
techniques
● Conclusion
– Data as “Source of Truth” → Integrity is a must
– Data in use → Integrity depends on utility

Confidentiality Controls for Data Privacy
Types of Confidentiality Controls
Secret Writing
Confidentiality
Control
Masking
Overt
Covert
Encryption
Hashing
Steganography
Digital
Watermarking

Real World Cryptography Implementation
● Cryptographic algorithms and parameters
– Symmetric: 3DES, AES / Asymmetric: RSA, ECC
– Key size
– Padding
– Symmetric algorithm specific parameters
● Mode: ECB, CBC, CFB, etc.
● Initialization Vector (IV) / Starting Variable (SV) / Nonce
● Key controls and key management
● Key change/exchange procedures
● Cryptographic toolkits
● Random number/seed generators

● Condenses arbitrary
message to fixed size
– h = H(M)
● Usually assume hash
function is public
● Hash used to detect
changes to message
● Well-know hash functions:
MD5, SHA-1, SHA-2
Hashing

● Role-based access control
● Separation of duties
● Least privilege
Authorization Design for Data Privacy

● Log data should include the who, what, where, and when
aspects of software operations
● Design decisions to retain, archive, and dispose logs should
not contradict external regulatory or internal retention
requirements.
● Sensitive data (direct and/or indirect identifiers) should never
be logged in plaintext form
● Automatically log the authenticated principal and system
timestamp
Accountability Design for Data Privacy:
Audit/Logging

Design Principle for Privacy: Need To Know
● Need to know limits information access to the information that an
individual requires to carry out his or her job responsibilities
(business needs)
● When access to covered data is broader than what is required for
legitimate purposes, there is unnecessary risk of an attacker gaining
access to the data

“Need to Know” Implementation
Name Address Phone
Jim Demetriou 4290 Cheval Circle, Stow, OH 44224 330-805-4211
Gary Furlong 24 Steeple Drive, Hillsborough, NJ 08844 908-359-1754
Maria Herring 8096 Wild Lemon Lane, Manlius, NY 13104 315-682-4453
John Sacksteder 2480 Pendower Lane, Keswick, VA 22947 240-994-6728
John Mantel 23 College Street, South Hadley, MA 01075 413-532-5562
Dan Okray W1748 Circle Drive, Sullivan, WI 53178 262-593-5004
● Which attributes these groups of people need or not need to
know?
– Outbound telesales
– Marketing researchers on geographic analysis
– Direct mail marketers

Design Principle for Privacy: Least Privilege
● When designing access controls, each user or system
component should be allocated the minimum privilege
required to perform an action for the minimum amount of
time
● To limit damage that can be caused by an accident, error, or
unauthorized act
● Benefits of the principle include:
– Better system stability
– Better system security
– Ease of deployment

24
“Least Privilege” Implementation
● Ensure that only a minimal set of users have
root/administrator/sa/sysadmin access
● Unless a permission is granted explicitly, the user or process
should not be able to access the protected resource.
● For data protection regulations, only those who need access
to certain data are allowed to have it, otherwise, it should be
totally secured from other internal people within the
business

● The concept of having more
than one person required to
complete a task.
● Primary objective the
prevention of fraud and
errors
● The requirement of two
signatures on a cheque.
Design Principle for Privacy: Separation of Duties

● Identification of a requirement (or change request); e.g. a
business person
● Authorization and approval; e.g. an IT governance board or
manager
● Design and development; e.g. a developer
● Review, inspection and approval; e.g. another developer or
architect.
● Implementation in production; typically a software change or
system administrator.
“Separation of Duties” Implementation

Terminology
● Data Attribute:
– Data field, data column or variable, an information that can be found across the data records in
a data set
● Dataset:
– A set of data records, conceptually similar to a table in a conventional database or spreadsheet,
having records (rows) and attributes (columns)
● Direct Identifier:
– A data attribute that on its own identifies an individual (e.g. fingerprint) or has been assigned to
an individual (e.g. Citizen ID)
● Indirect identifier or Quasi-Identifiers:
– A data attribute that, by itself/on its own, does not identify an individual, but may identify an
individual when combined with other information
● De-identification:
– The process used to prevent someone's personal identity from being revealed
● Re-identification:
– Identifying a person from an anonymized dataset

Link to
A Visual Guide to Practical Data De-Identification
https://fpf.org/wp-content/uploads/2016/04/FPF_Visual-Guide-to-Practical-Data-DeID.pdf

Source: A Visual Guide to Practical Data De-Identification, Future of Privacy Forum

Practical Data De-Identification (1/2)

Practical Data De-Identification (2/2)

Pseudonymization (1/2)
● Decoupling identifiable data from the dataset, usually by
means of identifier key references
● Pseudonym (aka Token) may represent one or more
attributes
● Pseudonyms can be
– Reversible (by the owner(s) of the original data), where the
original values are securely kept but can be retrieved and
linked back to the pseudonyms
– Irreversible, where the original values are properly disposed
and the pseudonymization was done in a non-repeatable
fashion

Pseudonymization (2/2)
● Pseudonyms persistence
– Persistent – Same pseudonym values represent the same
individual across different datasets
– Non-persistent – Different pseudonyms represent the same
individual in different datasets to prevent linking of the
different datasets
● Pseudonyms generation
– Random (Ex. UUID, GUID)
– Deterministic (Ex. Hashing, Encryption, PCI DSS Tokenization)

Pseudonymization – Example#1 (1/2)
Before Anomymization:
Name Address Phone
Name Address Phone
LAU5B90A 4290 Cheval Circle, Stow, OH 44224 330-805-4211
1YXHL5K0 24 Steeple Drive, Hillsborough, NJ 08844 908-359-1754
KOTACI4U 8096 Wild Lemon Lane, Manlius, NY 13104 315-682-4453
SDM1VHX3 2480 Pendower Lane, Keswick, VA 22947 240-994-6728
UJQXYU27 23 College Street, South Hadley, MA 01075 413-532-5562
9NG6Y5VF W1748 Circle Drive, Sullivan, WI 53178 262-593-5004
After Pseudonymizing the Name Attribute:

Pseudonymization – Example#1 (2/2)
Identity Database
Pseudonym Name
LAU5B90A Jim Demetriou
1YXHL5K0 Gary Furlong
KOTACI4U Maria Herring
SDM1VHX3 John Sacksteder
UJQXYU27 John Mantel
9NG6Y5VF Dan Okray

Pseudonymization – Example#2
Identity
Non-Identifiable Data
Full Data
First Name: Narudom
Last Name: Roongsiriwong
Age: 18
Gender: Male
Nationality: Thai
Blood Type: O
Occupation: Engineer
+
First Name: Narudom
Last Name: Roongsiriwong
Age: 18
Gender: Male
Nationality: Thai
Blood Type: O
Occupation: Engineer
=

Pseudonymization Guideline
● When to use
– Data values need to be unique and no need to keep original attribute
● How to use:
– Replace the respective attribute values with made up values
– The made up values should be unique, and should have no relationship to the original
values
● Tips
– Do not use running numbers as pseudonym
– This should be a key part of your Privacy by Design strategy
– Ensure not to re-use pseudonyms that have already been utilized
– Persistent pseudonyms are usually better for maintaining referential integrity across data
sets
– For reversible pseudonyms, the mapping tables or functions or secret encryption keys
should be securely kept and can only be used by the organization

Data Anonymization
● Anonymization is the process of removing private
information from the data
● Anonymized data cannot be linked to any one individual
account

What You Need to Aware of Anonymization
● Purpose of anonymization and its utility
● Characteristics of each anonymization techniques
● Inferred information after implementation
● Expertise with the subject matter
● Competency in anonymization process and techniques
● Recipients

Anonymization Techniques
Character Masking
Anonymization
Suppression
Attribute Suppression
Generalization
Modification
Swapping or Shuffling
Perturbation
Others
Data Synthetic
Data Aggregation
Recoding
Record Suppression

Attribute Suppression
Name Address Phone
Name Phone
Jim Demetriou 330-805-4211
Gary Furlong 908-359-1754
Maria Herring 315-682-4453
John Sacksteder 240-994-6728
John Mantel 413-532-5562
Dan Okray 262-593-5004
After Suppressing the “Address” Attribute:
The removal of an entire part of data (“column” in database) in a data set.

Attribute Suppression Guideline
● When to use
– That attribute is not required in the anonymized dataset, or when the
attribute cannot otherwise be suitably anonymized with another technique
● How to use:
– Delete (e.g. remove) the attribute(s), not hiding
– If the structure of the data set needs to be maintained, clear the data (and
possibly the header)
● Tips
– This is the strongest type of anonymization technique, because there is no
way of recovering any information from such an attribute
– Less sensitive derived attribute may be create to suppress the original
attribute(s). E.g. “Usage Duration” attribute base on “Check-In” and ‘Check-
Out” date and time attributes

Record Suppression
● The removal of an entire record in a data set
Name Address Phone
3BRYAYN8 Highlands Farm Woodchurch, Ashford, TN26 3RJ 2087726222
3O7T78EZ St Elizabeths, Much Hadham, SG10 6EW 2083435600
3WVYDLCN 10 Downing St, Westminster, London SW1A 2AA 1322341162
6SSC98FX Hermitage Court, Hermitage, Kent, ME16 9NT 2086887666
9CSYE673 Grimsby Road, Cleethorpes, North East Lincolnshire, DN35 7LB 1908262860
9DIHFAQ9 14 High Street, Brompton, Gillingham, ME7 5AE 2089440110
Can anyone guess
who should this person be?

Secure Software Design for Data Privacy

Record Suppression Guideline
● When to use
– The records are so unique and outliers can lead to easy re-
identification
● How to use:
– Delete the entire record, not just row hiding
● Tips
– The removal of a record can impact the data set such as for
statistical analysis

Character Masking
● The change of the characters of a data
value, e.g. by using a constant symbol
(e.g. “*” or “x”)
● Masking is typically partial, i.e. applied
only to some characters in the attribute

Character Masking Guideline
● When to use
– The data value is a string of characters and hiding some part is
sufficient to provide anonymity
● How to use:
– Replace the appropriate characters with a chosen symbol
● Fixed number of characters (e.g. for credit card numbers)
● Variable number of characters (e.g. for email address)
● Tips
– Subject matter knowledge of each data type to be mask is
needed to ensure the right characters are masked
– The data owners are meant to recognize their own data

Recoding
● A deliberate reduction in the precision of data
● Example:
– Converting a person’s age into an age range
– Converting a precise location into a less precise location

Recoding – Example
Name Address Phone
LAU5B90A 4290 Cheval Circle, Stow, OH 44224 330-805-4211
1YXHL5K0 24 Steeple Drive, Hillsborough, NJ 08844 908-359-1754
KOTACI4U 8096 Wild Lemon Lane, Manlius, NY 13104 315-682-4453
SDM1VHX3 2480 Pendower Lane, Keswick, VA 22947 240-994-6728
UJQXYU27 23 College Street, South Hadley, MA 01075 413-532-5562
9NG6Y5VF W1748 Circle Drive, Sullivan, WI 53178 262-593-5004
After Recoding the Address Attribute:
Name Address Phone
LAU5B90A Stow, OH 330-805-4211
1YXHL5K0 Hillsborough, NJ 908-359-1754
KOTACI4U Manlius, NY 315-682-4453
SDM1VHX3 Keswick, VA 240-994-6728
UJQXYU27 South Hadley, MA 413-532-5562
9NG6Y5VF Sullivan, WI 262-593-5004

Recoding Guideline
● When to use
– The data values that can be recoded and still be useful for the
intended purpose
● How to use:
– Design appropriate data categories and rules for translating data.
– Consider suppressing any records that still stand out after the
translation (see record suppression)
● Tips
– Design the data ranges with appropriate sizes
● Too large data range may cause the data too much modification
● Too small data range may be easy to re-identify

Shuffling
● Rearranging data in the data set where the individual
attribute values are still represented in the data set, but
generally, do not correspond to the original records

Shuffling – Example
Name Address Phone
After Shuffling:
Name Address Phone
Jim Demetriou 23 College Street, South Hadley, MA 01075 262-593-5004
Gary Furlong 2480 Pendower Lane, Keswick, VA 22947 315-682-4453
Maria Herring 24 Steeple Drive, Hillsborough, NJ 08844 413-532-5562
John Sacksteder 8096 Wild Lemon Lane, Manlius, NY 13104 908-359-1754
John Mantel W1748 Circle Drive, Sullivan, WI 53178 330-805-4211
Dan Okray 4290 Cheval Circle, Stow, OH 44224 240-994-6728

Shuffling Guideline
● When to use
– Subsequent analysis only needs to look at aggregated data and
there is no need for analysis of relationships between
attributes at the record level
● How to use:
– Identify which attributes to shuffle then shuffle or reassign the
attribute values to any record in the data set
● Tips
– Assess and decide which attributes need to be shuffled

Perturbation
● The value modification from the original data set in order to
be slightly different
● Two main techniques
– Probability distribution: data replacement from the same
distribution sample or from the distribution itself
– Value distortion: modification by multiplicative or additive
noise, or other randomized processes (more effective)

Perturbation – Example
Person Height (cm) Weight (kg) Age (years) Smokes? Disease A? Disease B?
198740 160 50 30 No No No
287402 177 70 36 No No Yes
398747 158 46 20 Yes Yes No
498732 173 75 22 No No No
598772 169 82 44 Yes Yes Yes
Attribute Anonymization Technique
Height (in cm) Base-5 rounding (5 is chosen to be somewhat proportionate to the typical height value
of, e.g. 120 to 190 cm)
Weight (in kg) Base-3 rounding (3 is chosen to be somewhat proportionate to the typical weight value
of, e.g. 40 to 100 kg)
Age (in years) Base-3 rounding (3 is chosen to be somewhat proportionate to the typical age va lue of,
e.g. 10 to 100 years)
(the remaining
attributes)
Nil, due to being non-numerica l and difficult to modify without substantial change in value
Perturbation Rules Using Base-X Rounding:

Perturbation – Example
198740 160 50 30 No No No
287402 177 70 36 No No Yes
398747 158 46 20 Yes Yes No
498732 173 75 22 No No No
598772 169 82 44 Yes Yes Yes
198740 160 51 30 No No No
287402 175 69 36 No No Yes
398747 160 45 18 Yes Yes No
498732 175 75 21 No No No
598772 170 81 42 Yes Yes Yes
After Purturbation:

Perturbation Guideline
● When to use
– Quasi-identifiers (typically numbers and dates) which may
potentially be identifying when combined with other data
sources, and slight changes in value are acceptable.
– Should not be used where data accuracy is important
● How to use:
– Depends on the exact data perturbation technique used

Other Techniques
● Data Synthetic
● Data Aggregation

Data Synthetic
● Description:
– Synthetic datasets separated from the original data, instead of
modifying the original dataset
● When to use:
– A large amount of data is required for system testing, but the
actual data cannot be used and yet the data should be “realistic”
like format, relationship among attributes, etc.
– Actual data not covered all test cases
● How to use:
– study the patterns from the original dataset (i.e. the actual data)
and apply the patterns when creating the “anonymised” dataset
(i.e. the synthetic data)

Data Aggregation
● Description:
– Converting a dataset from a list of records to summarized
values.
● When to use:
– Individual records are not required and aggregated data is
sufficient
● How to use:
– Using totals or averages, etc
– Discussion with the data recipient about the expected utility

Conclusion: Select the Right Anonymization
● Purpose of anonymization and its utility
● Characteristics of each anonymization techniques
● Inferred information after implementation
● Expertise with the subject matter
● Competency in anonymization process and techniques
● Recipients

Example Design:
E-Commerce on the Cloud
Pseudonymization
Client
Transaction DB
Personal Indentifiable
Information Service
Web API
PII DB
E-Commerce
Front-End Web Server

Example Design:
Personalized Marketing
Pseudonymization
Application
Data Warehouse
Data for Analytic
w/o Direct Identifier
(and/or Quasi-Identifier)
Business Intelligence
Tool
Personalized Info
Marketing
Campaigns
Direct Identifier
(and/or
Quasi-Identifier)
Personalized
Marketing Campaigns

Example Design:
PCI-DSS 3.2
Requirement 3: Protect stored cardholder data
Protection methods such as
● encryption,
● truncation,
● masking,
● and hashing
are critical components of cardholder data protection. If an
intruder circumvents other security controls and gains access to
encrypted data, without the proper cryptographic keys, the data
is unreadable and unusable to that person.
Pseudonymization
Recoding
Pseudonymization
Character Masking

Secure Software Design for Data Privacy

More Related Content

What's hot (20)

Similar to Secure Software Design for Data Privacy (20)

More from Narudom Roongsiriwong, CISSP (20)

Recently uploaded (20)

Secure Software Design for Data Privacy