Sunteți pe pagina 1din 10

 

Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P1 Web Application Vulnerabilities  Vulnerability is a key problem in any system 
that guards or operates on sensitive user 
data. Failure to suitably design and 
implement an application, detect a problem or 
promptly apply a fix (patch) is likely to result 
in a privacy breach. This risk also 
encompasses the OWASP Top 10 List of 
web application vulnerabilities and the risks 
resulting from them.  

How to check?  Countermeasures 
   
● Are regular penetration tests performed  ● Perform regular penetration tests by 
with a focus on privacy?  independent security experts. 
● Are developers trained regarding web  ● Track remediation of findings. 
application security?  ● Train application developers and architects 
● Are secure coding guidelines applied?  in secure development. 
● Is any of the used software out of date  ● Apply procedures for secure development 
(server, database, frameworks, other  (e.g. Security Development Lifecycle ­ 
infrastructure components)?  SDL). 
  ● Install updates, patches and hotfixes on a 
  regular basis. 

Example  References 
   
● Injection Flaws​  allow attackers among  ● OWASP Top 10 Project 
others to copy or manipulate data by  ● OWASP ASVS 
attacks like ​
SQL injection​ .  ● Open SAMM 
● Sensitive Data Exposure​  allows attackers  ● OWASP Proactive Controls 
gather sensitive information e.g. due to 
● Security Development Lifecycle (SDL) 
missing encryption with a 
man­in­the­middle attack.  ● OWASP Secure Application Design Project 
● Use of Insecure Direct Object References  ● Lists of known vulnerabilities can be found 
allows attackers to guess and access  at ​
CVE​  and ​
NVD 
sensitive information, especially if access  ● ISMS of the German Federal Office for 
control is missing.  Information Security (BSI​) 
● Usage of Components with Known 
Vulnerabilities​, e.g. unpatched software 
flaws, and ​Security Misconfigurations​ , e.g. 
unhardened application platform. 
● In general it is possible for attackers to 
gain access to, manipulate or delete 
personal data that the application is 
processing by abusing rights, entering 
malicious code or eavesdropping on 
communications. 
 
 

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P2 Operator­sided Data Leakage  Failure to prevent the leakage of any 
information containing or related to user data, 
or the data itself, to any unauthorized party 
resulting in loss of data confidentiality. 
Introduced either due to intentional malicious 
breach or unintentional mistake e.g. caused 
by insufficient access management controls, 
insecure storage, duplication of data or a lack 
of awareness.  

How to check?  Countermeasures 
   
● Research the reputation and reliability of  ● Appropriate Identity and Access 
the operator:  Management (physical as well as logical): 
○ Have there been former breaches  ○ Principle of least privilege. 
related to the operator?  ● Use strong encryption for all personal data 
○ Does the provider proactively prove  stored (data at rest) especially on mobile 
privacy and security and if yes, how?  media (e.g. USB memory sticks, laptop 
○ Is there a bug bounty program to  hard disks, tablet and phone local storage, 
report vulnerabilities?  backup tapes, portable hard disk drives). 
○ Is the provider certified according to  ● Awareness training for all employees 
ISO 27001 or ISO 27018 (cloud  regarding handling of personal data. 
providers)?  ● Implementation of a data classification and 
○ Is the operator located in a country  information handling policy. 
with high privacy standards?  ● Monitor and detect classified data when it 
● Audit the operator:  leaks from endpoints, web portals and 
○ Are privacy best practices in place?  cloud services (e.g. by Data Leakage 
○ Is awareness training mandatory for  Prevention, SIEM). 
all employees?  ● Implement ​ Privacy by Design 
○ Is there a privacy engineering team?  ● Anonymisation of personal data: 
○ How is personal data anonymized?  It is common practice to anonymise 
○ Is personal data encrypted?  personal data and use it for other purposes 
○ Who has access to the data  e.g. testing or marketing. Anonymisation is 
(need­to­know­principle)?  not easy (e.g.​ ​
aol search data leak​) and 
● Audit methods:  there are many​  ​
anonymisation theories 
○ Paper­based audit (fair)  which can be very complex. 
○ Interview­based audit (good)  ● Pseudonymisation which means that data 
○ On­site audit and system­checks  can only be connected to a person with 
(best)  help of a third party that knows the person 
and corresponding pseudonym. 

Example  References 
   
● Handbook for Safeguarding Sensitive PII  ● Article 29 Working Party on Anonymization 
● IT­Grundschutz­Catalogues 
 
   

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P3 Insufficient Data Breach Response  Not informing the affected persons (data 
subjects) about a possible breach or data 
leak, resulting either from intentional or 
unintentional events; failure to remedy the 
situation by fixing the cause; not attempting 
to limit the leaks.  

How to check?  Countermeasures 
   
General questions:  Countermeasures (in advance): 
● Is an incident response plan for privacy  ● Create and maintain incident response 
incidents in place?  plan. 
● Is this plan tested regularly (provide  ● Test incident response plan regularly. 
evidence e.g. a test protocol)?  ● Include privacy­related incidents in test. 
● Do you have a Computer Emergency  ● Establish a Computer Emergency 
Response Team (CERT) and / or a Privacy  Response Team (CERT). 
Team?  ● Establish a Privacy Team. 
● Do you have monitoring for incidents (e.g.  ● Continuously monitor for personal data 
SIEM) in place?  leakage and loss. 
If there was a privacy incident, did you:  Responding to the breach: 
● detect it (timeously)?  ● Validate the breach. 
● notify relevant parties, including the  ● Once a breach has been validated, 
individuals themselves, in a timely  immediately assign an incident manager to 
manner?  be responsible for the investigation. 
● protect evidence, remaining data during  ● Assemble incident response team. 
response / investigation?  ● Determine the scope and composition of 
Is your incident response:  the breach (e.g. legislation, confidentiality). 
● Timely ­ information is disclosed to  ● Notify the data owners. 
affected parties soon enough for them to  ● Determine whether to notify the authorities 
avoid additional harm?  (situation dependent). 
● Honest, accurate and understandable?  ● Decide how to investigate the data breach 
Organizations that experience a privacy  to ensure that the evidence is appropriately 
breach have a responsibility to clearly  handled. 
communicate the nature and scope of the  ● Determine whether notification of affected 
breach to those affected.  individuals is appropriate and if so, when 
● Established company wide for security  and how. 
breach notifications (policy)?  ● Collect and review any breach response 
documentation and analyse reports. 

Example  References 
 
AICPA Privacy Incident Response Plan Template  Key Steps for Organizations in Responding to 
  Privacy Breaches (Privacy Commissioner of 
ENISA recommendations for severity assessment  Canada) 
  Data Breach Response Checklist (PTAC) 

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P4 Insufficient Deletion of Personal Data  Failure to effectively and / or timeously delete 
personal data after termination of the 
specified purpose or upon request.  

How to check?  Countermeasures 
   
● Inspect the data retention / deletion  ● Deploy systems with good privacy 
policies and/or agreements.  practices, in this case minimization. 
● Evaluate their appropriateness.  ● Personal data has to be deleted after 
● Request deletion protocols.  termination of the specified purpose and 
● Test processes for deletion requests.  after an appropriate timeframe (e.g. one 
● Check if transparency is provided (which  month). 
data is deleted when and which data is not  ● Personal data has to be deleted on rightful 
deleted and why).  user request. 
  ● Secure locking (with very limited access to 
  the data) might be an option if deletion is 
not possible due to technical restrictions. 
● Real deletion is preferable though and 
minimizes the risk. 
● Data retention, archival and deletion 
policies and processes have to be 
documented and followed. 
● Evidence should be collected to verify the 
deletion as per policy. 
● Any data in backups, other copies or 
shared with third parties has to be 
considered. 
● Exceptions are possible in case of 
retention required by law. Access should 
be very limited and protocolled for this 
case. 
● When deleting data in cloud, take note of 
historical data stored in older snapshots. 
● Deletion of user profiles after longer 
periods of inactivity. 

Example  References 
   
Customer data is deleted automatically after a  ● https://ico.org.uk/for­organisations/guide­to
certain period of inactivity (Hotmail removes user  ­data­protection/principle­5­retention/ 
profiles in case they are not used for one year) or   
after termination of contract (it is not required by  ● German DIN standard 66398 
law to keep all customer information for accounting 
or other purposes). 
 
   

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P5 Non­transparent Policies, Terms and  Not providing sufficient information to 
Conditions  describe how data is processed, such as its 
collection, storage, processing and deletion. 
Failure to make this information 
easily­accessible and understandable for 
non­lawyers.  

How to check?  Countermeasures 
   
Check if policies, terms and conditions:  ● Terms & Conditions (T&Cs) should be 
● Are easy to find  specifically for the use and data processing 
● Fully describe data processing:  of the website. 
○ Who are you / who is processing  ● They should be easy to understand for 
the data  non­lawyers and not too long. 
○ Including data transfers  ● Provide an easily readable summary of the 
○ Analysis performed  terms and conditions as well as a long 
○ Retention time  version.  
○ Meta data used  ● Pictograms can be used for visual aid. 
○ What are the rights   ● Use separate T&Cs for use and data 
○ …  processing. 
● Understandable for non­lawyers  ● Use release notes to identify change 
● Complete, but KISS (Keep it short and  history of T&Cs and policies/notices over 
simple)  time. 
● Include a process for obtaining user  ● Keep track of which users consented to 
consent if the terms, policies or conditions  which version and any other time at which 
change.  they may opt in to newer versions. 
● Are available in the user’s language  ● Deploy Do Not Track on the server side. 
● Explain which data are collected  ● When collecting information it should be 
● Explain the purposes for which personal  clear why it is needed. You should also try 
data is collected   to predict whether you will be likely to do 
● Use a readability tester like  other things with it in the future and tell the 
https://readability­score.com/​ to check  users if you have such plans. 
whether a text is hard to read or not.  ● Provide a list of cookies, widgets etc. used 
● Are privacy rules actively communicated or  with an explanation of the use e.g. sharing 
does the user have to take action  data or advertising. 
● Provide an ​ opt­out­button​  for the users.  

Example  References 
   
● Easily readable summaries:  ● Privacy notices code of practice from ICO, 
○ http://www.avg.com/privacy  also contains a list of examples: 
○ 500px.com  https://ico.org.uk/media/for­organisations/d
● Explanation of cookies, widgets etc.  ocuments/1610/privacy_notices_cop.pdf 
including an ​ opt­out­button​
 if existing:  ● HTTPA​  (HTTP with Accountability) 
○ http://www.kaspersky.com/third­pa ● Biggest lie​ is a project that protests against 
rty­tracking  overly complicated T&Cs and shows other 
● Examples for Pictograms:   projects that try to change that. 
○ http://netdna.webdesignerdepot.co
m/uploads/2014/03/iubenda.jpg 
 

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P6 Collection of data not required for the  Collecting descriptive, demographic or any 
primary purpose  other user­related data that are not needed 
for the purposes of the system. Applies also 
to data for which the user did not provide 
consent.   

How to check?  Countermeasures 
   
● List personal data collected by the  ● Define the purpose of the collection of 
application.  personal data. 
● Request description of purpose.  ● Only collect personal data required to fulfill 
● Check if collected data is required to fulfill  the purpose. 
● Default is to collect as little data as 
the purpose. 
possible unless the user chooses 
● If data is collected that is not required for  otherwise (data reduction / minimization). 
the primary purpose(s), check if consent to  ● Provide the data subject the option to 
collect and process this data was given  provide additional data voluntarily to 
and is documented.  improve the service (e.g. product 
● Are individuals notified and asked if  recommendation, personalized 
purpose or processing is changed?  advertisement) with possibility to opt­out. 
● Are regular compliance checks regarding  ● The purpose for collection of personal data 
the collection of personal data and user  collected is specified no later than at the 
consent in place?  time of data collection. 
  ● Conditioned collection: Collect personal 
data only if they are really required for an 
used feature. 

Example  References 
   
Positive:  Article 29 Working Party Opinion on Purpose 
● A webshop collects Email addresses to  Limitation 
send an order confirmation to the buyer.   
This email address is not used to send  Privacy Design Strategies: 
news about products (another purpose)  ● M. Colesky, J.­H. Hoepman, and C. Hillen. 
unless the user actively chooses this  A Critical Analysis of Privacy Design 
option (opt­in).  Strategies​ . In ​
2016 International 
Negative:  Workshop on Privacy Engineering – 
● Amazon provides personalized  IWPE'16​ , San Jose, CA, USA, May 26 
advertisement to its users. This can be  2016. (to appear). 
disabled, but the default setting is on. From  ● J.­H. Hoepman. ​ Privacy Design 
a privacy point of view it should be  Strategies​ . In ​
IFIP TC11 29th Int. Conf. 
disabled by default and the user should  on Information Security (IFIP SEC 2014),​  
opt­in to receive personalized product  pages 446­459, June 2­4 2014. 
recommendations.   
 
 
 
 
 
The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P7 Sharing of Data with Third Party  Providing user data to any third­party, without 
obtaining the user’s consent. Sharing results 
either due to transfer or exchanging for a 
monetary compensation or otherwise due to 
inappropriate use of third­party resources 
included in the web site like widgets (e.g. 
maps, social networks buttons), analytics or 
web bugs (e.g. beacons). 

How to check?  Countermeasures 
   
● Is personal data transferred to third  Personal data is often shared with third parties 
parties?  through the integration of third party content like 
● Are third party solutions in use (plugins,  user tracking code, advertising banners, social 
buttons, maps, videos, advertising, etc.)  network buttons or videos, and third­party hosted 
and which ones?  JavaScript and style sheet libraries. 
● Is third party tracking disclosed (which third   
parties and what data).  The following measures should be considered for a 
● Can you provide a list of all third parties?  privacy­friendly use of third party content: 
● Check each third party against each of the  ● Use third party content only where it is 
criteria in this document.  required, not by default. 
● Did you rate them regarding privacy?  ● Use your own server as a “proxy” for 
● Is privacy and handling of personal data  content. 
part of the contract and if yes, what  ● Deploy full Do Not Track, to the latest W3C 
restrictions are in place?  standard. Prefer W3C standard over 
● Do you use privacy­friendly  unofficial EFF one. 
implementations of third party content (if  ● Tokenisation or anonymisation (data 
available)?  masking) should be considered for use 
● Do you use blacklists of third parties that  before sharing of data with a third party. 
are forbidden due to privacy concerns?  ● Develop a Third Party Monitoring Strategy: 
● Do you audit your third parties?  ○ Gateway release for third party 
● If you transfer data to third­parties, or use  content (whitelist or blacklist). 
third­party processing, is there a user  ○ Contractual arrangements 
consent for sharing data?  regarding Policies, Data usage, 
  etc. 
○ Monitoring of user complaints. 

Example  References 
   
Social network buttons do not transfer data unless  W3C Working Draft Tracking Compliance and 
they are clicked on:  Scope 
https://github.com/heiseonline/shariff   
  Attribute­based Credentials for Trust: 
Youtube provides the opportunity to enable a  https://abc4trust.eu/ 
privacy­enhanced mode and only transfers   
personal data in case of a click.  https://en.wikipedia.org/wiki/Do_Not_Track 
 
 
 

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P8 Outdated personal data  The use of outdated, incorrect or bogus user 
data. Failure to update or correct the data.  

How to check?  Countermeasures 
   
● Ask the operator how it is ensured that  ● Implement a procedure to update the 
personal data is up­to­date.  user’s personal data by obtaining inputs 
● Check for possibilities to update personal  from them after a certain time period. 
data in the application.  ● The user should approve data if he or she 
is triggering a “critical” action. 
● Are there regular checks to validate that 
● Provide a form to enable users to update 
data is up­to­date (e.g. “please verify your  their data. 
shipping address”)?   ● In case of an update make sure to forward 
● Question how long it is likely that data is up  the information to any third parties / 
to date and how often it usually changes.   subsystems that received the user’s data 
before (if there are any). 
 

Example  References 
   
An update form is provided on the website so that  UK ICO on keeping personal data up to date  
the user can update his or her data when needed.   
 
Amazon is asking whether your address and 
account data is correct before you can finish your 
order (CRM clearing). 
 
   

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P9 Missing or insufficient Session Expiration  Failure to effectively enforce session 
termination. May result in collection of 
additional user­data without the user’s 
consent or awareness.  

How to check?  Countermeasures 
   
● Is the logout button easy to find and  ● Automatic session expiration should be 
promoted?  set. Expiration time could differ widely 
● Is there an automatic session timeout < 1  depending on the criticality of the 
week (for critical applications < 1 day).  application and data. 
● Are session timeout lengths appropriate to  ● Session timeout should be no longer than 
the length required to complete a  a week and much shorter for critical use 
transaction (long enough) but also to the  cases. A best practice for medium 
sensitivity of the data that the session  criticality (e.g. webmailer, web shop, social 
accesses (shorter for higher sensitivity)?  network) is one day as default setting. 
● A single service can support several  ● Session timeout should be configurable by 
combinations of session sensitivity and  the user according to his or her needs. 
length. Each such available session type  ● If a user has not used the logout­button to 
should be evaluated.  finish his session the last time, the user 
  should see a reminder message at next 
login. 
● If the user is unable to logout, or the logout 
does not terminate the session completely, 
data may continue to be collected (e.g. 
tracking sites the user visits elsewhere). 

Example  References 
   
When a users forgets to logout from web.de  OWASP Session Management Cheat Sheet 
(German mail provider) a popup tells the users at   
next login that logging out is important for security  Carnegie Mellon Guidelines for Data Protection 
reasons.  recommends automatic session timeout besides 
  other controls 
Facebook does not implement automatic session 
expiration. The user has to logout manually. In 
case the user does not actively log out and 
someone else uses the device he or she can 
access or manipulate the user’s profile. 
 
Amazon implements security without logout button 
by partitioning the content into different sensitivity 
levels, and tracking the x­main and session­id 
cookies. Amazon ensures that only the 
authenticated user can access personal details, but 
provides personalized content to a returning user 
without login. 
   

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 
 
Top 10 Privacy Risks Projects 
 Countermeasures v1.0 

 
P10 Insecure Data Transfer  Failure to provide data transfers over 
  encrypted and secured channels which would 
exclude the possibility of data leakage. 
Failure to enforce mechanisms limiting the 
leak surface, e.g. allowing the inference of 
any user data out of the mechanics of Web 
application operation. 

How to check?  Countermeasures 
   
● What are the policies for protecting data in  ● Always send personal data by secure 
transit?  protocols i.e. not insecure protocol like 
● Is data encrypted during transfer?  ordinary email, many instant messaging 
● Are secure protocols and algorithms used?  clients, FTP. 
● Are privacy­friendly protocols available for  ● Configure transfer protocols so they are 
transfer?  secure enough for the types of data being 
● Are private protocols enforced where  transmitted. 
appropriate? (E.g. Login only available  ● Allow connections using the best available 
over HTTPS, and sensitive records only  secure protocols, where possible. 
accessible by TLS or SFTP)  ● Disallow weak protocols for sensitive 
information. 
● Avoid personal information in the URL, 
especially if the data transfer is 
unencrypted. 
● Activate privacy in protocols (e.g. Privacy 
Extensions in IPv6). 
● Support TLS/DTLS, do not support SSLv3. 
● Use ECDHE and GCM ciphers, do not 
support static RSA key exchange and 
CBC­based ciphers. 

Example  References 
   
● Configure services to disable broken  http://security.stackexchange.com/questions/7790/
security protocols such as SSLv3.  guidance­for­implementors­of­https­only­sites­serv
● Configure services to enable the latest  er­side 
secure protocols.   
● Enforce HTTPS for the entire Web  Jim Manico’s presentation at AppSecEU 2015: 
application session, from first visit to login  HTTPS is better than ever before ­ Now it's your 
page to completion of logout.  turn 
● Disable vulnerable file transfer services   
such as Telnet and FTP on file servers.  Privacy Extensions in IPv6 
Enable secure transfer protocols instead.   
  Background information: IEEE 802 Tutorial  about 
About the insecurity of current internet technologies  Designing Privacy into Internet Protocols (July 
and the initiative to build new ones:  2014) 
http://youbroketheinternet.org/ 
  

The OWASP Top 10 Privacy Risks Project is free to use. It is licensed under the Creative Commons CC­BY­SA v3.0 License 
Published on 2016­04­08 

S-ar putea să vă placă și