Network security and common threats

A real-life situation

Kestrel Valley Clinics, a fictional company, runs six small clinics and one head office. Its network has a FortiGate at the edge, a single flat office LAN, a file server, and a remote access VPN that accepts a username and password. One Monday the file server's shares are encrypted and a ransom note is on every desktop. The investigation finds that nothing exotic happened: a phishing email, a stolen password, a VPN without MFA, an unpatched server and a network where every device could reach every other device. Each step could have been stopped by a control the company either lacked or had switched off. This lesson explains the threats in that chain, the layers that answer them, and where a FortiGate fits.

What network security protects: the CIA triad

Security decisions become clearer when you ask which of three properties is at stake. Most incidents damage more than one.

Ransomware is a good example of all three: it denies availability by encrypting files, and modern groups also copy the data first (a confidentiality breach) to threaten publication if the ransom isn't paid.

Assets, threats, vulnerabilities and risk

Four words carry most security conversations. Use them precisely:

• Asset: anything worth protecting. Data (patient records), systems (the file server), services (the VPN) and the network itself.
• Vulnerability: a weakness. An unpatched service, a default password, a firewall policy that allows all services, a user who trusts every email.
• Threat: something that could exploit a vulnerability. A criminal group, a worm, a careless insider, a power cut.
• Risk: likelihood multiplied by impact. You can't remove every threat, so you reduce likelihood (patch, filter, authenticate) or impact (segment, back up, encrypt), and accept what remains on purpose.

A firewall reduces risk mainly by shrinking the attack surface, the set of services an attacker can reach, and by inspecting what it still allows. Every policy you add increases the surface a little, which is why each one needs a reason.

Common threats

The threats below cause most real incidents. None is new, and most incidents chain several of them together.

Notice how many of these use ordinary protocols: phishing pages are HTTPS, C2 often looks like web or DNS traffic, exfiltration may be an upload to a real cloud service. A port-based firewall rule such as "allow TCP 443 to the Internet" can't tell them apart from normal work. That is the main reason firewalls grew into next-generation firewalls that inspect content, identify applications and check reputation.

How an attack unfolds

Security teams describe attacks as a chain of stages. Formal models such as the Lockheed Martin Cyber Kill Chain and MITRE ATT&CK name them in more detail; in plain terms most attacks look like this:

The useful insight is that the attacker must succeed at every stage, while the defender only needs to break one. A control that blocks C2 traffic, for example, can make an infected laptop harmless even after the antivirus missed the file.

Defence in depth

Defence in depth means several independent layers, chosen so that each catches what the one before it misses. No single product provides all of them.

Learn more: Network Segmentation · Firewall Placement, Segmentation and Zero Trust

Mapping threats to FortiGate features

A FortiGate contributes to several layers: perimeter, segmentation (internal policies between zones), part of identity (user-based policies, MFA for VPN) and logging. The table maps each threat to a control and to the FortiGate feature that implements it. The last column is honest about the limits.

Two features carry most of that table for encrypted traffic: SSL inspection decides how much of HTTPS the other profiles can see, and logging decides whether anyone notices.

Learn more: Security Profiles and Inspection Modes · SSL/TLS Inspection

Walk-through: one incident, layer by layer

Here is the Kestrel Valley incident, mapped to the course lab. The VPN terminates on FGT1's port1 (203.0.113.2), PC1 (10.0.1.10) is a receptionist's PC, and in this version of the story the file server sits in the same flat LAN.

Logs existed on the FortiGate but were kept only on its local disk, were overwritten within days, and nobody was alerted. With logs sent to FortiAnalyzer and an alert for VPN logins from new countries, stage 2 would have been noticed on the Friday. The lesson for design: no stage needed an advanced attacker, and every stage had a cheap control.

What this looks like on a FortiGate

On a FortiGate, most perimeter controls attach to a firewall policy. A policy that allows traffic without profiles only checks addresses, ports and users. The same policy with profiles also inspects what passes. In the GUI you set them in the policy dialog under Security Profiles; in the CLI they are fields of the policy:

• utm-status enable turns security profiles on for the policy.
• ssl-ssh-profile sets how much of encrypted traffic is visible. certificate-inspection reads only the server name and certificate, which is enough for web and DNS category decisions but not for scanning file contents.
• av-profile, ips-sensor, webfilter-profile, dnsfilter-profile and application-list attach the antivirus, IPS, web filter, DNS filter and application control profiles.
• logtraffic all logs every session the policy allows, not only security events. It costs log storage, so decide per policy.

Verification

Signatures and ratings are only useful if they are current. Check the FortiGuard databases and when they last updated:

FGT1 # diagnose autoupdate versions
AV Engine
---------
Version: 7.00xxx
Contract Expiry Date: Mon Mar 15 2027
Last Updated using scheduled update on ...
Last Update Attempt: Mon Oct 12 05:41:00 2026
Result: No Updates
...
IPS Attack Engine
---------
...
Application Definitions
---------
...

Then confirm that logs leave the box. show log fortianalyzer setting shows whether FortiAnalyzer logging is enabled and to which server; in the GUI, Log & Report shows recent security events, and an empty IPS or antivirus log on a busy policy is a reason to check that the profiles are really attached.

What can go wrong

IPS and antivirus are enabled, yet the logs show nothing

Weeks of traffic, and not one security event. It looks like a quiet network; usually it is a blind one.

Malware still calls home although the DNS filter is on

The DNS filter logs show nothing for the infected host, but IPS or the endpoint reports C2 traffic.

An internal infection spreads although the perimeter is tight

Every PC and server sits in one VLAN, so traffic between them doesn't pass through the FortiGate.

Enterprise use and design guidance

• Start from the assets. List what matters most (patient data, payment systems, backups) and design layers around it, rather than starting from a product list.
• Treat remote access as Internet-facing. VPN gateways and their login pages are a common first target. Require MFA, limit sources where you can, and patch the firewall promptly.
• Segment by role and risk. Users, servers, guests, IoT and management each get their own zone. Internal policies are where lateral movement is stopped.
• Plan for encrypted traffic. Decide where deep inspection is used and where privacy or pinned applications require exemptions.
• Centralise logs. Send logs off the device to FortiAnalyzer or a SIEM, keep them long enough for an investigation (often months), and alert on high-value events.

Best practices

• Allow only the services each policy needs; avoid all as a service on anything but tightly scoped policies.
• Require MFA for remote access and for administrator logins.
• Keep FortiGuard subscriptions active and check that databases update.
• Patch Internet-facing systems first, including the FortiGate itself, and follow Fortinet's PSIRT advisories.
• Keep backups offline or immutable, and test restores.
• Review logs regularly, and alert on VPN logins, admin logins and blocked C2 attempts.

Key takeaways

Check yourself

Next: how firewalls themselves evolved in Stateless, stateful and next-generation firewalls, then where to place them in Firewall placement, segmentation and zero trust.