View source for Working Group on Holistic Security

==What's the goal?==
This working group began designing how to include risk assessment processes in every stage of human rights documentation projects.

Holistic Information Security for Human Rights Documentation

This resource intends to provide assistance to identify risks throughout the responsible data project life cycle. It has been created during the RDF on Human Rights Documentation, and thereby aims to support documentation practitioners in particular.


(https://wiki.responsibledata.io/Data_in_the_project_lifecycle)
==PREAMBLE: Start with a mission statement==

To complement the responsible data life cycle (given above), we'd like to come up with a risk assessment lifecycle that complements. Its goal is to support organizations working on human rights documentation to make sure the information is protected at every stage of the project.

The process starts with a policy or mission statement, which likely says we recognize that part of our mission is to document human rights violation, we take seriously our responsibility to do no harm, protect human rights defenders, our sources , our employees and our partners. 
Hence we will include risk assessment and security of our data through out our project

Next, step by step, we begin mapping out risk. Before we do this, we would like to explain what we mean by some core concepts.

++What is a risk?== 
We calculate risk using the simple formula:
Risk = Threat x Vulnerability x Impact

==What is a threat?== 
Is a generalised unwanted event which has some frequency and distribution. 
eg:  websites getting hacked , mobile phones being lost 

==What is a vulnerability?== 
Are we personally as an organisation/individual vulnerable to these threats 
eg: Could our website get hacked ? , Could I loose a mobile phone ? 

==What is Impact?==
What are consequences of these threats being realised to our Organisation. 
eg:  do we loose donors if our website was hacked ? , do we get arrest if some information is shared ?


==What are defined as threat areas?== 
Intentional unauthorised access to data- The attempted or successful access of information or systems, without permission or rights to do so.( like hacking , malware )
Accidental unauthorised access to data - Loss of physical devices , data or unintentional sharing of permissions to look at data .
Legal considerations - legislative context in which data is being collected (are those providing data breaking laws? activists meeting in secret, sex workers working together for safety), including human rights context (is documenting human rights itself controversial or in breach of local laws? what are implications?) 
Technical failure  -  like a hardware , web server failure , third party system software failure , database crash. 
Disasters  - Natural disasters(like floods , earthquakes, typhoons) and their impact  , termites or fire or any such. 
Environmental - understanding context , interested parties , potential adversaries, political situation 
Data leakage -  The intentional or accidental loss, theft or exposure of sensitive company or personal information.

==Process Definition of Assessing and Treating Risks== 
An organisation desiring to assess and treat risk is advised to  follow the below process: 
Create a policy statement - Discuss in the organisation how serious are we? Let us discuss responsible data.
Assignment of Resources - Assignment a person to coordinate, guide, monitor and report on security considerations and the process ( substantive role, not necessarily the IT or Security staff - though they should be involved)  
Conduct Periodic risk assessment and create a treatment plan. 
Periodic Review Process 
Identify activities/assets (need possible list at each stage)
Identify threat at every phase (need possible threat for each activity/asset)
Perform risk assessment for every threat (need card template)
Incidence response - Accept/Mitigate/Transfer/Avoid 
Risk Assessment Process 
For each activity or asset we begin risk assessment by considering:  activities and assets.  
For a single activity or asset, we identify the threat,  we assess how vulnerable we are, and what would be the impact if this threat happened. By rating each on a scale of 0 to 5 then multiplying these three numbers together we get a result which helps us prioritise. (This number is subjective and only meaningful to our own organisation; not designed to compare between organisations.)
 
==Example:==
Threat Type : Information about project reaches a (disapproving) government before it even begins.  (Risk assessment by poker planning sort of process)
Risk Assessment before Treatment : 
Threat = 4 (govt doesn't like human rights orgs), Vulnerability = 3 (cannot keep project secret) Impact = 5 (project may get shutdown). Risk = 4 x 3 x 12 = 60. 
Decide the risk treatment 
Treatment  Decided :  Mitigate by involving the govt and making it a joint project, so they look good by assessing human rights impact
Do the re-calculation after risk treatment 
Risk Assessment after Treatment : 
threat= 4 vulnerability = 1 impact = 5   risk=20

==Template:== 
https://docs.google.com/document/d/1X3wEwZ_q2AtkL6B3pibBO4u5t5l9RZ5ev3W7V6XYEQM/edit?usp=sharing

==Desired Outcome== 
Security is a part of the human rights documentation development exercise (culturally and practically).
Prioritised list of Risk for treatment or atleast understanding. 
More Responsible data. 
More trust for all the partners. 

====

Pre-Life
Activity/Asset: Choosing Partners
Possible Partners: Survivors, Activists, Other NGOs, Government,
Possible Threats: Early Shutdown, Partner Data Leakage, Targeting of Partner, Disclosure to adversary, targeting by adversaries
Possible Mitigation: Train partner, etc..

Other Activity/Asset: Choosing Questions, designing survey, decisions about what data to collect (or not collect),  Capability assessment


==Collecting Data==
Collecting data is itself an activity, and assets include the data collected as well as equipment like phones and laptops or vehicles. 

Example Threat: breach of  confidentiality / anonymity during data collection. (How are people's testimony/information kept safe during data collection and what are consequences of a breach? Mitigate using codes on forms and store names seperately. What happens if data collecting team is arrested in the field? what data could police/agents access if paper files, notebooks, phones or tablets/laptops are confiscated / stolen? Mitigate using codes, de-referencing, and strong password/encryption.)
Example Threat: difficulties of local permission / authority to collect data. May need to liaise with village chiefs, local police depending on context - but what if this itself compromises data collection activity by drawing attention to ti? What  are consequences of collecting data without permission/secretly?
Example threat:  at micro-local level could be security issues within or between households and can relate to gender, class, ethnicity, local power dynamics/elites etc. (collecting data about domestic violence, or documenting inter-ethnic/tribal/political conflict? who can overhear interview? 
Other examples might include poor documentation practice by researchers (e.g. putting someone's name on a questionnaire rather than a code, or careless use of code list), careless conversation (encryption doesn't prevent staff talking too loud on the bus); or staff safety/security (risk of arrest, or violence because of work they are doing), logistics related safety/security (car breakdowns, landslides, road closures; or in conflict zones, crossfire, checkpoints, frontlines moving etc.) 

Asset related threats during data collection:
- accidental loss of files/equipment 
- malicious theft/confiscation of files or equipment (deliberately to access data)
- data loss during transmission of data (interception of paper files in delivery, or online data interception)
- failure of equipment (including lack of electricity, internet access; paper version of data forms as backup, what are security issues of backup paper versions when lack of electricity foils our well though out strong encryption techniques?) 

==Storage==
Activity/Asset: Storing data
Possible storage: Paper, Hard drive, Internal server, Cloud
Possible Threats: Intentional unauthorized access to data, Accidental unauthorized access to data, Legal considerations to storing data, System failure, Disasters, Environmental, Data leakage, Data loss, Phone hacking, Theft, 
Possible Mitigation: 
        Paper – Making copies, storing somewhere secure, scanning to computer in different location
        Harddrive- Synchronizing with cloud, daily/weekly backups, encryption,
        Internal Server – Replicating data, backup, synchronizing with cloud
        Cloud – Internet connection backup, replicating locally
        
==Data Processing==

Activity/Asset: Extraction/Cleaning
Possible Threats: Data loss, Data leakage, Data theft, Sabotage, Data Injection, Accidental data corruption, Intentional data corruption

Activity/Asset: Verification
Possible Threats: Loss of primary source, false data

Activity/Asset: Data Analysis
Possible Threats: Allegation of bias, data leakage, 

==Presentation==
Activity: present data or analysis on a website
Possible threats: manipulation of results after intrusion, blocking of access, systems failure, legal (take down notice)
Mitigation: ensure everyone with access to website has basic  security awareness (password, two-factor authentication, virus-free devices) and access is mapped out with security focal point, create recovery plan for the case of account compromise, reliable hosting with trusted partner, denial of  service protection (deflect.ca is free protection for civil society and independent media)

Activity: Internal Memo or sharing with partner
Possible Threats: leakage to adversaries from inside or from partner
Mitigation: use secure communications when sharing, share on paper or in person in a safe space, have written agreement with partner on protection needs and measures

Doing Something With it
Activity/Asset: 

After Life
Activity/Asset: Data

==Next steps==

==Participants==