Network Security
Network security encompasses the controls, architectures, and mechanisms that protect data in transit and prevent unauthorised access to network resources. These controls operate at multiple layers of the network stack, from physical port security through application-layer filtering, creating overlapping protection that compensates for individual control failures. For mission-driven organisations operating across diverse environments, network security must function in well-resourced headquarters, bandwidth-constrained field offices, and hostile network contexts where adversaries control the infrastructure itself.
- Defence in depth
- Security architecture employing multiple independent layers of protection such that compromise of any single layer does not grant full access. Each layer addresses different attack vectors and operates independently of other layers.
- Network segmentation
- Division of a network into isolated zones with controlled communication paths between them. Traffic crossing zone boundaries passes through enforcement points that apply security policy.
- Firewall
- Network device or software that examines traffic against a rule set and permits or denies transmission based on source, destination, protocol, port, and packet characteristics.
- Network Access Control (NAC)
- System that authenticates devices and users before granting network connectivity, and may restrict access based on device health, user identity, or other attributes.
- Intrusion Detection System (IDS)
- System that monitors network traffic for signatures of known attacks or anomalous behaviour and generates alerts for security personnel.
- Intrusion Prevention System (IPS)
- System that monitors network traffic and actively blocks detected attacks, operating inline with traffic flow rather than passively observing copies.
Defence in depth model
The defence in depth model positions security controls at multiple points in the network path such that an attacker must defeat several independent mechanisms to reach protected resources. This layering provides resilience against both known attack techniques and novel methods that might bypass individual controls. A single firewall, however well-configured, represents a single point of failure; an attacker who discovers a bypass has unrestricted access. Multiple layers force attackers to chain multiple exploits, increasing the complexity and cost of successful attacks while creating more opportunities for detection.
The model organises controls into concentric zones, each with distinct security properties and trust levels. Traffic flows inward through progressively restrictive boundaries, with each boundary enforcing policy appropriate to the zones it separates.
+------------------------------------------------------------------------+| INTERNET || (untrusted, hostile) |+------------------------------------------------------------------------+ | v+------------------------------------------------------------------------+| PERIMETER ZONE || +------------------+ +------------------+ +------------------+ || | DDoS mitigation | | Web application | | Email gateway | || | (upstream or | | firewall | | (spam, malware) | || | appliance) | | | | | || +------------------+ +------------------+ +------------------+ || || +------------------------------------------------------------------+ || | PERIMETER FIREWALL | || | - Stateful inspection - Geographic blocking | || | - Protocol validation - Rate limiting | || +------------------------------------------------------------------+ |+------------------------------------------------------------------------+ | v+------------------------------------------------------------------------+| DMZ ZONE || +------------------+ +------------------+ +------------------+ || | Reverse proxy / | | Public web | | VPN | || | load balancer | | servers | | concentrators | || +------------------+ +------------------+ +------------------+ || || Purpose: Internet-facing services isolated from internal network || Trust level: Low - assumes compromise possible |+------------------------------------------------------------------------+ | v+------------------------------------------------------------------------+| INTERNAL FIREWALL || - Application-aware filtering - User/group-based rules || - TLS inspection (where legal) - Micro-segmentation enforcement |+------------------------------------------------------------------------+ | +---------------+---------------+ | | v v+-------------------------------+ +-------------------------------+| USER ZONE | | APPLICATION ZONE || | | || +----------+ +----------+ | | +----------+ +----------+ || | Wired | | Wireless | | | | App | | App | || | endpoints| | endpoints| | | | server 1 | | server 2 | || +----------+ +----------+ | | +----------+ +----------+ || | | || Trust: Medium - authenticated| | Trust: Medium - internal || users, managed devices | | services, server-to-server |+-------------------------------+ +-------------------------------+ | | +---------------+---------------+ | v+------------------------------------------------------------------------+| INTERNAL FIREWALL / MICROSEGMENTATION |+------------------------------------------------------------------------+ | v+------------------------------------------------------------------------+| DATA ZONE || +------------------+ +------------------+ +------------------+ || | Database | | File storage | | Backup systems | || | servers | | | | | || +------------------+ +------------------+ +------------------+ || || Trust: Highest protection - sensitive data, no direct user access |+------------------------------------------------------------------------+Figure 1: Defence in depth zone architecture showing progressive trust boundaries
Each zone boundary enforces the principle that traffic crossing the boundary requires explicit permission. The perimeter firewall denies all inbound connections except those to services published in the DMZ. The internal firewall denies direct connections from the DMZ to the data zone, requiring application servers to mediate all data access. This architecture means a compromised web server in the DMZ cannot directly query databases; the attacker must additionally compromise an application server with legitimate database access.
The number and configuration of zones varies with organisational complexity and risk tolerance. A small organisation with ten staff and limited infrastructure might implement three zones: untrusted (internet), semi-trusted (user devices), and trusted (servers and data). A large organisation with multiple offices and regulated data might implement a dozen zones with distinct policies for finance systems, HR data, programme beneficiary information, and general business systems.
Zone design follows the principle of least privilege applied to network access. Systems in a zone can communicate freely within that zone, but cross-zone communication requires traversing a control point that evaluates whether the specific source, destination, and protocol combination is permitted. A grants management application server needs database access but does not need to reach HR systems; the firewall rules reflect this requirement by permitting only the specific connection paths required for legitimate operation.
Firewall architecture
Firewalls examine network traffic and enforce policy by permitting or blocking connections based on configurable rules. The evolution from simple packet filters to modern next-generation firewalls has dramatically expanded the criteria available for policy decisions, enabling enforcement based on user identity, application behaviour, content type, and threat intelligence rather than just IP addresses and ports.
Stateless packet filters examine each packet in isolation, checking source address, destination address, protocol, and port against a rule list. These filters cannot track connection state, so permitting responses to outbound connections requires permitting all inbound traffic on the response port range. Stateless filtering remains relevant for high-throughput scenarios where performance requirements preclude stateful inspection, but offers limited security for general-purpose boundaries.
Stateful firewalls track connection state, recognising that a packet arriving on port 443 is a response to an established outbound connection rather than a new inbound connection attempt. This tracking enables default-deny inbound policies without breaking outbound connectivity. Stateful inspection is the baseline for modern network security; no perimeter or internal boundary should rely solely on stateless filtering.
Next-generation firewalls extend stateful inspection with application awareness, user identity integration, and threat intelligence. Rather than permitting TCP port 443, a next-generation firewall permits HTTPS while blocking other protocols tunnelled over the same port. User identity integration enables rules like “permit finance group to access accounting application” rather than “permit subnet 10.1.5.0/24 to port 8443”. Threat intelligence integration blocks connections to known malicious destinations and identifies traffic matching known attack patterns.
+-------------------------------------------------------------+| FIREWALL RULE PROCESSING |+-------------------------------------------------------------+| || 1. INGRESS || Packet arrives at interface || | || v || +--------------+ || | STATE LOOKUP | Check Connection Table || +--------------+ || | || +---------------------+ || | | || v v || 2. EXISTING CONN 3. NEW CONN || (Match Found) (No Match) || | | || v v || +--------------+ +--------------+ || | VERIFY STATE | | RULE CHECK | || | (Seq/Flags) | | (Top-Down) | || +--------------+ +--------------+ || | | || | +----------+---------+ || | | | | || | v v v || | [PERMIT] [DENY] [NO MATCH] || | | | | || | v | | || | +----------+ +----+----+ || | | ADD STATE| | || | +----------+ | || | | v || +----+-----+ +---------+ || | | DROP | || v | (Log) | || +----------+ +---------+ || | FORWARD | || +----------+ || |+-------------------------------------------------------------+Figure 2: Firewall packet processing flow showing state lookup and rule evaluation
Firewall rule design follows principles that minimise attack surface while enabling legitimate business operations. Rules should be as specific as possible: rather than permitting all traffic from a source network, permit only the required destination addresses and ports. Rules should include comments documenting the business purpose, the requester, and the approval date, enabling future review to identify rules that no longer serve valid purposes.
Rule ordering affects both security and performance. Firewalls evaluate rules sequentially until a match occurs, so placing frequently-matched rules near the top reduces processing overhead. Deny rules for known threats should precede permit rules to ensure malicious traffic is blocked even if a later rule would otherwise match. The final rule should be an explicit deny-all with logging, making the implicit deny visible and ensuring unexpected traffic generates audit records.
A sample firewall rule set for a small organisation illustrates these principles:
# Network Security - Perimeter Firewall Rules# Organisation: Example NGO# Last review: 2024-11-15# Next review: 2025-05-15
# Section 1: Threat intelligence blocks (evaluated first)1000 DENY from threat-intel-blocklist to any log-prefix="THREAT-INTEL"1001 DENY from any to threat-intel-blocklist log-prefix="THREAT-INTEL"
# Section 2: Geographic blocks (countries with no operational presence)1100 DENY from geo:RU,CN,KP to any log-prefix="GEO-BLOCK"
# Section 3: Inbound services (DMZ)2000 PERMIT from any to 203.0.113.10:443 comment="Public website"2001 PERMIT from any to 203.0.113.11:443 comment="Donor portal"2002 PERMIT from partner-networks to 203.0.113.12:443 comment="Partner API"
# Section 4: VPN access2100 PERMIT from any to 203.0.113.20:1194/udp comment="OpenVPN"2101 PERMIT from any to 203.0.113.20:51820/udp comment="WireGuard"
# Section 5: Outbound (from internal)3000 PERMIT from internal-users to any:443 comment="HTTPS outbound"3001 PERMIT from internal-users to any:80 comment="HTTP outbound"3002 PERMIT from servers to update-servers:443 comment="OS updates"3003 PERMIT from mail-server to any:25,587 comment="Email delivery"
# Section 6: Default deny9999 DENY from any to any log-prefix="DEFAULT-DENY"This rule set permits specific inbound services, allows outbound web access, and blocks everything else. The logging prefixes enable security monitoring tools to categorise blocked traffic for analysis.
Network access control
Network access control determines which devices may connect to the network and what resources they may access after connecting. Without NAC, any device physically connected to a network port or within wireless range gains network access. With NAC, connection attempts trigger authentication before the network becomes usable, and the authenticated identity influences subsequent access permissions.
The 802.1X standard defines port-based network access control for both wired and wireless networks. The standard specifies three roles: the supplicant (device requesting access), the authenticator (switch or wireless access point), and the authentication server (typically a RADIUS server). When a supplicant connects, the authenticator holds the port in an unauthorised state, permitting only authentication traffic. The supplicant provides credentials through the Extensible Authentication Protocol (EAP), the authenticator forwards these to the authentication server, and the server responds with accept or reject. Upon acceptance, the authenticator moves the port to an authorised state, optionally assigning the port to a specific VLAN based on the authentication result.
+----------------+ +----------------+ +----------------+| | | | | || SUPPLICANT | | AUTHENTICATOR | | AUTH SERVER || (endpoint) | | (switch/AP) | | (RADIUS) || | | | | |+-------+--------+ +-------+--------+ +-------+--------+ | | | | (1) Physical connect | | | or wireless associate | | +-------------------------->| | | | | | (2) Port held in | | | unauthorised state | | | | | |<--------------------------| | | (3) EAP-Request/Identity | | | | | |-------------------------->| | | (4) EAP-Response/Identity| | | (username) | | | |-------------------------->| | | (5) RADIUS Access-Request| | | (EAP-Message) | | | | | |<--------------------------| | | (6) RADIUS Access- | | | Challenge (EAP method) | |<--------------------------| | | (7) EAP-Request | | | (method-specific) | | | | | |-------------------------->| | | (8) EAP-Response | | | (credentials/cert) |-------------------------->| | | (9) RADIUS Access-Request| | | | | | | | | (10) Server validates | | | credentials against | | | identity store | | | | | |<--------------------------| | | (11) RADIUS Access-Accept| | | + VLAN assignment | | | + other attributes | |<--------------------------| | | (12) EAP-Success | | | | | | (13) Port authorised | | | VLAN assigned | | | Full network access | | | | |Figure 3: 802.1X authentication sequence showing supplicant, authenticator, and authentication server interaction
EAP methods vary in security properties and deployment complexity. EAP-TLS requires certificates on both client and server, providing mutual authentication and strong security but requiring certificate deployment to all endpoints. EAP-PEAP protects user credentials within a TLS tunnel, enabling password-based authentication without exposing passwords on the network; PEAP requires only a server certificate, simplifying deployment. EAP-TTLS similarly tunnels authentication within TLS and supports legacy authentication methods.
NAC systems often integrate device health assessment, also called posture checking. Beyond verifying user identity, posture checking evaluates whether the connecting device meets security requirements: Is the operating system patched? Is endpoint protection installed and running? Is the disk encrypted? Devices failing posture checks may be directed to a quarantine network with access only to remediation resources, or denied network access entirely.
Dynamic VLAN assignment based on authentication results enables differentiated access without physical network changes. A staff member authenticating with domain credentials receives assignment to the corporate VLAN with full access. A visitor authenticating with guest credentials receives assignment to a guest VLAN with internet access only. A contractor authenticating with partner credentials receives assignment to a limited VLAN with access only to specific systems. This dynamic assignment means a single physical port can serve different access levels depending on who connects.
For organisations unable to deploy full 802.1X authentication, MAC Authentication Bypass provides a weaker alternative that authenticates devices by MAC address. MAB is appropriate for devices that cannot support 802.1X supplicants, such as printers, IoT sensors, or legacy equipment. Because MAC addresses are easily spoofed, MAB should assign devices to isolated VLANs with minimal access, and should not be the sole authentication mechanism for general endpoints.
Intrusion detection and prevention
Intrusion detection systems monitor network traffic for evidence of attacks, generating alerts when signatures match or when traffic patterns deviate from established baselines. Intrusion prevention systems extend detection with active blocking, dropping malicious traffic before it reaches intended targets. The distinction between IDS and IPS is deployment position and response capability: IDS monitors traffic copies and alerts; IPS operates inline and blocks.
Signature-based detection compares traffic against a database of known attack patterns. When traffic matches a signature, the system generates an alert or blocks the traffic. Signatures exist for exploitation attempts against known vulnerabilities, command-and-control communications, data exfiltration patterns, and policy violations. Signature databases require regular updates to address new threats; a system with stale signatures misses recent attack techniques. Signature-based detection is effective against known threats but cannot detect novel attacks or zero-day exploits.
Anomaly-based detection establishes baseline patterns for normal network behaviour and alerts when traffic deviates significantly from these patterns. Baselines might characterise normal traffic volumes, common protocols, typical connection patterns, or expected internal communications. Anomaly detection can identify novel attacks that signatures miss, but generates false positives when legitimate activity deviates from learned patterns. Effective anomaly detection requires tuning periods to establish accurate baselines and ongoing adjustment as normal patterns evolve.
+----------------------------------------------------------------------+| NETWORK WITH IDS/IPS |+----------------------------------------------------------------------+
INTERNET | v +-----------+-----------+ | Perimeter firewall | +-----------+-----------+ | +----------------------+----------------------+ | | v |+--------+--------+ || IPS | (inline, blocking mode) || | || - Signature | || - Anomaly | || - Rate limiting | |+--------+--------+ | | | v |+--------+--------+ || DMZ | |+--------+--------+ | | | v |+--------+--------+ || Internal FW | |+--------+--------+ | | | +----------------------+----------------------+ | +----------------------+----------------------+ | | | v v v+--------+--------+ +---------+--------+ +---------+-------+| User zone | | App zone | | Data zone |+--------+--------+ +---------+--------+ +---------+-------+ | | | | | | +----------------------+----------------------+ | v +-----------+-----------+ | Network TAP / | | SPAN port | +-----------+-----------+ | v +-----------+-----------+ | IDS | (passive, alerting) | | | - Deep inspection | | - Full packet capture| | - Protocol analysis | +-----------+-----------+ | v +-----------+-----------+ | SIEM | | (correlation, | | alerting) | +-----------------------+Figure 4: IDS/IPS deployment showing inline prevention at perimeter and passive detection for internal traffic
IPS deployment requires careful positioning to maximise protection without introducing latency or becoming a bottleneck. Inline IPS at the perimeter blocks attacks before they enter the network, but must handle full internet bandwidth without adding perceptible latency. Deploying IPS on a 100 Mbps connection requires a device rated for sustained 100 Mbps throughput with all inspection features enabled; vendor throughput ratings often assume disabled features or simplified traffic. Internal IPS deployments between zones protect against lateral movement but multiply deployment complexity.
Detection tuning balances security coverage against operational impact. Enabling all available signatures generates excessive false positives, overwhelming security staff and training them to ignore alerts. Disabling signatures to reduce false positives risks missing actual attacks. Effective tuning starts with signatures relevant to deployed technology stacks (disable Windows attack signatures on Linux-only networks), adjusts thresholds based on observed traffic patterns, and creates exceptions for known-benign activity that triggers false positives.
Alert fatigue represents a significant operational risk. An IDS generating hundreds of daily alerts, most of which are false positives, provides less effective security than one generating ten alerts that security staff actually investigate. Alert tuning is an ongoing process: each false positive should trigger evaluation of whether the signature should be disabled, the threshold adjusted, or an exception created. Security staff investigating alerts should document findings, building institutional knowledge about which alerts indicate real threats versus normal activity.
Network segmentation for security
Network segmentation divides a flat network into isolated zones, limiting the blast radius of security incidents and enforcing least-privilege access between systems. Without segmentation, an attacker who compromises any system can directly access every other system on the network. With segmentation, compromise of a system in one zone provides no direct access to systems in other zones; the attacker must find additional vulnerabilities to move laterally.
Segmentation strategies range from coarse VLAN-based separation to fine-grained microsegmentation. VLAN segmentation groups systems into broadcast domains with routing between them, placing enforcement at layer 3 boundaries where firewalls or ACLs control inter-VLAN traffic. VLAN segmentation is simple to implement on existing infrastructure but provides only coarse separation, typically by department or function rather than by individual system.
Microsegmentation implements fine-grained controls at the workload level, restricting communication between individual systems regardless of network location. A microsegmented database server permits connections only from specific application servers on specific ports, denying all other traffic even from systems in the same VLAN. Microsegmentation typically uses software-defined networking or host-based firewalls with centrally-managed policies. The administrative overhead is higher than VLAN segmentation but provides stronger isolation.
Segmentation design starts with identifying systems that should communicate and building policy to permit only those communications. A grants management application consists of web servers, application servers, and a database. The web servers need to accept connections from users and communicate with application servers. The application servers need to receive connections from web servers and communicate with the database. The database needs to accept connections from application servers and reach backup systems. No other communication paths are required, so policy should deny them:
Grants Management Application - Segmentation Policy
Web tier (zone: DMZ) INBOUND: permit from users:any to web-servers:443 OUTBOUND: permit from web-servers to app-servers:8080 deny from web-servers to any
Application tier (zone: APP) INBOUND: permit from web-servers to app-servers:8080 OUTBOUND: permit from app-servers to db-servers:5432 permit from app-servers to ldap-servers:636 deny from app-servers to any
Database tier (zone: DATA) INBOUND: permit from app-servers to db-servers:5432 permit from backup-servers to db-servers:5432 OUTBOUND: permit from db-servers to backup-servers:5432 deny from db-servers to anyThis policy permits exactly the communication paths required for application function and denies everything else. An attacker compromising a web server cannot directly reach the database; they must additionally compromise an application server. An attacker compromising the database cannot reach other data zone systems or exfiltrate data directly; they must find a path through permitted connections.
Segmentation enforcement points require capacity for expected traffic volumes plus headroom for traffic growth and attack conditions. A firewall enforcing segmentation between application and data zones must handle normal query traffic, backup traffic, and potentially elevated traffic during attacks without becoming a bottleneck. Undersized enforcement points create availability risks that may pressure administrators to create overly-permissive rules.
Web filtering and proxy architecture
Web filtering controls user access to internet content, blocking categories of sites, specific domains, and content types based on organisational policy. Beyond policy enforcement, web filtering protects users from malicious sites, phishing pages, and malware downloads. Proxy architecture provides a control point for web filtering and enables additional security functions including TLS inspection, data loss prevention, and bandwidth management.
Forward proxies sit between users and the internet, receiving user requests, evaluating them against policy, and forwarding permitted requests to destination servers. Explicit proxy configuration requires client configuration to direct traffic through the proxy; transparent proxy deployment intercepts traffic at the network layer, requiring no client configuration. Transparent proxies simplify deployment but complicate HTTPS handling since the proxy cannot inspect encrypted traffic without performing TLS interception.
TLS inspection terminates user TLS connections at the proxy, allowing inspection of decrypted content before re-encrypting and forwarding to the destination. This inspection enables filtering based on full URLs rather than just domain names, detection of malware in encrypted downloads, and data loss prevention for encrypted channels. TLS inspection requires deploying a trusted CA certificate to endpoints so they accept the proxy’s certificates; it also raises privacy and legal considerations since the proxy sees all traffic content. Some jurisdictions and some types of data (banking, healthcare) may have legal restrictions on TLS interception.
Web filtering categories typically include malware and phishing (always blocked), adult content and gambling (blocked for policy reasons), and streaming media or social networking (blocked or throttled for bandwidth management). Category databases are maintained by filtering vendors and require subscription updates. Custom blocks address organisation-specific requirements not covered by standard categories.
Effective web filtering requires logging and reporting to identify policy violations, detect potential compromise (users accessing command-and-control domains), and demonstrate compliance. Logs should capture source user/device, destination, category, action taken, and timestamp. Log retention periods should align with organisational policy and any regulatory requirements.
Cloud-delivered web filtering services provide filtering without on-premises proxy infrastructure. These services route user traffic through vendor infrastructure, apply filtering policies, and forward permitted traffic to destinations. Cloud delivery simplifies deployment, particularly for distributed organisations with many locations, but routes all web traffic through third-party infrastructure with associated privacy and jurisdictional implications.
DDoS protection
Distributed denial of service attacks attempt to exhaust network, server, or application resources by flooding targets with traffic from many sources. Attack volumes can exceed target bandwidth capacity by orders of magnitude; a 100 Gbps attack against a site with 1 Gbps upstream connectivity cannot be mitigated locally because the upstream link saturates before traffic reaches defence systems.
Volumetric attacks flood targets with traffic volume, saturating bandwidth. Common techniques include UDP amplification using DNS, NTP, or memcached servers that respond to small requests with large responses, and SYN floods that exhaust connection state tables. Defence requires upstream filtering or scrubbing services that can absorb attack volume before it reaches the target.
Protocol attacks exploit weaknesses in network protocols, consuming resources with malformed or specially-crafted packets. SYN floods create half-open connections that exhaust state tables. Slowloris attacks hold HTTP connections open with minimal bandwidth. Defence involves rate limiting, connection timeouts, and protocol-aware filtering.
Application attacks target specific application vulnerabilities or resource-intensive operations, appearing as legitimate traffic while exhausting application capacity. A search function that performs expensive database queries can be overwhelmed by repeated search requests. Defence requires application-layer awareness to distinguish attacks from legitimate usage.
DDoS mitigation strategies layer according to attack type and volume:
On-premises mitigation handles low-volume attacks using firewalls and IPS with rate limiting and connection management. These defences fail when attack volume exceeds link capacity. Organisations with bandwidth under 10 Gbps should assume volumetric attacks will require upstream assistance.
Upstream ISP mitigation applies filtering at the ISP level, blocking attack traffic before it enters the customer link. ISP capabilities vary; some provide basic filtering at no cost, others offer premium DDoS protection services. Arrangements with ISPs should be established before attacks occur.
Scrubbing services route traffic through third-party infrastructure that filters attack traffic and forwards legitimate traffic. During attacks, DNS records or BGP announcements redirect traffic to the scrubbing service. This redirection adds latency during attacks and requires the scrubbing service to see all traffic content. Scrubbing services charge based on traffic volume and attack frequency.
CDN-based protection uses content delivery networks to absorb attacks at distributed edge locations. CDNs designed for DDoS protection can handle attacks in the hundreds of Gbps range. This approach works well for web applications but may not protect non-web services.
Attack response requires detection, classification, and mitigation selection. Detection uses traffic monitoring to identify volume anomalies or attack signatures. Classification determines attack type to select appropriate mitigation. Mitigation activates appropriate defences, potentially including ISP notification and scrubbing service engagement.
Wireless security
Wireless networks extend the network perimeter to any location within radio range, making authentication and encryption essential for confidentiality and access control. Unencrypted wireless traffic is trivially interceptable; weak authentication allows unauthorised access to network resources.
WPA3 represents the current security standard for wireless networks, improving on WPA2 with stronger encryption key derivation, protection against offline dictionary attacks on passwords, and forward secrecy preventing decryption of captured traffic even if the password is later compromised. WPA3-Personal uses Simultaneous Authentication of Equals (SAE) for password-based authentication; WPA3-Enterprise uses 802.1X authentication with EAP methods.
WPA2-Enterprise remains common and provides adequate security when properly configured. Enterprise mode uses 802.1X authentication rather than pre-shared keys, enabling individual credentials for each user and integration with identity management systems. The EAP method should be PEAP or EAP-TLS; legacy methods like LEAP should be disabled. Server certificate validation must be configured on clients to prevent evil twin attacks where attackers create fake access points with legitimate-appearing names.
+----------------------------------------------------------------------+| ENTERPRISE WIRELESS ARCHITECTURE |+----------------------------------------------------------------------+
+-------------------------+ | RADIUS Server | | (authentication) | | | | - User database or | | LDAP/AD integration | | - Certificate auth | | - Posture policies | +-----------+-------------+ | | RADIUS | +---------------------+---------------------+ | | | v v v+---------+---------+ +---------+---------+ +---------+---------+| Wireless | | Wireless | | Wireless || Controller | | Access Point | | Access Point || (centralised | | (autonomous or | | (field office, || management) | | lightweight) | | cloud-managed) |+---------+---------+ +---------+---------+ +---------+---------+ | | | | 802.1X auth | 802.1X auth | 802.1X auth | | | v v v +-----+-----+ +-----+-----+ +-----+-----+ | Client | | Client | | Client | | device | | device | | device | +-----------+ +-----------+ +-----------+
All clients authenticate with individual credentials Authentication determines VLAN assignment Failed authentication = no network accessFigure 5: Enterprise wireless architecture with centralised authentication
Pre-shared key (PSK) authentication uses a single password shared among all users of a network. PSK simplifies deployment but complicates credential management: when any user leaves the organisation or a device is lost, the PSK should be changed and redistributed to all remaining users and devices. PSK is appropriate for guest networks or small deployments where individual credentials create disproportionate management overhead. PSK networks should be isolated from corporate resources.
Wireless segmentation uses separate SSIDs for different purposes and trust levels: a corporate SSID with 802.1X authentication and full network access, a guest SSID with PSK and internet-only access, a device SSID for IoT equipment with restricted access. Each SSID maps to a different VLAN with appropriate firewall policy.
Rogue access point detection identifies unauthorised wireless devices broadcasting SSIDs. Attackers may deploy rogue APs to capture credentials or provide network access points. Enterprise wireless systems include rogue detection using managed APs as sensors; standalone wireless IDS provides similar capability without integrated management.
Field deployment considerations
Field offices present network security challenges that require adaptation of controls designed for well-resourced headquarters environments. Limited bandwidth, unreliable connectivity, constrained budgets, and physically accessible equipment all influence security architecture decisions.
Bandwidth constraints affect security control selection. Full TLS inspection at a 5 Mbps link creates unacceptable latency; DNS-based filtering provides category blocking without inline inspection overhead. Signature-based IDS with full rule sets may exceed processing capacity of field-appropriate hardware; reduced rule sets focusing on critical signatures maintain protection within hardware limits. Cloud-delivered security services may be impractical when connectivity is intermittent.
Hardware constraints require security functions to run on smaller, lower-power devices. A headquarters deployment might use dedicated firewall, IDS, and web filter appliances; a field office might consolidate all functions on a single unified threat management device or router with security features. Feature trade-offs are necessary when hardware cannot support all desired functions simultaneously.
Physical security differs in field contexts where equipment may be in accessible locations, subject to theft, or vulnerable to physical tampering. Hardware security modules and encrypted storage protect sensitive configuration. Remote wipe capabilities enable destruction of configuration data if devices are seized. Tamper detection alerts when enclosures are opened.
Resilience requirements include graceful degradation when connectivity fails or headquarters-based services are unreachable. Local authentication caches enable continued network access when central authentication servers are unreachable. Local policy enforcement continues protecting the network even when central management is unavailable. Automatic failover to backup connectivity maintains protection during primary link outages.
Legacy and unmanaged devices
Networks inevitably include devices that cannot participate in modern security architectures: legacy equipment with outdated software, IoT devices without security features, contractor equipment outside organisational management, and guest devices belonging to visitors. Security architecture must accommodate these devices without undermining overall protection.
Network isolation places unmanaged devices on separate network segments with restricted access. A printer VLAN permits printing from corporate devices but denies printer-initiated connections to other systems. An IoT VLAN permits devices to reach required cloud services but denies local network access. Guest networks provide internet access without any internal network connectivity. Isolation limits damage from compromised unmanaged devices.
MAC Authentication Bypass provides network access for devices that cannot support 802.1X authentication. MAB should assign devices to restricted VLANs and should be limited to known device MAC addresses. Regular audits of MAB-enabled devices identify unexpected entries that might indicate unauthorised devices or spoofing attempts.
Network behaviour analysis monitors unmanaged device traffic for anomalies that might indicate compromise. A printer that begins scanning network ports or communicating with unusual external destinations has likely been compromised. Behaviour baselines for each device type enable detection of deviations from normal patterns.
Compensating controls strengthen protection for networks including unmanaged devices. More aggressive IDS rules for segments with legacy devices compensate for devices’ inability to protect themselves. More restrictive egress filtering limits command-and-control options for compromised devices. Enhanced monitoring increases visibility into device behaviour.
Technology options
Network security technology spans open source solutions suitable for self-managed deployment, commercial products with vendor support, and cloud-delivered services requiring no infrastructure. Selection criteria include required features, operational capacity for management, budget constraints, and jurisdictional considerations for cloud services.
Open source firewall options include pfSense and OPNsense, both FreeBSD-based distributions providing stateful firewalling, VPN, and basic IDS/IPS through Suricata integration. These platforms run on commodity hardware, reducing costs for organisations with Linux/BSD administration skills. Feature sets rival commercial offerings for small to medium deployments. OpenWrt provides firewall and routing capabilities for embedded devices, relevant for field deployments on compact hardware.
Open source IDS/IPS includes Suricata and Snort, both providing signature and anomaly detection. Suricata offers better multi-threading performance on modern hardware. Both integrate with pfSense/OPNsense for unified deployment. Zeek (formerly Bro) provides network traffic analysis with different detection approaches than signature-based systems.
Open source NAC presents challenges as comprehensive solutions are less mature than commercial offerings. PacketFence provides open source NAC with 802.1X, captive portal, and VLAN management. FreeRADIUS provides the authentication server component for 802.1X deployments.
Commercial unified threat management platforms from vendors including Fortinet, Sophos, and WatchGuard consolidate firewall, IPS, web filtering, and other functions. These platforms suit organisations preferring integrated solutions with vendor support over component assembly. Nonprofit discount programmes reduce costs.
Cloud-delivered security services route traffic through provider infrastructure for filtering and protection. Cloudflare, Zscaler, and similar services provide web filtering, DDoS protection, and threat detection without on-premises infrastructure. Jurisdictional considerations apply since traffic routes through provider infrastructure; US-headquartered providers are subject to CLOUD Act provisions.
Implementation considerations
For organisations with limited IT capacity
Network security implementation with a single IT person focuses on high-impact controls with minimal ongoing management overhead. A unified threat management device at the network perimeter provides firewall, basic IDS, and web filtering in a single manageable platform. Cloud-delivered DNS filtering (Quad9, Cloudflare Gateway) provides malware and phishing protection without on-premises infrastructure. Wireless security uses WPA3 or WPA2-Enterprise with cloud-managed access points handling 802.1X through integration with identity providers.
The priority sequence for limited-capacity deployment:
- Perimeter firewall with default-deny and logging (immediate)
- DNS-based filtering for malware protection (immediate, no hardware)
- Network segmentation between user and server systems (within 3 months)
- Wireless authentication tied to user identities (within 6 months)
- Basic IDS monitoring on UTM device (as capacity allows)
For organisations with established IT functions
Larger organisations implement layered controls with dedicated devices for each function. Separate firewall, IDS/IPS, and web filtering platforms allow independent scaling and reduce single points of failure. Internal segmentation with microsegmentation for sensitive workloads provides defence in depth against lateral movement. Full 802.1X deployment on all network ports with posture assessment ensures only compliant devices connect.
Advanced capabilities include deception technology deploying honeypots that detect attackers who have bypassed perimeter controls, network behaviour analysis identifying anomalies that signature-based detection misses, and automated response playbooks that trigger containment actions when attacks are detected.
For field deployments
Field network security balances protection against operational constraints. Consolidated security on routing platforms minimises hardware and power requirements. Local policy enforcement operates independently during connectivity outages. Simplified configuration reduces troubleshooting complexity when local IT support is unavailable. Remote management with local fallback enables headquarters oversight with field autonomy when needed.
Cloud-managed security devices suit field deployments when connectivity permits. Management traffic is minimal compared to user traffic, so cloud management often works on constrained links. Local caching of policy enables continued operation during connectivity outages.