Security Engineering: Securing Networks

This course explores network security by analyzing network device deployment, reviewing network infrastructure security controls, and implementing network security monitoring. By the end of this material, you should be able to assess network infrastructure and determine where to place network security controls in order to provide the best protection for an organization’s network infrastructure. Familiarity with fundamental security principles and basic networking concepts is assumed.

Table of Contents

• Module 1: Analyzing and Deploying Network Devices
  • Switch Security
  • Router Security
  • Wireless Security
  • Virtual Private Networks (VPNs)
  • Logging and Reporting
  • Network Taps
• Module 2: Reviewing Network Infrastructure and Controls
  • Proxies
  • Tiered Architecture
  • Firewalls
  • Network Zones
  • Zero Trust Network Architecture
  • Routing Protocol Security
  • AAA and Remote Access
• Module 3: Implementing Network Security Monitoring
  • Network Logging
  • Security Information and Event Management (SIEM)
  • Network Intrusion Detection and Prevention
  • Network Security Monitoring Tools
  • Honeynets and Honeypots
  • Adversarial Tactics, Techniques, and Procedures
  • Compliance Considerations
• Summary

Module 1: Analyzing and Deploying Network Devices

This module analyzes the security controls that should be applied to the core categories of network devices — switches, routers, wireless access points, VPN concentrators — along with the logging practices and physical monitoring techniques (network taps) that support their secure deployment.

Switch Security

Layer 2 switch devices connect hosts — servers, workstations, IP phones — to an organization’s network infrastructure. When examining overall switch architecture, three tiers matter from a security perspective:

flowchart TB
    subgraph Access["Access Layer"]
        A1[Workstations]
        A2[IP Phones]
        A3[Printers]
    end
    subgraph Distribution["Distribution Layer"]
        D1[Broadcast domain control]
        D2[Inter-segment traffic handling]
    end
    subgraph Core["Core Layer"]
        C1[Backbone switching]
        C2[High performance / fault tolerance]
    end
    Access -->|Port Security| Distribution
    Distribution -->|VLANs / Trunking| Core

Access layer — port security. Hosts connect at the access layer, which is the entry point for end-user devices. Port security lets you create a list of secure MAC addresses authorized to connect to a switch port, and lets you cap how many devices may connect through that port. Two learning modes govern how the switch adds a device’s MAC address to the authorized list:

• Dynamic mode — the switch automatically learns the MAC address of connected devices. Learning can be capped to a single entry so only the first connected device is authorized; any later device with a different MAC address becomes unauthorized. This scales well for large environments.
• Static mode — the administrator manually configures the list of known secure MAC addresses, removing the risk of dynamically learning an unintended device.

Once the secure MAC address list is established, port security defines how the switch reacts when the maximum number of secure MAC addresses is reached:

Depending on the sensitivity of the environment, a security engineer can choose the more forgiving protect/restrict modes, or immediately shut the port down as soon as an unknown device connects.

Distribution layer — VLAN segmentation. The distribution layer controls broadcast domains and handles traffic between network segments. One of the strongest Layer 2 controls here is network segmentation using VLANs (Virtual Local Area Networks), which provide logical segmentation so hosts are grouped by VLAN assignment rather than by physical switch. A printer assigned to VLAN 20 can only be reached by other devices in VLAN 20, even across different physical switches.

To connect VLANs across switches, a trunk port carries multiple VLANs over a single physical link. Some switches can dynamically negotiate trunk ports — convenient, but attackers can abuse this feature to create unauthorized trunk links and bypass VLAN segmentation through VLAN hopping. Dynamic trunking protocols should be disabled so that trunk ports require explicit manual configuration.

Private VLANs (PVLANs) add further isolation by grouping switch ports according to a private VLAN role:

• Isolated private VLAN ports cannot communicate with each other even though they share the same VLAN.
• Community private VLAN ports can communicate with other ports in the same community.

This lets you isolate Layer 2 broadcast traffic so that even members of the same VLAN cannot see each other’s traffic when isolation is required.

Core layer — physical and management security. The core layer is the backbone of the network and must be highly performant and fault tolerant. Because core switches carry so much vital traffic:

• Physical access should be tightly restricted — these are not devices that should be reachable by just anyone.
• Remote management must use secure protocols such as SSH, ideally with certificate-based SSH authentication backed by a public key infrastructure (PKI).
• Logging should be enabled at the core layer (as well as at sensitive access/distribution switches) to provide security visibility — unlogged activity cannot be investigated or actioned.
• Patch management for switches must be prioritized to eliminate known vulnerabilities and exposures (CVEs).

flowchart LR
    A[Unauthorized MAC connects] --> B{Port Security Mode}
    B -->|Protect| C[Drop unauthorized frames<br/>Port stays up]
    B -->|Restrict| D[Drop unauthorized frames<br/>Log/alert violation<br/>Port stays up]
    B -->|Shutdown| E[Port immediately err-disabled]

Router Security

Routers operate at Layer 3, where subnetting isolates hosts by IP address range. Choosing an appropriately sized subnet mask matters for security as well as capacity planning:

Access control lists (ACLs). Extended ACLs permit or deny traffic based on source/destination IP address (Layer 3) as well as transport-layer information such as protocol and port (Layer 4) — for example, permitting SSH by matching TCP port 22, or denying inbound/outbound RDP by blocking TCP 3389 to sensitive Windows servers:

! Example extended ACL concept: deny RDP to sensitive Windows servers,
! permit SSH management traffic from the admin subnet
access-list 101 deny   tcp any host 10.10.20.50 eq 3389
access-list 101 permit tcp 10.10.5.0 0.0.0.255 any eq 22
access-list 101 deny   ip any any

Network Address Translation (NAT). NAT hides many internal devices and endpoints behind a single external IP address, often via port-forwarding, which uses Layer 4 port numbers to direct incoming traffic to specific internal devices. Restrict the number of port-forwarding rules — if a threat actor discovers them, they gain an attack avenue targeting specific internal devices, effectively exposing internal resources and services to the outside internet. NAT can also complicate IPsec, since NAT rewrites addressing information; NAT traversal using UDP encapsulation solves this by tunneling IPsec traffic to a destination device that lacks its own public IP address.

Securing routing protocols (overview). Router deployment should account for routing-protocol security:

• Authentication — protocols like BGP and OSPF support authentication to validate the authenticity of neighboring/peer routers exchanging route advertisements.
• TTL security — properly configuring time-to-live values (for example, BGP TTL security) ensures that only packets from directly connected peers, which will have a TTL of 255, are accepted — meaning the router only accepts packets from peers exactly one hop away.
• Route filtering — BGP route filtering or OSPF area filtering control the propagation of routes; BGP prefix filtering specifically protects against BGP hijacking attacks.

Router deployment considerations checklist:

• Physically secure router devices (locked data center rooms, key-card access, audit trail of physical entry).
• Use encrypted management protocols (SSH) with certificate-based authentication; for software-defined networking environments, configure policies per administrator/device.
• Enable logging for both performance and security visibility.
• Maintain router devices within the organization’s patch management process for both features and security vulnerabilities.

Wireless Security

For most enterprise security engineers, the primary wireless technology to secure is Wi-Fi (IEEE 802.11).

Physical considerations. Wi-Fi uses radio frequency waves, which propagate naturally beyond intended boundaries, so the physical range of transmission/reception must be managed — for example, by adjusting the decibel level of access point antennas. Before adjusting signal strength, an organization should conduct a wireless site survey to ensure coverage reaches intended clients while limiting the perimeter of Wi-Fi access based on the building/location.

Rogue access points. Threat actors set up wireless access points that imitate a legitimate SSID to lure legitimate users. Mitigations include regular wireless scanning combined with user security-awareness training — users should be trained to report suspicious Wi-Fi access points the same way they report phishing emails.

Guest and organizational access.

• Guest users (customers, vendors) can be routed through captive portals requiring registration and limiting the number of connected devices.
• Organizational users authenticate with organizational credentials (e.g., Active Directory) using IEEE 802.1X port-based network access control.

sequenceDiagram
    participant S as Supplicant (laptop)
    participant A as Authenticator (AP/Switch)
    participant AS as Authentication Server (RADIUS)
    S->>A: Connection request
    A->>S: EAP identity request
    S->>A: EAP identity response
    A->>AS: Forward credentials/EAP exchange
    AS->>AS: Verify credentials (incl. certificate-based EAP methods)
    AS-->>A: Access-Accept / Access-Reject
    A-->>S: Grant or deny network access

Under 802.1X, a supplicant (e.g., a user’s laptop) connects to an authenticator (e.g., a wireless access point) to begin authentication. The authenticator verifies the user’s credentials by communicating with an authentication server before granting the supplicant access. Support for varied credential types comes from the Extensible Authentication Protocol (EAP) family, including certificate-based authentication methods for stronger assurance.

Encryption. For enterprise environments, WPA3-Enterprise offers the strongest available encryption.

Ongoing operational hygiene. Wireless access points are physical hardware and must be regularly patched and hardened with updated configurations. As with switches and routers, enable appropriate logging levels to detect security events and monitor wireless performance.

Virtual Private Networks (VPNs)

VPNs encrypt data sent over the public internet, supporting two common scenarios:

1. Site-to-site — tunneling and encrypting traffic between two branch offices (e.g., Miami and New York City), allowing both branches to share network services and resources.
2. Remote access — connecting individual remote users to a site (e.g., the New York City office) so they can use resources that would otherwise be available only within that office.

flowchart LR
    RU[Remote User] -->|Encrypted VPN tunnel| INT((Public Internet))
    INT --> EF[Edge Firewall]
    EF --> ER[Edge Router]
    ER --> VG[VPN Gateway]
    VG -->|Authenticate| RAD[RADIUS Server]
    RAD -->|Apply network policy| VG
    VG --> IN[Internal Network Resources]
    VG -.->|or external IdP| IDP[External Identity Provider e.g. Okta]

Deployment flow: a remote site/user sends encrypted traffic over the public internet, which is filtered at an edge firewall, forwarded through an edge router, and terminated at a VPN gateway. Before internal traffic flows, VPN users are typically authenticated via a RADIUS server applying the appropriate network policy so authorized remote-access clients receive access to the resources granted to them. VPN gateways can also integrate with external identity providers (e.g., Okta). Additional firewalls can further filter VPN traffic destined for especially sensitive network segments.

Primary VPN protocols:

Using AH alone does not encrypt IP packets. Pairing AH with ESP increases overhead, so for sensitive resources choose ESP alone or ESP+AH based on your security requirements.

Cloud-based VPN options. Cloud providers (e.g., Microsoft Azure) let you configure a VPN client on a remote workstation to establish a VPN connection via a cloud VPN gateway, using a protocol of choice:

• IKE
• Secure Socket Tunneling Protocol (SSTP) — developed by Microsoft, primarily supported on Microsoft operating systems
• OpenVPN — highly configurable, open-source, uses TLS for encryption

Cloud providers also support site-to-site VPN connections (e.g., AWS Site-to-Site VPN) between remote branch offices. For organizations connecting multiple sites via a cloud-based VPN, a hub-and-spoke architecture is the preferred, more cost-effective design:

flowchart TB
    Hub((Miami — Hub))
    Hub --- Chicago[Chicago — Spoke]
    Hub --- Austin[Austin — Spoke]
    Hub --- NYC[New York City — Spoke]
    Hub --- LA[Los Angeles — Spoke]

A central hub site (e.g., Miami) anchors site-to-site VPN connections to each spoke (Chicago, Austin, New York City, Los Angeles), avoiding the higher expense of building individual connections between every pair of sites.

Logging and Reporting

Logging records events — who (users/identities) did what (action), when, and where — enabling investigation of why, and whether an action was malicious. Gathering logs is essential to supporting security event detection.

Protocols and platforms:

• SNMP (Simple Network Management Protocol) — collects object identifiers providing network device metrics (CPU usage, memory usage, temperature, and more), stored in a Management Information Base (MIB), giving insight into device status, performance, and availability.
• Syslog (RFC 5424) — a standardized logging protocol used by many network devices and Linux distributions. Provides centralized logging: Syslog-enabled devices send logs to a centralized Syslog server, ideally secured with TLS encryption and certificates. Syslog servers can feed into SIEM platforms for querying and filtering. Centralized Syslog storage also supports availability (redundant backup) and integrity verification (via hashing algorithms) of stored logs.

flowchart LR
    ND[Network Devices] -->|SNMP metrics| MIB[Management Information Base]
    ND2[Devices / Linux hosts] -->|Syslog over TLS| SS[Centralized Syslog Server]
    SS --> SIEM[SIEM Platform]
    MIB --> SIEM
    SIEM --> Analyst[Security Analyst: query, investigate, respond]

What to log:

• Configuration changes — especially to sensitive network resources (firewalls, routers), and particularly changes occurring outside scheduled change windows.
• Access and protocol activity — alert on unusual activity outside normal operational hours, especially for management protocols like RDP or SSH.
• Failed authentication attempts — a telltale sign of password spraying or brute-force attacks; prioritize alerting so analysts can investigate quickly.
• Large data egress — often related to data exfiltration (PII, internal secrets); log activity at network edges/boundaries (edge firewalls/routers) to catch this early.
• Performance metrics — help identify issues like denial-of-service attacks.

Logging supports both security investigations and governance, risk, and compliance (GRC) requirements, allowing internal and external auditors to verify the effectiveness of security controls.

Network Taps

Network tapping allows reading network traffic passing through an interface.

Port mirroring selects a switch port interface to mirror traffic from all other interfaces on the switch, connecting to a network analyzer. It can suffer performance issues under heavy traffic, so a purpose-built hardware network tap is recommended for high volumes.

Tap power types:

Tap deployment types:

flowchart TB
    subgraph Inline["Inline Deployment"]
        H[Host] --- T1[Network Tap] --- Sw[Switch]
        T1 --> NA1[Network Analyzer]
    end
    subgraph Aggregator["Aggregator Tap"]
        SwA[Switch] --> T2[Aggregator Tap]
        FwA[Firewall] --> T2
        T2 --> NA2[Network Analyzer]
    end
    subgraph Regeneration["Regeneration Tap"]
        HB[High-bandwidth link e.g. fiber] --> T3[Regeneration Tap]
        T3 --> NA3a[Network Analyzer 1]
        T3 --> NA3b[Network Analyzer 2]
    end

• Inline — placed between a host and switch; ideal for real-time monitoring with no packet loss, but represents a single point of failure if it malfunctions.
• Aggregator — combines multiple network interfaces/links (e.g., a switch and a firewall) into a single monitored stream; risk of congestion/packet loss if aggregated volume exceeds the monitoring port’s speed.
• Regeneration — typically connected to a high-bandwidth interface (e.g., fiber), replicating traffic out to multiple analyzers simultaneously; requires special configuration to ensure all downstream devices receive timely, accurate data, and is more complex given the high-bandwidth source.

Module 2: Reviewing Network Infrastructure and Controls

This module reviews the infrastructure components and architectural controls that shape how traffic flows through — and is filtered within — an organization’s network: proxies, tiered architectures, firewalls, trust zones, zero trust architecture, routing protocol security in depth, and AAA/remote access.

Proxies

A proxy acts as an intermediary facilitating communication on someone’s behalf — much like enlisting a middle person to conduct business with a counterpart across the globe.

Forward proxy — the client forwards requests to the proxy, which acts on the client’s behalf.

• Caches content locally so multiple clients don’t repeatedly fetch the same content from the internet, saving time and bandwidth.
• Logs client requests/connections, since all client activity passes through the proxy.
• Enforces rules limiting or denying traffic — e.g., blocking access to certain web resources/URLs.

Reverse proxy — proxies traffic on behalf of the server.

• Caches frequently requested content (media, web pages), improving client response time and reducing load on backend servers.
• Compresses responses to further reduce bandwidth usage.
• Filters client requests to protect backend servers — Web Application Firewalls (WAFs) are a form of reverse proxy (see Firewalls).
• Protects availability via load balancing, distributing traffic among a pool of backend servers and helping resist denial-of-service attacks.

SMTP proxies specifically distribute email protocol traffic among email servers to preserve mail service availability — important given the volume and criticality of email traffic in an enterprise.

flowchart LR
    subgraph Forward["Forward Proxy"]
        C1[Client] --> FP[Forward Proxy] --> Internet1((Internet))
    end
    subgraph Reverse["Reverse Proxy"]
        Internet2((Internet)) --> RP[Reverse Proxy] --> S1[Backend Server 1]
        RP --> S2[Backend Server 2]
        RP --> S3[Backend Server 3]
    end

Security engineers must review proxy deployments and select the appropriate type based on business needs.

Tiered Architecture

The most popular multi-tier design for web applications is the three-tier architecture: presentation tier, application tier, and data tier.

flowchart LR
    P[Presentation Tier<br/>Browser / Mobile App] -->|HTTP / REST APIs| A[Application Tier<br/>Web Server + App Logic]
    A -->|Queries| D[(Data Tier<br/>Database)]
    A -.WAF, API Gateway, Load Balancer.-> A

• Presentation tier — the client (workstation, mobile application) uses a browser or mobile app leveraging HTTP to interact with the application, directly or via RESTful APIs. Security review here focuses on testing and reviewing code used for client-based interactions.
• Application tier — the web server (or other server) hosting developer code and application logic that handles client requests/responses. Deploy Web Application Firewalls to stop OWASP Top 10-style web attacks, plus API gateways and load balancers to preserve availability and resist denial-of-service attacks.
• Data tier — databases storing large amounts of data used to respond to presentation-tier clients. Enable access controls based on identities, servers, and services so only appropriate parties can read, write, and modify data.

All inter-tier communication should be encrypted using strong protocols such as certificate-based TLS.

Firewalls

Network firewalls filter traffic primarily on lower-OSI-layer criteria: Layer 3 source/destination IP addresses, and Layer 4 ports/protocols (e.g., TCP 20/21 for FTP). This restricts access between network devices and safeguards against malicious traffic to network resources.

Firewall rule actions:

flowchart TD
    T[Inbound/Outbound Traffic] --> R{Matches a Rule?}
    R -->|Permit rule matches| Allow[Traffic allowed]
    R -->|Deny rule matches| Deny[Blocked + reply sent]
    R -->|Drop rule matches| Drop[Blocked silently, no reply]
    R -->|Reset rule matches| Reset[TCP connection terminated]
    R -->|No rule matches| Implicit[Implicit Deny: traffic blocked]

Next-generation firewalls (NGFW) add advanced capabilities beyond classic packet filtering:

• Deep packet inspection (DPI) — inspects packet payloads for malicious activity, malware, and data exfiltration.
• Stateful inspection — dynamically filters packets based on the state of established/active connections, protecting against attacks like session hijacking, and enabling active session control (terminate/reset unusual connections).
• Threat intelligence feeds — dynamically update firewall policies/rules using open-source or commercial threat intelligence, often exchanged via TAXII (Trusted Automated eXchange of Indicator Information) in the STIX (Structured Threat Information eXpression) format. Feeds typically include malicious domains, IP addresses, and file hashes.

Because of these capabilities, NGFWs detect and prevent threats more proactively than manually configured standard firewalls, and often absorb capabilities historically found in standalone network intrusion detection/prevention systems.

Web Application Firewalls (WAF) operate at the application layer to protect web applications/servers from malicious traffic — SQL injection, cross-site scripting, remote file inclusion, and other attacks catalogued by the OWASP Top 10 (Open Worldwide Application Security Project). OWASP also maintains the ModSecurity open-source WAF project; many commercial WAF products leverage the ModSecurity Core Rule Set.

Firewall type comparison:

Network Zones

Zones of trust are associated with the level of trust and security tied to how a resource connects to the network, largely governed by firewall placement and rule configuration.

Demilitarized zone (DMZ) example. A common DMZ setup exposes a web server to the public internet:

flowchart LR
    Internet((Public Internet<br/>Untrusted Zone)) --> ER[Edge Router]
    ER --> FW1[Firewall 1<br/>Highly restrictive]
    FW1 --> WS[Web Server<br/>DMZ / Semi-trusted Zone]
    WS --> FW2[Firewall 2<br/>Faces trusted network]
    FW2 --> FW3[Firewall 3<br/>Optional — creates screened subnet]
    FW3 --> Internal[Trusted Internal Network]

• The first firewall filters incoming client HTTP traffic destined for the web server with highly restrictive rules.
• The second firewall, facing the trusted internal network, must prevent unauthorized public internet users from reaching sensitive internal resources — while still allowing internal developers to push updates to the web server.
• A three-tier firewall architecture adds a third firewall between the DMZ and the internal network, creating a screened subnet: an additional monitored buffer for identifying malicious activity before it can reach the trusted zone.

Zero Trust Network Architecture

Zero trust can be summarized as “Never trust, always verify.” It eliminates implicit trust by requiring strong authentication for every identity accessing a network resource, every time, following strict identity verification. This supports the principle of least privilege — identities are granted only the access required for their job role (e.g., a help desk agent is denied access to a sensitive SQL database).

Zero trust also embraces assume breach: design network architecture as though a malicious adversary is already present, using segmented access, explicit authorization for every resource, and strong MFA — minimizing the blast radius of a potential compromise.

flowchart TB
    Identity[Any Identity / Device] -->|Every request re-verified| PolicyEngine{Policy Decision:<br/>Authenticate + Authorize}
    PolicyEngine -->|Deny| Blocked[Access Denied]
    PolicyEngine -->|Permit| Segment[Access to specific microsegment only]

Microsegmentation:

Software-Defined Perimeter (SDP). SDP makes network resources (IP addresses, ports, applications, workloads) unknown and inaccessible to unauthorized identities — only authorized connections between identities and resources can even be established, reinforcing least privilege and zero trust.

sequenceDiagram
    participant Client as Client (identity / device)
    participant Controller as SDP Controller
    participant Gateway as SDP Gateway (per resource)
    participant Resource as Network Resource
    Client->>Controller: Request access
    Controller->>Controller: Evaluate policy conditions + entitlements
    Controller-->>Client: Permit/Deny decision
    Controller->>Gateway: Communicate authorized entitlements
    Gateway->>Gateway: Enforce policy + dynamic microsegmentation
    Client->>Gateway: Establish connection
    Gateway->>Resource: Allow access per policy enforcement

The SDP client (identity or authorized device) requests access; the SDP controller evaluates the request against policy conditions and entitlements. If permitted, the controller communicates with the gateway assigned to the target resource, which performs policy enforcement and dynamically creates microsegmentation rules based on the controller’s entitlements — after which the client establishes a connection to the resource.

Routing Protocol Security

IP source routing. A legacy technique letting the sender specify the route a packet should take (rather than letting routers determine it via their routing tables). Most modern routers disable this by default since it has few legitimate uses and can let an attacker bypass security controls or perform network enumeration. Disable IP source routing if present.

OSPF threats and defenses:

flowchart LR
    A[Remote False Adjacency<br/>unauthorized OSPF adjacency] --> B[OSPF Spoofing<br/>impersonate a router, fraudulent source address]
    B --> C[Route Injection<br/>false info via Link State Advertisements]
    C --> D[LSA Flooding<br/>denial-of-service, resource exhaustion]

Defenses:

• Area authentication — validate authenticity of OSPF routers within an area using strong hashing (SHA-256 or above).
• Multi-area segmentation — avoid a single flat OSPF area to limit the spread of malicious LSAs.
• TTL security — accept OSPF packets only with a TTL of 255, preventing off-path remote attacks (only directly connected neighbors will present a TTL of 255).
• Logging and monitoring — as always, essential for visibility and incident response.

! Illustrative OSPF security hardening (Cisco IOS style)
router ospf 1
 area 0 authentication message-digest
interface GigabitEthernet0/1
 ip ospf message-digest-key 1 md5 <strong-key>
 ip ospf ttl-security hops 1

BGP threats and defenses:

Defenses:

• TCP Authentication Option (TCP-AO) — validates authenticity of BGP peers.
• Prefix filtering — limits the BGP IP prefixes accepted from peers, mitigating flooding and hijacking.
• Route Origin Validation (ROV) via RPKI (Resource Public Key Infrastructure) — cryptographically verifies ownership of BGP IP prefixes. Ownership is established through Route Origin Authorization (ROA); once verified, BGP routers use Route Origin Validation to confirm updates originate from the legitimate owner.
• TTL security — as with OSPF, only accept BGP packets with a TTL of 255, since TTL decrements by 1 per hop and a non-directly-connected peer’s packets will arrive with a lower value.

! Illustrative BGP security hardening (Cisco IOS style)
router bgp 65001
 neighbor 203.0.113.1 password <strong-shared-secret>
 neighbor 203.0.113.1 ttl-security hops 1
 neighbor 203.0.113.1 prefix-list INBOUND-FILTER in

Security engineers reviewing network infrastructure must account for these defenses and reflect them in network diagrams — for example, placing an OSPF border router at the edge of OSPF areas and the autonomous system boundary.

AAA and Remote Access

AAA stands for:

• Authentication — verifying an identity truly is who it claims to be.
• Authorization — the permissions, entitlements, and access granted to that identity.
• Accounting — a record of authentication/authorization actions performed by identities, systems, and network resources.

AAA protocol comparison:

Wireless tie-in. As covered in Wireless Security, the AAA server can serve as the authentication server in an 802.1X exchange, with the supplicant communicating through an authenticator (e.g., a wireless access point). AAA servers can use certificate-based authentication combined with encrypted communication.

VPN tie-in. As covered in Virtual Private Networks (VPNs), a VPN device/server acts as the authenticator communicating with an AAA server for authorization.

flowchart LR
    Sup[Supplicant / Remote User] --> Auth[Authenticator<br/>AP / VPN Gateway]
    Auth --> AAA[AAA Server<br/>RADIUS / TACACS+ / Diameter]
    AAA -->|Authenticate + Authorize + Account| Auth
    Auth -->|Grant scoped access| Resource[Network Resource]

Authorization enforcement. ACLs enforce permit/deny/drop decisions at both network and application layers. Remote management protocols — SSH, Windows Remote Management, Remote Desktop Protocol — are especially sensitive and must be authenticated via AAA protocol servers, with their sessions encrypted.

Module 3: Implementing Network Security Monitoring

This module covers the tooling and processes for turning network activity into actionable security intelligence: network logging protocols, SIEM platforms, network intrusion detection/prevention, additional monitoring tools (Zeek, Sigma, Detection-as-Code), honeynets, the adversarial TTPs security engineers must defend against, and the compliance frameworks that shape monitoring requirements.

Network Logging

Revisiting logging with a network focus: logging records who did what, when, and where, letting us determine why and monitor for malicious activity.

Packet capture is the most in-depth form of network logging, occurring at the network interface level. Common tools:

These tools perform low-level logging at the packet payload level — ideal for security investigations and performance troubleshooting.

High-level network traffic logging captures large volumes of flow data — IP addresses, Layer 4 ports/protocols, and other flow attributes — via protocols such as NetFlow and IPFIX (and other NetFlow variants). These require infrastructure: cache storage, collectors, and an export destination. They provide insight into devices, applications, and endpoints supporting security monitoring.

flowchart LR
    Iface[Network Interface] -->|Full payload| PCAP[Packet Capture<br/>WireShark / TCPdump / NetMon]
    Iface -->|Flow metadata| Flow[NetFlow / IPFIX]
    Flow --> Collector[Flow Collector + Cache Storage]
    PCAP --> Investigate[Security Investigation]
    Collector --> Investigate
    Investigate --> SIEMFeed[Feed into SIEM]

Operational practices:

• Prioritize highly sensitive assets/systems and apply deeper logging levels to them.
• Tune logging levels to avoid duplicate information and unnecessary resource consumption.
• Follow compliance requirements for log retention periods and required log types.
• Regularly test log collection effectiveness to ensure accurate data reaches the SIEM.

Security Information and Event Management (SIEM)

SIEM platforms collect log data from across the network so it can be queried, particularly for security investigations.

flowchart TB
    NF[Network Traffic Logs] --> Ingest[Collection / Correlation / Ingestion]
    SL[Syslogs] --> Ingest
    EL[Endpoint Logs<br/>Windows Event Log, EDR] --> Ingest
    Ingest --> Query[Security Team Queries]
    Query --> Alert[Alerts on Thresholds]
    Query --> Dash[Dashboards]
    Alert --> Analyst[Security Analyst Response]
    Dash --> Analyst

Log sources feeding a SIEM commonly include network traffic logs, Syslogs, and endpoint logs (e.g., Windows Event Log, EDR-vendor telemetry) — among many possible sources.

Querying. Splunk (a popular commercial SIEM, using the Search Processing Language) is one example; open-source alternatives include the Elastic, Logstash, and Kibana (ELK) stack.

Example query against collected endpoint logs looking for failed authentication attempts (Windows Security Event ID 4625 — failed logon):

index=* EventCode=4625
| stats count by user, Computer, src_ip, Message
| rename count as "Failed Authentication Attempts"
| sort - "Failed Authentication Attempts"

Example query looking for malicious scheduled-task activity (Windows Security Event IDs 4698, 4699, 4700 — scheduled task created / deleted / enabled), which often correlates with threat actors creating or modifying scripts for automated malicious action:

index=* (EventCode=4698 OR EventCode=4699 OR EventCode=4700)
| stats count by user, Computer, Message
| rename count as "Scheduled Task Events"
| sort - "Scheduled Task Events"

Alerting and dashboards. SIEM platforms can trigger alerts when a specific threshold is reached (e.g., a burst of failed authentication attempts), enabling rapid analyst response. Customizable graphical dashboards surface relevant information — endpoint event summaries, failed-authentication graphs, network traffic charts — making SIEM a critical platform for security investigation, network security intelligence, and overall network insight.

Network Intrusion Detection and Prevention

Historically, Network Intrusion Detection Systems (NIDS) passively monitored for intrusions and malicious activity and sent alerts, while Network Intrusion Prevention Systems (NIPS) actively blocked malicious traffic. Today these capabilities are commonly bundled together (IDS/IPS).

Snort. One of the oldest and most popular IDS/IPS tools. It performs real-time packet capture via libpcap (the same library used by WireShark/TCPdump) and lets you write Snort rules to analyze traffic using IP addresses, ports, protocols, and payload inspection based on signatures or behavior patterns. Pre-written community and commercial rule sets are available (e.g., a Cisco-managed Snort subscriber rule set), enabling detection of denial-of-service attacks, port scans, malware signatures, and other indicators of compromise.

Example Snort rule detecting RDP brute-force attempts — alerting whenever 5 or more TCP 3389 connections are established from the same external source IP within a 60-second window:

alert tcp $EXTERNAL_NET any -> $HOME_NET 3389 \
    (msg:"RDP brute force attempt"; \
     flow:established,to_server; \
     threshold:type threshold, track by_src, count 5, seconds 60; \
     sid:1000001; rev:1;)

• The alert action generates the message “RDP brute force attempt” (Snort can also reject or drop packets for active prevention).
• The rule only triggers on an established TCP session to a server on TCP port 3389.
• The threshold clause groups traffic by source IP and triggers once 5+ connections occur within 60 seconds.
• The SID uniquely identifies the rule; the revision number tracks updates.

Suricata. An open-source tool billed as more than an IDS/IPS — it can also perform HTTP request logging, DNS logging, and TLS logging/analysis. Suricata rules follow a similar structure to Snort rules.

Example Suricata rule detecting command-and-control (C2) traffic to a known malicious domain:

alert http any any -> any any \
    (msg:"Malware: Traffic flow to known Ransomware C2 server"; \
     flow:established; \
     http.host; content:"malicious_domain.com"; \
     sid:1000002; rev:1;)

This rule alerts on established HTTP traffic where the HTTP Host header matches malicious_domain.com. Pre-written rule sets are available from sources such as Emerging Threats and Cisco’s Snort/Sourcefire Vulnerability Research Team, in addition to commercial offerings.

IDS/IPS comparison:

Suspicious activity to detect with IDS/IPS:

• Initial/unusual access to highly classified assets from hosts that have never connected before, or access outside normal time windows/duration.
• Data exfiltration — IDS/IPS paired with data loss prevention (DLP) platforms that classify/label sensitive data make transfers highly visible.
• Credential abuse — stolen valid credentials used to access other resources (rules like the RDP brute-force example above help detect this).
• Known Indicators of Compromise (IOCs) — leverage prewritten signature/IOC rule sets from the threat-intelligence community.

Network Security Monitoring Tools

Zeek (formerly Bro) is an open-source network traffic analysis tool providing in-depth protocol analysis. It is more passive than Snort/Suricata — strong on detection and customization via Zeek scripts, but not designed as an intrusion prevention system. It scales well to large enterprise traffic volumes.

Illustrative Zeek script matching computed file hashes against a set of known-malicious hashes:

@load base/protocols/conn
@load base/files/hash

# Set of known-malicious file hashes to monitor for
global malicious_hashes: set[string] = {
    "44d88612fea8a8f36de82e1278abb02f",
    "5f4dcc3b5aa765d61d8327deb882cf99"
};

event file_hash(f: fa_file, kind: string, hash: string)
    {
    if ( hash in malicious_hashes )
        print fmt("Malicious hash detected: %s (source: %s)", hash, f$source);
    }

event file_new(f: fa_file)
    {
    # Triggers hashing so newly seen files are checked against malicious_hashes
    Files::add_analyzer(f, Files::ANALYZER_SHA256);
    }

• The script first loads base modules for connection tracking and file hashing.
• A malicious_hashes set lists file hashes of interest.
• A file_hash event handler checks whether a computed hash matches the set and, if so, prints an alert message including the matching hash and its source file.
• A file_new event handler triggers SHA-256 hashing of newly observed files, feeding the file_hash event.

Sigma. An open, vendor-agnostic, YAML-based signature format for writing SIEM detection rules that can be shared across different SIEM platforms.

Illustrative Sigma detection for CVE-2024-37085 (privilege escalation via unauthorized creation of the ESX Admins Active Directory group, which historically receives full administrative access on domain-joined ESXi hosts):

title: Potential CVE-2024-37085 ESX Admins Group Privilege Escalation
id: 8f2a6b3e-2c9a-4b7d-9f3e-1a2b3c4d5e6f
status: experimental
description: >
  Detects attempts to create the 'ESX Admins' Active Directory group via
  net.exe/net1.exe or PowerShell's New-ADGroup, a technique associated with
  exploitation attempts against CVE-2024-37085 to gain full administrative
  access to domain-joined ESXi hosts.
author: Security Engineering Team
date: 2024/07/01
logsource:
  category: process_creation
  product: windows
detection:
  selection_net:
    Image|endswith:
      - '\net.exe'
      - '\net1.exe'
    CommandLine|contains|all:
      - 'group'
      - '/add'
      - '/domain'
      - 'ESX Admins'
  selection_powershell:
    Image|endswith: '\powershell.exe'
    CommandLine|contains|all:
      - 'New-ADGroup'
      - 'ESX Admins'
  condition: 1 of selection_*
level: high

• Metadata — title, unique identifier, date, author, and a description of what the detection identifies.
• logsource — Windows event logs, category process_creation.
• selection_net — matches net.exe/net1.exe commands containing /add, /domain, ESX Admins, and group.
• selection_powershell — matches PowerShell commands containing New-ADGroup and ESX Admins.
• condition — fires when either selection matches.

Detection-as-Code. The practice of writing SIEM/IDS/Zeek/Sigma detections (Splunk SPL, Snort/Suricata rules, Zeek scripts, Sigma rules) using a software-development approach: version control (e.g., Git with revision tags), CI/CD pipelines for testing and validating new detection code, and collaborative development across the security team. This falls under the broader discipline of detection engineering, allowing teams to keep detections current and stay ahead of emerging threats.

flowchart LR
    Write[Write Detection<br/>SPL / Snort / Suricata / Zeek / Sigma] --> VCS[Version Control<br/>Git + revision tags]
    VCS --> CI[CI/CD Pipeline]
    CI --> Test[Automated Testing / Validation]
    Test --> Deploy[Deploy to Production Detection Stack]
    Deploy --> Monitor[Monitor + Tune]
    Monitor --> Write

Honeynets and Honeypots

A honeypot is a vulnerable system or application purposely created to lure adversaries, often seeded with artificial data to further entice attackers (like luring a bear with a pot of honey). Honeypots must be isolated when deployed. They can be built with:

• High interaction — mimicking a system with several running services for attackers to interact with.
• Low interaction — offering only basic services.

The objective is to track malicious TTPs (tactics, techniques, and procedures), enabling research to detect malicious activity earlier and develop preventive security controls.

A honeynet (“honey network”) is a network of multiple honeypots, simulating a more realistic environment with running services and interaction between honeypots. Honeynets should include decoy credentials to help track credential use and gain insight into network movement and authentication events. Honeynets have an advantage over single honeypots because the richer, active environment provides more detail and context on adversarial TTPs.

flowchart LR
    Internet((Internet)) --> EF[Edge Firewall/Router]
    EF --> HF[Honeynet Firewall<br/>isolates honeynet]
    HF --> HP1[Honeypot 1]
    HF --> HP2[Honeypot 2]
    HF --> HP3[Honeypot 3]
    HF --> MGMT[Management/Data Collection Segment]

The honeynet firewall isolates the honeynet from legitimate network resources, exposing the honeypots to would-be attackers while a management interface collects data on actions performed within the honeynet.

Adversarial Tactics, Techniques, and Procedures

Two widely used frameworks describe adversary behavior:

• MITRE ATT&CK — intricate detail on the TTPs used by hackers and advanced persistent threat (APT) groups.
• Lockheed Martin Cyber Kill Chain — a higher-level explanation of the stages of a cybersecurity attack from the adversary’s perspective.

Reviewing both frameworks helps security engineers understand attack stages and build controls targeting specific TTPs.

flowchart TD
    FC[First Contact<br/>Recon + Social Engineering<br/>e.g. phishing, third-party compromise] --> Persist[Fly Under the Radar / Persist]
    Persist --> P1[Malicious boot/logon scripts<br/>and scheduled tasks]
    Persist --> P2[Living off the land<br/>use built-in tools e.g. PowerShell]
    Persist --> P3[Disable logging<br/>erase tracks]
    Persist --> P4[Patch domain controller authentication<br/>weaken/bypass auth]
    Persist --> Move[Lateral Movement]
    Move --> Pivot[Pivot point: initial foothold machine]
    Pivot --> Target[Target systems with sensitive data / valuable credentials]
    Target --> Endgame[Endgame: Exfiltration]
    Endgame --> Ex1[Automated scripts]
    Endgame --> Ex2[Removable storage]
    Endgame --> Ex3[Email / cloud storage]
    Endgame --> Ex4[Command-and-control C2 channel<br/>persist for years]

Stage-by-stage summary:

1. First contact — intelligence gathering/reconnaissance to target an organization and gain initial access, frequently via social engineering (e.g., phishing) since manipulating people is highly effective — several major real-world breaches began this way. Attackers may also target a trusted third-party system to inject malicious code that the target organization unknowingly relies upon.
2. Flying under the radar / persistence — creating or modifying boot-up/logon scripts and scheduled tasks (potential privilege escalation vector); living off the land (using tools already present in the environment, e.g., PowerShell in a Windows environment, to avoid raising suspicion); disabling logging to erase evidence; and patching domain controller authentication to weaken or bypass authentication mechanisms and elevate privileges.
3. Lateral movement — the initial compromised machine (the pivot point) becomes the foothold from which the attacker jumps to more sensitive systems. Systems holding sensitive data or valuable credentials are primary targets, since harvested credentials enable further lateral movement, additional log deletion, and further discovery.
4. Endgame / exfiltration — the primary goal becomes exfiltrating collected sensitive data via automated scripts, removable storage, email, or cloud storage. Some attackers establish command-and-control (C2) systems to issue remote commands, in some cases persisting within a target’s network for years.

Compliance Considerations

Governance, risk, and compliance (GRC) covers organizational policies/processes/procedures, risk management as it relates to security, and compliance with government regulations, industry standards, and requirements. Security engineers implement controls that strengthen security posture and lower the risk of successful attacks — and compliance frameworks heavily influence which controls are required, and where they must be placed and configured.

PCI-DSS key security requirements:

• Secure cardholder data with firewalls and disciplined firewall rule/policy management.
• Physical security requirements protecting customer data — extending to physical access controls for network systems/devices.
• Encryption of data both in transit and at rest (e.g., mandatory HTTPS for web applications/servers).
• Regular security testing of networks, systems, and processes — including technical/physical penetration testing and testing of backup and recovery processes.
• External audit — organizations are subject to external auditors verifying deployment and configuration of the required security controls to maintain PCI-DSS compliance.

Summary

Securing a modern network requires layered controls across every tier of the architecture — from individual switch ports up through routing protocols, wireless access, VPN tunnels, firewalls, trust zones, and continuous monitoring.

Key principles from this course:

• Defense at every layer. Port security and VLAN segmentation protect Layer 2; subnetting, ACLs, and NAT protect Layer 3; TLS/certificate-based authentication protects management access at every layer.
• Segment aggressively. VLANs, private VLANs, DMZs, screened subnets, and zero trust microsegmentation all exist to limit an attacker’s blast radius and ability to move laterally.
• Assume breach, verify continuously. Zero Trust Network Architecture and Software-Defined Perimeter replace implicit trust with per-request authentication, authorization, and least privilege.
• Authenticate routing itself. OSPF and BGP are targets for spoofing, route injection, hijacking, and flooding — area/peer authentication, TTL security, and prefix/route-origin validation are essential countermeasures.
• Centralize and protect logs. SNMP, Syslog, NetFlow/IPFIX, and SIEM ingestion turn raw device activity into investigable security intelligence — and logs themselves must be protected for integrity and availability.
• Detect and respond systematically. IDS/IPS (Snort, Suricata), network analysis (Zeek), and shareable detection formats (Sigma), combined with Detection-as-Code practices, keep detection capability current against evolving threats.
• Study the adversary. MITRE ATT&CK and the Lockheed Martin Cyber Kill Chain describe how real attacks unfold — from initial contact and persistence through lateral movement to exfiltration — informing where controls and monitoring should be concentrated.
• Compliance shapes architecture. Frameworks like NIST CSF, HIPAA, GDPR, and PCI-DSS drive concrete requirements for firewalls, encryption, physical security, testing, and auditing.

Quick-reference: security controls by network layer/device

Security engineering checklist:

• Port security configured with an appropriate violation mode (protect/restrict/shutdown) on all access-layer switch ports.
• Dynamic trunking protocols disabled; VLANs and private VLANs used to segment sensitive traffic.
• Subnet sizes matched to host counts; extended ACLs restrict sensitive management protocols.
• NAT/port-forwarding rules minimized and reviewed for unnecessary exposure.
• Routing protocols (OSPF/BGP) configured with authentication, TTL security, and route/prefix filtering.
• Wireless networks use 802.1X + WPA3-Enterprise for staff and captive portals for guests; rogue AP scanning in place.
• VPNs use strong protocols (IPsec/IKE/ESP, MACsec where applicable) with AAA-backed authentication.
• Firewalls reviewed for rule correctness (permit/deny/drop/reset) and NGFW/WAF capabilities enabled where appropriate.
• Network zones and DMZ/screened-subnet architecture documented and enforced.
• Zero trust principles (least privilege, assume breach, microsegmentation) applied to sensitive resources.
• Centralized logging (Syslog/SNMP/NetFlow) feeding a SIEM, with retention aligned to compliance requirements.
• IDS/IPS (Snort/Suricata), Zeek, and Sigma-based detections deployed and maintained via a Detection-as-Code workflow.
• Honeynets considered for gathering adversarial TTP intelligence in isolated segments.
• MITRE ATT&CK and the Cyber Kill Chain used to map controls against real attacker behavior.
• Compliance obligations (NIST CSF, HIPAA, GDPR, PCI-DSS) mapped to implemented controls and validated through regular testing and audit.

Search Terms

security · engineering · securing · networks · cybersecurity · fundamentals · networking · systems · network · architecture · logging · monitoring