I design network security as part of the architecture: zones and firewall policy, identity based access, routing security at the internet edge, and the operations that keep rules honest over time. Step through the diagrams to see how each layer works.
No single control stops everything. I design security as layers, so each one catches what got past the one before, and every layer is watched.
Swipe sideways to see the whole diagram.
The perimeter still matters. Firewalls, DDoS (distributed denial of service) protection and routing security stop the noise and the obvious attacks before they reach anything important.
Some threats get in anyway, usually through a person. Zones and segments stop an infected laptop from reaching everything else.
A stolen password should not be enough. 802.1X on the network, multi factor authentication for people and least privilege for every account limit what one identity can do.
Servers and endpoints are hardened, patched and watched by endpoint protection, so an exploit that lands still has nowhere to go.
Every layer sends logs and flow records to one place. Layers slow an attacker down. Monitoring lets the team see it and respond.
Every stateful firewall works the same way underneath. Once that model is clear, the vendor is detail. Follow one connection through the firewall.
Swipe sideways to see the whole diagram.
A user opens a web page. The first packet of the flow, a TCP (Transmission Control Protocol) SYN that asks to open a connection, reaches the firewall on its inside interface.
The firewall works out the source and destination zones, then checks the rules top down: zones, addresses, ports and, on a modern firewall, the application. The first match wins. The application is not known from the first packet, so the firewall lets the handshake through and checks the rule again once it has identified the app.
If a rule allows it, the firewall applies NAT (network address translation) and writes a session: addresses, ports, protocol, zones and TCP state. Vendors do NAT and the policy check in different orders, which changes how rules are written.
Every later packet, in both directions, matches the session and skips the rule lookup. That is why return traffic needs no rule, and why a packet that does not fit the TCP conversation is dropped.
If the reply comes back through a different firewall, that firewall has no session and drops it. I design for symmetric paths, or use a firewall cluster that shares sessions and sends each packet to the member that owns the flow.
| Concept | Cisco ASA and Firepower | Palo Alto | Check Point | FortiGate | Juniper SRX, for reference |
|---|---|---|---|---|---|
| Segmentation | Security levels on ASA, zones on Firepower | Zones | Interfaces and network objects | Interfaces grouped into zones | Security zones |
| Rules | Access lists, access policy in FMC (Firewall Management Center) | Security rules with application ID | Access control rule base in layers | Firewall policy by interface pair | Policy per zone pair |
| NAT and policy | Rules use the real address | Original address, post NAT zone | Rules match the original packet | Policy uses the virtual IP object | Translated destination, original source |
| Management | FMC or Security Cloud Control | Panorama | Security Management Server | FortiManager | Security Director |
| Change model | Applied immediately or deployed from FMC | Candidate config, then commit | Edit, then install policy | Applied immediately | Candidate config, commit and rollback |
Most serious breaches start small and spread sideways. Segmentation decides how far one compromised device can get. Compare the three models.
Swipe sideways to see the whole diagram.
Flat network. One compromised laptop can talk to every server and database. Ransomware relies on exactly this.
Zones. Users, applications and data sit in separate zones, as VRFs (virtual routing and forwarding instances) with a firewall between them. The laptop can still reach other laptops, but reaches applications only on the ports the firewall allows, and cannot reach the data zone.
Micro segmentation. A policy wraps every workload, enforced with group tags in SD-Access, contracts in Cisco ACI (Application Centric Infrastructure) or a hypervisor firewall. Only declared flows are allowed, like the API to its database on one port. Location earns no trust: every flow is checked. That is zero trust applied to the network.
NIST Special Publication 800-207 (August 2020), from the US National Institute of Standards and Technology, says no network location earns trust. Every request is checked per session, using the identity, the device's health and policy, with least privilege. I use it as a checklist for each design, not as a product to buy.
North south traffic enters and leaves: users, the internet, partners. East west traffic runs between workloads, such as app to database, replication and backup, and is usually far larger. Perimeter firewalls see the first. Segmentation has to handle the second.
No admin access straight from the corporate network. Privileged access workstations, phishing resistant multi factor authentication and brokered, recorded sessions, as shown in the management plane section below.
Most traffic in a data centre runs east to west, between workloads, not north to south through the perimeter. I segment in three layers: zones with a firewall between them, micro segments inside each zone, and identity on every admin path. The hard part is switching it on without breaking a live application.
Swipe sideways to see the whole diagram.
I collect real flows for several weeks from flow records, firewall logs or the platform's own tools. Documentation is usually wrong, and month end jobs only show up once a month.
I write the rules from the evidence: web to app on 8443, app to database on 1433, database to backup. Each rule has an owner and a reason.
The rules run in log only mode. Anything that would be blocked, such as the test server reaching the web tier, is reviewed with the application owner before anything changes.
I enforce one application at a time, highest risk zones first, with a rollback ready. Now only the declared flows pass, and the stray flow is blocked and logged.
Rules live as code in Git, each with an owner and a review date. Owners recertify them on a cycle, and anything nobody claims is disabled, then removed.
| Option | Where it is enforced | Strengths | Watch out for |
|---|---|---|---|
| Cisco ACI endpoint and security groups | Leaf switches, in hardware | Line rate, covers bare metal, VMs and appliances | Stateless, limited by switch memory, ACI only |
| VXLAN (Virtual Extensible LAN) group policy (GPO) | The ingress VTEP (VXLAN tunnel endpoint) on the leaf | EVPN (Ethernet VPN) based, following Internet Engineering Task Force (IETF) drafts; classifies by VLAN, subnet or port | Stateless; needs NX-OS 10.4(3)F or later and careful scale planning |
| VMware NSX distributed firewall | Every virtual NIC (network interface card), in the hypervisor | Stateful, follows the VM when it moves, tag based | Covers only workloads on NSX hosts |
| Kubernetes network policy | The container network plugin | Per pod, defined with the application | Default allow until a policy exists |
| Host firewall agents | The server's own operating system | Works in any data centre or cloud | An agent on every server, and a compromised host can change it |
When the security team asks for every east west flow to cross a firewall, I first agree the real aim: to contain lateral movement and log the allowed flows. Central firewalls for everything are simple but costly and a bottleneck. Firewalls between zones plus micro segmentation inside them usually meets the aim at far lower cost.
Under PCI DSS (the Payment Card Industry Data Security Standard) v4.0.1, anything in, connected to, or able to affect the security of the cardholder data environment is in scope. A dedicated VRF, a stateful firewall as the only way in or out and a short list of named flows keep scope small. Scope leaks through shared tools, such as vCenter, backup proxies and monitoring, so I check those too.
I use the same zone names and rules in every data centre, pod and WAN site. The full zone matrix, with who may start a session to whom, is on the data centre page.
Network access control decides what a device may reach before it sends its first useful packet. I design it around Cisco ISE (Identity Services Engine): for users, for devices that cannot authenticate, and for engineers who manage the network. Results include a VLAN, a security group tag (SGT) or a narrow segment, and devices that cannot run 802.1X use MAC authentication bypass (MAB).
Swipe sideways to see the whole diagram.
The laptop presents its certificate to the switch over 802.1X (EAP over LAN), and the switch relays it to ISE inside RADIUS (Remote Authentication Dial In User Service). ISE checks it, and the user's groups in the directory, before anything else happens.
ISE answers with the result: a VLAN (virtual LAN), a downloadable ACL (access control list) or a security group tag (SGT) such as SGT 10. The same policy follows the user on any port, wired or wireless.
Printers, cameras and building controllers often cannot run 802.1X. MAC authentication bypass (MAB) checks the device's hardware address, and profiling gives a good idea of what the device is. Because a MAC address is easy to copy, it only gets a tightly limited segment.
Before full access, ISE can check that the laptop is patched and protected. A device that fails gets a remediation network only, until it is fixed.
Engineers log in to network devices through TACACS+ (Terminal Access Controller Access Control System Plus). Every command is authorised against their role and logged, so changes are attributable and auditable.
Swipe sideways to see the whole diagram.
Corporate. The laptop proves itself with EAP-TLS (EAP, the Extensible Authentication Protocol, carrying TLS, Transport Layer Security) and a machine certificate from the company PKI (public key infrastructure) or Intune. Posture checks patches and endpoint protection. When it passes, a change of authorisation (CoA, RFC 5176) moves it from limited to full access, without the user doing anything. Cisco devices listen for CoA on UDP 1700 by default, while RFC 5176 names 3799, so the port must match on both sides.
Bring your own device (BYOD). A personal phone signs in once through an onboarding portal, which installs its own certificate. From then on it authenticates like a corporate device, but lands in a separate, narrower role.
IoT. A camera cannot run 802.1X, so ISE checks its MAC address (MAC authentication bypass). It confirms what the device is by profiling DHCP (Dynamic Host Configuration Protocol), CDP or LLDP (the Cisco and Link Layer Discovery Protocols) and traffic data. Because a MAC address is easy to copy, it only reaches its recorder. Anything unknown is quarantined until someone claims it.
Guest. The switch or access point redirects the browser to a portal, a central web authentication flow. The visitor accepts the terms, registers or is approved by a sponsor. A change of authorisation then gives internet access only.
| Persona | What it does | Where I place it |
|---|---|---|
| Policy Administration Node (PAN) | Holds the configuration and policy. | A primary and a secondary, in two data centres. |
| Monitoring and Troubleshooting (MnT) | Collects logs and live sessions. | A pair, usually beside the PANs. |
| Policy Service Node (PSN) | Answers the RADIUS and TACACS+ requests. | Close to the users, at least two per region, often behind a load balancer. |
| pxGrid | Shares who is on the network with firewalls and the SIEM (security information and event management) platform. | Two to four nodes, so context sharing survives a failure. |
A large ISE 3.x deployment allows at most two PANs, two MnT nodes, 50 PSNs and four pxGrid nodes, 58 nodes in all. I size from Cisco's deployment and sizing guide for the release in use.
| Method | How it proves identity | When I use it |
|---|---|---|
| EAP-TLS | Certificates on both sides. No password crosses the network. | Corporate devices. My default. |
| PEAP (Protected EAP) with MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) | A TLS tunnel, then a username and password inside it. | Only where certificates are not yet possible. |
| TEAP (Tunnel Extensible Authentication Protocol) or EAP-FAST (Flexible Authentication via Secure Tunnelling) | A tunnel that can check the machine and the user together. | Where both machine and user identity matter. |
| MAB | The MAC address only. Not EAP at all. | Printers, cameras and building devices, always with profiling and a narrow segment. |
| TACACS+ | RADIUS | |
|---|---|---|
| Transport | TCP 49 (RFC 8907) | UDP 1812 and 1813 (RFC 2865 and 2866) |
| Protection | The whole body is obscured | Only the password is hidden |
| Design | Authentication, authorisation and accounting kept separate | Authentication and authorisation combined |
| Best for | Engineers logging in to devices, with every command authorised and logged | Network access: 802.1X, VPN and Wi-Fi |
| Cisco ISE | Aruba ClearPass |
|---|---|
| PAN and PSN nodes | Publisher and subscriber nodes in a cluster |
| Profiling | Device profiling, with ClearPass Device Insight |
| Posture | OnGuard |
| BYOD onboarding | Onboard |
| Guest portals and sponsors | Guest |
| Change of authorisation | The same RFC 5176 mechanism |
Every switch lists at least two policy nodes, with dead server detection. If none answers, a critical authentication policy keeps sessions that are already authorised up, and puts new ones on a safe critical segment until ISE returns, instead of locking the site out. I test this before go live.
I start in monitor mode, where every result is logged but nothing is blocked, fix what fails, then move to low impact and finally closed mode, a few sites at a time.
EAP-TLS depends on a working PKI, automatic enrolment and renewal. I plan that early, because expired certificates are the most common cause of a sudden lockout.
Whoever controls the management plane controls the network. I treat admin access as the most sensitive path in the estate: one controlled way in, every session recorded and every command logged.
Swipe sideways to see the whole diagram.
Admin work starts on a privileged access workstation (PAW): a locked down machine used only for admin, never for email or browsing. The engineer signs in with a named account and phishing resistant multi factor authentication.
The only route into the admin zone is the jump host run by privileged access management (PAM). There is more than one jump host, so it is not a single point of failure, and each is patched like a server.
PAM grants rights for a time window, records the whole session and injects a vaulted password, so the engineer never sees the shared credential. The session then crosses into the management network.
Devices sit in a management VRF or an out of band network. Each login and each command is authorised by TACACS+ against the engineer's role, so a junior engineer can read but not reload a core switch.
Logins, commands, configuration changes and failures all go to the SIEM (security information and event management) with accurate time from NTP (Network Time Protocol). That is the evidence an auditor asks for.
If TACACS+ cannot be reached, a local break glass account still works. Its password is sealed in the vault, needs two people to release, is changed after every use and raises an alert the moment it is used.
| Area | What I set |
|---|---|
| Remote access | SSH version 2 only, with a strong key. Telnet and HTTP off. Access lists on the lines. |
| Monitoring | SNMPv3 with authentication and encryption, using SHA (Secure Hash Algorithm) and AES (Advanced Encryption Standard), with views and an access list. No SNMP v2c communities. |
| Time | NTP from internal sources, with authentication. Logs are useless without the right time. |
| Logging | Syslog to two collectors, with millisecond timestamps and the time zone. |
| Passwords | Type 8 or type 9 secrets. Type 7 and type 5 are easy to reverse or crack, so they never appear. |
| Unused services | Off: unused interfaces shut, CDP and LLDP off on untrusted ports, no source routing. |
| Control plane | Control plane policing (CoPP) to protect the CPU, and authentication on routing protocols, such as HMAC (hash based message authentication code) SHA key chains for OSPF (Open Shortest Path First). |
| Control plane on NX-OS | Start from the built in CoPP profile (strict by default, or moderate, lenient or dense), check drops with show policy-map interface control-plane, and tune only with evidence. |
| NX-OS management | SNMPv3 users with SHA authentication and AES privacy, mapped to roles, sourced from the management VRF. TACACS+ with feature tacacs+ and a server group in the management VRF. Credentials kept in a vault, never in Git. |
| Type | What it is | Verdict |
|---|---|---|
| 0 | Plain text | Never |
| 7 | Reversible, from service password-encryption | Hides from a casual glance only |
| 5 | Salted MD5 | Weak |
| 6 | Reversible AES with a master key | For keys the device must read back, such as VPN keys |
| 8 | PBKDF2 (password based key derivation function 2) with SHA-256 | Good |
| 9 | scrypt | Best for login secrets |
Type 4 was a flawed SHA-256 scheme and has been withdrawn.
A compliance report compares every device with the baseline each night: Telnet back on, a missing NTP key, a new local user, an access list changed outside a window. Each finding is a ticket, fixed through change or recorded as an exception with an owner.
Logins and failures, TACACS+ command accounting, interface and routing changes, spanning tree events, 802.1X results, DHCP snooping and ARP (Address Resolution Protocol) inspection drops, firewall allows and denies at boundaries, VPN events and admin actions on every platform.
I stop, preserve and report. I note what I saw, when and on which device, and tell the security team through the agreed route. I do not reload the device, because that wipes the evidence in memory, and I contain only as the procedure says.
BGP (Border Gateway Protocol) believes what it is told, so anyone can announce someone else's addresses. RPKI (Resource Public Key Infrastructure) origin validation closes the most common gap: route origin authorisations (ROAs) say which autonomous system (AS) may originate a prefix, and my edge routers check every route against them. It does not check the rest of the path. Try the scenarios.
Swipe sideways to see the whole diagram.
ROA for the owner's space: 203.0.113.0/24, origin AS 64500, max length /24.
Every prefix gets a ROA with the right origin and a max length no longer than you announce. A loose max length lets a hijacker announce a more specific prefix with my AS forged as the origin, and it will show as valid.
RPKI is only as good as the registry data behind it. After a merger I reconcile who holds which address space, fix the RIR (regional internet registry) records, then publish ROAs.
Turn on origin validation, watch what would be dropped, fix anything of your own that shows invalid, then drop invalid routes at the edge.
Remote access used to mean putting people on the network. Zero trust access connects them to exactly the application they need, after checking who they are and the device they are using.
Swipe sideways to see the whole diagram.
Remote access VPN. A VPN (virtual private network) puts the user on the network through an encrypted tunnel. It works, but once connected that user, or anyone holding their password, can reach far more than the job needs.
Zero trust access. With zero trust network access (ZTNA), a broker checks the user, with multi factor authentication, and the health of the device on every connection, then connects them to one application. Nothing else is visible. Add cloud security for internet traffic and SD-WAN for branches, under one policy, and you have SASE (secure access service edge). The branch side is on the SD-WAN page.
IPsec tunnels with IKEv2 (Internet Key Exchange version 2), strong ciphers, certificate authentication and tunnels that are monitored like any other link, not left to fail quietly.
Multi factor authentication every time, device posture checked, and split tunnelling decided on purpose rather than by default.
With SASE the same rules apply in the office, at home and on the road, enforced in the cloud close to the user.
Almost every control on this page depends on certificates: 802.1X, VPNs, management HTTPS, APIs and storage replication. I design the PKI (public key infrastructure) and key management as shared services, because a self signed certificate or a key in a spreadsheet is an audit finding waiting to happen. The basics of encryption and TLS are on the security fundamentals page.
Swipe sideways to see the whole diagram.
The root certificate authority (CA) is kept offline, in a hardware security module (HSM). It only ever signs the issuing CAs, so the most valuable key is almost never exposed. Infrastructure gets its own issuing CA, separate from the one for users.
A new device arrives with a factory identity, an IDevID (initial device identifier, IEEE 802.1AR). It uses that to enrol over EST (Enrollment over Secure Transport, RFC 7030) or SCEP (Simple Certificate Enrollment Protocol) and ask for its operational certificate. Devices without a factory identity get a one time token instead.
The issuing CA checks the request against the inventory and signs an operational certificate, an LDevID (locally significant device identifier), for that device and nothing else.
Devices, controllers and automation prove themselves to each other with mutual TLS. Renewal is automatic, well before expiry, because an expired certificate is the most common cause of a sudden outage. Time from NTP has to be right first.
A lost or retired device has its certificate revoked. The CA publishes it on a revocation list or answers OCSP (Online Certificate Status Protocol) checks, so everything else stops trusting it.
| Piece | What it does |
|---|---|
| Key management service | Creates, stores, hands out, rotates, revokes and destroys keys. One service, not keys scattered across arrays and tools. |
| Hardware security module | The tamper resistant root of trust under the key manager. Banks usually ask for FIPS 140-3 Level 3, the US Federal Information Processing Standard for cryptographic modules. |
| KMIP | The Key Management Interoperability Protocol, an OASIS (Organization for the Advancement of Structured Information Standards) standard, on TCP 5696, that lets arrays, backup tools and vSphere fetch their keys from the key manager. |
| Encryption at rest | Arrays and self encrypting drives use AES-256. Destroying a key makes its data unreadable, which helps when drives are returned or retired. |
| Choice | What it gives | What it costs |
|---|---|---|
| Full TLS decryption | The firewall or proxy sees the content, so intrusion prevention (IPS) and data loss checks work. | CPU and latency, a trusted inspection certificate on every device, privacy and legal review. |
| Name only | Decisions on the server name (SNI, server name indication) in the ClientHello. In TLS 1.3 the certificate is encrypted, so it is not visible without decryption. | Light, but blind to the content, and blind to the name too when ECH (Encrypted Client Hello) is used. |
| Exempt categories | Banking, health and personal sites stay private by policy. | A documented list that HR and legal agree. |
I decrypt where the threat and the regulation justify it, size the platform for it, and keep a clear exemption list.
Firewalls rarely fail on day one. They decay: rules pile up, nobody remembers why, and the policy drifts away from the design. These are the habits I build into every estate.
| Annex A control | What it means in my designs |
|---|---|
| 8.9 Configuration management | Baselines for every platform, checked nightly. |
| 8.15 Logging and 8.16 Monitoring | Every device logs to the SIEM, and someone watches the alerts. |
| 8.17 Clock synchronisation | NTP from trusted sources, so logs line up. |
| 8.20 to 8.22 Network security and segregation | Zones, segments and firewalls, documented and tested. |
| 8.24 Use of cryptography | Approved algorithms, one PKI, keys in a key manager. |
| 8.32 Change management | Every change approved, evidenced and reversible. |
ISO/IEC 27001:2022 has 93 Annex A controls in four themes. It certifies a risk based management system, not a product, so I check what an organisation's certificate actually covers.
| Source | What it proves |
|---|---|
| AAA and PAM records | Who logged in, what they ran and when. |
| Firewall and fabric policy logs | Which flows were allowed or denied at each boundary. |
| Flow records (NetFlow or IPFIX, IP Flow Information Export) | What really talks to what, for segmentation and investigations. |
| Configuration history | What changed, when, and under which change. |
| Controller audit logs | Changes made through Catalyst Center, ACI, NSX or cloud consoles. |
| Segmentation tests | That blocked flows really are blocked, which PCI DSS asks for at least once a year, and every six months for service providers. |
Device logins go through TACACS+ to Active Directory groups over LDAPS (LDAP, the Lightweight Directory Access Protocol, over TLS), and web consoles use SAML (Security Assertion Markup Language) single sign on with multi factor authentication. Service accounts are named, vaulted and rotated, and leavers lose access on the same day.
I map each obligation, from policy, ISO 27001, PCI DSS or a regulator, to a control, then to a design decision, then to a test. That trace is what turns "we are compliant" into something an auditor can check.
The SIEM is the security view across every log source. Fabric analytics, such as Nexus Dashboard, is the network team's view of the fabric's own health. I feed both, and agree log formats with the security team before changing a source.
Vendor advisories are triaged by severity and by whether the flaw is known to be exploited. How I run patching and end of life is on the support and service management page.
Security work starts with risk, not products. I agree what we are protecting and from what, prove the current state with evidence, then design controls that the operations and security teams can run and keep proving.
Swipe sideways to see the whole diagram.
I start with the people who own the risk: what are the crown jewels, which threats matter most, and which obligations apply, such as ISO 27001, PCI DSS or a regulator. That sets the priorities before any product is discussed.
Functional requirements say what must be allowed, blocked, authenticated or logged. Non functional ones say how fast, how available and how provable: firewall throughput with inspection on, authentication time, log retention and how quickly a rule change can be made.
I analyse the existing rule bases for unused, shadowed and any to any rules, collect real flows from NetFlow and firewall logs, and inventory devices and identities from ISE, Active Directory and the CMDB (configuration management database). The gap list comes from evidence.
The design covers the zone model and flow matrix, firewall placement and high availability, access control with ISE, the management plane and logging. Every exception has an owner, and every decision goes in the decision log for the design authority.
New controls run in monitor mode first, so nothing is blocked until the logs have been reviewed with the application owners. Enforcement follows in waves, each through change control, then penetration and segmentation tests prove the result.
I agree who handles what: the network team runs the platforms, the security operations centre (SOC) watches the alerts, and every rule has an owner who recertifies it. Runbooks and the rule change process are tested during hypercare.
Security platforms need steady care: vendor advisories triaged by risk, regular software updates, rule base clean ups, certificate renewals and hardware replaced before end of support. Controls are tested every year so the evidence stays current.
What it must do.
How well it must do it, with a number wherever one can be agreed.
Typical starting targets. The real numbers come from the organisation's risk appetite and obligations.
| Tool or source | What it tells me |
|---|---|
| Firewall policy analysers (Tufin, AlgoSec or FireMon) | Unused, shadowed and risky rules, and which rules a change would touch. |
| NetFlow or IPFIX and firewall logs | The flows that really happen, for building the zone matrix. |
| Cisco ISE and Active Directory reports | Which users and devices connect, how they authenticate and what fails. |
| Vulnerability scanners (Nessus or Qualys) | Exposed services and missing patches on network and security devices. |
| SIEM searches | Current alert volumes and what the SOC actually looks at. |
| Configuration backups and compliance reports | How far each device has drifted from the hardening baseline. |
Most security faults look like network faults: something that should work is blocked, or something that should be blocked works. I prove where the packet stops before changing any rule.
packet-tracer on ASA or test security-policy-match on PAN-OS.| Layer | What I check |
|---|---|
| 1 and 2 · Physical and data link | Port state, 802.1X session on the port (show access-session interface), VLAN or SGT assigned. |
| 3 · Network | Routing on both sides, NAT translations, and whether the reply returns through the same firewall. |
| 4 · Transport | The session table on the firewall, TCP flags, and whether the SYN or the reply is being dropped. |
| 5 and 6 · Session and presentation | TLS handshake, certificates, inspection and decryption policy. |
| 7 · Application | App identification, URL category, IPS signature hits and the user's real experience. |
Vendor by vendor tools for proving a drop are on the firewall platforms page, and my general method is on the troubleshooting page.
A security control is only as good as the team running it. I agree the operating model before the first rule goes live.
The network team runs firewalls and NAC, the SOC watches alerts, and service owners own their rules, with clear escalation between them.
A standard request form, a risk check, a peer review, then change control. Simple changes get a fast path.
Health of every enforcement point, failover state, licence and certificate expiry, and log flow into the SIEM.
Proving a drop, emergency blocks, failing over a pair, restoring a policy node and handling a suspected compromise.
Rule owners confirm their rules on a cycle. Unclaimed rules are disabled, then removed.
Repeat faults and near misses get a root cause and a lasting fix.
Security platforms age faster than most network kit, because the threats move. I plan their life from the first design.
Security has run through my work in banking, industrial software, telecoms and the public sector, from the internet edge to the plant floor.
Secured the consolidated internet edge with RPKI based BGP origin validation and cleaned up RIR records across the merged address space. Shaped network security for AVEVA Historian and, during the OSIsoft acquisition, the PI System.
Defined routing security policy for the peering and transit edge: RPKI and ROA origin validation, and RIPE NCC resource governance.
Managed provider IP space and AS numbers with RIPE NCC, including RPKI ROAs, for a Tier 3 data centre serving over 300 customer sites.
Delivered the EMEA network refresh and kept the estate compliant with MiFID II throughout, with no service outages.
Network modernisation on Meraki, Nexus, FortiGate and Check Point, leading 7 engineers and third party suppliers.
Integrated a multi site estate, including distribution centres, with warehouse automation segmented from corporate IT, on Cisco, Palo Alto and VMware.
I work across Palo Alto, Check Point, Cisco Firepower, Cisco ISE, F5, IPsec VPN, zero trust and SASE. My home lab runs Cisco ASA, Palo Alto and Check Point firewalls and Cisco ISE. Backed by the CCIE Security written exam, the Cisco Security Core specialist certification and CCNP Enterprise. See all credentials
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.