Network models for security and operations

In practice, the model becomes valuable when you can place controls and signals correctly. This level is about security and operations thinking, grounded in correct network foundations.

Here is a simple way to avoid security theatre. Put each control where it can actually work.

Examples:

1. A strong password policy does not fix a broken access control check in an API.
2. TLS protects data in transit. It does not validate what the application does with data.
3. A firewall can block unwanted traffic. It cannot fix an unsafe query inside your code.

Use layers to place your controls, then verify the control with a test.

Worked example. The control you chose cannot physically help

A team sees credential stuffing attempts and responds by adding a Web Application Firewall rule. That might reduce noise at the edge, but it does not fix the real weakness if the application still allows unlimited login attempts, weak session handling, or poor MFA coverage.

My opinion: “security controls” should be treated like engineering, not like decoration. A control is only real if you can describe the failure mode it prevents and how you would test it.

Common mistakes (security theatre starter pack)

• Treating TLS as “security solved”. TLS is a transport protection, not an application authorisation strategy.
• Treating NAT as a firewall and assuming it provides policy.
• Spending time on controls that sound serious while leaving basic identity and logging gaps untouched.

Verification. A control is not real until you can test it

• State the control intent in one sentence. Example: “Only the app tier can reach the database tier on port 5432.”
• State the test. Example: “Attempt a connection from a blocked zone and confirm it fails, and that the block is logged.”

When a user says "the site is slow", you need signals that separate causes.

1. Link signals such as packet loss and retransmissions.
2. Transport signals such as connection time and resets.
3. Application signals such as response time and error rate.

If you only have application logs, you will miss many failure patterns.

When networking is “just web browsing”, bugs are annoying. When networking is control systems, safety systems, or critical infrastructure, bugs are expensive or dangerous. Formal methods exist because “we tested it a bit” is not a convincing argument when failure has a high cost.

Finite state machines (FSMs). The protocol is the allowed transitions

If you want a simple mental model: an FSM is a list of states and the events that move between them. Protocol specs often hide this behind prose. Implementations cannot. They must decide what to do for every packet in every state.

Petri nets. Concurrency is where protocols get weird

Petri nets are a way to model concurrent systems and prove properties like “no deadlock” or “this message eventually gets delivered”. You do not need to become a formal methods researcher to benefit. The practical takeaway is: concurrency plus retries plus timeouts creates edge cases you will not find by reading happy-path diagrams.

Verification. Steal the habit, not the vocabulary

• Write down the states that matter (even if informal).
• List the events that can occur out of order (timeouts, retries, duplicate messages).
• Define one safety property. Example: “We never apply the same command twice.”
• Define one liveness property. Example: “If the network recovers, the system eventually converges.”

Worked example. “The site is slow” is three different problems

When someone says “slow”, I immediately ask: slow to connect, slow to get the first byte, or slow to load everything. Those map to different signals: DNS + TCP + TLS timings, server response time (TTFB), and then asset loading.

My opinion: if you only watch averages, you are basically blind. Users feel tail behaviour. Averages are comforting. Percentiles are honest.

Maths ladder (optional). Percentiles, tail latency, and queues

Verification. A minimal signal set that actually separates causes

• DNS resolution time
• TCP connect time
• TLS handshake time
• Time to first byte (TTFB)
• Response status rate (4xx/5xx)
• Retransmission rate (when available)

Packet capture is observation. It is not exploitation. Only capture traffic you own or are authorised to inspect.

The goal in this course is interpretation:

1. Identify the protocols you see.
2. Confirm the order of events.
3. Relate a symptom to one layer boundary.

You do not need to craft attack traffic to learn these skills.

Common mistakes (captures edition)

• Capturing too much and drowning in noise instead of defining a hypothesis first.
• Forgetting that encrypted payloads are expected (TLS). You are often looking at metadata and timing, not the content.
• Capturing traffic you are not authorised to inspect. If you do not have permission, do not do it.

Verification. What you should extract from a safe capture

• Protocol order (DNS → TCP → TLS → HTTP)
• Evidence of retransmissions or resets
• Timing between events (where the wait is)

Segmentation is the practice of limiting which systems can talk to which systems. It reduces blast radius. It also makes incidents easier to contain.

I think in zones:

1. Public edge and CDN.
2. Application tier.
3. Data tier.
4. Admin and management plane.

The most common failure is letting the management plane become reachable from places it should not be.

Verification. A segmentation rule you can defend

• Draw the zones and list allowed flows.
• For one “should never happen” flow, state how you prevent it (policy) and how you detect it (logging/alerts).

Write a one page troubleshooting report for a made up incident. The incident can be "users cannot load the login page" or "some users get random timeouts".

Your report must include:

1. Symptom and impact.
2. Three hypotheses, one per layer boundary.
3. One test per hypothesis.
4. What evidence would confirm or disprove each hypothesis.

CPD evidence (operator-grade, still simple)

• What I studied: security by layer, observability signals, safe packet capture interpretation, segmentation and trust zones.
• What I produced: a one-page incident report with hypotheses, tests, and evidence.
• What changed in my practice: one habit. Example: “I will record connect time and TLS time separately from server response time.”
• Evidence artefact: the report plus a screenshot of the triage matrix choices.