Data Protection Policy (DPP ) (DRAFT)

1. Data Protection Policy (DPP)(DRAFT) Kirsten Baxter, Karen Ernst (LS)Charlotte Maria Viala (HR)Tim Smith (IT/CIS)Derek Mathieson (GS/AIS)Computer Security Team ACCU 2012/9/5

2. Do we lack a DPP? • ~/.ssh/FILE like ~/.ssh/id_dsa • ~/.ssh/identity • ~/.ssh/id_rsa • ~/.globus/FILE • ~/.gnupg/FILE • ~/.mozilla/FILE • ~/.cvspass • ~/.gitconfig • ~/.*htpass* ~/*htpass* • ~/.netrc • ~/.pine.pwd • ~/.gnome2/keyrings • ~/.kde/share/apps/kwallet/ • ~/.subversion/auth/simple/ • ~/private

3. Do we lack a DPP?

4. Do we lack a DPP?

5. Data Protection Policy (DPP) CERN Privacy Statement describes how and when CERN collects, uses and shares information when you use CERN's computing facilities; and, how CERN protects personal data stored in CERN's computing facilities. Data Classification Policy (DCP) The general classification scheme for all data that are stored and/or processed in electronic form. Data Storage Policy (DSP) The rules under which data must be stored. Data Access Policy(DAS) The rules under which data can be accessed. Data Transfer Policy(DTP) The rules under which data can be (digitally) transferred between data stores. Data Destruction Policy(DDP) The rules under which digital media must be wiped or destroyed such that any trace of data has disappeared from that media. Goal: Pragmatic, compact, applicable. Linked to AC10+.

6. Data Classification Policy (DCP) • "Sensitive Data": Data is highly confidential; disclosure would compromise personal data privacy or/and could cause damage to CERN or CERN's reputation or impede the work of CERN; data must be encrypted or equally secured for storage and in transit; data must be protected by login; authorization is typically limited to named individuals, who have unrestricted access for operational purposes, and to specific groups, who have restricted access subject to case-by-case control procedures. • "Restricted Data": Data is confidential; circulation of data is required for operational purposes but wide-spread disclosure is unacceptable; data must be protected by login; authorization is limited to named individuals or specific groups, who have access for operational purposes. • "Internal Data":Data is not confidential as such, but is intended for an internal audience only; external disclosure is undesired; data must be protected by login; audience is "CERN", i.e. all Members of the Personnel. • "Public Data": Data intended for disclosure; audience is unlimited. • (We avoid using “confidential” as it is inconsistently used at CERN) See https://cern.ch/security/rules/en/dcp.shtml

7. Examples of Sensitive Data • Personal data: medical records; documents and forms leading to the decision taking, in particular as regards recognition of merit (e.g. the MARS form) or disability or disciplinary sanctions; payment data; bank account details. • Computing data: aggregated security data like login information, command line activity or network traffic; forensics data; AFS/DFS "private"-folders; e-mail folders; passwords, certificates and other credentials; certain LANDB data; complete records of incoming and/or outgoing calls. • Financial and contractual data: credit card information; bids in response to price inquires and call for tenders; payment data; bank account details; e-banking; policies & procedures; performance indicators.

8. Examples of Restricted Data • Personal data: personal administrative file (in particular all documents certifying the personal and professional situation of a MP like date-of-birth, marriage, divorce certificates; administrative decisions as to assignment of functions, change of department, recognition of merit etc.), sex, nationality, private address & telephone number, employment applications and contract information, salary, salary position, CERN ID; decisions following a disciplinary procedure (issue of warning/reprimand or other disciplinary sanctions) and decisions on the recognition of a disability; staff association membership; the "Pension Fund file". • Computing data: AFS/DFS user spaces; MAC addresses; analysis software; elogbooks; accounting information for professional usage of a service, e.g. access to buildings or Grid resources; video surveillance streams (live and archive). • Documents: papers/analyses in draft; operations manuals; meeting minutes; internal memos; invention disclosure; patents (before publication); official letters. • Financial and contractual data: budget information and budget plans; team accounts; information covered by non-disclosure agreements (NDAs); CERN issued price inquires and call for tender documents (after market survey); offers; orders; contracts; IT documents (including list of suppliers); supplier invoices; accounting entries; requests for funds (CERN invoices); bank contracts; Knowledge Transfer contracts; sales reports; policies & procedures; performance indicators; Qualiac DB.

9. Examples of Internal Data • Personal data: preferred language; CERN ID photo; direct contact information like building and office information, e-mail addresses, telephone numbers (see e.g. the CERN phonebook ). • Computing data: account names, account details (see e.g. CERN Account Management ); WebReq device information; scans of number plates. • Documents: internal notes; non-public CERN policies; manuals; internal vacancies. • Financial and contractual data: certain AIS documents (like DAI, TID, JOB, SHIP, MAT) where the objective is to show CERN contributors where money is spent; supplier database; financial rules; purchasing reports; some finanical committee documents.

10. Examples of Public Data • Personal data: name, first name, CERN organization unit, institute affiliation or experiment, roles (DH, GL, SL, CSO, GLIMOS, SLIMOS, TSO, DSO, DPO, ...); generic contact information like P.O. box number, e-mail addresses, telephone numbers. • Computing data: AFS/DFS "public"-folders; software under copyleft license; public web-sites. • Documents: official CERN publications; papers; patents (after publication); Knowledge Transfer reports; information about ILO; this policy. • Financial and contractual data: vacancies; the Staff Rules and Regulations; Member State documents (once published); financial accounts; market surveys; finanical committee documents. Have a look through the examples: https://cern.ch/security/rules/en/dcp.shtmlComments welcome!!!

11. Consolidation ofCERN Computing Accounts Paolo Tedesco, Emmanuel Ormancey (IT/OIS)Computer Security Team ACCU 2012/9/5

12. CERN accounts for your dog • Today, there are no rules who can obtain a CERN primary computing account. You just need to be registered with HR. • That account allows owning plenty of CERN computing resources (mailbox, websites, other accounts, DFS/AFS disk space, …) and enables use of many CERN computing facilities (like LXPLUS, Windows PCs, INDICO, EDH, …). • That account will remain being still valid for two months after leaving CERN.Even if you just worked two days at CERN painting a wall… Thus, a clear definition is needed of who can use CERN computing facilities and who can own CERN computing resources and a proper split needs to be done between authentication & authorization. In addition, • there is no consistent usage of service and secondary accounts, • and confusion what a “lightweight account” is; • there are plans to open CERN to accept external accounts (“ID Federation”)

13. Levels of assurance for identities • Today, we consider five groups of identities with different level of “trust”(so-called Levels-of-Assurance, LoA): • Every computing service owner must define which LoA’s are authorized to use that service. P.ex. EDH can only be used by “CERN Registered” identities while the CERN market can be used by “Anonymous Identities”, too. • In addition, a service owner can demand a second factor for authentication (e.g. the CERN access card, a USB token, a mobile phone)

14. Eligibility REFEDS (Research and Education Federations) defines categories of personnel,see http://www.terena.org/activities/refeds/docs/ePSAcomparison_0_13.pdf) Every computing service owner must define which categories are authorized to use that service or own resources. General rules: • Computing resources can be owned by: Member (incl. Employee, Student) • Computing services can be used by: Member, Student, Staff, Faculty • Those can opt-in using Computing Services: Affiliate