On Wed, Dec 26, 2012 at 01:45:00AM -0500, bobal...@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
