Network and Communications Security

6.1 Understand and apply fundamental concepts of networking

Core idea: network fundamentals.

Scenario: A troubleshooting team cannot tell whether a failure is DNS, routing, firewall, or application-layer authorization.

Practitioner response: Map symptoms to OSI/TCP-IP layers, ports, protocols, paths, and control points before changing rules.

Concepts to Understand

• OSI and TCP/IP models: OSI and TCP/IP models is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• network topologies: network topologies is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• peer-to-peer and client-server relationships: peer-to-peer and client-server relationships is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• wired and wireless media: wired and wireless media is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• SDN, SD-WAN, virtualization, and automation: SDN, SD-WAN, virtualization, and automation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• commonly used ports and protocols: commonly used ports and protocols is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

6.2 Understand network attacks

Core idea: network attack response.

Scenario: A public service is under a volumetric attack and origin servers are saturated before firewall inspection.

Practitioner response: Use upstream or edge-based mitigation such as CDN/DDoS protection, then tune origin controls and monitoring.

Concepts to Understand

• DDoS: DDoS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• man-in-the-middle: man-in-the-middle is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• DNS cache poisoning: DNS cache poisoning is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• CDN countermeasures: CDN countermeasures is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• firewalls: firewalls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• network access controls: network access controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• IDPS: IDPS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

6.3 Manage network access controls

Core idea: network access control.

Scenario: Contractors need temporary remote access to an internal admin subnet.

Practitioner response: Use authenticated remote access with MFA, authorization scope, logging, expiration, and administrative protocol restrictions.

Concepts to Understand

• 802.1X: 802.1X is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• RADIUS: RADIUS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• TACACS+: TACACS+ is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• thin client: thin client is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• VPN: VPN is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• virtual desktop infrastructure: virtual desktop infrastructure is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

6.4 Manage network security

Core idea: segmentation.

Scenario: A compromise of a kiosk VLAN can reach management interfaces on switches and servers.

Practitioner response: Separate user, server, and management planes with segmentation, ACLs, firewall zones, and hardened management access.

Concepts to Understand

• inline, passive, and virtual device placement: inline, passive, and virtual device placement is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• physical and logical segmentation: Segmentation reduces blast radius only when rules, routes, identities, and management paths enforce the separation.
• data plane and control plane: data plane and control plane is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• VLANs: Segmentation reduces blast radius only when rules, routes, identities, and management paths enforce the separation.
• ACLs: ACLs is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• firewall zones: firewall zones is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• micro-segmentation: Segmentation reduces blast radius only when rules, routes, identities, and management paths enforce the separation.
• secure device management: secure device management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

6.5 Operate and configure network-based security appliances and services

Core idea: network appliance operation.

Scenario: A web application attack passes through the firewall because the traffic is allowed HTTPS.

Practitioner response: Use the right inspection point, such as WAF/application-layer controls, while keeping firewall and proxy policy aligned.

Concepts to Understand

• firewalls and proxies: firewalls and proxies is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• WAF: WAF is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• CASB: CASB is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• network IDS/IPS: network IDS/IPS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• routers and switches: routers and switches is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• WAN optimization and load balancing: WAN optimization and load balancing is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• NAC: NAC is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• DLP: DLP is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• UTM: UTM is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

6.6 Secure wireless communications

Core idea: wireless security.

Scenario: Guest wireless shares the same access path as corporate devices and uses a shared password.

Practitioner response: Separate guest and corporate wireless, use strong authentication/encryption, and restrict access with NAC and monitoring.

Concepts to Understand

• cellular: cellular is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• Wi-Fi: Wi-Fi is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• Bluetooth: Bluetooth is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• NFC: NFC is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• WPA, EAP, WPA2, and WPA3: WPA, EAP, WPA2, and WPA3 is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

6.7 Secure and monitor Internet of Things

Core idea: IoT security.

Scenario: A building sensor exposes a web console and cannot run endpoint security tooling.

Practitioner response: Isolate the IoT device, change defaults, restrict management access, monitor traffic, patch firmware, and plan replacement before EOL.

Concepts to Understand

• configuration: configuration is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• network isolation: network isolation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• firmware updates: firmware updates is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• end-of-life management: end-of-life management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

IDS vs IPS

Exam clue: If prevention is required, a passive IDS alone is not enough.

segmentation vs isolation

This comparison is covered through the domain objectives above and the SSCP review sheet.

firewall vs WAF vs proxy

This comparison is covered through the domain objectives above and the SSCP review sheet.

RADIUS vs TACACS+

This comparison is covered through the domain objectives above and the SSCP review sheet.

WPA2 vs WPA3

This comparison is covered through the domain objectives above and the SSCP review sheet.