Kathleen Moriarty

They Are Looking At WHAT? Service Provider Monitoring

Kathleen Moriarty
0 You have liked this article 0 times.

This is the second in a series of articles related to network and security management. This post digs deeper into the types of monitoring performed on internal and external networks to better understand considerations for your deployment plans.

Network operators, especially those managing enterprise networks and data centers have expressed concern with deploying TLSv1.3, which is normal at the start of an adoption curve. Through much work – listening  to operators and their explicit concerns – deploying  TLSv1.3 on Internet-based sessions terminating at the edge of the corporate network or data center is a logical first step that should not be business impacting. This conclusion is based on discussion with operators in several venues and contributions to “The Effect of Pervasive Monitoring on Operations”, a survey of management and monitoring techniques in use by operators on service provider and enterprise networks. Deployments on internal networks may require further study by organizations evaluating their network architecture, security policies, monitoring and management tool sets.

Service providers share their monitoring techniques

Much insight was gleaned in the survey as service providers discussed their monitoring techniques on the Internet. A reliable and trusted operator contributed that most of the monitoring performed is kept to packet headers for the transport, network, and data link layers. This information continues to be available in TLSv1.3, although handshake messages after the SERVERHELO are encrypted via the EncryptedExtensions, leaving some previously available information encrypted.  One such example is the application-layer protocol negotiation (ALPN), where the request is in the clear and the response is encrypted. The ALPN response includes the protocol to be used as selected by the server, offering confidentiality of this information from anyone observing the traffic that might be used subsequently. This may have some impact on monitoring requiring a shift in practices based on available information or the point of monitoring, possibly the edge versus network if this type of observation is permitted by policy at the edge.

Figure 1: Network layers of packet headers observed by Service Providers

One of our learnings from the survey was that when troubleshooting customers’ requests  requires additional information to debug an issue, service providers typically request the session capture information from the customer close to the edge.  Network monitoring remained limited to the headers previously mentioned. If the customer is fine exposing that information and provides it via a packet capture from their point of visibility, this type of debugging is still possible with TLSv1.3, or even IPsec, with a lower level of on-the-wire visibility. You may want to consider redacting information from packet content to avoid unintended data leakage.

TLSv1.3 adoption and deployment options

TLSv1.3 is a more secure protocol than TLSv1.2, with improved protection against interception and should be strongly considered to better protect your customers’ Internet-based sessions. We are in the learning curve prior to an adoption phase, understanding the clear benefits and where to deploy first will assist with adoption. The balance of monitoring and encryption is up to each organization, as is understanding when and where to deploy TLSv1.3.

TLSv1.3 provides forward secrecy and is provably secure (when 0-RTT is not in use) and should strongly be considered to protect sessions from interception on the Internet. 0-RTT enhances performance on session renegotiation when pre-shared keys are in use. This addition included in TLSv1.3 to assist with enhanced performance, but may not be right for your TLSv1.3 sessions. I recommend taking a hard look, considering whether 0-RTT is good match for the applications and data you are hosting. If performance is critical and outweighs the possible threat of a replay attack and loss of forward secrecy, implement with 0-RTT and the mitigation options. If you run business-critical servers with sensitive data, think twice about relying on the mitigation options. Instead, favor using an implementation that separates out the streams for 0-RTT and 1-RTT to also avoid possible configuration errors. 

Contribute to monitoring solutions

Turning toward enterprise and data center networks, the monitoring performed does include inspection of the packet payload at times. This may be the case for intrusion detection and information leakage monitoring, as well as debugging application-level problems. The difference for the enterprise scenario is that once inside the data center, the enterprise owns the data on their servers and has access to it anyway. For user sessions to the Internet, users are typically subject to monitoring per policy and user agreements from the time of employment. Organizations often have exceptions to this monitoring and exclude financial sites. For example, Germany has a legal expectation that employees have a right to perform some personal business from the workplace without interception. There have been two drafts submitted to date to the IETF detailing the types of monitoring performed and techniques used specific to enterprise and data center settings for visibility. They are open for contribution via the authors or on an IETF mailing list and include: TLS 1.3 Impact on Network-Based Security and Why Enterprises Need Out-of-Band TLS Decryption. Having this type of information as accurate and representative of real operational networks assists protocol designers as they consider use cases and possible solutions.

A previous blog details this problem a bit better with the transition to TLSv1.3. The final blog in this series will dive into the proposals for visibility and alternate solutions.

This has originially been published on the RSA blog.

0 You have liked this article 0 times.

You may also like

View more

About the author

Kathleen Moriarty, Chief Technology Officer, Center for Internet Security has over two decades of experience. Formerly as the Security Innovations Principal in Dell Technologies Office of the CTO, Kathleen worked on ecosystems, standards, and strategy. During her tenure in the Dell EMC Office of the CTO, Kathleen had the honor of being appointed and serving two terms as the Internet Engineering Task Force (IETF) Security Area Director and as a member of the Internet Engineering Steering Group from March 2014-2018. Named in CyberSecurity Ventures, Top 100 Women Fighting Cybercrime. She is a 2020 Tropaia Award Winner, Outstanding Faculty, Georgetown SCS. Kathleen achieved over twenty years of experience driving positive outcomes across Information Technology Leadership, IT Strategy and Vision, Information Security, Risk Management, Incident Handling, Project Management, Large Teams, Process Improvement, and Operations Management in multiple roles with MIT Lincoln Laboratory, Hudson Williams, FactSet Research Systems, and PSINet. Kathleen holds a Master of Science Degree in Computer Science from Rensselaer Polytechnic Institute, as well as, a Bachelor of Science Degree in Mathematics from Siena College. Kathleen authored "Transforming Information Security: Optimizing Five Concurrent Trends to Reduce Resource Drain", published July 2020.

Comments 0