Internet DRAFT - draft-witten-protectingendpoints
draft-witten-protectingendpoints
Network Working Group B. Witten
Internet-Draft Symantec
Intended status: Informational December 13, 2017
Expires: June 16, 2018
Necessity of Network and Third Party Protection of Endpoints
draft-witten-protectingendpoints-00
Abstract
This document describes the logic for third-party and network
security to complement strong cryptographic protocols, and presents
data, including independently verifiable data, helping scale the
importance of blocking attacks that might be hiding in encrypted
network traffic. This report includes data from multiple sources.
Some of that data is verifiable.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Witten Expires June 16, 2018 [Page 1]
Internet-Draft Network Protection of Endpoints December 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Relevant Data . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Number of Certificates Issued to Phishing Sites . . . . . 3
2.2. Attack Rates, first data provider . . . . . . . . . . . . 4
2.3. Attack Rates, second data provider . . . . . . . . . . . 4
2.4. Portion of Attack Traffic Already Hiding in HTTPS . . . . 4
2.5. Additional Observations . . . . . . . . . . . . . . . . . 5
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
A classic model of security emphasizes only "communications security"
between two "secure endpoints," with emphasis on both the need to
secure the endpoints, and the need to protect the communications
between those endpoints. Modern cryptographic protocols help protect
the communications. However, most endpoints still have
vulnerabilities. These vulnerabilities often have serious
consequences, including host compromise, and violation of any
confidentiality, integrity, and availability properties desired for
the information on the host and to which the host has access. Of
course, resultant consequences can be far worse for many parties
including consumers, activists, dissidents, commercial companies,
banks, utilities, and critical infrastructure of nearly all manner,
as well as anyone who depends on them. In this context, mitigation
of endpoint vulnerabilities is very important.
Mitigation of endpoint vulnerabilities is often achieved via
different means. For instance, security conscious and security
knowledgeable users and administrators often lock down endpoints with
strong operational security techniques. Alternatively, many users
and administrators with less security expertise often depend on third
party products to help protect their endpoints. Sometimes these
endpoint protection solutions install directly onto or into the
endpoint to be protected. However, sometimes the manufacturer of an
endpoint has produced a "closed" endpoint into which enough security
cannot be installed, or cannot be installed by anyone other than the
manufacturer who has already failed to install enough security. In
such cases, it's often possible to configure the endpoint and network
to ensure that all traffic to the endpoint is routed through a
security gateway attempting to protect the endpoint. This is often
done through either constraining the physical network topology, or by
Witten Expires June 16, 2018 [Page 2]
Internet-Draft Network Protection of Endpoints December 2017
trunking all of an endpoint's traffic through a Virtual Private
Network (VPN) which effectively connects the endpoint to the security
gateway. Note that with the rise of increasingly closed operating
systems for mobile and "Internet of Things" (IoT) devices, this model
of routing traffic through a security gateway is growing since such
vulnerable closed devices can only get additional security from the
network if not from the manufacturer who already failed to build in
adequate security.
2. Relevant Data
2.1. Number of Certificates Issued to Phishing Sites
In August of 2017, broadly trusted Certificate Authorities (CA)
including most commonly "Let's Encrypt," issued more than 4,800 TLS
certificates to phishing sites. Over the past year, these same CA's
issued more than 25,000 TLS certificates to phishing sites. We offer
below a conservative month by month count of TLS certificates issued
to phishing sites.
+----------------+-------+
| Month | Count |
+----------------+-------+
| August 2017 | 4,800 |
| July 2017 | 4,000 |
| June 2017 | 2,900 |
| May 2017 | 3,600 |
| April 2017 | 3,200 |
| March 2017 | 2,600 |
| February 2017 | 2,400 |
| January 2017 | 2,200 |
| December 2016 | 1,600 |
| November 2016 | 1,100 |
| October 2016 | 500 |
| September 2016 | 200 |
| August 2016 | 200 |
| July 2016 | 90 |
| June 2016 | 80 |
| May 2016 | 60 |
| April 2016 | 60 |
| March 2016 | 40 |
| February 2016 | 30 |
+----------------+-------+
Table 1: Conservative Counts of TLS Certificates Issued to Phishing
Sites
Witten Expires June 16, 2018 [Page 3]
Internet-Draft Network Protection of Endpoints December 2017
We note 20x year-over-year growth in issuance of TLS certificates to
phishing sites by trusted CA. We also note that phishing links are
distributed through many means including not only email but also
malicious web advertising often referred to as "malvertising," along
with other means such as SMS and instant messaging. We also note
that the numbers above do not include the vast number of legitimate
websites which are then later compromised and used for phishing along
with other types of attacks.
2.2. Attack Rates, first data provider
On a sampling of 90 million endpoints, in a given week of November
2017, 4 million of those endpoints were attacked. Of those 4 million
machines attacked in that week, more than 1 million were protected by
Intrusion Prevention Systems (IPS) inspecting network traffic. The
other 3 million were protected by other technologies.
2.3. Attack Rates, second data provider
A second source contributed data to this report. From that source,
for the month of October, 17.5 million users received 13 million
attempts at infection through malware, and 2 million attempts at
phishing. We also note that while some malware attempts are
malicious attachments, others are links to files which then
downloaded over FTP, HTTP, or HTTPS.
If the data is extrapolated, the data from both providers implies (a)
attack rates of more than 100 million attacks per year, and (b) each
endpoint would be compromised multiple times per year if not for the
third party security technologies protecting these endpoints, or some
other protection, such as tight operational security of the endpoints
on a level which is beyond the abilities of the average person. Of
course, every person, including consumers, deserve the right to
protect themselves and to choose the technologies and technology
providers they prefer to protect them.
2.4. Portion of Attack Traffic Already Hiding in HTTPS
A third source contributed data to this report. From that source, in
three days of January of 2017, over a million file download requests
were requests for malware. Of that million, more than 60,000 were
"second stage" requests. For this source, for that three-day period,
out of 1,396 of the most dangerous files, only 137 (9.8%) were from
HTTPS URLs.
That same source also sampled a period in November of 2017. From
that source, in three days of November of 2017, over 974,000 file
download requests were requests for malware. 117,000 of these
Witten Expires June 16, 2018 [Page 4]
Internet-Draft Network Protection of Endpoints December 2017
requests (roughly 12%) were confirmed as HTTPS or confirmed as TLS or
SSL. An additional 26% of those requests (total of 38% = 26% + 12%)
served files over port 443, but it was unclear whether the protocol
was HTTPS or something else.
2.5. Additional Observations
The data above in sections 2.2 and 2.3 does not include attacks
leveraging weaknesses in browser security models such as pop-under
mining of crypto-currency without the user's awareness [Tung], or
remote code exploitation vulnerabilities such as [rapid7] and
[Cimpanu], or CVE-2012-1845, CVE-2012-2897, CVE-2012-5112, CVE-
2012-5142, CVE-2016-1962, CVE-2016-1935, or over a dozen other high
severity remote code execution vulnerabilities found in browsers over
the past ten years. Of course, this is no criticism of browsers
specifically. All code has vulnerabilities. Concern stems from
those vulnerabilities being embedded in a "first line of defense"
running on the user's devices where mistakes can be quite damaging to
the device and the device's user. Instead, the reality that all code
has vulnerabilities should more strongly help drive urgency of
creating lines of defense in the network where exploitation of
vulnerabilities on disposable virtual machines can be far less
devastating than exploitation in the endpoint for an end user and
information on their device.
3. Conclusion
Precluding network based protection for endpoints is not consistent
with the imperative to treat mass surveillance as an attack. Mass
hacking of endpoints is surveillance by another means.
Endpoints currently face risks of compromise at a rate of a million
endpoints per week. Network based mitigation of endpoint
vulnerabilities is increasingly important to protecting those
endpoints.
Exposing millions of users per year to phishing, malvertising, and
countless other attacks, and denying them network based protection
against those attacks seems inconsistent with stated goals and
objectives of the IETF. Failing to standardize safer ways to provide
endpoints such network based protection against endpoint
vulnerabilities similarly seems to fall short of stated IETF goals
and objectives.
Witten Expires June 16, 2018 [Page 5]
Internet-Draft Network Protection of Endpoints December 2017
4. Informative References
[Cimpanu] Cimpanu, C., "RCE Vulnerability Affecting Older Versions
of Chrome Will Remain Unpatched", BleepingComputer rce-
vulnerability-affecting-older-versions-of-chrome-will-
remain-unpatched, August 2017.
[rapid7] Moulu, A., "Samsung Galaxy KNOX Android Browser RCE",
rapid7 samsung_knox_smdm_url, November 2017.
[Tung] Tung, L., "Windows: This sneaky cryptominer hides behind
taskbar even after you exit browser", zdnet windows-this-
sneaky-cryptominer-hides-behind-taskbar-even-after-you-
exit-browser, November 2017.
Author's Address
Brian Witten
Symantec Corporation
Email: brian_witten@symantec.com
Witten Expires June 16, 2018 [Page 6]
