Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt

Bret Jordan <jordan.ietf@gmail.com> Mon, 15 July 2019 15:07 UTC

Return-Path: <jordan.ietf@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971F712015C for <secdispatch@ietfa.amsl.com>; Mon, 15 Jul 2019 08:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ixF1w-rWw6qt for <secdispatch@ietfa.amsl.com>; Mon, 15 Jul 2019 08:07:24 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B4F120167 for <secdispatch@ietf.org>; Mon, 15 Jul 2019 08:07:24 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id az7so8432709plb.5 for <secdispatch@ietf.org>; Mon, 15 Jul 2019 08:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9An9YjiEvFHUQTK28Q5c1nYoLy5wPreotca4uLsJF6E=; b=XIVKhzCHmW32nTSlc6mhG1ZKcG2RDN6PIa9AcRcmxyeZSw/VWm1dyRRVxnitOBYfVs RLvyrpHUpbmvZ5gFjYedz+gr3ieW+6SItC0QalqUGRmRvbGXoatwmdWS3bfOnBqNaJEH J9u7v/4wmqzTj+iT4kju7K2EsIyeVIwW8yYQAewKFfchmY/knOXjO3VvKo+B2NSI1E1W eGuBaA/vWo/TW2BzO9bOys/lO67xb7wDWh5aXiibdLRpATBFg+1w97DEgjY0Vzs0H/94 oRANApc9BOuyY3JMHnIsF7CEY5fgnlcTFFveAXFWS20sER77/9JYaZKyZOfvprE+hTCd ywpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9An9YjiEvFHUQTK28Q5c1nYoLy5wPreotca4uLsJF6E=; b=ZFAthBcpkvAHPCnvNgR9LNkQ5FFB2/WGCbJVNAlIUjaxcUv5dp/DDqjDhH4rb3XjKy 8DZp2eb7MxuIFQjpdaMKmSaOB5Jx6X7xvA9//vgxRS9eFgI8L+UiWyFRe7Bns3WyVtbW M8DNK+vnT8+4YD5W+2k9Fu+McxNGPDVXSTdErNe+2Ev6zQaMv8J1zDwc4mv8602jzEbd i2QOKM1MCEf+1F1RBLHUEaVAgvIgjSjxzx3KCNJihHJtkiUaUZ4bGKxtq9eebUAsVf+R Ul9vUQHa/aKxIfx41Jp6gFfqrL5T8L2N9Su/1r+hRTCOBgfks3y2Y2ljfeyBnrkYLUTl xJBg==
X-Gm-Message-State: APjAAAVDRgClM2mQgj1YOBGwq63YX/qB3sZ6gARZuwE+4dwzogqcH/aL fDVeA54dF9F47tVBmK4WOnA=
X-Google-Smtp-Source: APXvYqxGhwyHJJBn/hxtblcp/yUV+EtvlSt8CvCwGpjlclMa/I6HZkabNdtg85YyqOYtTQm0Ly9Frg==
X-Received: by 2002:a17:902:e287:: with SMTP id cf7mr28613368plb.32.1563203243740; Mon, 15 Jul 2019 08:07:23 -0700 (PDT)
Received: from ?IPv6:2605:a601:a990:4d00:c449:d519:8ae0:afe7? ([2605:a601:a990:4d00:c449:d519:8ae0:afe7]) by smtp.gmail.com with ESMTPSA id p15sm16802880pjf.27.2019.07.15.08.07.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 08:07:22 -0700 (PDT)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <A59918B5-C6B7-4632-B95F-E9AD24C16C96@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8AD0D2F-7809-4D28-807C-1CE9250CE918"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 15 Jul 2019 09:07:19 -0600
In-Reply-To: <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com>
Cc: Melinda Shore <melinda.shore@nomountain.net>, secdispatch@ietf.org, smart@irtf.org
To: Eliot Lear <lear@CISCO.COM>
References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <CAMm+Lwh3KW6ZBbMktwmLcKyY8=_ysLYJF_7MsAuiOat6baQ=Kg@mail.gmail.com> <B551EF79-7E6E-4C4E-ADCA-6538F7972222@gmail.com> <CAMm+Lwg+2RFiXK43nJv7pD3OgM8y=ziVYxBkXD3F2kJyz37SxQ@mail.gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <CAHbuEH5WUv-a4nKt5YAZosO-vE773Jh3xn1+-hA=4J7RBERc3g@mail.gmail.com> <45cc67f6-3dd4-9788-29e5-4cc82471e6ee@nomountain.net> <9683DFBC-1816-4C0A-8D8A-4CE36318C72C@cisco.com> <d5f05651-849f-4048-3123-8ee17a0c0a96@nomountain.net> <C2AD999E-2B53-4E17-B033-4B722ADFA677@cisco.com> <AC7FADF1-A556-46AF-9A5C-F464AA4772B9@gmail.com> <469416D4-F549-4CAD-9C81-3D4A5A271B6A@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/UvDqSp1mNQNa37tkF6w9NgXHz2w>
Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 15:07:28 -0000

Eliot,

However, many here assume that the endpoint can run security software, that security software is available for all endpoints, or that security software can be updated all at once across an organization/enterprise. Other also assume that if you just patched your software, you would be safe.  These assumptions are horribly wrong and goes to show the fundamental lack of understanding.

The reason I called them out the way I did was I was trying to be explicitly clear on where the attack was coming from and what role the endpoint had in that attack. I did not want to assume that everyone understood the attack surface and threat model. 

So a client may initiate the connection to a compromised site or content. This is a very common case for initial infection.  However, once the threat actor is in the network, they often move laterally through the network and compromise machines where the attack is not initiated from the victim endpoint, but rather initiated from a compromised endpoint. So what you can see and do to protect your network changes. 

All of this is pretty basic network/cyber security 101 stuff.  What the IETF needs to know is how SoC analysts need and require sensors on the network, network log data, and DNS data to help identify these attacks and find them. We always had a saying when I was on the other side of the fence, “operating systems and software can always be made to lie, but the network never does..” Network analysis and network forensics is a critical part of the day-to-day analysis in a SoC.  This is often how intrusion sets are detected and threat actors behavior in the network is tracked.  This is not about selling product as some believe. This is about organizations and enterprises protecting their systems, networks, and data.  

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 15, 2019, at 2:01 AM, Eliot Lear <lear@CISCO.COM> wrote:
> 
> Hi Bret,
> 
>> 
>> 1) Is the content or content provider that the user is going to compromised and trying to attack the endpoint?
>> 2) Is the content provider that the user is going to a stage 2 delivery site?
>> 3) Is the content provider that the user is going to the location for outbound malicious content (data exfiltration, CnC traffic)
>> 4) Is the content provider that the user is going to adversely tracking and monitoring everything the end client does, aka active surveillance versus passive surveillance?
>> 5) Is the remote site that the user did not go to attack the end point.
> 
> While we tend to think of endpoints as being equivalent in class, in which case your use of the term "content provider” would be somewhat redundant, from a scaling perspective I am far more concerned about unwatched unmanaged endpoints than I am about content services.  And again, to me it is a matter of what problems I think might be tractable.
> 
> Eliot