This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Industry:FTC Protecting Consumer Privacy"

From OWASP
Jump to: navigation, search
(Draft Text version 2: e ii) modified and e iii) added re-Achim's comments)
(Draft Text version 2: s iii) text extended)
Line 117: Line 117:
 
ii) In the report under "fraud detection", the use of "web server logs" are explicitly mentioned.  These are not the only source of event data, and in any case, are not considered sufficient for most data protection purposes.  Practices should include the collection, aggregation and analysis of all types of event information (which could contain data about consumers). We would suggest changing the phrase "ordinary web server logs" to "network security devices, web server, security event, audit, local client and other logs".
 
ii) In the report under "fraud detection", the use of "web server logs" are explicitly mentioned.  These are not the only source of event data, and in any case, are not considered sufficient for most data protection purposes.  Practices should include the collection, aggregation and analysis of all types of event information (which could contain data about consumers). We would suggest changing the phrase "ordinary web server logs" to "network security devices, web server, security event, audit, local client and other logs".
  
iii) The list of commonly accepted practices should add "misuse detection and prevention".  This is quite similar to the existing "fraud prevention" practice already included, but not all suspicious activity and attacks involve deception or personal gain as the intent.  Not all unwanted activity is necessarily a crime.  The intent may be to alter, delete or steal data, or to view unauthorized information, or to prevent access to the service by others.  Included in this should be process verification (e.g. testing and audit) which are not malicious, but do form part of detection & prevention.
+
iii) The list of commonly accepted practices should add "misuse tracking, detection and prevention".  This is quite similar to the existing "fraud prevention" practice already included, but not all suspicious activity and attacks involve deception or personal gain as the intent.  Not all unwanted activity is necessarily a "crime".  The intent may be to alter, delete or steal data, or to view unauthorized information, or to prevent access to the service by others.  Included in this should be process verification (e.g. testing and audit) which are not malicious, but do form part of detection & prevention.  Misuse tracking, detection and prevention is used to protect consumers and their data.
  
 
iv) The list of commonly accepted practices should include data required for "state management" purposes (e.g. using cookies as user identifiers, and temporary storage of user state properties at the server).  Many applications will not work at all unless session management data are allowed.  This data may need to be replicated across locations for load balancing and redundancy.  A consumer would expect a particular web service to be available when they want it, and to have all their relevant information available and accurate.  This requires data storage and replication.  This data of course is still subject to privacy controls, limitations to use, etc.
 
iv) The list of commonly accepted practices should include data required for "state management" purposes (e.g. using cookies as user identifiers, and temporary storage of user state properties at the server).  Many applications will not work at all unless session management data are allowed.  This data may need to be replicated across locations for load balancing and redundancy.  A consumer would expect a particular web service to be available when they want it, and to have all their relevant information available and accurate.  This requires data storage and replication.  This data of course is still subject to privacy controls, limitations to use, etc.
Line 128: Line 128:
 
ii) The selected mechanism ALSO needs to be clear, easy-to-find, usable, and understandable by ORGANIZATIONS involved in developing, operating, hosting and delivering online services, otherwise the consumer's choice may be meaningless.  Guidance on who is responsible for what, and how each party needs to support the mechanism would be required.  For example, if an HTTP header is to be used, the issue of intermediate devices such as proxy servers, traffic management and firewalls would presumably also have to act upon the instruction?  It would need to be clear what is, and is not, tracking in these locations.  Data may be gathered by the application, by intrusion detection systems, in audit trails - as well as in web server logs.  Online websites may also contain code hosted by third parties e.g. widgets, buttons, syndications, code libraries, and these potentially would also have to act upon the instruction.
 
ii) The selected mechanism ALSO needs to be clear, easy-to-find, usable, and understandable by ORGANIZATIONS involved in developing, operating, hosting and delivering online services, otherwise the consumer's choice may be meaningless.  Guidance on who is responsible for what, and how each party needs to support the mechanism would be required.  For example, if an HTTP header is to be used, the issue of intermediate devices such as proxy servers, traffic management and firewalls would presumably also have to act upon the instruction?  It would need to be clear what is, and is not, tracking in these locations.  Data may be gathered by the application, by intrusion detection systems, in audit trails - as well as in web server logs.  Online websites may also contain code hosted by third parties e.g. widgets, buttons, syndications, code libraries, and these potentially would also have to act upon the instruction.
  
iii) Some options for implementing a Do Not Track mechanism may leave no trace of the consumer's requests.  But this equally means it may be impossible to prove whether a consumer did opt out of tracking or not.  The ability to verify this, or investigate a consumer complaint against an organization, needs to be considered and clear guidance given to system designers and developers about what is expected and required.
+
iii) Some options for implementing a Do Not Track mechanism may leave no trace of the consumer's requests.  For example, HTTP headers are typically not logged anywhere currently.  But this equally means it may be impossible to prove whether a consumer did opt out of tracking or not.  The ability to verify this, or investigate a consumer complaint against an organization, needs to be considered and clear guidance given to system designers and developers about what is expected and required.
  
  

Revision as of 08:46, 16 February 2011


Return to Global Industry Committee

ACTIVITY IDENTIFICATION
Activity Name FTC Protecting Consumer Privacy
Short Description Provide response to the FTC Staff Report "Protecting Consumer Privacy in an Era of Rapid Change - A Framework for Businesses and Policymakers"
Related Projects None
Email Contacts & Roles Primary
Colin Watson
Secondary
Mailing list
Please use the Industry Committee list
ACTIVITY SPECIFICS
Objectives
  • Review report - in particular issues relating to web application security
  • Where appropriate, draft a response for submission
  • Submit the response as an official OWASP statement
Deadlines
  • 20 Jan 2011 - Complete first draft response
  • 24 Jan 2011 - Circulate draft
  • 4 Feb 2011 - Prepare final version
  • 7 Feb 2011 - Submit to FTC
Status
  • In Progress
Resources FTC Staff Report: Protecting Consumer Privacy in an Era of Rapid Change - A Framework for Businesses and Policymakers

FTC report announcement press release, 1 Dec 2010

FTC deadline extension, press release, 21 Jan 2011

Response submission using the comment form by 18th February 2011


Submission Response

Latest first


Final version

tbc


Draft Text version 2

Introduction

This official response has been submitted on behalf of the Open Web Application Security Project (OWASP) by the OWASP Global Industry Committee, following our own consultation process.

Response

The OWASP response is to eight of the FTC's questions for comment, which we have labelled a) to h) for our own purposes. The questions responded to relate to aspects within OWASP's mission to "to make application security visible, so that people and organizations can make informed decisions about true application security risks.". In some cases where OWASP does not have an agreed opinion, questions are not answered explicitly and instead we have raised application related matters which may affect consideration of other responses to the question.

a) Companies should promote consumer privacy throughout their organizations and at every stage of the development of their products and services > Incorporate substantive privacy protections > When it is not feasible to update legacy data systems, what administrative or technical procedures should companies follow to mitigate the risks posed by such systems?

i) Although it may be economically infeasible to change legacy systems, it is often the case that these systems are modified, or access provided to them through new mechanisms (e.g. by a web service, or using a mobile application). The changes and additions should have privacy built in.

ii) For legacy data systems which cannot be altered, the techniques of data minimization, data integrity checking and data tokenization should be considered first. Thereafter conventional administrative and technical controls (e.g. segregation of duties, principle of least privilege, etc) should be applied based on a risk assessment, but we would like to highlight the following application-specific controls:

  • documentation of security defaults and options that affect security
  • secure configuration of the application and application environment
  • application event log analysis
  • application layer firewalls
  • application surface exposure minimization
  • application layer intrusion detection and prevention
  • content (data) egress monitoring

iii) If multiple channels (e.g. desktop application, web site, web service, mobile application, accessible web site) are used to deliver a business process, all of these should have similar levels of privacy protection built in, so that one channel can not be used to circumvent another, and similarly for non-online alternatives (e.g. customer call center, walk-in shop, telephone self-service, etc).


b) Companies should promote consumer privacy throughout their organizations and at every stage of the development of their products and services > Maintain comprehensive data management procedures > How can the full range of stakeholders be given an incentive to develop and deploy privacy-enhancing technologies?

i) Privacy requirements should be build into development & procurement practices. Verification processes must be undertaken to ensure these have been delivered - a risk based approach should be used to ensure effort is applied proportionately through the portfolio of processes.

ii) It is not sufficient just to use PETs - they must be installed, configured and operated correctly. For example, selection of weak algorithms, exposure of keys or provision of access to decrypted data through an application can all circumvent "encryption as a solution". The use of TLS (SSL) can be undermined by exposing session variables over plain HTTP, SSL can be set up incorrectly (it is not "secure by default") and many applications (e.g. websites, mobile apps, email clients) make it very hard for users to tell whether SSL is being used correctly, and there is little consistency in visual signals for users. We would recommend that guidance is created defining the minimum technical standards for each PET, and also related procurement specifications and audit checklists and self-assessment questionnaires.

iii) OWASP has the leading repository of application security knowledge (see these standards, guidelines, etc which reference OWASP http://www.owasp.org/index.php/Industry:Citations ); for example has a begun a "Cheat Sheet" series, one of which relates to HTTP over SSL (TLS): http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet Separate guidance with different emphasis and detail would be required for various audiences. OWASP has continuing voluntary efforts to translate its materials into many world languages.


c) Companies should promote consumer privacy throughout their organizations and at every stage of the development of their products and services > Maintain comprehensive data management procedures > What roles should different industry participants – e.g., browser vendors, website operators, advertising companies – play in addressing privacy concerns with more effective technologies for consumer control?

i) For services delivered over web technologies, besides the operators of the services, the software programming languages, code libraries, frameworks, host environment, network and browser can all affect the efficacy of privacy protection. Every part of the supply chain throughout the software development life cycle (including operation and disposal), needs to be able to understand the privacy-affecting aspects and effects. There is an need for increased visibility in the supply chain, as well as to consumers.

ii) But consumers are neither best placed, nor have sufficient resources, to undertake checks on the controls in place. And some measures might be more economically enforced at one point in the process and its delivery than another. For example, removing cross-site scripting (XSS) vulnerabilities on a single website, protects many consumers.

iii) Owners of websites and other online applications should take responsibility for protection of consumer data. This includes all the actions taken by their application, and any third party content included.

iv) However, not all collection/tracking of consumer data may be undertaken by legitimate (non-malicious/privacy compliant) websites and other legitimate applications. Legitimate sites may become compromised due to the presence of security flaws and lack of mitigating measures so that content from malicious hosts is included (e.g. drive-by downloads), or users are redirected to those. But consumers may also be tricked into visiting malicious sites (by phishing, or because the sites are genuine in some way), or they may choose to download files to view or execute which unknowingly contain malicious code. In these cases, protective measures in the browser and operating system, and operators of legitimate sites have no control over these aspects. They can of course use development and deployment practices which build security into their own services; but these do not help if consumers visit other locations.


d) Companies should simplify consumer choice > Commonly accepted practices > Is the list of proposed “commonly accepted practices” set forth in Section V(C)(1) of the report too broad or too narrow?

i) The commonly accepted practice of "internal operations" may not always be obvious to consumers. The example of websites collecting information about visits and click-though rates is used in the report. Consumers may well expect the organisation they are interacting with to do this, but they probably are not expecting their data to be collected, stored and processed directly by a third party which is often the case. This is not at all obvious to consumers and is quite different to the physical example of hotels and restaurants collecting customer satisfaction surveys themselves. Apart from web analytics, the inclusion of other third party hosted code (e.g. code libraries, widgets, syndicated content) has a similar effect.

ii) In the report under "fraud detection", the use of "web server logs" are explicitly mentioned. These are not the only source of event data, and in any case, are not considered sufficient for most data protection purposes. Practices should include the collection, aggregation and analysis of all types of event information (which could contain data about consumers). We would suggest changing the phrase "ordinary web server logs" to "network security devices, web server, security event, audit, local client and other logs".

iii) The list of commonly accepted practices should add "misuse tracking, detection and prevention". This is quite similar to the existing "fraud prevention" practice already included, but not all suspicious activity and attacks involve deception or personal gain as the intent. Not all unwanted activity is necessarily a "crime". The intent may be to alter, delete or steal data, or to view unauthorized information, or to prevent access to the service by others. Included in this should be process verification (e.g. testing and audit) which are not malicious, but do form part of detection & prevention. Misuse tracking, detection and prevention is used to protect consumers and their data.

iv) The list of commonly accepted practices should include data required for "state management" purposes (e.g. using cookies as user identifiers, and temporary storage of user state properties at the server). Many applications will not work at all unless session management data are allowed. This data may need to be replicated across locations for load balancing and redundancy. A consumer would expect a particular web service to be available when they want it, and to have all their relevant information available and accurate. This requires data storage and replication. This data of course is still subject to privacy controls, limitations to use, etc.


e) Practices that require meaningful choice > Special choice for online behavioral advertising: Do Not Track > How can such a mechanism be designed to be clear, easy-to-find, usable, and understandable to consumers?

i) Not all tracking is necessarily undertaken on a server elsewhere. Some applications may utilize local storage (on the consumer's device). Intermediate network devices may also store data, even if transiently. These should also be considered.

ii) The selected mechanism ALSO needs to be clear, easy-to-find, usable, and understandable by ORGANIZATIONS involved in developing, operating, hosting and delivering online services, otherwise the consumer's choice may be meaningless. Guidance on who is responsible for what, and how each party needs to support the mechanism would be required. For example, if an HTTP header is to be used, the issue of intermediate devices such as proxy servers, traffic management and firewalls would presumably also have to act upon the instruction? It would need to be clear what is, and is not, tracking in these locations. Data may be gathered by the application, by intrusion detection systems, in audit trails - as well as in web server logs. Online websites may also contain code hosted by third parties e.g. widgets, buttons, syndications, code libraries, and these potentially would also have to act upon the instruction.

iii) Some options for implementing a Do Not Track mechanism may leave no trace of the consumer's requests. For example, HTTP headers are typically not logged anywhere currently. But this equally means it may be impossible to prove whether a consumer did opt out of tracking or not. The ability to verify this, or investigate a consumer complaint against an organization, needs to be considered and clear guidance given to system designers and developers about what is expected and required.


f) Practices that require meaningful choice > Special choice for online behavioral advertising: Do Not Track > Should the concept of a universal choice mechanism be extended beyond online behavioral advertising and include, for example, behavioral advertising for mobile applications?

i) It would perhaps be short-sighted to restrict the consumer client software to only be websites delivered over HTTP. Existing Rich Internet Applications (RIAs) may communicate using other protocols. A consumer might expect that opting out of behavioral advertising in one software application, applied to all software applications on the device.

ii) It could be difficult for consumers to differentiate between "online" and "mobile" - for example mobile applications can sometimes incorporate web pages. It mail also be useful to think of email clients as another example. The consumer doesn't actually care about the underlying technology - it's all "online data".


g) Companies should increase the transparency of their data practices > Reasonable access to consumer data > Should companies inform consumers of the identity of those with whom the company has shared data about the consumer, as well as the source of the data?

i) With applications, the data sharing can be occurring at the same time as it is being provided, and not necessarily subsequently. For example, including code from a third party within a web page where the user is identifiable. In these cases, it may make sense to inform the consumer in advance.

ii) Consumers also may not expect some data practices/uses within organizations e.g. intra department data sharing. For example, the use of real consumer data in development and test environments, or using data mining techniques on a CRM system.


h) Companies should increase the transparency of their data practices > Reasonable access to consumer data > Should consumers receive notice when data about them has been used to deny them benefits? How should such notice be provided? What are the costs and benefits of providing such notice?

Denial of benefits may occur when a user is logged out, locked out or otherwise prevented from accessing an application (e.g. IP address blacklisting). In some cases a particular consumer may be known (e.g. by the relationship to a particular user account name) or may only be through some other identifier (e.g. network address), which may not always be possible to identify an individual consumer at the time. Notices in these cases should include messages given by the application electronically.

About OWASP

to be added in final draft

Draft Text version 1

Introduction

This official response has been submitted on behalf of the Open Web Application Security Project (OWASP) by the OWASP Global Industry Committee, following our own consultation process.

Response

The OWASP response is to eight of the FTC's questions for comment, which we have labelled a) to h) for our own purposes. The questions responded to relate to aspects within OWASP's mission to "to make application security visible, so that people and organizations can make informed decisions about true application security risks.". In somke cases, questions are not answered explicitly where OWASP does not have an agreed opinion, but intstead application related matters to consider are highlighted which may affect the topic of the question.

a) Companies should promote consumer privacy throughout their organizations and at every stage of the development of their products and services > Incorporate substantive privacy protections > When it is not feasible to update legacy data systems, what administrative or technical procedures should companies follow to mitigate the risks posed by such systems?

i) Although it may be economically infeasible to change legacy systems, it is often the case that these systems are modified, or access provided to them through new mechanisms (e.g. by a web service, or using a mobile application). The changes and additions should still consider building privacy in.

ii) For legacy data systems which cannot be altered, the techniques of data minimization, data integrity checking and data tokenization should be considered first. Thereafter conventional administrative and technical controls (e.g. segregation of duties, principle of least privilege, etc) should be applied, but we would like to highlight the following application-specific controls:

  • documentation of security defaults and options that affect security
  • secure configuration of the application and application environment
  • application event log analysis
  • application layer firewalls
  • application surface exposure minimization
  • application layer intrusion detection and prevention
  • data egress monitoring

iii) If multiple methods (e.g. desktop application, web site, web service, mobile application, accessible web site) are used to access a business process, all of these should have similar levels of privacy protection built in, so that one channel can not be used to circumvent another, and similarly for non-application alternatives (e.g. customer call center, walk-in shop, telephone self-service, etc).


b) Companies should promote consumer privacy throughout their organizations and at every stage of the development of their products and services > Maintain comprehensive data management procedures > How can the full range of stakeholders be given an incentive to develop and deploy privacy-enhancing technologies?

i) Privacy requirements should be build into development & procurement practices. Verification processes must be undertaken to ensure these have been delivered - a risk based approach should be used to ensure effort is applied proportionately through the portfolio of processes.

ii) It is not sufficient just to use PETs - they must be installed, configured and operated correctly. For example, selection of weak algorithms, exposure of keys or provision of access to decrypted data through an application can all circumvent "encryption as a solution". The use of TLS (SSL) can be undermined by exposing session variables over plain HTTP, SSL can be set up incorrectly (it is not "secure by default") and many applications (e.g. websites, mobile apps, email clients) make it very hard for users to tell whether SSL is being used correctly, and there is little consistency in visual signals for users.


c) Companies should promote consumer privacy throughout their organizations and at every stage of the development of their products and services > Maintain comprehensive data management procedures > What roles should different industry participants – e.g., browser vendors, website operators, advertising companies – play in addressing privacy concerns with more effective technologies for consumer control?

For services delivered over web technologies, besides the operators of the services, the software programming languages, code libraries, frameworks, host environment, network and browser can all affect the efficacy of privacy protection. Every part of the supply chain throughout the software development lifecycle (including operation and disposal), needs to be able to understand the privacy-affecting aspects and effects. There is an need for increased visibility.


d) Companies should simplify consumer choice > Commonly accepted practices > Is the list of proposed “commonly accepted practices” set forth in Section V(C)(1) of the report too broad or too narrow?

i) The commonly accepted practice of "internal operations" may not always be obvious to consumers. The example of website collecting information about visits and click-though rates is used. Consumer may well expect the organisation they are interacting with to do this, but they probably are not expecting their data to being collected, stored and processed directly by a third party which is often the case. This is not at all obvious to consumers and is quite different to the physical example of hotels and restaurants collecting customer satisfaction surveys themselves. Apart from web analytics, the inclusion of other third party hosted code (e.g. code libraries, widgets, syndicated content) has a similar effect.

ii) In the existing practice of "fraud detection", the use of "web server logs" are explicitly mentioned. These are not the only source of event data, and in any case, are not considered sufficient for most data protection purposes. Practices should include the collection, aggregation and analysis of all types of event information (which could contain data about consumers). We would suggest changing the phrase "ordinary web server logs" to "web server, security event, audit, local client and other logs".

iii) The list of commonly accepted practices should include misuse detection and prevention. This is quite similar to the existing "fraud prevention" practice already included, but not all suspicious activity and attacks involve deception or personal gain as the intent. Not all unwanted activity is necessarily a crime. The intent may be to alter, delete or steal data, or to view unauthorized information, or to prevent access to the service by others. Included in this should be process verification (e.g. testing and audit) which are not malicious, but do form part of detection & prevention.

iv) The list of commonly accepted practices should include data required for "state management" purposes (e.g. using cookies as user identifiers, and temporary storage of state properties at the server). Many applications will not work at all unless session management data are allowed. This data may need to be replicated across locations for load balancing and redundancy. This data of course is still subject to privacy controls, limitations to use, etc.


e) Practices that require meaningful choice > Special choice for online behavioral advertising: Do Not Track > How can such a mechanism be designed to be clear, easy-to-find, usable, and understandable to consumers?

i) Some applications may utilize local storage (on the consumer's device), and this should also be considered. Not all tracking is necessarily undertaken on a server elsewhere.

ii) The selected mechanism also needs to be clear, easy-to-find, usable, and understandable by ORGANIZATIONS involved in developing, operating, hosting and delivering online services, otherwise the consumer's choice may be meaningless. Guidance on who is responsible for what, and how each party needs to support the mechanism would be required. For example, if an HTTP header is to be used, the issue of intermediate devices such as proxy servers, traffic management and firewalls would presumably also have to act upon the instruction? It would need to be clear what is, and is not, tracking in these locations. Data may be gathered by the application, by intrusion detection systems, in audit trails - as well as in web server logs. Online websites may also contain code hosted by third parties e.g. widgets, buttons, syndications, code libraries, and these potentially would also have to act upon the instruction.


f) Practices that require meaningful choice > Special choice for online behavioral advertising: Do Not Track > Should the concept of a universal choice mechanism be extended beyond online behavioral advertising and include, for example, behavioral advertising for mobile applications?

i) It would perhaps be short-sighted to restrict the consumer client software to only be websites delivered over HTTP. Existing Rich Internet Applications (RIAs) may communicate using other protocols. A consumer might expect that opting out of behavioral advertising in one software application, applied to all software applications on the device.

ii) It could be difficult for consumers to differentiate between "online" and "mobile" - for example mobile applications can sometimes incorporate web pages. It mail also be useful to think of email clients as another example. The consumer doesn't actually care about the underlying technology - it's all "online data".


g) Companies should increase the transparency of their data practices > Reasonable access to consumer data > Should companies inform consumers of the identity of those with whom the company has shared data about the consumer, as well as the source of the data?

i) With applications, the data sharing can be occurring at the same time as it is being provided, and not necessarily subsequently. For example, including code from a third party within a web page where the user is identifiable. In these cases, it may make sense to inform the consumer in advance.

ii) Consumers also may not expect some data practices/uses within organizations i.e. intra department data sharing. For example, the use of real consumer data in development and test environments.


h) Companies should increase the transparency of their data practices > Reasonable access to consumer data > Should consumers receive notice when data about them has been used to deny them benefits? How should such notice be provided? What are the costs and benefits of providing such notice?

Denial of benefits may occur when a user is logged out, locked out or otherwise prevented from accessing an application (e.g. IP address blacklisting). In some cases a particular consumer may be known (e.g. by the relationship to a particular user account name) or may only be through some other identifier (e.g. network address), which may not always be possible to identify an individual consumer at the time. Notices in these cases should include messages given by the application electronically.

About OWASP

to be added in final draft


Return to Global Industry Committee