Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Draft checklist for choosing tools

Rich Kulawiec rsk at gsp.org
Thu Jan 3 15:58:25 PST 2013


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?"




More information about the liberationtech mailing list