Home M3AAWG Blog We Used to Be Able to Monitor the Network, Didn't We? A Look at Understanding and Safeguarding Network Integrity

Author: M3AAWG Data and Identity Protection Committee

In a recent members’ meeting hosted by the Messaging, Malware, Mobile Anti-Abuse Working Group, attendees learned more in a session, "We Used to Be Able to Monitor the Network, Didn't We?" about ensuring that ISP and enterprise security teams can continue to:

  • Get a baseline for what's "normal" or "typical" for their network
  • Dig into anomalous/unauthorized traffic they may discover (or have reported to them)
  • Prevent network abuse (while NOT getting in the way of legitimate use), and
  • Work any incidents that may arise.

Key items covered included:

I. Zero Trust

a. What is "Zero Trust?" and how does Zero Trust relate to a loss of ability to monitor?
b. Zero Trust as a top security priority for both the federal government and the enterprise
c. What Zero Trust pragmatically entails, including:    

▪ Multi-factor authentication
▪ Device inventories
▪ Networks segmented by application
▪ Encrypted DNS and web traffic
▪ Application testing
▪ Applications assumed to be Internet-exposed by default
▪ Data categorization
▪ Leveraging the cloud
▪ Logging and information sharing

d. Examples of how each of the above areas may have ALREADY been deployed e. The reality that there are a ton of additional details that should also be understood before sites decide that Zero Trust is the right solution for them and their company.

II. VPNs

a. The reality that the public is much more interested in virtual private networks (VPNs) than Zero Trust in particular or cybersecurity generally
b. The speaker clarified that VPNs means 3rd-party free or commercial VPNs, not enterprise VPNs
c. The reality that while a growing number of entities are promoting VPN adoption and use, VPNs can have both advantages AND drawbacks...
d. VPNs cause a loss of network visibility for local security teams, but if the VPN does its job well, any problematic behavior happening over the VPN becomes the VPN provider's problem
e. 3rd party VPNs may (paradoxically) NEGATIVELY impact the VPN user's privacy

▪ The VPN provider WILL be able to see the user's unencrypted traffic
▪ The VPN provider WILL know the identity of the VPN user
▪ The VPN may offer imperfect protection, "leaking" clues about your identity/what you're doing online
▪ VPN usage may limit the sites you can visit and increase the likelihood that your visit is viewed as potentially suspicious
▪ VPNs may not be permitted in all locations, a consideration for some travelers
▪ VPN service ownership may be hard or impossible to ascertain

f. Having considered the advantages and disadvantages of VPNs, sites should share guidance with their users

III. TLS 1.3

a. The difference between TLS 1.2 and 1.3 and why you should upgrade
b. Who's already got TLS 1.3 deployed, and how you can check other sites of your choice
c. TLS 1.3 Interception (TLS "Man In The Middle") and arguments in favor/against

IV. DoH

a. What stub-resolver-to-recursive-resolver traffic can tell an eavesdropper about a user
b. DNS over TLS, DNS over HTTPS and M3AAWG documents discussing the differences
c. The impact of 3rd party recursive resolvers on you and your users
d. Signaling your preferences with respect to stub-to-recursive resolver encryption (and the reality that trying to block encrypted DNS will just drive users to 3rd party VPNs)
e. The reality that 3rd party recursive resolvers are not all alike: the speaker discussed two important technical differences (how Qname Minimization is handled, and how EDNS0 Client Subnet Extension is handled)

V. ECH

a. Even when network sessions are protected with TLS encryption, network traffic still discloses the name of the site that users are visiting -- unless Encrypted Client Hello (ECH) is used
b. Unfortunately, ECH still hasn't seen much deployment to-date

You can find M3AAWG best practices at https://www.m3aawg.org/published-documents

The views expressed in DM3Z are those of the individual authors and do not necessarily reflect M3AAWG policy.