N10-009 network security explained

Network security is worth 14% of CompTIA Network+ N10-009 — around 13 of the 90 questions and the smallest domain. It is deliberately foundational: depth belongs to Security+.

Cover it properly, but proportionately. Thirteen questions does not justify three weeks.

Common attacks

Recognise them by their network signature:

The exam gives a symptom and asks for the attack, so learn the signature rather than the definition.

Hardening

• Change default credentials. The most common correct answer in the domain.
• Disable unused ports and services.
• Keep firmware current.
• Secure protocols over insecure ones: SSH not Telnet, HTTPS not HTTP, SFTP not FTP, SNMPv3 not earlier versions.
• Port security on switches, limiting which devices may connect.

That secure-alternative pairing links directly back to the concepts domain, where the ports and protocols live.

Segmentation and access control

• VLANs for logical separation — the same mechanism as in implementation, here framed as a security control.
• DMZ / screened subnet for services reachable from outside.
• Firewalls and access control lists, and the principle of least privilege applied to network access.
• NAC — checking a device’s posture before allowing it on.
• Guest networks isolated from internal resources.

Encryption, certificates and key management

Objective 4.1 lists encryption of data in transit and data at rest, and certificates, split into PKI and self-signed. Objective 4.3 adds key management as a defence technique. Network+ wants the purpose of each, not the mathematics.

Data in transit versus data at rest. In transit means data moving across a network: protect it with protocols such as TLS (HTTPS, LDAPS, SMTPS), SSH, or an IPsec VPN tunnel. At rest means data stored on a disk, a NAS or SAN, a backup or a laptop: protect it with storage or full-disk encryption. One does not cover the other. A file sent over HTTPS is protected on the wire and lands unencrypted on the server unless the storage is encrypted as well.

Certificates. A certificate binds a public key to an identity, such as a server’s hostname. With PKI, a certificate authority (CA) signs the certificate, and clients that trust that CA’s root certificate accept it without prompting. A self-signed certificate is signed by its own key, so nothing vouches for it: browsers and clients warn about it unless someone deliberately installs it as trusted. Many switches, firewalls and access points ship with a self-signed certificate on their management interface. It still encrypts the session, but it does not prove you reached the real device.

Key management covers the life of the keys behind all of this: generating them securely, storing private keys where only their owner can read them, distributing and rotating them, and revoking certificates when a key is compromised or a device is decommissioned. Encryption is only as strong as the protection of its keys — a private key copied to a shared folder undoes everything above.

Exam pitfall: an administrator connects over HTTPS to a new device’s web interface, the browser shows a certificate warning, and one option claims the connection is unencrypted. It is not. The warning is about trust, because the certificate is self-signed or issued by a CA the browser does not trust. The fix is a certificate from a trusted CA, or deliberately trusting that device’s certificate — never falling back to HTTP.

Symmetric and asymmetric keys, hashing and how PKI chains work are in the cryptography basics guide.

Authentication and remote access

• AAA: authentication, authorisation and accounting.
• Multifactor authentication.
• VPNs: site-to-site versus remote access, and that the point is an encrypted tunnel over an untrusted network.
• Wireless authentication: pre-shared key versus enterprise with a RADIUS server.

Single sign-on and SAML

Objective 4.1 lists SSO and SAML alongside MFA, RADIUS, LDAP and TACACS+ as authentication options under identity and access management. They solve a different problem from the others in that list.

Single sign-on (SSO) means a user authenticates once, to one trusted identity provider, and then reaches several applications without logging in to each separately. Fewer passwords means fewer reused or written-down passwords, one place to enforce MFA, and one place to disable an account when someone leaves. The trade-off is that the single login becomes very valuable, so it needs MFA.

SAML (Security Assertion Markup Language) is an open OASIS standard widely used to deliver web-based SSO. Three parties are involved: the user’s browser, the identity provider (IdP) that authenticates the user, and the service provider (SP), the application the user wants. The SP redirects the browser to the IdP; the IdP authenticates the user and sends back a digitally signed XML assertion stating who the user is, often with attributes such as group membership; the SP checks the signature against the IdP it trusts and grants access. The application never sees the user’s password.

How it differs from its neighbours in the same objective:

• RADIUS and TACACS+ are AAA protocols for network access and device administration — Wi-Fi with 802.1X, VPN logins, administrators logging in to switches and routers.
• LDAP is a directory protocol for looking up and verifying accounts, often the store behind an IdP or a RADIUS server.
• SAML federates identity into web applications, frequently across organisations — staff using their company credentials to sign in to a SaaS application, for example.

Exam pitfall: a question asks how employees can use their corporate credentials to sign in to several cloud web applications without separate passwords, and offers RADIUS or TACACS+. Those authenticate network and device access; browser-based SSO to web applications points to SAML. The reverse also holds: controlling which commands administrators may run on a router is TACACS+, not SAML.

OAuth, OpenID Connect and a SAML sign-in step by step are in the SSO, SAML and OAuth guide.

Physical security

Easy marks: locks, badge access, cameras, secured wiring closets, and the reminder that physical access usually defeats logical controls.

Sample questions

What to practise

Write the attack-to-signature table from memory. Then list every insecure protocol from the concepts domain with its secure replacement — that single list answers a surprising number of questions across both domains.

Then stop. This domain is 14%, and the time you save belongs in troubleshooting, which is worth nearly double.