Least privilege
Every person, device and service gets only the access its job needs, for only as long as it needs it. Admin rights are separate accounts, used through a jump host and logged.
Security fundamentals
The security basics every design rests on
Every secure network I design uses the same building blocks: identity, encryption, certificates, TLS (Transport Layer Security) and IPsec (Internet Protocol security) tunnels, and well guarded switch ports. This page shows how each one works, with diagrams you can step through.
Overview
Three goals, many controls
Every security control I design protects at least one of three things: confidentiality, integrity and availability, often called the CIA triad. Switch between them to see what each one guards against.
Swipe sideways to see the whole diagram.
Confidentiality. Only the people meant to read data can read it. Encryption in transit (TLS, IPsec, and MACsec, the IEEE (Institute of Electrical and Electronics Engineers) 802.1AE link encryption) and at rest, plus access control, keep it that way. Anyone who copies the link sees only ciphertext.
Integrity. Data arrives exactly as it was sent. A keyed hash (HMAC, a hash based message authentication code) or a digital signature travels with the data, so any change, accidental or deliberate, makes the check fail and the receiver rejects it.
Availability. The service is there when people need it. Redundant links and devices, spare capacity, DDoS (distributed denial of service) protection and tested backups keep it running when something fails or is attacked.
Defence in depth
No single control stops everything, so I layer them: the edge, segmentation, identity, hardened workloads and monitoring. Each layer catches what got past the one before.
Zero trust
Being on the network earns no trust. Every request is checked against identity, device health and policy. I show how I build it on the security page.
AAA
Who you are, what you may do, and what you did
AAA stands for authentication, authorisation and accounting. On every network device I build, logins go to a central server rather than local passwords, so access can be granted, limited, audited and removed in one place. Follow an engineer logging in to a switch over SSH (Secure Shell), checked by a TACACS+ (Terminal Access Controller Access Control System Plus) server on TCP (Transmission Control Protocol) port 49, here Cisco ISE (Identity Services Engine).
Swipe sideways to see the whole diagram.
The engineer opens an SSH (Secure Shell) version 2 session to the switch with their own named account. Shared logins such as "admin" hide who made a change, so I never use them day to day.
The switch passes the login to a TACACS+ (Terminal Access Controller Access Control System Plus) server, here Cisco ISE (Identity Services Engine), which checks the password and group in the directory. Multi factor authentication can sit here too.
TACACS+ can check every command. Read only staff can look but not change. Network engineers can configure but not erase the switch. The policy lives in one place, not on every device.
Every login and every command is recorded with the user and the time. When something changes without a change record, accounting shows who did it and when.
If the servers cannot be reached, the switch falls back to a local break glass account. Its password is sealed and rotated, and using it raises an alarm. I test the fallback before I save any AAA change.
RADIUS and TACACS+ side by side
| Point | RADIUS (Remote Authentication Dial In User Service) | TACACS+ |
|---|---|---|
| Main use | Network access: 802.1X on switches and Wi-Fi, VPN (virtual private network) logins | Device administration: logins to switches, routers and firewalls |
| Transport | UDP (User Datagram Protocol) 1812 for authentication, 1813 for accounting (older kit uses 1645 and 1646) | TCP 49 |
| Encryption | Only the password field is hidden. RadSec (RADIUS over TLS) protects the rest. Since BlastRADIUS (CVE-2024-3596), every server and client should require the Message-Authenticator attribute. | The whole body is obfuscated with a shared secret, which is weak; RFC (Request for Comments) 9887 adds TLS 1.3 |
| AAA functions | Authentication and authorisation travel together in one reply | Authentication, authorisation and accounting are separate, so each command can be checked |
| Standard | Open standard (RFC 2865 and RFC 2866) | Cisco designed, published as RFC 8907 |
Encryption
Keys, hashes and signatures
Four building blocks sit under almost every secure protocol I deploy. Once these are clear, TLS, IPsec, SSH and 802.1X are just different ways of putting them together. The figure uses AES (Advanced Encryption Standard), RSA (Rivest, Shamir and Adleman), ECIES (Elliptic Curve Integrated Encryption Scheme) and SHA (Secure Hash Algorithm).
Swipe sideways to see the whole diagram.
Symmetric encryption. One secret key encrypts and decrypts. AES (Advanced Encryption Standard) with 128 or 256 bit keys, usually in GCM (Galois/Counter Mode), carries almost all data in TLS, IPsec and on disks. The hard part is getting the same key to both ends safely.
Asymmetric encryption. Each side has a key pair. What one key encrypts, only the other can decrypt, so a public key can be shared with anyone. It is far slower, so protocols use it to agree or protect a symmetric key, then switch to AES.
Hashing. A hash turns any data into a fixed length digest. SHA-256 is the usual choice; MD5 (Message Digest 5) and SHA-1 are broken and I remove them. Add a shared key and it becomes an HMAC (hash based message authentication code), which proves the data is unchanged and came from someone holding the key. Passwords need a slow, salted function such as PBKDF2 (password based key derivation function 2), scrypt or Argon2 instead, so guessing is expensive.
Digital signature. Alice hashes the message and signs the hash with her private key. Bob checks it with her public key. A match proves the message came from Alice and was not changed. I verify a software image's hash or signature before every upgrade.
How two sides agree a secret in public
Diffie-Hellman key exchange lets two devices agree a shared secret over a link anyone can watch, without ever sending the secret. TLS, IPsec and SSH all start this way. The numbers here are tiny so you can check them by hand.
Swipe sideways to see the whole diagram.
Alice and Bob agree two public numbers: a prime p and a generator g. Anyone may see them. Here p is 23 and g is 5, small enough to check by hand. In the paint picture, this is a shared base colour.
Each side picks a secret it never sends. Alice picks 4 and Bob picks 3. In the paint picture, each adds its own secret colour to the base.
Each side sends g to the power of its secret, mod p. Alice sends 5⁴ mod 23, which is 4. Bob sends 5³ mod 23, which is 10. The eavesdropper sees 23, 5, 4 and 10, like seeing mixed paint without knowing the secret colours.
Alice raises Bob's 10 to her secret: 10⁴ mod 23 is 18. Bob raises Alice's 4 to his: 4³ mod 23 is also 18. Both now hold 18, which never crossed the link. It seeds the session keys.
Real exchanges use primes of 2048 bits or more, or elliptic curves such as P-256 (IKE group 19) and X25519. Finding the secret from 4 is the discrete logarithm problem, which is impractical at that size. Newer hybrid exchanges add ML-KEM (module lattice key encapsulation mechanism), a post quantum algorithm.
Try it: work out a shared secret
Pick a prime, one of its generators and two secrets. Each side's working is shown, and both arrive at the same number. Real systems use numbers hundreds of digits long.
Alice sends A = 5⁴ mod 23 = 4. Bob sends B = 5³ mod 23 = 10.
Alice works out 10⁴ mod 23 = 18. Bob works out 4³ mod 23 = 18. Both hold 18.
The building blocks at a glance
| Building block | What it gives | What I use | Where I meet it |
|---|---|---|---|
| Symmetric encryption | Confidentiality at high speed | AES-128 or AES-256 in GCM, or ChaCha20 with Poly1305 | TLS and IPsec data, MACsec on links, disk encryption |
| Asymmetric encryption | Key agreement and encryption to a public key | Elliptic curve Diffie-Hellman, RSA 2048 bits or more | TLS and IKE key exchange, certificates |
| Hash | A fingerprint that shows any change | SHA-256 or SHA-384. MD5 and SHA-1 are retired. | Checking software images before an upgrade |
| HMAC | Integrity plus proof of a shared key | HMAC with SHA-256 | IPsec, OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol) authentication, API (application programming interface) signing |
| Digital signature | Proof of who sent it, and that it is unchanged | ECDSA (Elliptic Curve Digital Signature Algorithm), EdDSA (Edwards curve Digital Signature Algorithm), RSA | Certificates, signed software, code signing |
MACsec
MACsec (IEEE 802.1AE) encrypts each Ethernet link hop by hop at line rate with AES in GCM mode. Keys come from MKA (MACsec Key Agreement, defined in the 2010 edition of IEEE 802.1X), using a pre shared CAK (connectivity association key) or keys from 802.1X. Each switch decrypts and encrypts again, so the traffic is clear inside the box.
Certificates and TLS
Proving who is on the other end
Encryption is useless if you are talking to the wrong server. A PKI (public key infrastructure) binds a name to a public key with a certificate that a trusted CA (certificate authority) has signed. Follow one certificate from its CSR (certificate signing request) to revocation through a CRL (certificate revocation list) or OCSP (Online Certificate Status Protocol). The root key lives in an HSM (hardware security module).
Swipe sideways to see the whole diagram.
The server makes a key pair and sends a CSR (certificate signing request) holding its public key and the names it wants to prove. The private key never leaves the server.
The intermediate CA checks the server really controls those names, then signs the certificate. The root CA signed the intermediate and is kept offline, its key in an HSM (hardware security module), so a breach of the intermediate can be recovered from.
During the TLS handshake the server sends its certificate and the intermediate. Forgetting the intermediate is one of the most common reasons a site works in one browser and fails in another.
The browser checks each signature up the chain to a root it already trusts, then the name and the valid from and to dates. Any failure stops the connection with a certificate warning.
If a key leaks, the CA revokes the certificate and publishes it on a CRL (certificate revocation list) or answers OCSP (Online Certificate Status Protocol) queries. Public certificates now last 200 days at most, falling to 47 days by 2029, so I automate renewal.
The TLS handshake, version 1.2 and 1.3
Swipe sideways to see the whole diagram.
TLS 1.2. Two round trips pass before any data flows. I only allow key exchange with ECDHE (elliptic curve Diffie-Hellman with temporary keys), so each session gets fresh keys and a stolen server key cannot decrypt old traffic. That property is called forward secrecy. Old RSA key exchange lacks it, so I turn it off.
TLS 1.3. The client sends its key share in the first message, so the handshake takes one round trip and everything after ServerHello is encrypted, even the certificate. Only forward secret key exchange and modern ciphers remain. Encrypted Client Hello can now hide the server name as well. I make it the default and keep TLS 1.2 only where something still needs it.
Running certificates well
| Stage | What I do |
|---|---|
| Inventory | Every certificate, its owner, where it is installed and when it expires, found by scanning, not by memory. Expired certificates are one of the most common causes of outages. |
| Issue | Public sites use a public CA. Internal devices, 802.1X and VPNs use an internal CA, with the root offline and its key in an HSM. |
| Renew | Automated with ACME (Automatic Certificate Management Environment) where possible. Under CA/Browser Forum rules, public certificates last 200 days at most from March 2026, 100 days from March 2027 and 47 days from March 2029. |
| Revoke | Revocation is published on CRLs and, by some CAs, through OCSP. Let's Encrypt switched OCSP off in August 2025 and now uses CRLs only, so I make sure clients can reach the CRL points. Where OCSP is used, the server can staple a fresh response into the handshake. Browsers usually soft fail, carrying on when they cannot get an answer. |
| Plan ahead | Post quantum cryptography is coming. The NCSC (National Cyber Security Centre) asks organisations to finish discovery and planning by 2028, move the most important systems by 2031 and complete migration by 2035, starting with a list of where cryptography is used. |
IPsec
How a VPN tunnel comes up
IPsec protects traffic between two sites' LANs (local area networks), or a user and a site, at Layer 3, even through NAT (network address translation). IKE (Internet Key Exchange) agrees the keys and ESP (Encapsulating Security Payload) carries the data in SAs (security associations). Step through an IKEv2 tunnel build. The deeper VPN designs and fault finding are on the wide area network and VPN page.
Swipe sideways to see the whole diagram.
A host in LAN A sends to LAN B. Router A matches the traffic to the tunnel, through a crypto policy on a policy based VPN or a route into a tunnel interface on a route based VPN, and starts IKE on UDP 500.
Two messages agree the IKE proposal (encryption, integrity and Diffie-Hellman group), swap key shares and nonces, and detect any NAT on the path. The routers now share keys that protect the rest of IKE.
Two encrypted messages prove each side's identity with a certificate or a pre shared key, and build the first child SA (security association) for data, with its traffic selectors. That is four messages in all, against nine in IKEv1 main and quick mode.
Data travels in ESP (Encapsulating Security Payload, Internet Protocol number 50). There are two one way SAs, each with its own SPI (security parameter index). One side's encrypt counter should rise with the other side's decrypt counter.
ESP has no ports, so a NAT device cannot track it. When IKE_SA_INIT detects NAT, both sides switch to UDP 4500 from IKE_AUTH onwards and wrap ESP in UDP. A tunnel that works without NAT but fails through it usually means UDP 4500 is blocked.
Before a lifetime runs out, CREATE_CHILD_SA builds fresh SAs. With PFS (perfect forward secrecy) it runs a new Diffie-Hellman exchange, so one stolen key cannot decrypt earlier traffic. Dead peer detection clears SAs for a peer that has gone.
What ESP does to a packet
Swipe sideways to see the whole diagram.
Transport mode. The original IP header stays, and only the payload is encrypted. The ICV (integrity check value) at the end proves nothing changed. It suits host to host traffic, and GRE (Generic Routing Encapsulation) over IPsec, where GRE already adds the outer header.
Tunnel mode. The whole original packet is encrypted and a new IP header carries it between the gateways. This is the normal mode for site to site VPNs. The extra headers cost bytes, so I check the MTU (maximum transmission unit) and clamp the TCP MSS (maximum segment size).
NAT traversal. A UDP header on port 4500 gives a NAT device something to track. Firewalls between the peers must allow UDP 500, UDP 4500 and, without NAT, ESP itself.
AH (Authentication Header, IP protocol 51). AH checks the whole packet, including the IP header apart from fields that change in transit, such as the TTL (time to live), but encrypts nothing. Any NAT changes the header and breaks the check, so I use ESP, which gives encryption and integrity together.
| Point | IKEv1 | IKEv2 |
|---|---|---|
| Messages to the first tunnel | Main mode 6, plus quick mode 3. Aggressive mode uses 3 but exposes the identity. | 4: IKE_SA_INIT and IKE_AUTH |
| NAT traversal and dead peer detection | Add on extensions | Built in, plus MOBIKE (IKEv2 mobility and multihoming) so a remote user keeps the tunnel when their address changes |
| Authentication | The same method both sides | Each side can differ, and EAP (Extensible Authentication Protocol) suits remote users |
| Rekeying | New quick mode exchanges | CREATE_CHILD_SA, cleaner and with fewer drops |
| Errors | Vague | Clear notifications such as NO_PROPOSAL_CHOSEN and TS_UNACCEPTABLE |
| Algorithms to remove | DES (Data Encryption Standard), 3DES, MD5, SHA-1 and Diffie-Hellman groups 1, 2 and 5, still offered by many old peers | The same list. Government networks follow the customer's crypto policy and NCSC (National Cyber Security Centre) guidance |
| My choice | Only for an old peer that cannot do better | The default, with AES-256 GCM, SHA-256 or stronger as the IKE PRF (pseudo random function), and Diffie-Hellman group 19 or 20 |
Attacks
Know the attack, place the defence
Most attacks I design against are old and well understood. The skill is putting the right control at the right layer. Here is a classic one, ARP (Address Resolution Protocol) spoofing, and the switch feature that stops it. A fake reply on the same VLAN (virtual local area network) ties the gateway's address to the attacker's MAC (media access control) address.
Swipe sideways to see the whole diagram.
Normal. The laptop uses ARP (Address Resolution Protocol) to learn the gateway's MAC address, then sends every off subnet packet there. ARP has no authentication, so it believes any reply.
ARP spoofing. A device on the same VLAN sends unrequested ARP replies saying it owns 10.1.1.1. The laptop updates its table and sends traffic through the attacker, who can read it or change it and pass it on. That is a man in the middle attack.
Dynamic ARP inspection. The switch checks each ARP against the DHCP (Dynamic Host Configuration Protocol) snooping binding table on untrusted ports and drops any that do not match. TLS with proper certificate checks still protects the data if something gets through.
Common attacks and how I stop them
| Attack | How it works | What stops it |
|---|---|---|
| DDoS | A flood fills a link, a server or a firewall's session table | Upstream scrubbing, rate limits, spare capacity and anycast for public services |
| Man in the middle | An attacker relays traffic between two parties and reads or changes it | TLS with certificate checks, dynamic ARP inspection, 802.1X and MACsec |
| ARP spoofing | Fake ARP replies point the gateway's address at the attacker | Dynamic ARP inspection backed by DHCP snooping |
| DHCP starvation and rogue DHCP | The real pool is exhausted, then a fake server hands out a bad gateway or DNS (Domain Name System) server | DHCP snooping, port security and DHCP rate limits |
| MAC flooding | Thousands of fake MACs fill the switch's table, so it floods every frame to every port | Port security with a MAC limit per port |
| VLAN hopping | The attacker talks a port into trunking, or double tags a frame to reach another VLAN | Fixed access ports, trunk negotiation off, an unused native VLAN |
| Phishing | A message tricks someone into handing over a password or running malware | Phishing resistant MFA (multi factor authentication) such as FIDO2 (Fast Identity Online) keys, mail filtering, training |
| Ransomware | Data is stolen and encrypted, then a payment is demanded | Segmentation, patching, endpoint detection, immutable backups and tested recovery |
| SQL (Structured Query Language) injection | Crafted input runs commands in the database | Parameterised queries, input validation and a WAF (web application firewall) |
| XSS (cross site scripting) | Injected script runs in another user's browser | Output encoding, a Content Security Policy and a WAF |
| Password spraying | A few common passwords are tried against many accounts | MFA, banned password lists, smart lockout and alerts on failures spread across many accounts |
Layer 2 security
Guarding the access port
Most attacks start from a device plugged into a wall port. A few switch features, built on each other, stop the classic Layer 2 tricks. Step through them on one access switch: DHCP snooping, DAI (dynamic ARP inspection), IPSG (IP source guard) and port security.
Swipe sideways to see the whole diagram.
With DHCP snooping on, the uplink to the real server is trusted and access ports are not. As the laptop gets its lease, the switch records the IP address, MAC address, VLAN and port in a binding table. The next three features all use that table.
A rogue DHCP server, often a home router plugged in by mistake, answers on an untrusted port. The switch drops server replies there, so nobody gets a bad gateway or DNS server.
Dynamic ARP inspection (DAI) checks every ARP on untrusted ports against the binding table. The attacker's claim to own the gateway's address does not match, so it is dropped and logged.
IP source guard (IPSG) builds a filter per port from the table. Port 3 never got 10.1.1.20, so packets it sends with that source address are dropped.
Port security limits each port to a set number of MAC addresses, usually two or three for a phone and a computer. A flood of fake MACs breaks the limit and the port is shut into err disabled state, with an alert.
The access port baseline I build
| Feature | What it stops | Key setting on Cisco IOS XE | How I roll it out |
|---|---|---|---|
| DHCP snooping | Rogue DHCP servers and starvation | ip dhcp snooping vlan 20 and ip dhcp snooping trust on uplinks | First, VLAN by VLAN, and wait a full lease period so the table fills. Option 82 is inserted by default; if the server or an upstream switch drops it, use no ip dhcp snooping information option |
| Dynamic ARP inspection | ARP spoofing and man in the middle | ip arp inspection vlan 20 | After snooping. Static hosts need an ARP ACL (access control list) or a static binding |
| IP source guard | Spoofed source addresses | ip verify source on the access port | Last, once bindings are stable and saved to flash |
| Port security | MAC flooding and unknown devices | switchport port-security maximum 3 | Violation modes: protect drops silently, restrict drops and logs, shutdown err disables the port. I start with restrict, then shutdown. Sticky MACs stay tied to the old port after a desk move, so I clear them. 802.1X is the stronger control |
| Storm control | Broadcast storms spreading | storm-control broadcast level 1.00 | Baseline real traffic first; trap before shutdown |
| BPDU (bridge protocol data unit) guard | A rogue switch joining spanning tree | spanning-tree bpduguard enable with PortFast | On every edge port, with err disable recovery decided by policy |
| Trunk hygiene | VLAN hopping | switchport mode access and switchport nonegotiate | Unused native VLAN, never VLAN 1 for users, allowed VLANs pruned |
| 802.1X with MAB (MAC authentication bypass) | Anything unknown getting on the network | Identity based access with MAC authentication bypass (MAB) for devices without a supplicant | Monitor mode, then low impact, then closed. Details on the security page |
Switch spoofing
A port left in a dynamic mode can be talked into trunking with DTP (Dynamic Trunking Protocol), giving the attacker every VLAN. I set every port to access or trunk on purpose and turn negotiation off.
Double tagging
A frame with two 802.1Q tags arrives on the native VLAN. The first switch strips the outer tag and the next one reads the inner tag. It only works one way and only from the native VLAN, so an unused, tagged native VLAN stops it.
Private VLANs
Hosts in an isolated private VLAN can only reach the promiscuous port, usually the gateway. Hosts in a community can also reach each other. I use them for DMZ (demilitarised zone), backup and management networks where neighbours should never talk.
Management plane
Protecting the device that protects the network
A router or firewall has three planes: data (traffic passing through), control (routing protocols) and management (logins and monitoring). An attacker who owns the management plane owns the device. CoPP (control plane policing) keeps the processor alive under attack, whether the traffic is routing, SNMP (Simple Network Management Protocol), ping over ICMP (Internet Control Message Protocol) or a flood.
Swipe sideways to see the whole diagram.
Control plane policing. Traffic to the device itself is classified and given a rate. Routing protocols always get through, management is allowed only from known sources, ping is limited, and everything else is held to a small cap, so a flood cannot starve the processor and drop routing neighbours.
My hardening baseline for network devices
| Control | What I set | Why |
|---|---|---|
| Logins | SSH version 2 only, Telnet off: ip ssh version 2, transport input ssh, and an access class allowing jump hosts only | Credentials never cross the network in clear text |
| AAA | TACACS+ for staff, a sealed local break glass account, command accounting | Named people, least privilege and an audit trail |
| SNMP | SNMPv3 at the authPriv level (authentication and encryption) only; versions 1 and 2c off | Community strings travel in clear text |
| Time | At least three NTP (Network Time Protocol) sources with authentication | Logs, certificates and Kerberos all depend on the right time |
| Logging | Syslog to a central collector with timestamps, plus a local buffer | Evidence survives a reload or a compromised device |
| Routing protocols | OSPF authentication with HMAC SHA key chains, BGP with TCP-AO (TCP Authentication Option) or MD5, GTSM (Generalized TTL Security Mechanism, which checks the IP time to live) and maximum prefix limits | Nobody can inject or hijack routes |
| Source checks | uRPF (unicast reverse path forwarding) in strict mode on single homed edges, loose mode where routing is asymmetric | Spoofed source addresses are dropped at the edge |
| Unused services | HTTP (web) server off, CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol) off on untrusted ports, unused ports shut in a parking VLAN | Less to attack and less to leak |
| Software | Images checked against the vendor's hash, current supported releases, advisories tracked | Edge devices are a favourite target, and old code is the easiest way in |
I base each baseline on the vendor's hardening guide and the CIS (Center for Internet Security) Benchmarks, record every exception with a risk owner and a review date, and check devices against it automatically.
Firewall basics
From packet filters to next generation firewalls
A router ACL, a stateful firewall and a next generation firewall all permit and deny traffic, but they see very different amounts. Compare what each one knows about the same conversation. Vendor by vendor detail is on the firewall platforms page.
Swipe sideways to see the whole diagram.
Stateless ACL (access control list). Rules are read top down and the first match wins, with an implicit deny at the end. It is fast and done in hardware, so I use ACLs to protect the control and management planes. But each packet is judged alone, and the return rule has to be wide open.
Stateful firewall. The first packet is checked against the policy, then a session is written. Replies match the session, and a packet that does not fit the TCP conversation is dropped. Return traffic through a different firewall has no session, so I keep paths symmetric.
Next generation firewall (NGFW). On top of state it identifies the application whatever the port, maps addresses to users, and runs IPS (intrusion prevention), URL (web address) filtering and malware checks. Throughput drops as features are enabled, especially TLS decryption, so I size for the features I will use.
Zones group interfaces by trust, and policy is written for each pair of zones. A Cisco router can do the same with the IOS zone based firewall, where traffic between zones is dropped unless a zone pair policy inspects it. Traffic to the router itself sits in the self zone, which stays open until I write a policy for it, so I plan every interface and the self zone first or management access breaks.
NAT types
| Type | What it does | Typical use |
|---|---|---|
| Static NAT | One inside address always maps to one outside address | A published server |
| Dynamic NAT | Inside addresses borrow from a pool, one to one | Partner links with address rules |
| PAT (overload) | Many inside addresses share one outside address, told apart by port | Users browsing the internet |
| Destination NAT | Changes the destination, often one port only | Port forwarding to a server |
| Twice or policy NAT | Translates source and destination together, based on both | Overlapping addresses after a merger |
| Identity NAT | Matches traffic and leaves it untranslated | Keeping VPN traffic out of the internet PAT rule |
VPN types
| Type | How it works | Where I use it |
|---|---|---|
| Site to site IPsec | Two gateways build a tunnel, policy based or route based | Branches, partners, cloud backup paths |
| Remote access IPsec | IKEv2 client on the laptop to a VPN gateway | Staff working away from the office |
| SSL (Secure Sockets Layer) or TLS VPN | Tunnel or web portal over HTTPS (secure web) | Still common, but some vendors are retiring it. Fortinet removed SSL VPN tunnel mode in FortiOS 7.6.3 |
| ZTNA | Zero trust network access: a broker connects a checked user to one application | Replacing full network VPNs for most users |
| GRE and DMVPN (Dynamic Multipoint VPN) | Routable tunnels, protected with IPsec, built on demand between spokes | Hub and spoke wide area networks, and the home lab backup path |
Logging and SIEM
Seeing it happen, in one place
Controls slow an attacker down. Logs let a team see it and respond. Every device I build sends its logs to a central SIEM (security information and event management) platform with the right time, so events from different devices line up. The figure adds EDR (endpoint detection and response) on servers and a SOC (security operations centre) analyst.
Swipe sideways to see the whole diagram.
Correlation. One failed login means little. Five failed VPN logins for one account from abroad, then a success, then a new admin session on a firewall, is an incident. The SIEM only sees that pattern if every source sends logs with the right time.
| Tool | What it does | Where it sits |
|---|---|---|
| IDS (intrusion detection system) | Watches a copy of traffic and alerts | A SPAN (switched port analyser) port or tap, out of the path |
| IPS (intrusion prevention system) | Inspects traffic in the path and blocks matches | Inside a next generation firewall or inline |
| EDR (endpoint detection and response) | Watches processes on laptops and servers, and can isolate a host | An agent on each endpoint |
| NDR (network detection and response) | Spots unusual behaviour in flows and packets | Fed from taps, mirror ports and flow records |
| SIEM | Collects, stores and correlates logs from every source | Centrally, with retention set by policy and regulation |
| SOAR (security orchestration, automation and response) | Runs playbooks, such as blocking an address or disabling an account | Next to the SIEM |
Frameworks
The frameworks I design against
Frameworks give security a shared structure, so a design can be checked and audited. These are the ones I meet most. The UK government frameworks, such as the Cyber Assessment Framework, are on the government and defence page.
ISO/IEC 27001
A standard for running an ISMS (information security management system). The 2022 edition's Annex A lists 93 controls in four themes: organisational, people, physical and technological. I map my designs to the controls an organisation has chosen.
NIST Cybersecurity Framework 2.0
Published in February 2024 by the US National Institute of Standards and Technology. Six functions: Govern, Identify, Protect, Detect, Respond and Recover. Useful for showing a board where the gaps are.
Cyber Essentials
Five technical controls from the NCSC: firewalls, secure configuration, user access control, malware protection and security update management. Cyber Essentials Plus adds independent testing.
CIS Controls version 8.1
Eighteen prioritised controls from the Center for Internet Security, grouped into three implementation groups so smaller teams know where to start.
MITRE ATT&CK
A public knowledge base of real attacker tactics and techniques. I use it to check that each likely technique has a control or a detection, and to test the SIEM.
Incidents and faults
When something goes wrong
Security incidents and security faults both need a calm, ordered response. The first hour decides how much damage is done and how much evidence survives. This is the order I work in.
Swipe sideways to see the whole diagram.
Most incidents start as an alert or a report from someone who noticed something odd. I confirm it is real, open an incident record and note the time, because regulators and contracts often set clocks from the moment of detection.
I work out what is affected and how badly, set the severity and bring in the right people: security, network, service owners and, where needed, legal and communications.
Stopping the spread comes before finding the cause. A quarantine VLAN, a shut port, an endpoint isolation or a firewall block buys time. Short term containment should not destroy evidence.
I preserve evidence first, then build the timeline from logs, flow records and captures. This is where good logging and correct time on every device pay off.
The cause is removed, systems are rebuilt or restored from clean backups, and keys and passwords are rotated. Monitoring stays tight in case the attacker returns.
A blameless review turns the incident into fixes: root causes, better detections and updated playbooks. Personal data breaches go to the ICO (Information Commissioner's Office) within 72 hours where UK GDPR requires it.
Security faults I see, and how I find them
A user lost the network after DAI was turned on
Check: show ip arp inspection statistics vlan 20 and the log for denied ARP from that host; show ip dhcp snooping binding to see whether the host has a binding; show interfaces status err-disabled in case the ARP rate limit shut the port.
Usual cause: a host with a static address has no DHCP binding, so its ARP fails the check.
Fix and prevent: add an ARP ACL or a static binding through change, and recover the port. Roll out snooping first, then DAI, then IP source guard, and save bindings to flash.
Engineers cannot log in to a device
Check: the ISE live logs to see whether the request arrived and which policy it hit; show tacacs for server state; test aaa group tacacs+ USER PASSWORD legacy from the device; the source interface the device uses to reach the servers.
Usual cause: the device sits in the wrong network device group, a shared secret mismatch, or the servers cannot be reached from the management source address.
Fix and prevent: correct the group or secret; use the break glass account if the servers are down. Test AAA changes from a second session before saving.
Users see a certificate warning
Check: the expiry date, whether the name is in the certificate's subject alternative names, and whether the intermediate is sent: openssl s_client -connect www.example.co.uk:443 -showcerts. Also check the client's clock, and any TLS inspection device that swaps the server's certificate for its own.
Usual cause: an expired certificate, a missing intermediate, or a TLS inspection CA the client does not trust.
Fix and prevent: renew and install the full chain. Keep an inventory with expiry alerts and automate renewal.
A VPN works directly but fails through NAT
Check: show crypto ikev2 sa on both peers; captures for UDP 500 and UDP 4500; the firewall and NAT device rules between the peers.
Usual cause: UDP 4500 is blocked, or NAT traversal is off on one peer.
Fix and prevent: allow UDP 500 and 4500 and enable NAT traversal. Record the required ports in the design.
A device stays unauthorised on an 802.1X port
Check: show access-session interface Gi1/0/5 details on the switch, then the reason in the ISE live logs: no supplicant, a rejected certificate, or a failed MAC authentication bypass.
Usual cause: a printer or sensor with no 802.1X support and no MAB profile, or an expired client certificate.
Fix and prevent: profile the device and give it a limited MAB policy, or renew the certificate. Run new policies in monitor mode before closed mode.
Logins and certificates fail after a clock problem
Check: show clock and show ntp associations; certificates that are "not yet valid"; log timestamps that do not line up.
Usual cause: a device lost its NTP source. Kerberos allows only five minutes of clock difference by default, and certificates check dates.
Fix and prevent: restore NTP with authentication, use at least three sources, and alert on clock drift.
My full method for any fault, with the OSI (Open Systems Interconnection) model and the commands for each layer, is on the troubleshooting page. How incidents and problems run inside a service is on the support and service management page.
Projects
Where I put these basics to work
These fundamentals sit under every security design I have delivered, and I practise them on real kit in my home lab.
Firewalls, AAA and access control
My home lab runs Cisco ASA (Adaptive Security Appliance), Palo Alto and Check Point firewalls, Cisco ISE for network access control, and TACACS on Windows Server for device logins, with DMVPN tunnels between the sites.
Network and security transformation
Led network and security transformation as lead architect through AVEVA's reverse merger, modernising every site worldwide, and shaped network security for AVEVA Historian and, during the OSIsoft acquisition, the PI System.
Regulated banking estate
Delivered the EMEA (Europe, Middle East and Africa) network refresh and kept the estate compliant with MiFID II (the Markets in Financial Instruments Directive) throughout, with no service outages.
Segmentation after a merger
Integrated a multi site estate after the merger, with warehouse automation segmented from the corporate network, on Cisco, Palo Alto and VMware.
I work across Palo Alto, Check Point, Cisco Firepower, Cisco ISE, F5, IPsec VPN, zero trust and SASE (secure access service edge). I have passed the CCIE (Cisco Certified Internetwork Expert) Security written exam and hold the Cisco Certified Specialist Security Core certification.
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.