hi Stephen,
trimming CC, proposing we move this to privsec-discuss to stop accumulating Narten points... :)
> On 8 Nov 2017, at 10:36, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:
>
>
>
> On 08/11/17 09:16, Brian Trammell (IETF) wrote:
>> Indeed, I've been disappointed and perplexed that so much of the
>> rhetoric around encryption post-Snowden (as epitomized by 7258) has
>> focused exclusively on a nation-state
>
> Ahem:-) 7258 says:
>
> "The
> motivation for PM can range from non-targeted nation-state
> surveillance, to legal but privacy-unfriendly purposes by commercial
> enterprises, to illegal actions by criminals. "
>
> I think we got that right. I agree that there has been too little
> focus put on the non-state actor cases.
7258-the-document is fine. It's the simplification of the discussion following 7258 that I'm disappointed with.
>> or co-opted/evil
>> large-network-operator attacker model, which is certainly a point of
>> concern but not really where the biggest threat to collective privacy
>> lies these days. I'm concerned that in our drive to Encrypt All The
>> Things, absolutely the correct response when your only concern is a
>> nation-state on the wire, we risk making it difficult to understand
>> and defend against (what I'll call) the corporate-data-hording
>> attacker model. To date, most of the evil toys phoning home and other
>> such nastiness that I've heard of has been discoverable in part
>> because said evil toys were using circumventable, crap, or no
>> crypto.
>
> Yea, a different thread.
...here is that thread...
> I agree with Ted though, our job is partly
> to ensure that the bits on the wire don't give the game away in all
> cases. I'd also note that those exfiltrating data have plenty of
> standard and non-standard tools available to try hide their actions
> so us making standards such that exfiltration seems easier to spot
> doesn't change the problem much for the exfiltrator.
>
> So I don't agree that the tension here is between standard crypto
> protocols and spotting exfiltration as the latter can be done via
> stego or covert channels or other non crypto ways of hiding data.
There are two and a half exfiltration models here which are technically similar but operationally distinct, and it might make sense to tease them apart to see if that sheds some light on ways to approach this problem:
(1) Corporate exfil (your "marketing slides" example below). Here, in most cases, the data exfiltrated is stored on systems owned by the data owner, and is accessed using credentials issued by the data owner, usually by an employee, contractor, or other natural person intentionally given access to some of those systems, if not to the specific data owned. A lot of the "we need to see content" argument is based on this model. In any case, best practices in enterprise IT prescribe a defense-in-depth approach, with a network perimeter (currently with cleartext inspection, in the future hopefully without) as well as endpoint security on servers and clients, and there is an IT security department/organization with a clear responsibility to detect and prevent exfiltration. In this envrionment, we're probably already down the stego rathole, and as in most things human intelligence, though expensive and difficult, is the best way to prevent the insider threat.
From a technical standpoint, in almost all of these cases, the exfiltration can *could* be detected on the endpoint, before it's sent, though to my knowledge most of the systems research in this space (doing things like trying to taint RAM, files, and sockets that *could have seen* information content derived from a given object) has results that cannot currently be made to apply to most practically usable systems. Trying to close the gap between theoretical and applicable in terms of endpoint exfil detection is certainly worth effort here.
(2) IoT exfil (a lazy characterization, but let's run with it for the headline potential). Here, the data exfiltrated is generated by a device owned by the data owner, but the data owner has no access to that data without exceptional means -- for these purposes I'm going to go ahead and make a stretch that the law hasn't universally yet, and say that pictures of you taken in your house by a teddybear you bought belong to you.
Most consumers don't have a corporate IT department behind them, so the defense now is some researcher notices that teddybear X is sending a *whole lot* of data to some AWS instance somewhere, hacks the crap crypto and figures out that, yeah, that's video of what the teddybear sees. There might be stego here already, too, but we wouldn't know about it without treating all IoT firmware as malware and analyzing it as such. Come to think of it, that might be a promising (if high-risk) career direction for young malware researchers.
(2.5) Platform/app exfil: stuff like apps keeping full mobility traces, even when the app isn't focused or the trace isn't necessary for the app's function. Here, you have a lot of the same properties as IoT exfil, with the caveat that the platform owner steps into the IT security management role. It can restrict apps' access to information through app store restrictions, API restrictions, and a system of permissions (though we all know how well that works in practice on Android) and user prompts ("do you want TrackMeEverywhere to see your location even when you aren't using it?"). This works better than (2) above as long as you have absolute trust in the platform, and decays to (2) above when you don't.
I think that (1) and (2/2.5) are fundamentally different beasts, in terms of who's doing the detecting and maybe in terms of how.
> The following may well work regardless of crypto: "I'll send you
> the marketing slides, in one of which will be an image that you
> can zoom until you can read the paper the actor is holding and on
> that you'll find the secret formula":-)
>
> I do however think it could be worthwhile someone documenting
> the myriad ways in which exfiltration can be done or has been done
> (esp. from home/enterprise networks) but I don't recall one of
> those. Anyone know of a good survey that is not aiming to sell
> some specific product/service?
Argh, no. Adding it to my list of things I'd like to have time to think more about.
Cheers,
Brian
Attachment:
signature.asc
Description: Message signed with OpenPGP