[HOT] HOT Security Working Group

David Schmitt david at black.co.at
Tue May 7 19:31:48 UTC 2013


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 hot at openstreetmap.org 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



More information about the HOT mailing list