Network+ N10-009 Domain 4: Network Security

Domain 4 accounts for 14% of N10-009. The percentage is smaller than the other domains, but security clues appear inside routing, switching, wireless, operations, and troubleshooting questions. A switchport that accepts any device is both an implementation choice and an access-control decision. A false default gateway from a rogue DHCP server looks like a connectivity problem until the unauthorized service is identified.

Security questions become easier when you identify four things: the asset, the threat, the control point, and the evidence that would prove the control worked. A certificate protects a different decision than an access control list. Port security addresses a different problem than 802.1X. A screened subnet changes where a public service sits, while URL filtering changes which destinations users may request.

Use this guide to compare nearby answers and follow the attack path. The official objectives remain the coverage checklist. The examples below show where each control belongs and what failure or attack it can reasonably prevent, limit, detect, or investigate.

Domain 4 objective map

The three objectives form a practical sequence. Objective 4.1 supplies the security model. Objective 4.2 shows what can go wrong. Objective 4.3 asks you to place a control against that path. Keep moving between them instead of studying three unrelated lists.

Make security decisions from the traffic path

Begin with the normal path. A managed laptop connects to a switchport, authenticates through 802.1X, receives an address from an approved DHCP service, resolves a name through an approved DNS resolver, crosses a firewall between zones, and establishes an encrypted application session. Administrative changes come through a restricted management path using an individual account and centralized authorization.

An attacker or failure changes one of those steps:

• A rogue DHCP server supplies the wrong gateway or DNS resolver.
• ARP spoofing changes the local mapping between an IP address and a MAC address.
• DNS poisoning changes the address returned for a name.
• An evil twin persuades a wireless client to join the wrong access point.
• A stolen administrator credential turns an approved management protocol into an unauthorized session.
• A DDoS attack overwhelms a service or its upstream capacity even though the configuration is otherwise correct.

The best control usually sits close to the changed behavior. DHCP snooping belongs on switches that can distinguish trusted DHCP paths from access ports. Certificate validation belongs at the endpoint establishing the protected session. ACLs and firewalls belong at Layer 3 and Layer 4 boundaries. Identity-based admission belongs at the network edge before broad access is granted.

Separate encryption in transit from encryption at rest

Data in transit is moving between systems or components. TLS-protected HTTPS, SSH, IPsec, and protected wireless sessions are examples. The security question is whether the endpoints authenticate appropriately, negotiate an approved protocol and algorithm, protect keys, and reject invalid or untrusted peers.

Data at rest is stored on a drive, database, backup, mobile device, or other persistent medium. Full-disk encryption can protect a stolen laptop while database or file-level encryption may protect selected information from broader storage access. Backups need the same attention because a copied backup can contain the information an attacker wanted from the production system.

Encryption supports confidentiality, but it does not automatically supply every part of the CIA triad. A server can encrypt traffic and still be unavailable. An authorized user can alter encrypted data after authentication. A valid encrypted session can carry malware or a destructive command. Match the control to the stated requirement instead of treating encryption as a general-purpose shield.

What encryption does not prove by itself

A padlock icon shows that a protected session was established, not that the remote service is honest, correctly configured, free of malware, or authorized for the requested business action. Trust depends on certificate validation, identity, policy, endpoint condition, and the application itself.

A VPN protects traffic across an untrusted path, but it also extends access. The VPN user or site must still be authenticated, authorized, segmented, monitored, and limited to the required resources. Encryption can hide malicious traffic from devices that lack an inspection point, so placement and visibility matter.

Use certificates and PKI for scalable trust

A digital certificate binds an identity or name to a public key and carries information such as issuer, subject, validity period, permitted uses, and signatures. Public key infrastructure supplies the policies, certificate authorities, registration processes, trust stores, issuance, renewal, revocation, and validation that make certificates manageable at scale.

A simplified TLS trust decision looks like this:

1. The server presents a certificate and the certificates needed to build a trust chain.
2. The client checks whether the requested hostname matches the certificate.
3. The client checks dates, signatures, permitted use, and whether the chain reaches a trusted root.
4. The endpoints establish session keys and protect the application traffic.

A certificate warning can come from an expired certificate, a hostname mismatch, an untrusted issuer, a missing intermediate certificate, a revoked certificate, or a client clock that makes the dates appear invalid. Clicking through the warning removes the protection that the validation step was supposed to provide.

Publicly trusted and private PKI

Public services usually need certificates that common client trust stores recognize. Internal services can use a private certificate authority when managed endpoints trust that authority and the organization can operate issuance, renewal, revocation, backup, and recovery correctly. Private PKI is useful, but it creates an operational responsibility rather than free trust.

Self-signed certificates

A self-signed certificate signs itself rather than chaining to a separately trusted authority. It can still protect traffic from passive observation after the client accepts the key, but the client needs a safe way to know that the certificate belongs to the intended system. Blindly accepting an unfamiliar self-signed certificate during a possible on-path attack defeats that identity check.

Self-signed certificates are common on newly installed appliances and labs. A production decision may be to replace them with certificates issued by an approved public or private PKI, especially when many administrators or automated clients must validate the service consistently.

Key management is part of certificate security

Protect private keys from unauthorized use and extraction. Define who can request, approve, install, rotate, revoke, recover, and destroy keys. Monitor expiration before a service outage. Back up keys only when recovery requirements justify it, and protect those copies at least as strongly as the originals.

Distinguish authentication, authorization, and identity services

Authentication verifies the claimed identity. Authorization decides what that identity may do. Accounting records activity, time, usage, or commands. The three functions are often grouped as authentication, authorization, and accounting (AAA), but a scenario may ask for one specific decision.

A valid login does not imply administrative access. A user can authenticate successfully and still be denied a protected VLAN, device command, file, or application because authorization policy does not permit it.

MFA and SSO solve different problems

Multifactor authentication combines factors from different categories, such as something known, something possessed, or something inherent. Two passwords are two examples of the same factor type, not MFA.

Single sign-on allows one authentication event or identity session to support access to multiple connected services. SSO improves usability and can centralize policy, but it also raises the importance of protecting the identity provider and session. SSO does not necessarily mean MFA. An environment may use both.

Time-based authentication commonly generates a short-lived code from a shared secret and the current time. Clock drift can cause valid users to fail, which connects this security topic to the time-service controls in Domain 3.

The table compares Remote Authentication Dial-In User Service (RADIUS), Terminal Access Controller Access-Control System Plus (TACACS+), Lightweight Directory Access Protocol (LDAP), Security Assertion Markup Language (SAML), and role-based access control (RBAC). Each term belongs to a different part of the identity or administration workflow.

RADIUS and TACACS+ are not interchangeable labels

RADIUS commonly appears when an endpoint or user is trying to join a network through Wi-Fi, VPN, or 802.1X. TACACS+ commonly appears when an administrator is logging into network infrastructure and the organization wants centralized command authorization and accounting.

The exact protocol security depends on deployment. Classic RADIUS and TACACS+ have limitations that should not be described as modern end-to-end encryption of the entire exchange. Protected transports and secure network placement may be required. For Network+ questions, start with the use case: network admission points toward RADIUS; network-device administration often points toward TACACS+.

Apply least privilege

Least privilege grants only the access needed for the approved task and duration. A help-desk role may view interface status and bounce an access port without changing routing policy. A monitoring account may read counters without modifying configuration. An automation identity may manage one device group through an API rather than receive unrestricted interactive access.

Use individual accounts where accountability matters. Shared administrator accounts hide who performed a change and make credential rotation harder. Emergency access accounts can exist, but they need strong protection, monitoring, and review after use.

Combine physical and deception controls with logical controls

Cameras and locks address physical access in different ways. A lock is primarily preventive because it restricts entry. A camera is primarily detective because it records or reveals activity, though its visible presence can also discourage some behavior. Neither replaces access logs, visitor procedures, rack locks, port controls, or logical authentication.

Physical compromise can bypass carefully designed logical controls. An attacker with access to an unlocked network closet may connect a rogue device, reset equipment, steal a configuration, attach a packet-capture device, or interrupt power and cabling.

Honeypots and honeynets

A honeypot is a decoy system or service intended to attract and observe suspicious activity. A honeynet is a broader decoy network containing multiple systems or services. Their value comes from controlled observation because legitimate users should have little reason to interact with them.

Deception technology needs isolation and monitoring. A compromised decoy must not become a convenient path into production or a launch point toward other systems. The data can support detection and investigation, but a honeypot does not patch vulnerable production servers or block an attack by itself.

Use security terminology precisely

The terms describe relationships. A threat actor may use an exploit against a vulnerability in an asset, creating risk to confidentiality, integrity, or availability.

Confidentiality, integrity, and availability (CIA) triad

• Confidentiality limits information disclosure to authorized parties.
• Integrity protects information and systems from unauthorized or undetected change.
• Availability keeps systems and information accessible when authorized users need them.

A DDoS attack primarily targets availability. An on-path attacker who reads traffic threatens confidentiality. A rogue DHCP or DNS service can threaten integrity by supplying false network information and may then affect availability or confidentiality.

Audits, data locality, PCI DSS, and GDPR

An audit compares evidence against stated requirements, policies, standards, or regulations. The evidence may include configurations, logs, access reviews, diagrams, change records, vulnerability results, training records, and control tests.

Data locality concerns where data is stored, processed, transmitted, or otherwise handled. Architecture decisions may be constrained by region, jurisdiction, contract, or organizational policy. A cloud service's global reach does not remove those requirements.

Payment Card Industry Data Security Standard (PCI DSS) applies to environments that store, process, or transmit payment account data and to systems that can affect the security of that environment. General Data Protection Regulation (GDPR) establishes data-protection requirements involving personal data in its scope. Network+ expects recognition of the names and operational implications, not legal interpretation. Real compliance decisions require the applicable current text and qualified organizational guidance.

Use segmentation to reduce unnecessary trust

Segmentation separates systems by role, risk, function, ownership, or required communication. VLANs create logical Layer 2 boundaries. Routers, Layer 3 switches, firewalls, ACLs, and security policies control traffic between segments. Microsegmentation can apply finer policy around workloads or applications, though the N10-009 objective focuses on the practical need to separate distinct device groups.

The examples include Internet of Things (IoT), Industrial Internet of Things (IIoT), supervisory control and data acquisition (SCADA), industrial control systems (ICS), operational technology (OT), and bring your own device (BYOD) networks. The expansion identifies the device group; the policy decision comes from its risk and required communication.

Segmentation without enforcement is only an addressing plan. If a guest VLAN can route freely to management interfaces, the names of the VLANs do not create security. Verify the firewall rules, ACLs, routing, wireless client isolation, and management-source restrictions that enforce the design.

Segmentation supports zero trust but does not equal zero trust

Zero trust removes implicit trust based only on network location or asset ownership. Authentication and authorization are evaluated before access to a resource, and policy can consider user, device, service, context, and risk. Segmentation can limit paths and reduce exposure, but placing a device on an internal VLAN should not automatically grant broad access.

Recognize the network effect of an attack

The exam may name the attack, describe its behavior, or show a symptom. Focus on what information or forwarding decision became false, overloaded, or unauthorized.

DoS and DDoS

A denial-of-service attack can come from one source or one attack path. A distributed denial-of-service attack uses multiple sources, commonly a botnet or reflected traffic. Distribution makes source blocking and capacity defense harder.

Volume is only one method. Attacks can exhaust connection tables, application workers, CPU, memory, or a protocol-specific resource. The answer should fit the symptom. A large upstream flood may require provider or DDoS-scrubbing assistance, while a vulnerable service that consumes CPU on a small request may require patching, filtering, rate limits, or application changes.

Reflection and amplification use third-party services to send larger responses toward a spoofed victim address. Ingress filtering, restricting exposed UDP services, rate limiting, and provider coordination can reduce the problem. A local ACL may help with a narrow source or service, but it cannot recover bandwidth already saturated before traffic reaches the device.

Connect Layer 2 attacks to switch controls

VLAN hopping

VLAN hopping describes methods that cross an intended VLAN boundary through switching behavior or misconfiguration. Two commonly discussed paths are switch spoofing and double tagging.

An access port should not dynamically become a trunk because an untrusted endpoint asks. Configure the intended mode, limit allowed VLANs on trunks, use an unused native VLAN where the design calls for it, avoid placing user traffic on the native VLAN, and disable unused ports. The exact platform commands differ, but the decision is consistent: remove unneeded trunk negotiation and limit the trunk's scope.

Double-tagging depends on native-VLAN handling and the attacker's relationship to the first switch. The inner tag can remain after the outer native-VLAN tag is removed. It is generally one-directional and constrained by topology, so do not describe it as magical access to every VLAN.

MAC flooding

A switch learns source MAC addresses and associates them with ports. An attacker can send frames with many fabricated source addresses to pressure or fill the forwarding table. The historical description says the switch may begin flooding unknown unicast frames more broadly, but modern behavior varies by platform and resource protection.

Port security can limit the number or identity of MAC addresses learned on an access port and define what happens after a violation. Monitoring should also detect unusual MAC churn or many addresses appearing on a user-facing port. Port security does not authenticate a person, and a permitted MAC address can still be copied.

ARP poisoning and spoofing

ARP maps local IPv4 addresses to MAC addresses. A false ARP reply can tell a client that the attacker's MAC belongs to the default gateway, or tell the gateway that the attacker's MAC belongs to a victim. If forwarding continues through the attacker, the position can support an on-path attack. If it does not, connectivity may fail.

Dynamic ARP inspection can validate ARP messages against trusted bindings, often learned through DHCP snooping. Static ARP entries can help in narrow cases but do not scale well. Segmentation reduces the size of the local broadcast domain and therefore the number of systems directly exposed to local ARP manipulation.

Separate DNS, DHCP, and on-path attacks

DNS poisoning and spoofing can produce the same user symptom as a compromised website: the name resolves to an attacker's address. Check which resolver answered, the returned record, TTL, DNSSEC validation where used, local hosts-file entries, and whether multiple trusted resolvers agree. A certificate warning after redirection can be an important clue because the attacker's server may not possess a certificate valid for the requested name.

Rogue DHCP changes network configuration before the application request begins. The client may receive an attacker-controlled gateway or DNS resolver, enabling later interception or redirection. The clue is in the lease: DHCP server identifier, assigned gateway, DNS settings, scope, and timing.

DHCP snooping marks trusted ports for legitimate server replies and blocks unauthorized replies from access ports. It can also build binding information used by other controls. Configure the trusted direction carefully. Marking every uplink and access port as trusted removes the protection.

An on-path attack describes the attacker's position, not one single method. ARP spoofing, rogue DHCP, DNS manipulation, malicious wireless, compromised routing, or a deceptive proxy can help create that position. The defense follows the method plus endpoint validation and encryption.

Recognize wireless, social, and malware paths

Rogue access point and evil twin

A rogue AP is an unauthorized wireless access point. It might be connected by an employee for convenience, installed by an attacker, or created through a misconfigured hotspot. An evil twin deliberately imitates a trusted wireless network to attract clients, often using the same or similar SSID.

The SSID is a name, not proof of identity. Enterprise wireless clients should validate the authentication server or certificate according to policy. Wireless monitoring can identify unexpected BSSIDs, channels, security settings, and signal locations. Wired controls can detect or block unauthorized AP connections. User training helps prevent acceptance of strange certificate prompts or captive portals.

Social engineering

• Phishing uses deceptive messages, pages, or attachments to obtain information, credentials, payment, or code execution.
• Dumpster diving searches discarded material or equipment for useful information.
• Shoulder surfing observes screens, keyboards, badges, or documents directly.
• Tailgating follows an authorized person into a restricted area without separate authorization.

Technical controls and physical procedures work together. MFA can reduce the value of a stolen password, but a sophisticated phish may target the second factor or session. Privacy screens and workstation placement help with shoulder surfing. Secure disposal helps with dumpster diving. Badges and access controls help only when people do not hold the door for unverified visitors.

Malware

Malware is a broad category that includes code designed for unauthorized access, disruption, theft, surveillance, persistence, or extortion. Network symptoms can include command-and-control traffic, scanning, unexpected DNS queries, unusual outbound volume, lateral movement, disabled security services, or encryption of shared data.

Network controls can limit communication and spread, but endpoint prevention, detection, patching, application controls, backups, identity protection, and incident response remain important. Blocking one destination does not prove the infected endpoint is clean.

Harden devices and control admission

Device hardening removes unnecessary attack paths and reduces the damage available through required ones. Start with a current inventory and approved baseline, then apply controls such as:

• Disable unused physical ports, logical interfaces, management protocols, discovery services, and application services.
• Change default passwords and remove default or unused accounts.
• Use individual administrative identities, MFA where supported, least privilege, and centralized AAA.
• Restrict management access to approved sources and protected protocols such as SSH and HTTPS.
• Patch operating systems and firmware through change control.
• Protect configuration backups, keys, logs, and recovery access.
• Set time correctly so authentication, certificates, logs, and investigations agree.
• Monitor configuration drift, failed logins, privilege use, new services, and unexpected interfaces.

A disabled switchport is useful when no device should connect there. It does not solve unauthorized access on a port that must remain active. That is where admission controls matter.

Understand the 802.1X roles

The supplicant is the endpoint requesting access. The authenticator is the switch or access point controlling the edge. The authentication server commonly uses RADIUS to evaluate credentials or certificates and return an access decision or attributes.

A failed 802.1X exchange may leave the port unauthorized, place the endpoint in a guest or remediation role, or allow a fallback method according to policy. The secure answer is not automatically "fail open" or "fail closed." Availability, risk, device type, emergency access, and the stated requirement matter.

Manage keys, rules, and security zones

Key management

Keys must remain protected throughout generation, distribution, storage, use, rotation, recovery, revocation, and destruction. The strongest algorithm does not help if private keys are copied from an open file share or shared in a ticket.

Use approved key lengths and algorithms, separate duties where appropriate, limit key access, record ownership, monitor certificate and key expiration, and rotate credentials after compromise or personnel changes. Pre-shared keys become difficult to attribute and rotate when many devices or people share them.

ACLs, URL filtering, and content filtering

ACL order matters on platforms that process rules from top to bottom. A broad permit placed before a narrow deny can make the deny ineffective. Identify source, destination, protocol, port, direction, and state, then test required and prohibited traffic after the change.

Trusted, untrusted, and screened zones

A trusted zone has a higher level of assumed control, but the name should not grant unlimited access. An untrusted zone includes networks such as the public internet where the organization does not control the endpoints or traffic. Policy between zones should permit the minimum required flows.

A screened subnet places public-facing or externally reachable services in a separate security zone, often called a DMZ. External clients may reach the published service, while direct access from that service to internal systems remains tightly limited. Management should use a protected administrative path rather than the same public interface.

A screened subnet does not make the server safe by location alone. The service still needs hardening, patching, monitoring, restricted outbound access, protected secrets, backups, and application security.

Work through security scenarios

Scenario 1: Clients receive the wrong gateway

Some users receive the normal address range but a different default gateway and DNS server. The problem appears only on one floor and changes after clients renew their leases.

Inspect the DHCP server identifier and switch path. A rogue DHCP service on an access port can answer clients before the approved server. DHCP snooping should allow server replies only from trusted directions, and the unauthorized device should be removed and investigated. Replacing the approved DHCP scope does not address the competing server.

Scenario 2: A contractor needs one internal application

A contractor uses a personally owned device and needs access to one web application for two weeks. The device should not reach management, server, or user networks.

Use identity-based access, MFA, a limited role, and a path that exposes only the required application, such as an approved clientless gateway or tightly controlled remote-access policy. Place BYOD in a restricted segment and log access. Broad VPN access followed by a reminder to avoid other systems is not least privilege.

Scenario 3: A switch administrator should run only support commands

Help-desk staff must view interface state and reset access ports, but they must not change routing, trunks, or security policy.

Centralized device administration with TACACS+ and command authorization can map the support role to approved actions and record activity. A shared local administrator password provides neither least privilege nor individual accountability.

Scenario 4: Users see a certificate warning on a familiar site

DNS returns an unexpected address, and users receive a hostname mismatch warning. Ignoring the warning loads a page that resembles the normal sign-in screen.

Stop the session. Verify the resolver, returned records, certificate subject, issuer, and path. DNS manipulation or an on-path redirection can send users to an attacker-controlled server that lacks a valid certificate for the requested name. Installing the unfamiliar certificate as trusted would hide the evidence and increase exposure.

Scenario 5: A public web server needs an internal database

Internet users need HTTPS access to a web server. The web server needs one database connection to an internal service. It does not need general access to user devices, management interfaces, or other servers.

Place the web service in a screened subnet. Permit inbound HTTPS from the untrusted zone to the web service, permit only the required database flow toward the specific internal destination, and restrict management to a protected administrative path. Limit unnecessary outbound traffic and monitor both permitted paths.

Scenario 6: One access port learns hundreds of MAC addresses

A user-facing switchport rapidly learns changing MAC addresses, and forwarding-table usage increases.

Investigate for MAC flooding, an unauthorized downstream switch, a loop, virtualization, or another legitimate multi-device use before choosing the response. On a normal single-device access port, port-security limits and violation handling can contain the behavior. Disabling the entire switch may restore table capacity, but it creates a larger outage and removes evidence from unaffected ports.

Scenario 7: A guest network can reach printer and management addresses

The guest SSID uses a separate VLAN, but guests can still open printer pages and a switch management interface.

The VLAN created a broadcast boundary, not sufficient policy enforcement. Add or correct firewall and ACL rules between the guest, internal, and management zones. Verify both allowed internet access and denied internal destinations. Renaming the SSID or hiding it does not enforce segmentation.

Common Network+ Domain 4 traps

Calling SSO multifactor authentication

SSO reduces repeated sign-ins. MFA combines different factor types. They can be used together, but one does not imply the other.

Using authorization to describe login verification

Authentication verifies identity. Authorization evaluates permissions after or alongside that identity decision.

Treating LDAP as a replacement word for every identity service

LDAP accesses directory information. RADIUS commonly supports network access, TACACS+ commonly supports device administration, and SAML commonly supports federation. Follow the use case.

Assuming a self-signed certificate provides no encryption

A self-signed certificate can support an encrypted session. The main problem is how the client validates identity and establishes trust safely.

Treating the padlock as proof that a site is safe

TLS protects the session to the certificate's validated identity. A malicious site can obtain a valid certificate for its own name.

Using a VLAN name as evidence of segmentation

The enforcement comes from routing, ACLs, firewalls, wireless policy, and management restrictions. Verify the path between zones.

Choosing MAC filtering when the scenario requires user identity

MAC addresses can be observed and copied. 802.1X with centralized authentication better fits identity-based network admission.

Choosing port security for a rogue DHCP server without considering DHCP snooping

Port security can limit MAC behavior, but DHCP snooping directly controls which ports may send DHCP server responses.

Confusing rogue AP and evil twin

A rogue AP is unauthorized. An evil twin is a deceptive AP designed to imitate a trusted network. An evil twin is rogue, but a convenience AP installed by an employee may not imitate an existing SSID.

Confusing ARP spoofing and DNS spoofing

ARP changes a local IP-to-MAC mapping. DNS changes name-to-address information. Both can redirect traffic, but the evidence and enforcement points differ.

Calling every interception an ARP attack

An on-path position can come from wireless deception, routing compromise, rogue DHCP, DNS manipulation, proxy configuration, or physical insertion. ARP spoofing is one path on a local IPv4 segment.

Applying a local firewall rule to an upstream DDoS bottleneck

A downstream device cannot restore capacity already exhausted before traffic reaches it. Provider coordination, scrubbing, rate controls, architecture, and upstream filtering may be required.

Using URL filtering to block a transport port

An ACL or firewall rule fits source, destination, protocol, and port decisions. URL filtering works with requested web destinations or categories.

Assuming a screened subnet is trusted

A public-facing service remains exposed. The screened subnet limits paths and separates risk; it does not convert the server into an internal trusted endpoint.

Forgetting key rotation and expiration

Keys and certificates have lifecycles. A secure deployment needs ownership, renewal, revocation, rotation, backup policy, and monitoring before expiration creates an outage.

Rapid review checklist

You are ready to move beyond Domain 4 review when you can:

• Distinguish encryption in transit from encryption at rest and explain what encryption does not prove.
• Describe certificate trust chains, hostname validation, expiration, private PKI, and self-signed certificate risks.
• Separate authentication, authorization, accounting, MFA, SSO, RBAC, and geofencing.
• Match RADIUS, TACACS+, LDAP, and SAML to their common network roles.
• Explain least privilege and why individual administrator accounts improve accountability.
• Classify locks, cameras, honeypots, and honeynets by their practical security role.
• Connect assets, threats, vulnerabilities, exploits, and risk without swapping the terms.
• Apply confidentiality, integrity, and availability to a described impact.
• Recognize the operational purpose of audits, data locality, PCI DSS, and GDPR.
• Design separate policy for IoT, IIoT, SCADA, ICS, OT, guest, BYOD, and management segments.
• Explain why segmentation requires enforcement between zones.
• Identify DoS, DDoS, VLAN hopping, MAC flooding, ARP poisoning, DNS poisoning, rogue DHCP, rogue AP, evil twin, and on-path behavior from symptoms.
• Distinguish phishing, dumpster diving, shoulder surfing, tailgating, and malware paths.
• Harden devices by removing unused access, replacing defaults, restricting management, maintaining software, and monitoring drift.
• Choose port security, 802.1X, MAC filtering, or broader NAC policy from the stated admission requirement.
• Identify the supplicant, authenticator, and authentication server in an 802.1X flow.
• Explain why key generation, distribution, storage, rotation, revocation, and destruction all matter.
• Choose an ACL, URL filter, or content filter according to what must be evaluated.
• Distinguish trusted, untrusted, and screened zones and define the minimum required flows between them.

After reviewing, take a Network+ N10-009 practice test. For each missed security question, identify the exact control point. Was the false information learned through ARP, DHCP, DNS, wireless, or identity? Was the decision about admission, authorization, filtering, segmentation, trust, or availability? That classification usually eliminates several attractive but misplaced answers.

Official references

• CompTIA Network+ certification page
• CompTIA Network+ N10-009 exam objectives
• NIST SP 800-207: Zero Trust Architecture
• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks
• NIST SP 800-63-4: Digital Identity Guidelines
• RFC 2865: Remote Authentication Dial In User Service
• RFC 8907: The TACACS+ Protocol
• PCI Security Standards Council document library