Data in Transit

Security teams usually describe data in three states: stored on a disk (data at rest), opened and processed by an application (data in use), and moving from one place to another (data in transit, also called data in motion). The third state covers everything from a message to a colleague to a backup copied to another site.

Data in transit is exposed in a particular way: it leaves the systems the organization controls and crosses networks, providers, and devices that it does not. That is why data protection programs treat it as a separate problem with its own controls, not as a side effect of storage security.

Business data travels through a handful of channels, and each one fails in its own way. Email is the oldest: a message may cross several servers before it arrives, and email monitoring sees it clearly only while it is still on systems the company controls.

The standard defense is TLS, the protocol behind HTTPS and many secure email and file-transfer connections. It succeeded the older SSL protocol, and the sequence is the same for most applications.

1. 1

   Negotiate

   Client and server agree on a protocol version and a set of encryption algorithms.

2. 2

   Authenticate

   The server presents a certificate, and the client checks it against the certificate authorities it trusts.

3. 3

   Exchange keys

   Both sides derive shared session keys without ever sending them in the clear.

4. 4

   Protect the traffic

   Data is encrypted and carries an integrity check, so any change on the way is detected.

Anexet watches data in transit on the workstation through its agents and through network traffic and website control. The profile screen shows which protocols are intercepted and whether encrypted traffic is included, and the certificate screen shows how encrypted web sessions are made readable for analysis.

1 / 2

• 
• 

Encryption answers one question: can someone on the path read or change the data? It does not ask whether the sender should be sending it. That gap is where most data exfiltration happens, because an employee who uploads a file over HTTPS is using a perfectly secure connection.

The failures are rarely about weak algorithms. They are about assumptions, and shadow IT makes the last one worse, because unapproved services add destinations that nobody reviewed.

• Trusting the internal network and leaving server-to-server traffic in plain text
• Turning off certificate checks to make an error disappear, which removes protection against impersonation
• Keeping legacy protocols such as plain FTP or HTTP because nothing has broken yet
• Assuming email is encrypted end to end when only some hops use encryption
• Treating HTTPS to any destination as safe, including personal storage and unapproved services

Most security and privacy frameworks expect data to be protected while it is transmitted, though each words it differently. GDPR asks for appropriate technical measures and names encryption as an example, the HIPAA Security Rule contains a transmission security standard, and PCI DSS requires strong cryptography when cardholder data crosses open public networks.

In an audit the question is evidence: which channels carry regulated data, which of them are encrypted, and what happens when one is not. A current map of data flows and a working compliance management routine make those answers quick to give.

Begin by mapping where confidential and regulated data really moves, then encrypt whatever still travels in plain text and inspect what leaves over encrypted channels. Encryption closes the road to outsiders, and a DLP system covers the road employees take legitimately.