How One Packet Capture Could Sink Your SOC 2 Audit - And Open You to Lawsuits

By Ramyar Daneshgar
Security Engineer | USC Viterbi School of Engineering

Disclaimer: This article is for educational purposes only and does not constitute legal advice.

Executive Summary

Protocols like Telnet, FTP, and POP3 are still present across many enterprise environments - including cloud-based vendors, managed service providers, and healthcare organizations. These older technologies predate modern security expectations and lack built-in encryption or integrity controls.

This is no longer a theoretical concern. When security auditors or regulators conduct investigations, one of the first things they examine is network communication - specifically whether your organization protects sensitive information in transit. Tools like Wireshark and tcpdump can reveal whether usernames, passwords, or business data are being sent unencrypted.

This article explains how legacy protocols expose organizations to legal risk, contractual breach, and SOC 2 audit failure. It provides a roadmap for identifying, remediating, and documenting protocol-related vulnerabilities before they appear in a regulator’s findings or courtroom discovery.

1. The Hidden Risk in Legacy Protocols

Legacy protocols were not designed for today’s internet threat landscape. Most of them transmit authentication and session data in plain text, which means any actor with access to internal traffic - such as a compromised endpoint or an insider - can read and misuse sensitive data.

Common examples include:

• Telnet: Used for remote login and device management without encryption.
• FTP: Sends files, including configuration backups and reports, in plain text.
• POP3 and IMAP: Pull emails from a mail server without requiring encryption by default.
• SMTP: Sends outgoing mail with no guarantee of encryption unless STARTTLS is enforced.

Why This Is Legally Significant

Several privacy and security laws require organizations to take “reasonable security measures”. That includes the expectation that any data transmitted across networks - whether internal or external - is protected from unauthorized access.

Continued use of these protocols violates those expectations. Even if a breach does not occur, the mere existence of these services can demonstrate negligence or lack of due diligence in court.

Regulations that mandate encryption or secure transmission include:

• California Privacy Rights Act (CPRA), Section 1798.100(e)
• General Data Protection Regulation (GDPR), Article 32
• Gramm-Leach-Bliley Act (GLBA), Safeguards Rule
• HIPAA Security Rule, 45 CFR § 164.312(e)(1)

Regulatory Example:
In In re Chegg, Inc. (FTC, 2023), the company was penalized for failing to secure user credentials. One of the cited failures was the use of transmission methods that lacked encryption. Chegg was ordered to implement a comprehensive security program and undergo biennial assessments for the next decade.

2. What SOC 2 Auditors Are Looking For

SOC 2 audits are based on five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. The most relevant criteria for protocol security fall under Security and Confidentiality.

Auditors are not only reviewing policy documents. They also examine actual evidence from your environment - this includes system configurations, firewall rules, and sometimes packet captures or screenshots of tools like Wireshark.

Below are examples of SOC 2 controls commonly violated when legacy protocols are detected:

Real-World Audit Scenario

An internal auditor reviewing network traffic sees that internal routers are managed using Telnet, not SSH. A tcpdump capture shows plaintext administrator passwords sent across the wire.

This becomes an audit finding. It shows the absence of encryption, failure to follow configuration management standards, and possibly failure to monitor high-risk activities.

Auditors escalate these issues, especially when customer data, login credentials, or sensitive business communications are involved.

3. How Packet Captures Create Legal Evidence

Every unencrypted packet can be used as proof of negligence. If there is a data breach or security investigation, opposing counsel, regulators, or third-party forensic teams may request logs, network captures, or system images.

Even if no breach occurred, the fact that plaintext credentials or internal documents were accessible in transit may be sufficient to:

• Trigger enforcement under CPRA, GDPR, or HIPAA
• Nullify a claim that "reasonable security measures" were in place
• Result in breach of contract if secure transmission was promised to customers or partners

Key takeaway: If your organization cannot prove that traffic was encrypted, you may not be able to defend against legal claims.

4. Common Protocol Vulnerabilities and Tools That Reveal Them

The tools below are commonly used by both red teams and auditors to detect insecure traffic:

Wireshark

Graphical network analysis tool. Filter traffic using protocol names like ftp, imap, telnet, or smtp. Shows session contents, login attempts, and email metadata.

tcpdump

Command-line packet capture. Use this to capture and review traffic live:

sudo tcpdump -A port 110  

Reveals POP3 traffic in ASCII, including username and password transmissions.

Ettercap / Bettercap

Used to simulate man-in-the-middle attacks, showing how unencrypted sessions can be intercepted and altered without detection.

Hydra

Brute-force attack tool to demonstrate lack of account lockout protections or use of weak credentials on services like IMAP or FTP.

These tools are powerful, but also available to anyone. Attackers, regulators, and auditors all use them to determine whether data in transit is protected.

5. Legal and Contractual Exposure

Continuing to use legacy protocols may put you in violation of:

• Data protection laws
• Vendor risk policies
• Cloud service agreements
• Data processing addenda (DPAs)

Many contracts now include clauses requiring encryption of data in transit. These clauses often state that data shall be "protected using industry-standard security controls, including TLS or equivalent secure transport methods."

If your systems continue to use Telnet or FTP, you may be in material breach of contract - even without a single incident occurring.

6. How to Mitigate the Risk Before It Appears in an Audit

1. Inventory and Identify Legacy Protocols

Use network scans or asset discovery tools to identify systems using ports associated with insecure protocols. Focus on port 23 (Telnet), 21 (FTP), 110 (POP3), 143 (IMAP), and 25 (SMTP).

2. Replace with Secure Equivalents

• Replace Telnet with SSH
• Replace FTP with SFTP or SCP
• Use IMAPS (port 993) and POP3S (port 995)
• Require STARTTLS for SMTP, or use SMTPS on port 465

3. Conduct Encrypted Transport Testing

Run Wireshark internally on common endpoints to validate that traffic is encrypted. If login credentials or emails are visible without decryption, the channel is not secure.

4. Update Policies and Contracts

Make encryption a required standard in internal security policies and vendor contracts. Reference specific controls such as SOC 2 CC6.6 or GDPR Article 32.

5. Document Compensating Controls

If you cannot remove a legacy service due to technical constraints, document what security layers are applied to mitigate risk. Examples include virtual LAN segmentation, encrypted tunnels, and access restrictions.

7. Summary Table: Common Legacy Protocols and Associated Compliance Failures

Conclusion

Insecure network protocols are no longer an internal IT concern - they are a legal liability and a clear sign of noncompliance.

Regulators, customers, and auditors increasingly expect that data in transit is encrypted by default. Failure to meet this expectation can lead to enforcement action, lost contracts, or reputational damage.

Using tools like Wireshark or tcpdump to evaluate your traffic gives you a chance to correct these weaknesses before they become public findings.

When designing or assessing your security program, the key question is not whether a breach has happened. The question is whether you can prove that sensitive data is being protected at every layer- including in transit.