[liberationtech] Draft checklist for choosing tools

[Nadim Kobeissi]

I think that is a wonderful checklist! Perhaps also add:

* Make sure tool has been audited and that the audit results have been
published,
* Take into consideration the accessibility of the tool to potential third
parties that may need it.

Sorry if any of the above points have already been mentioned.


NK


On Fri, Jan 4, 2013 at 1:58 AM, Rich Kulawiec <rsk at gsp.org> wrote:

> On Wed, Dec 26, 2012 at 01:45:00AM -0500, bobalice at lavabit.com wrote:
> > Comments and suggestions would be appreciated. Happy holidays!
>
> A suggested addition, perhaps not worded as succinctly as it could be:
>
> *Third-party Infrastructure*
>
> Some tools, perhaps nearly all tools, rely on third parties for data
> transmission, data storage, authentication, etc.  Tools should/must
> enumerate the third parties involved and the type of information
> made available to them. [1]  Some (all?) third parties should be
> presumed-compromised, e.g., security issues are rampant everywhere
> (c.f. dataloss mailing list) [2], ISPs are likely monitored by their host
> governments, freemail providers are likely insecure and multiply-owned by
> intruders, social networks are likely providing complete data feeds to
> host governments, and any other third party of significance likely has
> either (a) one or more under-the-table arrangements or (b) freelancing
> personnel doing the same.
>
> To clarify that last clause: in the case of (a), there are some third
> parties out there which are clearly motivated entirely by profit, so
> why *wouldn't* they accept an offer of cash for data from any government
> willing to make one?  (They're certainly willing to take cash from
> advertisers, marketers, spammers, data aggregators, etc.)   Of course
> some governments need not proffer cash, as they can simply demand
> the data using implied or overt threats.
>
> In the case of (b), if I were, let's say, the Syrian intelligence
> service, I would think it a highly worthwhile investment to purchase a
> Rackspace engineer, an Amazon cloud admin, a Twitter engineer, etc., for
> whatever amount of crisp tax-free income in an envelope it would require,
> in return for either data-feeds-of-interest or particular bits of data
> on demand.  Of course another approach to (b) would be to plant people
> there -- time-consuming, expensive, etc., but certainly any number of
> governments have the resources to groom and educate their own loyalists
> for possible future positions at (let's say) Google or Skype.  And a
> few dozen engineers in the right places could prove to be more valuable
> intelligence assets than hundreds of staff elsewhere...particularly if
> their political allegiance motivates them to do the job for free.
>
> That's not meant to impugn those particular companies or their staff,
> it's simply to observe that in all operations above a certain minimum
> size, there exists a nonzero number of staff who can be purchased on
> the open market or whose loyalties lie elsewhere *and* that almost no
> operation anywhere defends its internal data against its own staff in
> any meaningful way.
>
> ---rsk
>
> [1] Easy to say, hard to do.  A tool might rely on DNS (with all the
> attendant issues), a domain (and thus its registrar), a domain's web site
> host, etc.  I have the hunch that if we actually tried to map out the
> dependency tree for some of these tools that we'd be at it for a while.
> I also have the hunch that we would be unhappy at what we found, i.e.,
> I think the dependencies are far more extensive than we're comfortable
> with.
>
> [2] One of the issues with the pervasive security problems we face is
> secondary data loss.  There are two ways to acquire data from a target
> (absent cooperation from the target or the target's staff): (1) steal it
> (2) wait for someone else to steal it, then steal it from them.
> In many cases (1) is tedious and expensive, while (2) is fast and cheap.
> In the case of high-value data, the relevant questions for attackers
> are not "will someone steal it?" or "when?" because the most likely answers
> are "yes" and "yesterday".  The questions are "who are they?" and "how
> can we swipe it from them?"
>
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130104/1cb3348e/attachment.html>