On 2013-05-06 04:00, Schuyler Erle wrote:
Our first step was to organize a short conference call with George Chamales, a security expert known for his expertise in disaster response and particularly in crowdsourcing, and a long-time supporter of HOT. George recently wrote "Towards Trustworthy Social Media and Crowdsourcing", a policy brief sponsored by the Wilson Center, which I strongly recommend reading.[1]
The "Understanding What Can Go Wrong" chapter was particularly eye-opening and should be a must read for all participants in crisis areas :-/
We took detailed notes during the call, which are shared as a Google Doc.[2] Please feel free to comment directly on the document: http://goo.gl/4qGZu The key takeaway from the call was that, rather than having a one-size-fits-all "security policy", our policy should to be break down every HOT activity into a workflow, against which security threats and responses can be assessed on a case-by-case and ongoing basis.
I do not think I completely understand what a "workflow" is in this context. The following is under the assumption that a workflow denotes a set of related activities, several of which can be joined under a single activation / project. Examples might be "armchair mapping", "field surveying", or "OSM/HOT education". Does that match?
If that's the case, it might be beneficial to have a set of prototypical workflows, each with an associated, generalized risk discussion. These could then be used to efficiently assess each particular case.
Some very high-level dimensions might include location of the participant (local-mobile, local-stationary, rural, urban, remote), political situation (stable growth project, disaster preparedness, disaster response, disaster recovery, tense, hidden conflict, open conflict), expected adversaries (local ethnicities, local power groups, regional power groups), etc.
For example, my perception of risks for armchair mappers is mostly centered around spear fishing (the practice of targeting an individual in a social engineering attack), general vulnerabilities in the used end devices (i.e. the PC of the mapper), and general OSM vulnerabilities.
Participants in the field on the other side, have probably a completely different risk profile and a much higher variance of said profile across projects than us stay-at-homes. There are surely others much better qualified to discuss that than myself.
One aspect that seems to be missing (or maybe just I have missed it) is securing HOT as a project on a higher level. While it is clear that the physical / technological infrastructure requires protection (as noted in the doc), the integrity of the project also requires attention. e.g. it is currently not clear who on the [email protected] list is representing the project and who is just a helping hand (like myself). To fix this, HOT needs to establish consistent and reliable communications in both directions (that is sending and receiving information).
On the sending side, a moderated hot-announce@ mailing list and/or official email aliases and signatures can help in establishing consistency.
On the receiving side, HOT should have well-publicized contact addresses which are handled according to their labels. From the software development world I know that a properly managed security@ alias can make a huge difference between those who quietly add to the value of their product and those who go up in (metaphoric) flames regularly.
Regards, David
[1] http://www.scribd.com/doc/138508756/Towards-Trustworthy-Social-Media-and-Crowdsourcing [2] http://goo.gl/4qGZu
_______________________________________________ HOT mailing list [email protected] http://lists.openstreetmap.org/listinfo/hot
