2.2Impact on data visibility

Even once you can choose a data source (previous section), that data may not reflect the truth in the first place. Networks are full of technologies that legitimately rewrite or hide traffic, and as a side effect the visibility of monitoring data drops. For example, if NAT/PAT rewrites the IP, the "source IP" in a boundary log is no longer the real endpoint, and if encryption is in play the content is unreadable. This section builds familiarity with the representative visibility-reducing technologies and the analyst's perspective of judging where to re-obtain information that has become invisible.

2.2.1Rewriting/hiding addresses and paths

• NAT/PAT translates many internal private IPs to one global IP (plus ports). In logs outside the boundary, all sources appear as the same global IP, so which internal endpoint is unclear. Correlation requires the NAT translation table (who used which port when) matched against inside logs.
• An ACL (access control list) is a filter, but for visibility a deny/permit without logging (silent drop) can hide the existence of a flow from later investigation. Over-narrowing what an ACL mirrors/logs creates blind spots absent from the monitoring data.
• Load balancing distributes traffic across multiple servers or paths. One logical conversation is scattered across several physical paths or servers, so a single sensor misses the whole picture and logs are split across different backends. Correlation needs the load balancer's logs joined with the backend logs.

2.2.2Wrapping content and anonymizing

• Encryption makes the payload unreadable. Traffic protected by TLS etc. hides its content (sent data or commands) from monitoring, and even a full tcpdump yields no cleartext. Countermeasures: decrypt where you need visibility (TLS inspection), or pivot to correlation via metadata (NetFlow, fingerprints like JA3) that does not rely on content.
• Tunneling and encapsulation wrap one protocol inside another. Many uses are legitimate (VPNs), but they can hide traffic that should be blocked inside a permitted path (e.g., DNS or HTTPS), slipping past naive port/protocol checks. Without content inspection or app identification (AVC), it goes unnoticed.
• TOR relays traffic through multiple nodes with layered encryption to anonymize the source. From the boundary the peer appears as a TOR exit/entry node rather than the true destination, making destination-IP reputation and attribution hard. P2P has many peers talking directly, so there is no central-server log and traffic is distributed and hard to trace.

In the SOC you are investigating an incident where the boundary firewall log shows "heavy access from global IP 203.0.113.10 to a suspicious external site." But 203.0.113.10 is the company-wide PAT post-translation address, so in the boundary log every internal endpoint appears as this same IP. Reporting only "the source is 203.0.113.10" is incomplete triage that overlooks the NAT-induced visibility loss. The correct move is to key on the outside destination IP + destination port + timestamp and match against the NAT/PAT translation table (or the inside PAT logs) to pin down the real internal private IP that held that port at that instant. Next, if that endpoint's traffic is encrypted (HTTPS), tcpdump yields no cleartext. So you switch tactics and assess maliciousness without content—using NetFlow metadata (destination, frequency, byte counts), web-filter reputation/category, and, if needed, adding the target to TLS inspection. Further, if the traffic is DNS tunneling (data embedded in DNS queries), port 53 is permitted in many environments and slips past naive policies—here the clue is metadata anomalies such as query length or subdomain entropy (randomness). The lesson is clear: do not let visibility-reducing technologies (NAT, encryption, tunneling, TOR) end at "we cannot see"; always design "in which other layer/log can I re-obtain the same fact"—that is the analyst's correlation skill.

2.2.3Section summary

• NAT/PAT collapses many internal endpoints to one global IP, hiding the true source; identification needs correlation with the translation table/inside logs
• Encryption, tunneling/encapsulation, and TOR hide content, the real protocol, or the source; re-obtain via metadata correlation, app identification, and reputation
• P2P, load balancing, and over-suppressed ACL logging scatter/split traffic and create blind spots; recover the whole picture via log joining and sensor placement