Privacy by Design: White Papaer

SYMANTEC PROPRIETARY / CONFIDENTIAL – DRAFT Copyright © 2015 Symantec Corporation. All rights reserved.

Privacy by Design - Symantec’s Privacy Principles 1

Privacy by DesignA proposal for updates to current design process to increase focus on privacy

Kristyn Greenwood & Ryan LacrossSymantec Corporation: Website Security

SYMANTEC PROPRIETARY – DRAFT Copyright © 2015 Symantec Corporation. All rights reserved.

Gatekeeper 2.0 - Australian Privacy Principles 2

2 Definition of Terms

3 Privacy Principles

1 Introduction

What’s in this deck?

4 Proposed Updates to Guidelines

SYMANTEC PROPRIETARY – DRAFT Copyright © 2015Symantec Corporation. All rights reserved.


1 Introduction

• Privacy by design proposal• Current Process challenges


Privacy by Design Proposal

• Problem statementSymantec’s Website Security UX team has a robust design process and the company has clear policies for handling data that should be kept private but the UX team lacks tactical guidelines for designing products that actively promote privacy. In addition, the team lacks a consistent method of documenting the privacy requirements of features.

• The proposalCurrent design process should be updated with a common framework and set of tools that can be shared among all members of the product teams (UX, QA, PM, UI).

• Benefit to Symantec

Symantec is trusted to handle data appropriately. Our goal is to develop procedures to ensure this trust is maintained and be able to document these procedures.



Current Process Challenges

• Challenge 1: Large amount of dataOver 50% of the data collected by Symantec’s products is categorized as private at some level. Our products require the collection, validation and authentication, and dissemination of this information - for the purposes of providing security to our customers and for them to, in turn, to secure their customers.

• Challenge 2: Frequently changing requirementsSymantec’s products require frequent updates and design changes that impact the collection and sharing of information, including some which had previously been treaded as private. - Government regulations or industry standards change leading to new

requirements related to the treatment of private data.- External corporations and organizations change their policies or ways of

doing business that require customers to reassess their decisions regarding the sharing of private data.




2

• There are various types of information that can be considered ‘private’.

– Personal information– Sensitive information– Confidential information

Definition of Terms


Personal Information

• Information about someone whose identity is apparent or can reasonably be ascertained

- Not knowing an individual’s name does not mean you can’t identify that person.

- Symantec gathers this type of information as part of the validation and authentication processes.

• Examples of personal information:

– User ID– Names– Email addresses– IP address



Sensitive Information

• A subset of personal information relating to the following:

– Racial or ethnic origin– Political opinions– Membership of a political association– Religious/Philosophical beliefs or affiliations– Membership of a professional or trade association/union– Sexual preferences or practices– Criminal record– Health and/or genetic information



Sensitive Information (cont.)

• Sensitive information should be subject to a higher level of privacy protection than other personal information

– It may only be collected with consent– It may not be used for any other purpose than for which it was collected

• Symantec’s Privacy Policy says not to collect or use anything defined as sensitive information:

– Under no circumstances do we collect personal data related to racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, or sex life.



Confidential

• Information about customer corporations, networks, personnel, or systems that is shared with Symantec to allow our tools to manage their systems, data, or to perform tasks.

• Should be protected at the highest level. Controls must be put in place to prevent unauthorized visibility.

• Examples of corporate confidential information:

– Personal or organizational passwords, – Information about internal systems: internal domains, private certificates– Domain ownership – Information about network configuration: IP addresses, gateways, ports




Guidelines that impact the suggestions contained within this proposal.

Privacy Principles3


Privacy References

• Privacy by Design– Initially proposed by the Information & Privacy Commissioner of Ontario,

Ann Cavoukian, Ph.D. in the late 1990s– Consists of 7 foundational principles

• The Australian Privacy Principles– Australian Privacy Principles (APP) in 2014 set out 13 requirements for

handling personal information

• US Laws & Regulations– There is no single law or regulatory agency that covers all aspects of data

privacy within the US– Consequently there is no single consolidated source of guidelines that can

be provide guidance



Overview of Ontario’s Privacy by Design Principles

1. Proactive not Reactive; Preventative not Remedial

The Privacy by Design (PbD) approach is characterized by proactive rather than reactive measures. It anticipates and prevents privacy invasive events before they happen. PbD does not wait for privacy risks to materialize, nor does it offer remedies for resolving privacy infractions once they have occurred — it aims to prevent them from occurring. In short, Privacy by Design comes before-the-fact, not after.

2. Privacy as the Default Setting

We can all be certain of one thing — the default rules! Privacy by Design seeks to deliver the maximum degree of privacy by ensuring that personal data are automatically protected in any given IT system or business practice. If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy — it is built into the system, by default.

3. Privacy Embedded into Design

Privacy by Design is embedded into the design and architecture of IT systems and business practices. It is not bolted on as an add-on, after the fact. The result is that privacy becomes an essential component of the core functionality being delivered. Privacy is integral to the system, without diminishing functionality.

4. Full Functionality — Positive-Sum, not Zero-Sum

Privacy by Design seeks to accommodate all legitimate interests and objectives in a positive-sum “win-win” manner, not through a dated, zero-sum approach, where unnecessary trade-offs are made. Privacy by Design avoids the pretense of false dichotomies, such as privacy vs. security, demonstrating that it is possible to have both.



Overview of Ontario’s Privacy by Design Principles (continued)

5. End-to-End Security — Full Lifecycle Protection

Privacy by Design, having been embedded into the system prior to the first element of information being collected, extends securely throughout the entire lifecycle of the data involved — strong security measures are essential to privacy, from start to finish. This ensures that all data are securely retained, and then securely destroyed at the end of the process, in a timely fashion. Thus, Privacy by Design ensures cradle to grave, secure lifecycle management of information, end-to-end.

6. Visibility and Transparency — Keep it Open

Privacy by Design seeks to assure all stakeholders that whatever the business practice or technology involved, it is in fact, operating according to the stated promises and objectives, subject to independent verification. Its component parts and operations remain visible and transparent, to users and providers alike. Remember, trust but verify.

7. Respect for User Privacy — Keep it User-Centric

Above all, Privacy by Design requires architects and operators to keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice, and empowering user-friendly options. Keep it user-centric.



Overview of the Australian Privacy Principles

APP 1 – Open and transparent management of personal Information APP 2 – Anonymity and pseudoanomity APP 3 – Collection of solicited personal information APP 4 – Dealing with unsolicited personal information APP 5 – Notification of the collection of personal information APP 6 – Use or disclosure of personal information APP 7 – Direct marketing APP 8 – Cross-border disclosure of personal information APP 9 – Adoption, use or disclosure of government related identifiers APP 10 – Quality of personal information APP 11 – Security of personal information APP 12 – Access to personal information APP 13 – Correction of personal information




Additions to current design guidelines to aid in incorporating Privacy by Design

4 Proposed Updates to Guidelines

• Black Hat personas• Feature requirements related to privacy• QA tests• Design heuristics


Black Hat Personas• Definition: – Personas are an integral part of a user-centered design, and are fictional

characters created to represent a specific cluster or type of user. – Black Hat personas are created to represent individuals who are

unauthorized users or unauthorized recipients of private data.• Owner: UX• Why: – Black Hat personas help direct attention towards the treatment of private

data and ensure requirements are defined for unauthorized users as well as authorized ones.

• Examples of Black Hat personas – Hacker– Phisher– Disgruntled employees (of customer)– Competitors



Feature Requirements Related to Privacy• Definition: – Requirements describe a feature and define tasks the product must

perform, conditions that it must meet, or qualities it must possess.• Owner: PM & UX• Why:– Attention to privacy is increased during development if feature

descriptions include requirements related to the treatment of private data that is collected, manipulated, and displayed.

• Questions that can aid in development of privacy requirements– Is collected or displayed data private? – How do we handle this private information?– Where do we keep copies of this private information?– Which systems contain this private information?– Who has access to this information?



QA Tests

• Definition A series of steps designed to determine whether a feature works as it was designed or if requirements were met.

• Owner: PM & QA• Why

A standard library of test cases related to privacy ensures common issues related to privacy as well as those that are product specific are run at every release ensuring that privacy requirements are met.

• Examples of QA tests related to privacyValidate the login functionality so only Admin Level users are able to view private data.– Login as User 1 (has Admin Role). Go to module A and search for item X.

Result = Success– Login as User 2 (has Reader Role), Go to module A and search for item X.

Result = Failure



Heuristics

• Definition

General usability guidelines and applied principles to be employed in the design and evaluation of a system.

• Owner: UX• Why

Attention to privacy is enhanced during development if a standard set of design heuristics specifically targeted at ensuring private data is handled appropriately.

• Examples of Heuristics related to privacy

1. Be transparent: Clearly communicate why we collect personal and confidential data and how we handle it.

2. Request information only when necessary: Ask for personal or corporate information ONLY if it is required to perform a task or deliver a service. Requested information may ONLY be used for the purpose it was requested for.



Heuristics (continued)

3. Allow anonymity: If the tasks or activity does not require the individual or organization to be validated, don’t ask for data.

4. Ensure accuracy: Information collected should be accurate, complete, and up to date.

5. Verify user identity before providing information: Information should only be provided to a user who has proven their identity and has the appropriate access level.

6. Prevent unauthorized access: Private and confidential data should be stored in a manner designed to prevent unauthorized access.

7. 2nd hand collection: If user information is received from a second party, inform the user of how you got their information and how you'll use it.

8. Access to information: Users should have access to any information about themselves and be able to update or correct it.




3

• Privacy by Design: The 7 Foundational Principles; by Ann Cavoukian, Information and Privacy Commissionaire of Ontario. Jan. 2011 (https://www.ipc.on.ca/images/Resources/7foundationalprinciples.pdf)

• Australian Privacy Principles Guidelines; by Office of the Australian Information Commissioner. March 2015. (https://www.oaic.gov.au/resources/agencies-and-organisations/app-guidelines/APP_guidelines_complete_version_1_April_2015.pdf)

Bibliography

https://www.ipc.on.ca/images/Resources/7foundationalprinciples.pdf

https://www.ipc.on.ca/images/Resources/7foundationalprinciples.pdf

https://www.oaic.gov.au/resources/agencies-and-organisations/app-guidelines/APP_guidelines_complete_version_1_April_2015.pdf

