From nobody Wed Nov 8 08:22:38 2017 Return-Path: X-Original-To: privsec-discuss@ietfa.amsl.com Delivered-To: privsec-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804F8128768 for ; Wed, 8 Nov 2017 08:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXHqhpXK3UQc for ; Wed, 8 Nov 2017 08:22:30 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697901286D6 for ; Wed, 8 Nov 2017 08:22:30 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 371A9340D88; Wed, 8 Nov 2017 17:22:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.26655); Wed, 8 Nov 2017 17:22:29 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 8 Nov 2017 17:22:29 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 35354388; Wed, 08 Nov 2017 17:22:29 +0100 From: Brian Trammell (IETF) Message-Id: <20264F85-19D3-4CFD-859E-5CF0978B45F2@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_212FE71A-1F59-4A20-AF3B-AF56B045B386"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 17:22:28 +0100 In-Reply-To: <1ba3b565-3bcf-2493-0f79-36ca3bf6a933@cs.tcd.ie> Cc: IETF Discussion Mailing List , privsec-discuss@iab.org To: Stephen Farrell References: <9bd4e3f2-b781-16cd-f486-56e491c239f7@ericsson.com> <77bb17eb-abd2-f611-b737-f5b9d8b5188e@network-heretics.com> <6.2.5.6.2.20171029112156.11bf51e8@elandnews.com> <02fd9185-eb3b-80bb-9b09-536b6120e911@network-heretics.com> <6.2.5.6.2.20171029130937.113d0e80@elandnews.com> <9a7f241c-e8ad-18eb-392f-276c62af287c@ericsson.com> <37687bbf-4c06-0542-8efa-b3cd8a016c4a@network-heretics.com> <4450ac76-f3d4-96c7-7df6-bc424d9cfd3b@ericsson.com> <9edf410b-54dd-66a6-12f0-6b65cbe7a32a@cs.tcd.ie> <55B7E8CA-A4E7-4A74-A10B-21FBD56DCFCF@google.com> <0d41ecbf-f0a8-d4d5-fdaf-94251d2cabaa@cs.tcd.ie> <88CBE84D-6BF8-4540-A7FF-FA1EF35E580C@trammell.ch> <1ba3b565-3bcf-2493-0f79-36ca3bf6a933@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Privsec-discuss] detecting exfiltration X-BeenThere: privsec-discuss@iab.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy and Security Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 16:22:33 -0000 --Apple-Mail=_212FE71A-1F59-4A20-AF3B-AF56B045B386 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 >=20 >=20 > 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 >=20 > Ahem:-) 7258 says: >=20 > "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. " >=20 > 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. >=20 > 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. >=20 > 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. =46rom 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":-) >=20 > 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 --Apple-Mail=_212FE71A-1F59-4A20-AF3B-AF56B045B386 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloDL0QACgkQihK3vwvq RqPSsxAAgFfNJRJohKfUoyaO3Kq/7b1R5sLjjHsk6h00Rb6XxlTafyh5+eJtBek2 ckmtBS8MaQqRHpyR6qC1MoXMFOiTf5tSZc4cwFmL7FjQZpuUqNouyygfv+8KMdKv mHa3a0KH6UcWwSZpeNP+8yQpMRDiMSInaBpg5rn/LeR7kwxLUBw5NRlJ6Qh/n4Lf QXIG8TUlqeQ7e6ij7ficBKvAmn3HQYEzCa2PnMksUZWwq4jiq8a2/b63IeKMFyPF bbn9rnO6iyUV/iCDNXFM9B36uO0AoEQ6w5eWeXIQWv+WjjC0TQr31409x9FVRyWn 8C7JXy/Jh+22PgGEHxV3OxdBRsJ5ZD26sayxy1cy5tNeW6O3eQPqsxya/6XYp9bO lJt3NzRwvcPaF4Zo3Rc3l6vI09YhwdSXEBHR3HyzDjNO8/Xs7VYvZnDnDuvJkR/l ce8PS+0sqaupDjlxcluR06/2VN3gC5offIdWN050hJW3HQjFmKifoWurU7GUOOzI yjdNGfiqFJpf6W3b6we2VvI+Az/0U4pYHrPHfr6C/bXXfP1fxmBK6JRAAJ5WXLuU D1peE2Zxu1ZAT2j1axD3JCiNib0HeVLDwZpCWWYBRxP5JsVzjRsGMzFfNN5fIv8J 4uHQyfTADiG5cvd2NO78Ea++GjHIDnX1qoHfqwkbOovm2ZCfN5s= =qj/F -----END PGP SIGNATURE----- --Apple-Mail=_212FE71A-1F59-4A20-AF3B-AF56B045B386--