Security+ Secure Baselines, Endpoint Security, and Asset Management

Introduction

This lesson opens Domain 4, Security Operations, the largest domain of SY0-701 at 28% of the exam. It covers objective 4.1, applying common security techniques to computing resources, and objective 4.2, explaining the security implications of proper hardware, software, and data asset management. Where earlier domains asked "what could go wrong and what design prevents it", this domain asks "what do you actually do on Monday morning to keep systems secure".

Security+ endpoint security and asset management scenarios include a laptop fleet drifting from its standard configuration, a rogue access point in a meeting room, a mobile phone with company mail on it, an application that must be tested before release, or a server that is leaving service and must be disposed of safely. The correct answer usually names a specific, practical technique, so the goal of this lesson is to attach each technique to the problem it solves.

Learning objectives

After this lesson you will be able to:

• Establish, deploy, and maintain a secure baseline for operating systems and devices.
• Select hardening techniques for workstations, servers, network devices, and mobile devices.
• Compare mobile deployment models (BYOD, COBO, COPE, CYOD) and mobile management controls.
• Choose appropriate wireless security settings, authentication methods, and installation considerations.
• Apply application security techniques: input validation, secure cookies, static code analysis, code signing, and sandboxing.
• Describe the asset management life cycle: acquisition, assignment, monitoring, enumeration, and disposal.

1. Secure baselines: establish, deploy, maintain

A secure baseline is a documented, approved configuration that every system of a given type must meet. It might say that Windows laptops use full-disk encryption, a host firewall is on, the built-in guest account is disabled, only approved software is installed, and the password policy meets company standards. Baselines come from vendor guidance and community benchmarks such as the CIS Benchmarks, DISA STIGs, and Microsoft security baselines, then are tailored to the organization.

The exam breaks the baseline life cycle into three verbs:

Configuration drift is the slow divergence of systems from the baseline because of manual changes, emergency fixes, or software installs. Left alone, drift creates the one-off, unpatched, unmanaged server that attackers love. Automated compliance scanning (for example, a SCAP-based scanner or a configuration management tool in "check" mode) compares each system with the baseline and reports deviations. Deviations are either remediated or documented as approved exceptions with a compensating control.

Example 1: a golden image that ages badly

A regional retailer builds a Windows 11 golden image in January and uses it for every new point-of-sale back-office PC. By September the image still contains an old browser version and a local administrator account that was created for the build. Newly imaged PCs are already out of compliance on day one. The fix is not to abandon images but to treat the image as a versioned artifact: rebuild it monthly from the current baseline, run a compliance scan on the output before release, and retire older image versions through change management.

2. Hardening targets

Hardening reduces the attack surface of a system by removing or restricting everything it does not need. The exam lists several target types, and the techniques overlap.

Key hardening techniques:

• Default password changes. Vendor defaults are public knowledge and the first thing an attacker tries.
• Removal of unnecessary software and services. Each installed package is code that may be vulnerable and must be patched.
• Host-based firewall. Controls inbound and outbound traffic per host, according to configured rules; permissive outbound settings may still allow scanning, so verify the effective policy.
• Host-based intrusion prevention (HIPS). Blocks known-bad behaviors on the endpoint.
• Disabling ports and protocols. On a server, close what the application does not need; on a switch, administratively shut down unused ports. An unused VLAN alone is not equivalent to disabling a port; apply a policy that prevents unauthorized connectivity.
• Encryption. Full-disk encryption (BitLocker, FileVault, LUKS) protects a lost laptop; TPM-backed keys can support protection, but encryption depends on implementation, key handling, and device state. It does not protect plaintext in an unlocked session.
• Least privilege. Daily-use accounts are not administrators; elevation is deliberate and logged.

Exam tip. When a scenario says a new device "works fine out of the box", suspect default credentials, default services, and an unnecessary management protocol. The best first action is nearly always to harden before connecting it to production.

Review segmentation, patching, and hardening controls when tailoring the approved build.

3. Endpoint security

An endpoint is a computing device at the edge of an organization’s access or workload environment, including laptops, phones, workstations, and servers. The exam expects you to know the layered controls that sit on endpoints.

• Anti-malware / antivirus: signature, heuristic, and other detection techniques; modern products can detect previously unseen behavior as well as known files.
• Endpoint detection and response (EDR): continuous recording of process, file, registry, and network activity on the endpoint, behavioral detection, and the ability to isolate a host and investigate. It extends beyond signatures to catch fileless and living-off-the-land attacks.
• Extended detection and response (XDR): correlates telemetry across endpoints, email, identity, network, and cloud to give a wider view.
• Host-based firewall and HIPS: described above.
• Application allow-listing (whitelisting): only approved executables may run. This is stronger than block-listing because unknown software is denied by default; the cost is administrative effort when software changes.
• Patch management: operating system and application updates deployed on a schedule with emergency paths for critical vulnerabilities.
• Full-disk encryption, Secure Boot, and measured boot with a TPM have different roles: encryption protects stored data, Secure Boot enforces permitted signatures, and measured boot records measurements for evaluation/attestation. A TPM does not by itself block every boot change.
• Data loss prevention agents: block copying of regulated data to USB or personal cloud storage.
• Removable media control: disable autorun and restrict USB storage on sensitive systems.

Worked example: choosing between block-listing and allow-listing

Scenario. A hospital runs 40 workstations in an imaging department. They run one specialist application, and a recent ransomware incident started from a downloaded installer. Management wants the strongest control that is still manageable. Options: (A) update antivirus signatures daily, (B) block the top 500 known-malicious executables, (C) application allow-listing limited to the imaging software and operating system components, (D) forbid internet access in a policy memo.

Reasoning.

1. The risk is unauthorized executables running. The set of legitimate executables on these machines is small and stable.
2. Signature-only updates (A) and the fixed block list (B) mainly address listed threats and may miss new code. Modern antivirus may also use behavioral detection; the scenario’s “signatures only” option is the limitation.
3. Allow-listing (C) denies everything not approved, which matches a small, stable environment, so the administrative cost is low.
4. A policy memo (D) is an administrative control with no technical enforcement.

Solution. Option C. It is a preventive technical control suited to fixed-function systems. Combine it with EDR for detection of allowed-but-abused tools, and with patching.

4. Mobile devices and deployment models

Mobile devices carry corporate data outside the network perimeter, so the organization chooses how much control it keeps. The four deployment models:

Mobile device management (MDM) and the broader unified endpoint management (UEM) enforce policy: required PIN or biometric, encryption, approved apps, remote lock and remote wipe, geofencing, and compliance checks that block non-compliant devices from corporate mail. For BYOD, use the platform’s supported work profile, managed enrollment, or app-protection controls to separate corporate data. Android work profiles and managed apps on other platforms are different mechanisms. Selective wipe targets managed data; delivery, offline behavior, and copies exported outside managed apps must be considered.

Mobile-specific risks and controls:

• Jailbreaking / rooting removes OS protections; MDM compliance checks can detect some compromised devices and restrict access, depending on platform support and detection effectiveness.
• Sideloading installs apps from outside the official store, bypassing vetting; restrict it by policy.
• Lost or stolen devices: encryption, strong screen lock, remote wipe, and device location services.
• Insecure connections on public Wi-Fi: use VPN or per-app VPN.
• Application control: allow-list approved corporate apps.
• Biometrics, context-aware authentication, and push notifications improve usability; they supplement rather than replace a strong device passcode.

Example 2: BYOD for a consultancy

A 60-person consultancy lets staff read mail on personal phones. A departing consultant is on competitor business-development calls the next week. Disabling the account stops future service access but does not by itself erase downloaded messages. With supported managed profiles or app-protection policies, IT can request removal of managed corporate data while preserving personal apps and photos. Confirm completion: for example, an app-based selective wipe can wait until the app next runs, and exported copies may remain beyond its reach. That privacy-preserving selective wipe is the argument for containerization in BYOD.

5. Wireless security

Wireless security has three parts: encryption protocol, authentication method, and physical deployment.

Encryption and authentication protocols

An ordinary WPA2/WPA3-Personal deployment uses a shared passphrase; per-device or multiple-passphrase vendor features can alter this operational model, but they are not certificate-based 802.1X authentication. Enterprise mode authenticates each user or device individually with IEEE 802.1X: the client (supplicant) talks to the access point or switch (authenticator), which relays to a RADIUS server (authentication server). The EAP method decides what credentials are used:

• EAP-TLS: certificate-based mutual authentication, well suited to managed devices with a PKI. Enforce trusted certification authorities, expected server identities, and appropriate client-certificate lifecycle checks.
• PEAP: a server-authenticated TLS tunnel protects an inner EAP method, commonly password-based. Its security depends on validating the server and on the selected inner method.
• EAP-TTLS: similar tunneled approach.
• EAP-FAST: Cisco method using protected access credentials.

Other wireless controls: captive portals for guest access (a web page that collects acceptance or credentials before granting access); an isolated guest VLAN with internet-only access; MAC filtering (weak, since MAC addresses can be spoofed); disabling WPS (the PIN method is vulnerable to brute force); rogue access point detection using a wireless intrusion prevention system (WIPS); and rotating a shared passphrase when staff leave. A captive portal does not itself encrypt an otherwise open Wi-Fi link.

Installation considerations

• Site survey: measuring signal strength, interference, and coverage before and after installation.
• Heat map: a visual overlay of coverage and dead spots built from the survey.
• Access point placement: central and high, away from interference, with channel planning so neighboring APs do not overlap (for example, 1, 6, and 11 with 20 MHz channels in a compatible 2.4 GHz regulatory domain; follow local rules and survey results).
• Controller-based versus standalone management and power-over-Ethernet cabling.
• Signal leakage: tune power levels so coverage does not extend far outside the building.

Worked example: choosing wireless authentication

Scenario. A law firm with 120 staff has a corporate PKI and Active Directory. Currently the office uses WPA2-Personal with a shared passphrase that has been on a whiteboard for three years. Three former employees still know it. The firm wants individual accountability and automatic revocation when someone leaves. Which design?

Reasoning.

1. A shared passphrase cannot identify individuals and cannot be revoked per user, so changing the passphrase means reconfiguring every device.
2. Enterprise mode with 802.1X moves authentication to RADIUS, which can enforce per-user or per-device policy. For certificate authentication, coordinate account authorization, certificate revocation, reauthentication, and termination of active sessions; disabling an account is not a universal instant disconnect.
3. Because a PKI exists, EAP-TLS with device or user certificates avoids passwords entirely and provides mutual authentication when clients verify the expected server identity and trust chain. Certificate enrollment alone does not prevent a rogue-network connection if validation is disabled.
4. PEAP would also meet the accountability requirement but relies on passwords and on clients validating the server certificate.

Solution. WPA3-Enterprise (or WPA2-Enterprise where hardware demands) with 802.1X, RADIUS, and EAP-TLS. Place guests on a captive-portal VLAN. Why not the alternatives: MAC filtering is trivially spoofed; hiding the SSID is not a security control; simply rotating the shared passphrase repeats the same weakness.

Connect certificate and account lifecycle decisions to provisioning, MFA, and access management.

6. Application security

Applications are attacked through the way they accept and handle input. Objective 4.1 lists the techniques:

• Input validation: check type, length, range, and format of all input on the server, and reject or sanitize unexpected data. Validation enforces business rules but does not replace parameterized SQL or context-aware output encoding for XSS prevention. Validation on the client alone is not security because an attacker can bypass the browser.
• Output encoding and parameterized queries: prevent injected data from being interpreted as code.
• Secure cookies: set the Secure flag (sent only over HTTPS), HttpOnly (not readable by JavaScript, limiting theft through XSS), and SameSite (limits cross-site sending and reduces CSRF).
• Static application security testing (SAST) / static code analysis: examines source code without running it, early in development, to find injection flaws, hard-coded secrets, and unsafe functions.
• Dynamic application security testing (DAST): tests the running application from the outside, finding runtime and configuration issues.
• Code signing: the publisher signs with a private key; verification against a trusted signing identity checks provenance and integrity. A valid signature does not establish that code is harmless or free of vulnerabilities, especially if a signing key or build pipeline is compromised.
• Sandboxing: runs code in an isolated environment with restricted access to files, memory, and the network to limit the impact of untrusted execution. Isolation can have flaws; use a maintained sandbox, controlled networking, and appropriate handling of test data. Browsers, mail gateways, and malware analysis labs use it.
• Allow-listing of applications and libraries, and software composition analysis for open-source dependencies.
• Monitoring and logging of application events for detection.

Example 3: a login form that trusts the browser

A web application limits the "age" field to digits with JavaScript. A tester sends the request directly with a script and submits 5; DROP TABLE users;--. Because the server concatenates the untrusted value into SQL, the payload may alter the query. Its exact effect depends on the query, driver, and database privileges. Fixes: server-side validation of type and range, parameterized queries so the value is never part of the SQL syntax, least-privilege database credentials, and a web application firewall as a compensating layer. SAST may flag the unsafe construction before release; detection depends on language, rules, and data-flow coverage and does not guarantee a clean result.

7. Comparison: choosing the right technique

8. Asset management: hardware, software, and data

Objective 4.2 reminds you that you cannot protect what you do not know you own. The asset life cycle:

1. Acquisition and procurement: buy from approved, vetted suppliers; define security requirements in contracts (supply chain risk); record the purchase.
2. Assignment and accounting: assign each asset an owner and classification, and record it in an inventory or configuration management database (CMDB). Tag hardware with asset numbers.
3. Monitoring and asset tracking: keep the inventory current with automated discovery, enumeration (scanning to list devices, services, and software), and agents; detect unauthorized (shadow IT) devices and unlicensed software.
4. Disposal and decommissioning: remove an asset safely when it leaves service.

Disposal techniques and the data sanitization vocabulary are tested often:

Data retention ties in: keep data only as long as policy and law require, then destroy it. Retention applies to logs, backups, and records alike.

Other 4.2 ideas include software licensing and end-of-life (EOL) and end-of-support (EOS) tracking, because normal security updates can end. Check extended-security support arrangements before concluding that no update path exists. Systems at EOS need a replacement plan or compensating controls such as isolation.

Worked example: decommissioning a server rack

Scenario. A company retires 12 servers with a mix of SSDs and spinning disks that held customer personal data. Some servers will be sold to a refurbisher; failed disks will go to waste. Which actions fit?

Reasoning.

1. Servers being resold need the data removed while the drives remain usable: select a documented method appropriate to media and data sensitivity. Overwriting may support reuse of magnetic disks; for SSDs, use a supported sanitization/erase function or cryptographic erase only when its prerequisites are met. Verify completion and effectiveness rather than trusting a command name.
2. If failed drives cannot complete a verified sanitization process, use appropriate physical destruction; degaussing is limited to suitable magnetic media and does not sanitize SSD flash.
3. Because personal data is involved, the company needs evidence for auditors: asset records updated, a certificate of sanitization or destruction, and chain of custody to the vendor.
4. The inventory entries are marked decommissioned so monitoring does not flag them as missing.

Solution. Apply the verified, media-appropriate method; use destruction where sanitization cannot be established. Keep method and verification records, chain of custody, and inventory updates. A generic “secure erase” label or certificate alone is not assurance. Why not "delete and format"? That leaves recoverable data.

Use vulnerability scanning, logging, and remediation checks to reconcile discovered assets with their actual security state.

9. Common pitfalls

• Treating a baseline as a one-time project instead of a maintained, versioned standard.
• Using MAC filtering or SSID hiding as the primary wireless control.
• Relying on client-side validation.
• Forgetting that degaussing does nothing to SSDs.
• Assuming all BYOD needs full-device MDM: managed app protection can also support selective wipe on supported apps and platforms.
• Confusing EDR (detects and responds on endpoints) with a host firewall (filters traffic) or anti-malware (which can combine signatures with heuristics and behavior detection).
• Treating the asset inventory as an IT-only list; without owners and classifications, nobody is accountable for patching or disposal.

10. Exam tips

• "Consistent configuration across hundreds of systems" points to baselines, golden images, and configuration management.
• "Only approved software runs" means allow-listing.
• "Individual accountability on Wi-Fi" means 802.1X with RADIUS; "certificates on both sides" means EAP-TLS.
• "Selective wipe on a personal phone" means containerization or a managed work profile.
• "Analyze untrusted code safely" means sandbox.
• "Verify the author of software" means code signing.
• "SSD disposal" means cryptographic erase or physical destruction, not degaussing.
• "Find what is on the network" means enumeration or discovery scanning, then reconcile with the inventory.

11. Mini case study

Case. Fabrikam Logistics has 300 employees, a warehouse with handheld scanners, and a head office. Problems found in an audit: (1) head-office laptops were imaged three years ago and differ widely; (2) the warehouse Wi-Fi uses one shared WPA2 passphrase printed on the break-room wall; (3) managers read mail on personal phones with no controls; (4) the customer portal has had two injection findings; (5) a spreadsheet inventory lists only half the scanners, and old scanners were thrown in the bin.

Tasks. Recommend one prioritized fix per finding.

Solution.

1. Define a CIS-based baseline, rebuild the golden image, deploy through Group Policy or UEM, and schedule weekly compliance scans to catch drift. Handle exceptions through change management.
2. Move the warehouse to WPA3 or WPA2 Enterprise with 802.1X and RADIUS (certificates on managed scanners; for devices that cannot do 802.1X, a separate SSID/VLAN with strict firewall rules as a compensating control). Remove the posted passphrase.
3. Enroll phones in MDM with a managed work profile, require PIN and encryption, block jailbroken devices, and enable selective wipe.
4. Add server-side input validation and parameterized queries, run SAST in the build pipeline and DAST before release, and put a WAF in front as a compensating layer.
5. Run discovery and enumeration to build a complete inventory with owners, require sanitization and a certificate for retired scanners, and record decommissioning.

Order of priority: item 4 (internet-facing, known vulnerabilities) and item 2 (shared secret exposure) first, then 3, 1, and 5 as a managed program.

Key terms

• Secure baseline: approved configuration standard for a system type.
• Configuration drift: divergence from the baseline over time.
• Hardening: reducing attack surface by removing or restricting features.
• EDR / XDR: behavioral endpoint detection and response, and its cross-domain extension.
• Allow-listing: default-deny application control.
• MDM / UEM: tools to manage and secure mobile and other endpoints.
• BYOD, COPE, COBO, CYOD: mobile deployment models.
• 802.1X, RADIUS, EAP-TLS: port-based authentication, its authentication server, and certificate-based method.
• WPA3 / SAE: current Wi-Fi protocol and its password-based key exchange.
• Site survey / heat map: measurement and visualization of wireless coverage.
• Input validation: server-side checking of data before use.
• Sandboxing: isolated execution environment.
• Code signing: cryptographic proof of origin and integrity of code.
• Enumeration: listing devices, services, or accounts.
• Cryptographic erase: sanitization by destroying the encryption key.

Summary checklist

• I can describe how to establish, deploy, and maintain a secure baseline and detect drift.
• I can list hardening actions for endpoints, servers, and network devices.
• I can distinguish antivirus, host firewall, HIPS, allow-listing, EDR, and XDR.
• I can compare BYOD, COPE, COBO, and CYOD and explain MDM and containerization.
• I can choose the right wireless authentication and explain site surveys and heat maps.
• I can apply input validation, secure cookies, SAST/DAST, code signing, and sandboxing.
• I can walk an asset from acquisition to disposal and choose a sanitization method.

Sources

• CompTIA Security+ V7 objectives summary (opens in a new tab) — objectives 4.1–4.2.

• CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks (opens in a new tab)

• NIST SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise: https://csrc.nist.gov/pubs/sp/800/124/r2/final (opens in a new tab)

• NIST SP 800-88 Rev. 2: media sanitization (opens in a new tab)

• OWASP Cheat Sheet Series, Input Validation: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html (opens in a new tab)

• Cisco: WPA3 and wireless security implementation (opens in a new tab) — vendor implementation guidance, not the WPA3 specification.

• Microsoft: selective wipe of managed app data (opens in a new tab)

• Microsoft: EAP certificate requirements (opens in a new tab)

• Microsoft: mobile app management and protection FAQ (opens in a new tab)