[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