Understand Network Security

Open a web page on a laptop and the request leaves wrapped like a set of nested envelopes (an analogy, not networking terminology): the browser's request is wrapped with transport information, then with addressing for the trip across networks, then with framing for the local link, and finally sent as signals over a cable or a radio link. Each wrapping step is the work of one layer, and the receiving computer unwraps them in reverse order. Objective 4.1 of the Certified in Cybersecurity (CC) exam outline^[1] has four parts: concepts (the OSI and TCP/IP models, IPv4, IPv6 and virtual private networks, or VPNs), firewalls, wireless, and embedded systems with the Internet of Things (IoT). Each part asks the same question: where does a failure or a requirement sit, and which control acts there (a firewall, VPN, intrusion detection or prevention system, or wireless or device protection)? Objective 4.2, network security architecture, covers segmentation, defense in depth and zero trust, and objective 4.3 is cloud security.

Layers and encapsulation

A layer is one slice of the communication job, providing a defined service to the layer above it. Encapsulation is the wrapping process. As outgoing data moves down the stack, the layers performing encapsulation add the information they need to do their part (the link layer's wrapping forms a frame); at the receiving host, the matching layers read and remove that information as the data moves back up to the application. The National Institute of Standards and Technology (NIST) describes data passing "from the highest layer through intermediate layers to the lowest layer, with each layer adding more information", then being passed upwards through the layers at the destination (NIST SP 800-41r1, section 2.1^[2]). RFC 1122 calls that information a header: the transport layer's unit of transmission "consists of a transport protocol header followed by application protocol data", and the Internet layer's "consists of an IP header followed by transport layer data" (RFC 1122, section 1.3.3^[3]).

Why layers matter for security

Every control works on particular layers. A device that reads only addresses and ports cannot judge what a web request asks for, and encryption hides the encrypted content from devices along the path that lack access to the plaintext. When a scenario describes a failure or a requirement, place it at its layer first; the right control is one that operates there.

The figure below traces one web request down the sender's stack and up the receiver's, using the four layers of the TCP/IP model (application, transport, Internet and link) that The TCP/IP model and how it maps to OSI explains below.

The takeaway: traffic is built in layers, each layer adds its own information on the way down and removes it on the way up, and a control can act only on the layers it can see.

This section covers the Open Systems Interconnection (OSI) reference model, the seven-layer vocabulary that security discussions use to say where a problem or a control sits. The model is published by ITU-T as Recommendation X.200, with identical text as ISO/IEC 7498-1, and it is a conceptual framework rather than software you install: it says it is not an implementation specification (ITU-T X.200^[4]). Its value is shared language: "a layer 3 device" or "a layer 7 firewall" means the same thing to everyone.

Layer	Name	What it does	Examples
1	Physical	Moves bits as signals over a physical medium	Cable, optical fiber, radio link
2	Data link	Organizes communication over one local link and detects errors from the physical layer	Ethernet frames, MAC addresses
3	Network	Moves data across interconnected networks, handling routing and relaying	IPv4, IPv6, routers
4	Transport	Provides end-to-end transfer between the two communicating systems	TCP, UDP, ports
5	Session	Organizes and synchronizes the dialogue between communicating applications	Setting up, synchronizing and ending an exchange
6	Presentation	Handles how exchanged data is represented, so both sides interpret it consistently	Agreed data syntax and formats
7	Application	Gives applications their access to network services	HTTP (web), DNS (name resolution), SMTP (email)

The layer descriptions follow ITU-T X.200 clause 7, which, for example, gives the session layer the job of letting cooperating entities "organize and synchronize their dialogue and ... manage their data exchange" and gives the presentation layer "common representation of the data transferred" (ITU-T X.200, clause 7^[4]). A MAC (media access control) address is the address assigned to a network interface at the data link layer (NIST SP 800-41r1, section 2.1^[2]).

Reading a failure by layer

A disconnected cable, or a radio signal that never arrives, is a physical-layer problem: nothing above it works until bits move again, and no application setting fixes it. Delivering an Ethernet frame to the next device on the same local link is data-link work, while choosing a path across several networks is network-layer work, explained under IP addressing below. Session and presentation are easy to swap: the session layer manages the conversation (who speaks, when, and how the exchange is kept in step), while the presentation layer manages the format of what is said.

Classify a protocol by the service it provides

DNS (the Domain Name System) translates names into addresses, which tempts people to file it at the network layer because addresses are involved. It is an application-layer protocol: classify a protocol by the service it provides to applications, here name resolution, not by the kind of data it handles. NIST lists DNS, HTTP and SMTP together as application-layer protocols that rely on the layers beneath them (NIST SP 800-41r1, section 2.1^[2]).

The takeaway: count the layers from the bottom up and identify each by its job (signals, local link, routing across networks, end-to-end transport, dialogue, representation, application services).

This section covers the four-layer model of the protocol suite the Internet actually runs, and how its layers line up with the seven OSI layers. RFC 1122 names the layers of the Internet protocol suite as application, transport, Internet and link (RFC 1122, section 1.1.3^[3]). From top to bottom:

• The application layer carries application protocols such as HTTP, DNS and SMTP.
• The transport layer provides end-to-end communication services for applications; TCP and UDP are its two primary protocols.
• The Internet layer is where IP lives, moving packets across networks.
• The link layer handles communication with the network a host is directly attached to.

Other documents use different labels for the same four layers: NIST SP 800-41 calls them application, transport, IP (network) and hardware (data link) layers, and NIST SP 800-77 uses application, transport, network and data link (NIST SP 800-41r1^[2]; NIST SP 800-77r1^[5]).

An approximate correspondence

TCP/IP layer	Approximate OSI counterpart	Examples
Application	7 application, 6 presentation	HTTP, DNS, SMTP
Transport	4 transport	TCP, UDP
Internet	3 network	IPv4, IPv6
Link	2 data link, 1 physical	Ethernet

The correspondence is approximate. RFC 1122 says the Internet application layer "essentially combines the functions of the top two layers -- Presentation and Application -- of the OSI reference model" (RFC 1122, section 1.1.3^[3]). NIST's labels supply the lower rows: its IP layer is "also known as the Network Layer", and its hardware layer, "also known as the Data Link Layer", "handles communications on the physical network components" (NIST SP 800-41r1, section 2.1^[2]). Neither source assigns the OSI session layer to a TCP/IP layer, and the four-layer model has no separate session layer. The practical consequence, drawn side by side in the figure below: TCP/IP has no separate presentation or session layer, and its application layer essentially combines OSI presentation and application functions.

The takeaway: TCP/IP has four layers: application, transport, Internet and link.

This section covers the transport layer, which carries data between the two communicating systems, and the port numbers it uses to tell their conversations apart. Two transport protocols dominate, and they offer different services.

• TCP (Transmission Control Protocol) provides "a reliable, in-order, byte-stream service to applications" (RFC 9293^[6]). It sets up a connection first, and lost data is retransmitted and delivered in order.
• UDP (User Datagram Protocol) is connectionless. RFC 768 states that delivery and duplicate protection are not guaranteed and that applications requiring ordered, reliable delivery should use TCP (RFC 768^[7]). An application that uses UDP and still needs reliability has to provide it itself.

Neither protocol routes packets between networks; routing is the job of the network layer (OSI layer 3; the Internet layer in TCP/IP). A requirement that the transport protocol itself deliver data reliably and in order points to TCP, never UDP.

Ports

A port is a number the transport layer uses to identify a communication endpoint on a host. A destination port generally identifies a service listening on the destination host, and a source port identifies where that host should send its reply (NIST SP 800-41r1, section 2.1^[2]). Familiar numbers such as TCP 80 for web traffic or TCP 25 for sending mail are conventions that services commonly use, not requirements: the same NIST guide notes that many applications use several ports and that web sites also commonly use ports such as 8080 (NIST SP 800-41r1, section 4.1.3^[2]).

The takeaway: TCP is the reliable, ordered, connection-based transport, UDP the connectionless one, and a port number names an endpoint by convention.

This section covers how Internet Protocol version 4 (IPv4) and version 6 (IPv6) address traffic across networks, and what changes when a network runs both.

Logical addresses and routers

IPv4 and IPv6 are network-layer protocols. Interfaces participating in IP communication use logical IP addresses, and packets carry a destination IP address that lets them be delivered across interconnected networks. A router is "a computer that is a gateway between two networks at OSI layer 3 and that relays and directs data packets through that inter-network" (NIST glossary: router^[8]); it forwards each packet toward the destination network using the destination IP address. A MAC address works differently: it identifies an interface for frame delivery on the local link, not a destination several networks away (NIST SP 800-41r1, section 2.1^[2]).

Routing is not filtering

Connecting a local network to other networks, including the Internet, is routing. Deciding whether traffic is allowed is filtering, a separate security function, even when one device performs both; NIST notes that firewalling is often combined with routing, and that technologies associated with firewalls are sometimes more accurately part of routing (NIST SP 800-41r1, section 2.1^[2]). A firewall's filtering decides whether traffic may pass; it does not choose the path the traffic takes.

IPv6: more addresses, not automatic security

RFC 8200 describes IPv6 as "a new version of the Internet Protocol (IP), designed as the successor to IP version 4" and states that it increases the IP address size from 32 bits to 128 bits (RFC 8200^[9]). The larger space answers the exhaustion of IPv4 addresses as connected devices multiplied (NIST SP 800-119^[10]). An address, however large the space it comes from, says nothing about whether traffic is confidential or authorized; that still takes encryption and access control.

Coexistence and dual stack

NIST is direct: "IPv6 is a new protocol that is not backward compatible with IPv4" (NIST SP 800-119^[10]). An IPv6-only device therefore cannot communicate directly with an IPv4-only device using its own protocol alone; the two need a coexistence or transition arrangement. One approach is dual stack, in which a device runs both protocols and uses whichever one its peer supports. That is support for two protocols, not a translation between them.

Dual stack has a security cost. NIST warns that it exposes every dual-stack node to the vulnerabilities of both protocols, and that organizations need a consistent security policy for IPv4 and IPv6, including firewalls and packet filters (NIST SP 800-119, section 6.4.3^[10]). The firewall guide adds that blocking traffic not expressly permitted should happen whether the traffic has an IPv4 or an IPv6 address (NIST SP 800-41r1, section 4.1.2^[2]). An IPv4-only rule set on a dual-stack network does not establish appropriate filtering for IPv6 traffic.

The takeaway: IP addresses carry packets across networks and routers forward them; IPv6 enlarges the address space but cannot talk to IPv4 directly, and a network running both must secure both.

This section covers network address translation (NAT) and why it is not a firewall. NAT replaces the IP addresses inside packets as they cross a boundary between networks. Its most common use lets devices on a private network, whose addresses are not globally unique, share a public address to reach the Internet; NAT translates the private addresses into public ones before packets are forwarded to the other network (NIST glossary: network address translation^[11]).

NIST SP 800-41 settles the category in one line: NAT "is sometimes thought of as a firewall technology, but it is actually a routing technology" (NIST SP 800-41r1, section 2.1^[2]). Hiding internal addresses is a side effect of the translation. NAT does not evaluate whether a connection is one the organization's policy authorizes, so a requirement such as "only the finance department's systems may reach the payroll server" belongs in firewall policy, not in an address translation rule.

The takeaway: NAT changes addresses; a firewall decides which traffic is allowed.

A sales manager in a hotel needs the company's internal systems, and a branch office needs a permanent link to headquarters. Both send organizational traffic across networks the organization does not control, and a virtual private network (VPN) is the standard answer to both. NIST describes a VPN as "a virtual network built on top of existing physical networks that can provide a secure communications mechanism" for the data carried between networks or nodes (NIST glossary: virtual private network^[12]). A VPN can provide confidentiality, integrity, data origin authentication (confirming the claimed source of received data), replay protection (refusing data already accepted, so replayed packets are not accepted again) and access control (NIST SP 800-77r1^[5]; NIST glossary: data origin authentication^[13]).

What the protection consists of

An approved secure VPN is one way to protect organizational traffic crossing an untrusted network such as the Internet; NIST advises assuming that external networks contain hostile threats (NIST SP 800-46r2^[14]). Each protection has its own job: encryption keeps the traffic confidential, integrity protection detects changes made in transit, and authentication establishes that each end is the party it claims to be. The protected path between the two VPN endpoints is called the tunnel.

Two architectures

At the organization's end of a tunnel sits a VPN gateway, a dedicated device or part of a firewall or router (NIST SP 800-77r1, section 2.4.1^[5]); despite the shared word, it is not an application-proxy gateway, the firewall type that relays application connections. The two architectures, both drawn in the figure below, differ in what sits at each end of the tunnel (NIST SP 800-77r1^[5]):

Architecture	Tunnel endpoints	Typical use
Remote-access VPN (NIST: host-to-gateway)	One user's device and the organization's VPN gateway	Traveling employees and teleworkers reaching internal services
Site-to-site VPN (NIST: gateway-to-gateway)	Two network gateways	A branch office and headquarters, or two partner networks

A site-to-site VPN carries traffic selected for protection between the networks behind the two gateways, so users there do not each set up their own tunnel. A requirement to connect two entire office networks therefore points to a site-to-site VPN; a remote-access session connects one device.

Where the protection ends

A VPN protects traffic between its tunnel endpoints and nothing else. NIST SP 800-46 states that tunneling protects communications between the client device and the VPN gateway, but does "not provide any protection for the communications between the VPN gateway and internal resources", and that application software and data at rest on the client device are not protected by the tunnel and need other protection (NIST SP 800-46r2, section 2.2.1^[14]). A VPN also does not show that either device is free of malware: an infected laptop sends its traffic through the tunnel just as faithfully as a clean one. Endpoint security and permissions on the resources stay necessary alongside the VPN.

A VPN is not a VLAN

A VLAN (virtual local area network) is a broadcast domain partitioned and isolated within a network at the data link layer, so one physical LAN can be split into several logical ones (NIST glossary: virtual local area network^[15]). It separates traffic logically inside a local network; it is not a cryptographically protected path, so it cannot protect traffic crossing the public Internet.

The takeaway: a VPN encrypts, integrity-protects and authenticates traffic between its two tunnel endpoints; pick remote access for one device and site-to-site for two networks, and keep endpoint and resource protections in place.

This section covers what a firewall is for and the two policy choices that shape every rule set: deny by default, and filtering in both directions. Firewalls are "devices or programs that control the flow of network traffic between networks or hosts that employ differing security postures" (NIST SP 800-41r1^[2]). The firewall applies a policy, a set of rules saying which traffic is allowed, and everything it does follows from that policy.

Deny by default

NIST's guidance is that firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy; this practice, deny by default, "decreases the risk of attack" and is "a more secure approach than permitting all traffic that is not explicitly forbidden" (NIST SP 800-41r1, section 4^[2]). Under deny by default, a business need for a communication is what earns it a rule, which keeps unnecessary services unreachable. The opposite approach, allowing everything except a list of known-bad services, leaves every unlisted service open, including ones nobody knew were running. Deny by default describes a policy choice the organization makes, not a promise about how a particular product is configured out of the box.

Both directions: ingress and egress

Filtering traffic entering a network is ingress filtering; filtering traffic leaving it is egress filtering (NIST SP 800-41r1, section 2.1.1^[2]). Egress rules control which external services internal systems may contact; NIST's examples include blocking use of external file transfer servers and permitting outbound traffic only from the organization's own source addresses. A requirement to restrict what internal systems connect to is therefore an egress rule; an ingress rule examines the wrong direction.

The takeaway: a firewall enforces a policy, the sound default is to permit only what the business needs, and the policy covers outgoing as well as incoming traffic.

A policy may allow web traffic on port 80 and still need to stop instant messaging running over that same port, and only a firewall that examines more than the port number can tell the two apart (NIST SP 800-41r1, section 2.1.3^[2]). A firewall can combine several inspection capabilities, so read them as levels of inspection rather than rival products; NIST’s 2009 guide noted that few firewalls sold at that time did only packet filtering (NIST SP 800-41r1, section 2.1.1^[2]).

Capability	What it examines	What it remembers	Decision it supports
Packet filter	Source and destination addresses, protocol, ports, interface and direction	Nothing: each packet is judged alone (stateless)	Allow or block by address, protocol and port
Stateful inspection	The same, plus connection state	A state table of current connections	Admit packets that belong to an allowed connection
Application-aware inspection	The application protocol and content	Connection state as well	Allow or block by what the application is doing

Packet filtering

A packet filter makes its decision from information in the packet: source and destination IP addresses, the protocol, and possibly transport ports, along with the interface and direction (NIST SP 800-41r1, section 2.1.1^[2]). Packet filters, which NIST also calls stateless inspection firewalls, "do not keep track of the state of each flow of traffic", so they cannot associate multiple packets within a single session, and they "are not concerned about the content of packets". A packet filter therefore cannot interpret what an application message says.

Stateful inspection

Stateful inspection tracks each connection in a state table and compares every new packet against it, "blocking packets that deviate from the expected state" (NIST SP 800-41r1, section 2.1.2^[2]). NIST's example: an attacker sends a packet whose header claims it belongs to an established connection; a stateful firewall first checks that the connection really is in its state table. When a decision depends on whether traffic belongs to an existing, allowed exchange, stateful inspection is the capability that supports it.

Application-aware inspection

Application-aware inspection looks at the application traffic itself. Two forms appear in NIST's guidance (NIST SP 800-41r1, sections 2.1.3 and 2.1.4^[2]):

• An application firewall adds analysis of application protocols to stateful inspection, so it can, for instance, block an email attachment type the organization does not permit or detect instant messaging running over port 80.
• An application-proxy gateway acts as an intermediary that "never allows a direct connection" between the two hosts: each connection attempt becomes two separate connections, client to proxy and proxy to destination, and the proxy inspects the content before forwarding what the policy permits. External hosts see only the proxy, so internal addresses stay hidden.

A requirement to terminate and mediate application connections calls for proxy behavior; ordinary packet forwarding passes the original connection through.

A port number is not an application identity

A port identifies a communication endpoint that is commonly associated with a service, but the number alone does not prove which application is using it. NIST's application-firewall example of spotting instant messaging over port 80, the port typically used for web traffic, shows the gap (NIST SP 800-41r1, section 2.1.3^[2]). Allowing an application only because it uses a port associated with an approved service lets any other application through that port too. When policy must tell apart applications that share a permitted port, use application-aware inspection.

The figure below contrasts a firewall that forwards one inspected connection with an application-proxy gateway that holds two separate connections.

The takeaway: packet filters judge each packet by its header, stateful inspection adds connection context, and application-aware inspection, from an application firewall or a proxy gateway, judges what the application is actually doing.

This section covers the main blind spot every firewall shares. NIST puts it plainly: "Firewalls can only work effectively on traffic that they can inspect", and firewalls "cannot read application data that is encrypted" (NIST SP 800-41r1, section 2.3^[2]). Encrypted traffic passing through a firewall stays unreadable to it, however advanced its inspection engine; inspection depth does not supply a decryption key.

The firewall can still apply policy to what remains visible, such as addresses, ports and the fact that a connection exists. To inspect the content itself, the organization needs an authorized point where the plaintext is available, typically where the protected connection terminates. NIST's VPN placement advice shows the logic: VPN functions are often part of the firewall itself, because placing the VPN endpoint behind the firewall would make VPN traffic pass through the firewall while encrypted, preventing the firewall from inspecting it (NIST SP 800-41r1, section 2.1.6^[2]). NIST also recommends a policy for traffic the firewall cannot understand, such as blocking encrypted traffic that is not authorized to be encrypted.

The takeaway: a firewall sees only what is not encrypted; inspecting protected content requires authorized access to the plaintext, not deeper inspection.

This section covers firewalls that run on the protected device rather than at the network edge. Host-based firewalls (on servers) and personal firewalls (on desktops and laptops) are software residing on the hosts they protect, and each "monitors and controls the incoming and outgoing network traffic for a single host" (NIST SP 800-41r1, section 2.2.1^[2]).

What sets a host-based firewall apart is where it runs: an office perimeter firewall protects only traffic that passes through the office boundary. When an employee's laptop connects directly to a hotel or café network, traffic not routed through the office boundary stays outside the perimeter firewall's view. A host-based firewall travels with the laptop and keeps enforcing its policy wherever the laptop connects. The Cybersecurity and Infrastructure Security Agency (CISA) makes the same point for wireless networks: attackers who can tap directly into a wireless network may be able to get around the network firewall, and a host-based firewall adds a layer of protection on the device (CISA: securing wireless networks^[16]).

Host-based and network firewalls are complementary, not alternatives: they enforce policy at different locations.

The takeaway: a host-based firewall protects one device wherever it connects; a perimeter firewall protects only traffic that crosses the perimeter.

This section covers the two monitoring controls that sit alongside firewalls: one reports, the other can also act. NIST defines intrusion detection as "the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents", and intrusion prevention as "the process of performing intrusion detection and attempting to stop detected possible incidents" (NIST SP 800-94, section 2^[17]).

• An intrusion detection system (IDS) records information about what it observes and alerts the people responsible.
• An intrusion prevention system (IPS) does everything an IDS does and can also respond, for example by stopping the attack itself or changing the security environment, such as reconfiguring a firewall.

Both are technical controls, enforced by hardware, software or firmware; they differ in function, not in control type. A requirement to block identified malicious activity automatically therefore calls for an IPS; an IDS supplies observations and alerts but no enforcement.

Where each one sits

A sensor is the IDS or IPS component that monitors network activity (NIST SP 800-94, section 3.1.1^[17]), unlike an IoT sensor, which observes the physical world. NIST explains that sensors deployed inline, where "the network traffic it is monitoring must pass through it", are placed there mainly so that they can stop attacks by blocking traffic, while passive sensors monitor a copy of the traffic and "typically provide no reliable way" to stop it reaching its destination (NIST SP 800-94, section 4.2.2^[17]). A network IPS deployed to block traffic directly, by dropping packets, therefore sits inline; an IDS, which only alerts, can watch a passive copy, as the figure below shows.

Signatures and anomalies

Detection methods also differ (NIST SP 800-94, section 2.3^[17]):

• Signature-based detection compares observed events against signatures, patterns that correspond to known threats. It is very effective against known threats and largely ineffective against previously unknown ones and variants.
• Anomaly-based detection compares observed activity against profiles of normal behavior built up over time and flags significant deviations, which makes it effective at spotting previously unknown threats.

No IDS or IPS is perfectly accurate: a false positive flags benign activity as malicious, and a false negative misses malicious activity (NIST SP 800-94, section 2.2^[17]). For an IPS, a false positive can mean blocked legitimate traffic.

The takeaway: an IDS detects and alerts, an IPS detects and can block; signatures catch known patterns, anomaly detection catches departures from normal.

This section covers how machine learning (a form of artificial intelligence, AI) changes network monitoring, and what an entry-level practitioner does with what it reports. The CC exam outline expects candidates to understand "how AI-powered firewalls and Intrusion Detection Systems (IDS) go beyond simple signature matching", how AI affects the security of wireless networks and embedded systems, and how these tools "use machine learning to identify unusual network behavior", so that candidates can "monitor dashboards and report potential anomalies" (CC exam outline, AI guidance^[1]).

Learned behavior extends anomaly detection

An AI-assisted firewall or IDS learns what normal traffic looks like and flags behavior that departs from it. That is the anomaly-based method from the previous section, built from learned patterns, and it complements signature matching rather than replacing it. An alert that says a device's traffic deviates from its learned behavior is therefore an anomaly finding, not a signature match. The same behavior-based approach applies to conventional, wireless and embedded-device traffic.

An alert is evidence, not a verdict

An anomaly score is an indicator for triage, not the conclusion of an investigation: detection tools produce false positives (NIST SP 800-94, section 2.2^[17]), and an unusual pattern may have a legitimate cause. An entry-level practitioner who sees such an alert keeps the relevant details (which device, what behavior, when), reports it through the organization's established process, and escalates within their assigned authority. Declaring a confirmed compromise from the score alone skips the analysis the incident response process exists to perform.

The takeaway: AI-assisted tools flag unusual network behavior beyond known signatures, and the practitioner's job is to preserve the details and report the anomaly for review.

This section covers what a wireless LAN is and why it changes the security picture. Wireless local area networks (WLANs), commonly called Wi-Fi, are groups of wireless networking devices "within a limited geographic area, such as an office building, that are capable of exchanging data through radio communications", based on the IEEE 802.11 family of standards (NIST SP 800-153, section 2^[18]).

Clients and access points

An infrastructure WLAN has two fundamental kinds of components: client devices, such as laptops and smartphones, and access points (APs). An AP logically connects client devices to a distribution system, "typically the organization's wired network infrastructure" (NIST SP 800-153, section 2^[18]). Joining clients to the organization's WLAN is the access point's job; a Bluetooth link between a device and its peripherals is a different, personal-area technology covered in Bluetooth below.

Radio does not stop at the wall

Wireless access is an entry path into the network, alongside the wired ports, and it needs protection of its own. To monitor a wired network an attacker needs physical access or a compromised system, but for a WLAN "an attacker simply needs to be within range of the wireless transmissions", and directional antennas can extend that range well beyond the standard WLAN range (NIST SP 800-153, section 3.1^[18]). CISA notes that an access point's indoor range is typically 150 to 300 feet and may reach 1,000 feet outdoors (CISA: securing wireless networks^[16]). A building with locked doors can still have its Wi-Fi received from the car park, so the link needs protection even inside a secured building.

The takeaway: an access point connects wireless clients to the wired network, and its radio signal reaches beyond the walls, so wireless access needs its own protection.

This section covers the two choices that protect a Wi-Fi network: which security protocol encrypts the radio link, and how users prove who they are when they join.

Encryption: WPA3 first

Wi-Fi security has gone through several generations: WEP (Wired Equivalent Privacy), the original protocol, then Wi-Fi Protected Access (WPA), WPA2 and WPA3. CISA states that "WPA3 is currently the strongest encryption" and advises equipment that specifically supports WPA3, because using the older protocols could leave a network open to exploitation; when connecting to access points, CISA says to ensure they use at least WPA2 (CISA: securing wireless networks^[16]). Guidance from the National Security Agency (NSA) allows a mixed WPA2/WPA3 setting where some devices cannot use WPA3, so newer devices still get the stronger method (NSA: best practices for securing your home network^[19]).

The practical rule: use WPA3 where supported, appropriately secured WPA2 only where compatibility requires it, and never WEP or the original WPA for business traffic. Keeping WEP to support an old device weakens wireless protection for that device's convenience.

Authentication: personal vs enterprise

Wi-Fi protection comes in two authentication styles:

• Personal mode uses a shared password; WPA2-Personal uses pre-shared key (PSK) authentication, while WPA3-Personal uses Simultaneous Authentication of Equals (SAE).
• Enterprise mode authenticates each user or device individually, typically through an authentication server, with credentials or certificates issued to that user or device. The NSA's WPA3 report discusses enterprise configurations that use certificate-based authentication (EAP-TLS) (NSA: WPA3 cybersecurity technical report^[20]).

Enterprise names the authentication method, not the network's owner: CISA calls an organization's Wi-Fi an enterprise Wi-Fi network, and one relying on a single shared password still uses Personal mode (CISA: securing enterprise wireless networks^[21]).

When an organization needs to know who connected and to revoke one person's access without disturbing everyone else, enterprise authentication is the choice. A shared passphrase identifies no one: the network learns only that someone knew the key, and removing one person means changing the key for every user. Making the passphrase longer improves its strength but does not make it individual. The UK National Cyber Security Centre (NCSC) makes the same comparison for VPN authentication, noting that certificates can be revoked one at a time, unlike a pre-shared key (NCSC: virtual private networks^[22]).

The takeaway: encrypt with WPA3 (or WPA2 where necessary, never WEP), and use enterprise authentication when access must be individual and individually revocable.

An office with encrypted Wi-Fi can still lose a user to an attacker's stronger-signal copy of a trusted hotspot, gain an unauthorized access point, or lose service to radio interference (CISA: securing wireless networks^[16]; NIST SP 800-153, section 3.1.1^[18]). Encryption alone stops none of the three, each attacking something different: an evil twin copies a trusted network's name (the user's trust), a rogue access point is connected without authorization (the organization's control), and jamming makes the radio channel unusable (availability).

Evil twin: imitating a trusted network

In an evil twin attack, an adversary gathers information about a legitimate access point and then sets up a system that impersonates it, often broadcasting a stronger signal so that users connect to it instead; the attacker can then read the victim's unprotected traffic (CISA: securing wireless networks^[16]). A familiar network name proves nothing, because an impersonating access point can advertise exactly the same name, and picking the strongest signal plays into the attack. Because names can be copied, CISA advises confirming a public hotspot's name and password before use, so that the connection goes to a trusted access point (CISA: securing wireless networks^[16]).

Rogue access point: unauthorized is the test

A rogue access point is one the organization has not authorized on its network. NIST describes an attacker deploying an AP configured to look like part of the organization's WLAN, which "can provide a backdoor into the wired network, bypassing perimeter security mechanisms, such as firewalls", and lists "unauthorized WLAN devices, including rogue APs" among what continuous monitoring must detect (NIST SP 800-153, sections 3.1.1 and 3.3^[18]). An access point an employee plugs in for convenience creates the same unmanaged path into the network as one an attacker hides under a desk. The distinction is authorization status, not the installer's intent: business convenience is not network authorization, so the employee's device is still a rogue access point and should be reported.

Jamming: an availability attack

Wireless communication depends on a usable radio channel. NIST notes that a wireless denial of service can occur "inadvertently, such as other electronic devices causing interference", or intentionally (NIST SP 800-153, section 3.1.1^[18]); deliberate radio interference is called jamming. Encryption protects the information carried over a working link but does nothing to make the radio channel usable, so stronger Wi-Fi encryption is not a response to jamming. Connectivity that must survive interference needs an approved alternative path, such as a wired connection.

The takeaway: an evil twin fakes a trusted network's identity, a rogue access point is any unauthorized one whatever the intent, and jamming attacks availability, which encryption cannot restore.

This section covers the monitoring control built for the radio environment itself. A wireless intrusion detection system monitors wireless network traffic and analyzes its wireless networking protocols to identify suspicious activity (NIST SP 800-94, section 5^[17]). NIST SP 800-153 calls the combined detection and prevention form a WIDPS and describes sensors placed at designated locations within an organization's facilities (NIST SP 800-153, section 3.2^[18]).

What it watches for

NIST recommends continuous WLAN monitoring that can detect, among other things (NIST SP 800-153, section 3.3^[18]):

• unauthorized WLAN devices, including rogue access points and unauthorized client devices;
• devices that are misconfigured or using weak WLAN protocols;
• unusual usage patterns, such as many failed attempts to join the WLAN in a short time;
• denial-of-service attacks and conditions, including interference;
• impersonation and man-in-the-middle attacks.

Why the wired controls cannot do this job

Some wireless events happen entirely over the air before any traffic reaches the wired network, and a perimeter firewall does not monitor the radio medium at all. A rogue access point can open a path that never crosses the firewall it would need to be caught by. Wireless intrusion detection complements the controls that inspect wired traffic. A wireless IDS detects and alerts; a product that can also block is the prevention form, the WIDPS that NIST SP 800-153 describes, which is the wireless counterpart of an IPS.

The takeaway: wireless intrusion detection watches the airwaves for rogue devices and wireless attacks that wired controls never see.

This section covers a wireless risk created by a single device rather than by an attacker's equipment. NIST defines "dual connected" as "a client device that is connected to both a wired network and a WLAN at the same time"; if an attacker gains unauthorized wireless access to such a device, "the attacker could then use it to access or attack resources on the wired network" (NIST SP 800-153^[18]). If compromised, the device can become a bridge that lets traffic avoid the network-based controls intended for the more trusted network.

The risk extends beyond the classic wired-plus-Wi-Fi case. NIST notes that devices are commonly connected to several wireless networks at once, such as cellular, Bluetooth and WLAN, and recommends that organizations assess these combinations, state in policy which dual connections are permitted or prohibited, and enforce that policy through security controls (NIST SP 800-153^[18]). Each network may be acceptable on its own; the danger is the path the shared device creates between them.

The figure below shows the bridge: the intended route into the trusted network crosses the perimeter firewall, and the dual-connected laptop opens a second one.

The takeaway: a device on two networks at once can link them, so simultaneous connections are a policy decision, not an automatic yes.

This section covers Bluetooth, the second wireless technology objective 4.1 names. NIST describes Bluetooth as "an open standard for short-range radio frequency (RF) communication", used primarily to establish wireless personal area networks (WPANs) (NIST SP 800-121r2^[23]), the kind of connection that links a phone or laptop to a headset, keyboard or other peripheral. It is not how clients join an organization's WLAN.

Short range is not protection

Bluetooth devices are "susceptible to general wireless networking threats, such as denial of service (DoS) attacks, eavesdropping, man-in-the-middle (MITM) attacks, message modification, and resource misappropriation" (NIST SP 800-121r2^[23]). A short range shrinks the area an attacker must reach but does not remove the exposure, so Bluetooth security settings still matter.

Pairing is a trust decision

Pairing is the step in which two Bluetooth devices establish a security relationship. NIST's guidance: perform pairing as infrequently as possible, ideally in a secure area (indoors, non-public, away from windows, with physical access controls) where attackers cannot observe it, and do not respond to any message requesting a PIN "unless the user has initiated a pairing and is certain the PIN request is being sent by one of the user's devices" (NIST SP 800-121r2, Table 4-2^[23]). An unexpected pairing request is therefore not a routine prompt to accept to restore connectivity; accepting it establishes trust with a device whose identity has not been confirmed.

Turn it off when it is not needed

NIST recommends that Bluetooth capabilities be disabled when not in use, and that devices that cannot disable Bluetooth be shut off entirely, to minimize exposure (NIST SP 800-121r2, Table 4-2^[23]). Bluetooth is its own wireless interface: disable Bluetooth explicitly when it is not needed.

The takeaway: Bluetooth is short-range personal-area radio that still faces wireless attacks, so pair only deliberately and with a known device, and disable it when unused.

This section covers computing that is built into equipment and controls physical processes. NIST describes the insertion of information technology (IT) capabilities "into existing physical systems, often replacing or supplementing physical control mechanisms", and gives the example that "embedded digital controls replaced analog mechanical controls in rotating machines and engines" (NIST SP 800-82r3, section 2.1^[24]). Operational technology (OT) is the broader family of systems that act on the physical world, with industrial control systems as one member: NIST defines it as "programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment)", detecting or causing change "through the monitoring and/or control of devices, processes, and events", with examples including industrial control systems, building management systems, fire control systems and physical access control (NIST glossary: operational technology^[25]).

An industrial control system (ICS) is a general term for the control systems found in industrial sectors and critical infrastructure, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS) and programmable logic controllers (PLC); its components act together "to achieve an industrial objective (e.g., manufacturing, transportation of matter or energy)" (NIST glossary: industrial control system^[26]).

A cyber change can be a physical change

Because these systems monitor or control physical processes, an attacker who alters a controller can change how real equipment behaves, not only what data says. NIST's guidance on OT security exists to address the "unique performance, reliability, and safety requirements" of these systems (NIST SP 800-82r3^[27]). A compromised industrial controller is therefore not merely an information-disclosure problem: its ability to change equipment behavior is the main concern.

The takeaway: embedded and industrial control systems turn digital commands into physical actions, so their security is about safe, reliable operation as much as about data.

This section covers how the physical stakes described in the previous section change three routine IT activities: responding to a suspected compromise, patching, and installing security tools.

Respond with safety first

OT security must account for human safety and the physical process. NIST notes that for devices that act on the physical world, operational requirements "for performance, reliability, resilience, and safety may be at odds with common cybersecurity and privacy practices for conventional IT devices" (NIST IR 8228^[28]). An immediate reboot or shutdown, a standard desktop remedy, may be unsafe for a controller running a process. A junior practitioner who suspects a problem involves the designated operations and security personnel and follows the approved response procedure rather than acting alone.

Test and coordinate patches

Industrial patches are not applied on an office schedule. Guidance from the U.S. Department of Homeland Security, hosted by CISA, explains that while IT patching tolerates relatively frequent downtime, "any sudden or unexpected downtime of ICSs can have serious operational consequences", so patches face more stringent validation before deployment; patches should be tested in an environment that closely simulates operations, including compatibility testing (CISA: recommended practice for patch management of control systems^[29]). The same guidance has IT, security, process engineering and operations personnel plan patching together, and has urgency reviews decide between patching now and implementing a workaround. When that review chooses a workaround instead of a patch, or a component is no longer supported, approved compensating protections reduce the risk while a longer-term remedy is arranged.

Match protection to what the device can run

Many embedded and legacy OT devices lack the processing power, memory or operating-system support that conventional endpoint security agents need, and adding an agent may be impossible or may interfere with real-time operation. NIST observes that cybersecurity capabilities are often different for such devices, so organizations "may have to select, implement, and manage additional controls" (NIST IR 8228^[28]). Protection then comes from approved surrounding controls, such as restricting which systems may talk to the device, rather than from a workstation agent installed on every controller.

The takeaway: in OT, safety and availability shape the response, patches are tested and scheduled with operations, and protection fits what the device can actually support.

This section covers what makes a device part of the Internet of Things (IoT) and why that matters for security. NIST describes IoT devices by their capabilities: every IoT device has at least one transducer capability, either sensing ("the ability to provide an observation of an aspect of the physical world") or actuating ("the ability to change something in the physical world"), together with interface capabilities such as a network interface (NIST IR 8228, section 2^[28]). NIST's examples run from thermostats, home security cameras, door locks and light bulbs to industrial equipment.

IoT is therefore not limited to industrial equipment: a connected sensor in an office or a smart lock on a door is IoT too. Some IoT devices are part of industrial control systems; many are ordinary consumer or workplace devices. Classifying every IoT device as an ICS overlooks non-industrial IoT uses.

Three security implications

Because an IoT device senses or acts on the physical world, its security covers its data, its connections and its physical function. NIST's worst case for a device with actuators is that a compromise could let an attacker "endanger human safety, damage or destroy equipment and facilities, or cause major operational disruptions" (NIST IR 8228, section 3.1^[28]). NIST also notes that many IoT devices cannot be accessed, managed or monitored the way conventional IT devices can (NIST IR 8228^[28]), which is why the capabilities in the next section matter.

The takeaway: an IoT device combines network connectivity with sensing or actuation, from industrial sensors to smart locks, so its security reaches into the physical world.

To inventory, update and monitor a batch of identical smart sensors, an organization relies on capabilities built into the devices themselves. NIST IR 8259A sets out a core baseline of such device cybersecurity capabilities (NIST IR 8259A^[30]); five of them map directly onto everyday management decisions.

Capability	What the device can do	Why it matters
Device identification	Be uniquely identified both logically and physically	Staff can tell one unit from another during inventory, maintenance and investigation
Logical access to interfaces	Disable local and network interfaces not needed for its core function, and restrict each interface to authorized entities	Fewer ways to interact with the device
Software update	Accept updates only from authorized entities, through a secure mechanism that verifies and authenticates each update before installing it	The update path reduces the risk of installing unauthorized code
Data protection	Protect the data it stores and transmits from unauthorized access and modification	Readings and commands stay confidential and trustworthy
Cybersecurity state awareness	Report its cybersecurity state to authorized entities	Defenders can tell normal operation from degraded protection

Identity: one unit, not one model

A unique logical identifier distinguishes the device from all others, typically for automated management and monitoring, while a unique physical identifier lets staff distinguish the device "whenever the unique logical identifier is unavailable", such as after a device failure (NIST IR 8259A^[30]). A product model name is shared by every unit of that product, so using it as the inventory identity makes individual devices indistinguishable.

Interfaces: local ones count too

The interface capability covers "local and network interfaces" (NIST IR 8259A^[30]). Protecting only the Internet connection while an unnecessary local management interface stays open leaves a second way in.

Updates: authenticity, not a version number

The update capability includes "the ability to verify and authenticate any update before installing it" and to "restrict updating actions to authorized entities only" (NIST IR 8259A^[30]). A newer version label does not establish that an update is genuine; verification does.

Data: stored as well as transmitted

Data protection covers the data the device "stores and transmits" (NIST IR 8259A^[30]). Sensor readings can reveal sensitive conditions, and altered readings or commands can misrepresent or change the physical environment. Encrypting the network path protects data only while it travels; readings kept on the device need their own protection.

State reporting: working is not the same as secure

A device with state awareness can "differentiate between when a device will likely operate as expected from when it may be in a degraded cybersecurity state" and make that information available to an authorized monitoring service (NIST IR 8259A^[30]). A simple device may only report whether it is operating as expected; another may provide event logs or integrity status. These signals matter because a sensor that still produces readings may nonetheless be running compromised software, and many IoT devices have no conventional user interface on which a problem would show.

The takeaway: a securable IoT device can be told apart from every other unit, exposes only needed interfaces, installs only verified updates from authorized parties, protects stored and transmitted data, and reports its security state.

A requirement or symptom is met by the control or concept that works at its layer, in its direction and at its location; an alternative fails when it works at the wrong layer, in the wrong direction or at the wrong location, or does a different job.

Concepts: layers, addressing and VPNs

Situation	Control or concept	Alternative and why it fails
Cable unplugged or radio signal lost	Physical layer	Application layer: nothing above the physical layer works until signals move
Ethernet frame delivery on the local link	Data link layer	Network layer: that is routing between networks
Keeping an application dialogue synchronized	Session layer	Presentation layer: that handles data representation
Agreeing on how exchanged data is represented	Presentation layer	Session layer: that manages the dialogue
DNS name resolution	Application layer	Network layer: DNS is classified by its service, not because it deals with addresses
Layers of the TCP/IP model	Application, transport, Internet, link	A separate presentation layer, which only OSI has
Transport itself must be reliable and ordered	TCP	UDP is connectionless and leaves reliability to the application
Forwarding packets toward another network	Router (network layer)	Firewall filtering decides what may pass, not the path
Network runs IPv4 and IPv6	Same policy applied to both	IPv4-only rules leave IPv6 traffic unfiltered
IPv6-only host must reach an IPv4-only host	A coexistence or transition arrangement	Assuming IPv6 is backward compatible with IPv4
Restrict which systems reach an application	Firewall policy	NAT translates addresses; translation does not decide which traffic is authorized
Traffic must cross the Internet confidentially	Approved secure VPN	VLAN: logical separation inside a local network, no cryptographic protection
Connect two office networks	Site-to-site VPN	Individual remote-access sessions connect one device each
Laptop may carry malware	Endpoint security alongside the VPN	The VPN protects only traffic between tunnel endpoints

Firewalls and detection

Situation	Control or concept	Alternative and why it fails
Only business-required traffic allowed	Deny-by-default policy	Allow by default with a list of known-bad services
Restrict which external services internal systems contact	Egress filtering	Ingress filtering examines the wrong direction
Decision needs application content	Application-aware inspection	A packet filter reads information such as addresses, protocol and ports and is "not concerned about the content of packets" (NIST SP 800-41r1, section 2.1.1[2])
Decision depends on an established connection	Stateful inspection	A packet filter keeps no connection context
Terminate and mediate client connections	Application-proxy gateway	Ordinary packet forwarding passes the original connection through
Two applications share an allowed port	Application-aware inspection	A port rule cannot prove which application is using the port
Inspect encrypted content	Authorized access to plaintext where the connection terminates	Deeper inspection does not decrypt anything
Laptop on public Wi-Fi	Host-based firewall	Office perimeter firewall never sees those direct connections
Block identified attacks automatically	IPS	An IDS only alerts
Alert based on deviation from learned behavior	Anomaly-based (AI-assisted) detection	Signature matching looks for known patterns
AI anomaly alert appears on a dashboard	Preserve details and report through the established process	Declaring a confirmed compromise from the score alone

Wireless, embedded systems and IoT

Situation	Control or concept	Alternative and why it fails
Joining clients to the organization's wireless network	Wi-Fi access point	Bluetooth is a personal-area link
Old device supports only WEP	WPA3, or WPA2 where needed; replace the device	Keeping WEP for compatibility
Wi-Fi access must be traceable and individually revocable	Enterprise authentication	A longer shared passphrase is still shared
Familiar network name with the strongest signal	Confirm the hotspot's name and password before use	An evil twin can copy the name and outshine the real AP
Employee installs an unauthorized access point for convenience	Rogue access point: report it	Calling it approved because it supports legitimate work
Radio jamming	Alternative path, such as wired access	Stronger encryption does not restore the radio channel
Find unauthorized radio access points	Wireless intrusion detection	A wired perimeter firewall does not monitor the airwaves
Laptop on the wired network and another wireless network	Control dual connections by policy	Approving because each network is acceptable alone
Unexpected Bluetooth pairing request	Decline unless you initiated it and know the device	Accepting it to restore connectivity
Remove Bluetooth exposure	Disable Bluetooth	Disabling Wi-Fi leaves the Bluetooth interface on
Compromised industrial controller	Treat as a physical-process risk	Treating it as only an information-disclosure issue
Suspected problem on a running controller	Involve operations and security and follow the procedure	Rebooting it like a desktop
Patching production controllers	Test and schedule with operations staff	Office automatic-update schedule
Controller cannot run a security agent	Approved surrounding controls	Installing a workstation agent on every controller
Smart lock or office sensor	IoT device	Classifying every IoT device as an ICS
Many identical sensors in inventory	Unique identifier per unit	Using the model name for every unit
Update with a newer version number	Verify authenticity before installing	Trusting the version label
Readings stored on the device	Protect stored data too	Transport encryption ends when transmission ends
Sensor still produces readings	Check reported security state	Treating working output as proof of security

The takeaway: identify the layer, the direction, the location and the job the scenario needs, then pick the control that does exactly that job.