Computing Resource Security — SY0-701 Study Guide

Secure baselines and hardening targets

Securing a computing resource starts with one hardened configuration and the discipline to keep every device on it, which is the heart of objective 4.1, apply common security techniques to computing resources. CompTIA expresses that discipline as the secure baseline, three ordered verbs that carry a resource from its hardened starting state into ongoing protection (CompTIA Security+ SY0-701 exam objectives^[1]):

Establish, author the hardened configuration: which services are disabled, which settings are mandated, which accounts exist. NIST formalizes this as secure configuration management: a documented baseline configuration plus a process to control and audit changes to it (NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems^[2]).
Deploy, push that exact configuration to every in-scope device so they all start identical (a golden image for workstations/servers, Group Policy Objects (GPOs) in a Windows domain, or an MDM configuration profile, MDM (mobile device management) is the mobile enforcement engine defined in Wireless and mobile device solutions below).
Maintain, detect and correct configuration drift over the device's life. A baseline that is established but never re-checked decays as patches, local exceptions, and new threats accumulate, so SP 800-128 pairs the baseline with continuous monitoring of the configuration. The figure traces this establish → deploy → maintain loop from SP 800-128.

Hardening is per-target, not one checklist

Hardening shrinks the attack surface by disabling unneeded function and constraining what remains. The technique follows the target:

Target	Representative hardening measures	Key constraint
Mobile devices	MDM-enforced encryption, screen lock, app allow/deny list, remote wipe	Mixed ownership; personal data
Workstations	Patch, host firewall, EDR/AV, full-disk encryption, least-privilege accounts, account lockout	User-operated; broad software
Servers	Remove default accounts and unused services/roles, host firewall, restrict admin, patch	High value; many roles
Switches & routers	Disable unused ports, replace Telnet with SSH, secure the management plane, change defaults	Network reachability
Cloud infrastructure	Least-privilege IAM, security groups, disable public access, encryption, logging	Shared responsibility
ICS/SCADA	Network isolation/segmentation, compensating controls, restricted management	Often unpatchable; uptime-critical
Embedded systems & RTOS	Vendor firmware updates where possible, network isolation, disable unused interfaces	Fixed-function; limited update path
IoT devices	Change default credentials, segment onto a dedicated VLAN, firmware updates	Weak default security at scale

The recurring exam trap is applying a workstation-style control to a target that cannot accept it: ICS/SCADA, embedded, and RTOS devices frequently cannot be patched on a normal cycle or run an EDR agent, so the correct answer is usually isolation plus compensating controls (NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security^[3]). Match the measure to what the device can actually support.

The secure-baseline lifecycle: establish the hardened config, deploy it identically, then maintain it by detecting and correcting drift, which loops back to re-establish.

Wireless and mobile device solutions

Wireless design: site surveys and heat maps

Before securing a wireless network you design its physical coverage. A site survey measures real RF conditions in the building (signal strength, interference, and existing networks) and a heat map visualizes that coverage so access points (APs) are placed for adequate signal without excessive overlap, and so rogue APs or interference sources are located. Poor placement is itself a security problem: dead zones drive users onto untrusted networks, and bleed-over past the building lets an attacker associate from the parking lot.

Mobile deployment models and MDM

The deployment model decides ownership, and ownership decides how much the organization may control. The figure groups the three models by owner: the corporate-owned pair share full control, while BYOD stands apart with the lightest touch.

BYOD (bring your own device): the employee owns the device. Control is lowest; the org typically manages only a work container and can perform a selective wipe of corporate data, not a full-device wipe, because the personal data is the employee's.
COPE (corporate-owned, personally enabled): the organization owns the device and permits limited personal use. Control is highest: full MDM enforcement and full-device wipe.
CYOD (choose your own device): the organization owns the device, but the employee selects it from an enterprise-approved list and it runs the required management agent (EMM/MDM). Because the hardware is corporate-owned, control is high. Full MDM enforcement and a full-device wipe, like COPE; CYOD differs from COPE only in that the employee picks the model from the approved set.

Mobile device management (MDM) is the enforcement engine introduced above: it pushes the configuration profile and enforces encryption, passcode/screen-lock, app management (allow/deny lists), and remote lock/wipe. NIST's mobile guidance frames centralized management of these controls as the core of enterprise mobile security (NIST SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise^[4]). Connection methods the policy must govern include cellular, Wi-Fi, Bluetooth, NFC, and USB tethering. Each is an attack surface MDM can restrict.

Wireless security settings

WPA3 is the current Wi-Fi security standard. It replaces WPA2's pre-shared-key (PSK) four-way handshake with SAE (Simultaneous Authentication of Equals), a password-authenticated key exchange that resists the offline dictionary attacks WPA2-PSK was vulnerable to, and adds forward secrecy.
Personal vs Enterprise. WPA3-Personal uses a shared passphrase (via SAE). WPA3-Enterprise authenticates each user individually through 802.1X / EAP to a RADIUS server, so access is per-user and revocable rather than a single passphrase everyone shares.
AAA / RADIUS. In the enterprise mode the AP (authenticator) relays the user's EAP credentials to a RADIUS authentication server. EAP is a framework, not one method. Common variants are EAP-TLS (mutual certificate authentication, strongest) and PEAP (server certificate protecting an inner password method) (Microsoft Learn: Extensible Authentication Protocol (EAP)^[5]). The deep RADIUS-vs-TACACS+ AAA comparison belongs to the access-management subtopics; here RADIUS is simply the back end that makes per-user wireless auth possible.

Mobile deployment models grouped by owner: corporate-owned COPE and CYOD allow full MDM and full-device wipe; employee-owned BYOD gets a work container and selective wipe only.

Application security, sandboxing, and monitoring

Computing resources run software, so objective 4.1 extends the same hardening mindset into the application. The figure groups these techniques by intent: preventive controls that stop a flaw from shipping or running, then the detective layer that watches the running resource.

Application security techniques

Input validation: check that input conforms to expected type, length, format, and range before processing it, preferably with an allow-list (accept known-good) rather than a deny-list. It is the root defense against injection and buffer-overflow classes, where a crafted oversized or malformed input is the attack (NIST glossary: buffer overflow^[6]). Validate on the server side; client-side checks are a usability aid an attacker simply bypasses.
Secure cookies: set session-cookie attributes so tokens cannot leak: Secure (sent only over HTTPS), HttpOnly (unreadable by JavaScript, blunting cross-site scripting theft), and SameSite (restricting cross-site sending, reducing CSRF exposure).
Static code analysis (SAST): examine source code without executing it to find flaws (insecure patterns, tainted data flows) early in development.
Dynamic code analysis (DAST), including fuzzing: run the application and feed it input (including malformed/random input in fuzzing) to surface faults that only appear at runtime. NIST positions automated source-code (static) and dynamic/binary analysis as complementary techniques in secure development (NIST SP 800-218, Secure Software Development Framework (SSDF)^[7]). Static finds issues earlier and cheaper; dynamic catches behavior static analysis cannot see.

Sandboxing

Sandboxing executes untrusted code or files in an isolated environment with restricted access to the host's resources, so that if the code is malicious the damage is contained. It is used both as a development/testing isolation technique and operationally to detonate suspicious files and observe their behavior before trusting them.

Monitoring

The objective closes with monitoring of the computing resource. Hardening and validation are preventive; monitoring is the detective layer that confirms the resource still matches its baseline and surfaces the behavior the earlier controls were meant to stop. (The broader alerting/SIEM tooling is the sibling subtopic Alerting and Monitoring; here monitoring is the final step of securing the individual resource.)

Exam-pattern recognition

"Ensure every workstation deploys in the same hardened state" → establish a secure baseline and deploy via golden image / GPO; drift detection is the maintain step.
"Legacy SCADA/ICS device cannot be patched or run AV" → isolate/segment and apply compensating controls, not schedule a patch or install EDR.
"Employees use personal phones for email; protect corporate data without touching personal data" → BYOD with MDM containerization and selective wipe (full-device wipe is the COPE answer).
"Stop offline dictionary attacks on the Wi-Fi passphrase" → WPA3 (SAE), not WPA2-PSK.
"Give each wireless user individual, revocable credentials" → WPA3-Enterprise with 802.1X/EAP to RADIUS, not a shared PSK.
"Best place AP coverage and find rogue APs" → site survey + heat map.
"Stop SQL injection / XSS at the source" → server-side input validation (allow-list) plus secure cookie attributes (HttpOnly/Secure/SameSite).
"Find flaws without running the app" → static analysis (SAST); "by running it with crafted input" → dynamic analysis / fuzzing (DAST).
"Run an unknown executable safely to watch what it does" → sandbox.

Application-security controls by intent: preventive (analyze without running: SAST, input validation; or run in isolation: DAST/fuzzing, sandboxing) and detective (monitoring).

Mobile deployment model → device ownership → who controls it → typical fit

Deployment model	Device ownership	Organization control	Typical fit / trade-off
BYOD (bring your own device)	Employee owns the device	Lowest, usually limited to a managed work container; selective wipe only	Cheapest for the org; highest privacy/legal friction and weakest control
COPE (corporate-owned, personally enabled)	Organization owns the device	Highest, full MDM, full-device wipe, policy enforcement, with limited personal use allowed	Strong control and full visibility; org pays for hardware
CYOD (choose your own device)	Organization owns (employee picks from an approved list)	High, corporate-managed like COPE, from a vetted hardware set	Balances user choice with corporate ownership/control

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A secure baseline is established, deployed, then maintained

Objective 4.1 frames the secure baseline as three actions, not a one-time document: establish the hardened reference config, deploy it identically to every in-scope device, and maintain it by continuously checking for and correcting configuration drift. The maintain step is the control's backbone: a baseline that is set once and never re-enforced decays into drift, so continuous compliance checking is part of the baseline, not an add-on.

1 question tests this

An organization uses a Python script to compare the configurations of 500 servers against a defined secure baseline every night and report…

Deploy a baseline by golden image, GPO, or MDM profile

Identical, repeatable deployment is what makes a baseline measurable: push it as a golden image for workstations and servers, as Group Policy Objects (GPOs) across a Windows domain, or as an MDM configuration profile for mobile. Every device then boots in the same known-good state, so any later deviation is detectable drift measured against one reference rather than guesswork.

1 question tests this

A security administrator discovers that employees have installed unapproved file-sharing applications on company-issued mobile devices.…

Hardening removes reachable function and is target-specific

Hardening shrinks the attack surface by disabling unneeded services and ports and constraining what remains, but there is no universal checklist, because the right technique follows the target (workstation vs switch vs server vs cloud vs ICS). The exam rewards matching the measure to the device's constraints; a generic "just harden it" answer ignores that an ICS controller and a workstation accept entirely different controls.

Harden ICS/SCADA, embedded, and RTOS by isolation, not patching

Operational-technology targets (ICS/SCADA, embedded systems, RTOS) often run for 20+ years on vendor-unsupported software that cannot be patched on a normal cycle, and anti-malware frequently isn't available for PLCs/DCS, so AV/EDR requirements can't be met on those endpoints. The correct hardening is network segmentation/isolation plus compensating controls (e.g., a deep-packet-inspection firewall, Purdue-model zones), because the device can't defend itself.

Trap Applying a workstation playbook to a PLC: "schedule the patch" or "install antivirus" on a SCADA device that supports neither.

5 questions test this

IoT hardening: change defaults and segment onto its own VLAN

IoT devices ship with weak default security at scale, so core hardening is replacing default credentials, applying firmware updates where the vendor offers them, and placing the device on a dedicated/segmented VLAN. Segmentation is the load-bearing control: a compromised sensor confined to its own VLAN cannot pivot into the production network even when it can't otherwise be secured.

Trap Leaning on firmware updates as the primary IoT control, when many IoT devices never receive patches and segmenting them onto their own VLAN is what actually contains a compromise.

Switch/router hardening locks down the management plane

Network-device hardening disables unused ports, replaces Telnet with SSH so management traffic is encrypted rather than plaintext, changes default credentials, and restricts who can reach the management plane (e.g., dedicated management network/ACLs). The goal is to remove cleartext administration and cut the number of reachable interfaces an attacker can probe.

Trap Keeping Telnet for management because it is on an "internal" network, when Telnet still ships credentials in cleartext that anyone sniffing the segment can read.

Site survey plus heat map place APs and expose rogues

Securing Wi-Fi starts with measuring the RF environment: a site survey captures real signal strength, interference, and neighboring networks, and a heat map visualizes coverage so access points land where signal is adequate and where rogue APs or interference appear. Coverage that bleeds past the building wall is itself an exposure, letting an outsider reach the SSID from the parking lot.

Trap Treating excess Wi-Fi coverage as purely a performance concern, when signal bleeding into the parking lot is an attack surface, not just wasted range.

The mobile deployment model sets the control ceiling

The deployment model fixes device ownership, and ownership caps how much the organization may control. BYOD = employee-owned personal device, lowest control (corporate work container, selective wipe only). CYOD = corporate-owned but chosen by the employee from an enterprise-approved list and required to run the management agent; company ownership allows high control (full MDM, full-device wipe), like COPE. COPE = corporate-owned, personally enabled, highest control (full MDM, full-device wipe). Ownership, not who picked the device, is what decides the ceiling.

Trap Calling CYOD employee-owned because the user picks the model: the company buys and owns the device, so it allows a full-device wipe like COPE, unlike employee-owned BYOD.

3 questions test this

Wipe granularity follows ownership: BYOD (employee-owned) gets a selective wipe; corporate-owned (CYOD/COPE) get a full wipe

Wipe granularity follows ownership. On the employee-owned BYOD device the organization may only selectively/enterprise-wipe the corporate container; it cannot erase the employee's personal data. On corporate-owned devices (CYOD and COPE) it may perform a full-device wipe of the entire user partition. "Remove company data without touching personal files" → BYOD + selective wipe.

Trap Treating CYOD like BYOD: CYOD is corporate-owned (like COPE), so a full-device wipe is allowed. Only on employee-owned BYOD does a full wipe wrongly destroy the employee's personal data.

4 questions test this

MDM is the engine that enforces mobile policy

Mobile device management (MDM), part of an EMM/UEM suite, pushes the configuration profile and enforces device encryption, passcode/screen-lock timeout, application allow/deny lists (allowlist preferred), and remote lock/wipe. It is the mechanism that turns the deployment-model policy into settings actually applied on the device, rather than a policy that only exists on paper.

5 questions test this

MDM treats each mobile connection method as attack surface

A mobile device's connection methods (cellular, Wi-Fi, Bluetooth, NFC, and USB tethering) are each a reachable attack surface, and MDM policy can disable or restrict any of them. Turning off unused radios and interfaces is part of mobile hardening: a disabled Bluetooth or NFC stack is one fewer wireless entry point to exploit.

WPA3 uses SAE to defeat offline PSK dictionary attacks

WPA3-Personal replaces WPA2's pre-shared-key four-way handshake with SAE (Simultaneous Authentication of Equals), a password-authenticated key exchange (the Dragonfly handshake, RFC 7664) that is resistant to offline dictionary attack: an attacker who captures the exchange cannot brute-force the passphrase offline, because any advantage requires live interaction with a participant. WPA3 also adds forward secrecy. "Stop offline cracking of the Wi-Fi passphrase" → WPA3/SAE, not WPA2-PSK.

Trap Picking WPA2-PSK with a longer passphrase: a captured WPA2 handshake still cracks offline; only SAE removes that offline path.

1 question tests this

A security administrator upgrades a corporate wireless network from WPA2-Personal to WPA3-Personal. Which security improvement provided by…

WPA3-Enterprise authenticates each user via 802.1X/EAP to RADIUS

WPA3-Personal shares one SAE passphrase among everyone; WPA3-Enterprise authenticates each user individually through 802.1X/EAP to a RADIUS (AAA) server, so credentials are per-user and revocable instead of one secret the whole office holds. "Give each wireless user individual, revocable credentials" → WPA3-Enterprise + 802.1X/RADIUS, revoking one user never forces a network-wide passphrase change.

Trap Choosing WPA3-Personal for an office that needs per-user revocation, when its single shared SAE passphrase forces a network-wide change every time one person leaves.

Input validation is the first-line defense against injection and overflow

Input validation checks input for expected type, length, format, and range before it is processed, preferably with an allow-list (accept known-good) rather than a deny-list that is full of bypassable loopholes. It is the foundational defense against injection and buffer-overflow classes, where crafted oversized or malformed input is the attack, paired with parameterized queries for SQLi specifically. Validate server-side: client-side checks are a usability aid an attacker simply bypasses.

Trap Relying on client-side (JavaScript) validation as the security control: an attacker hits the API directly and skips the browser entirely.

2 questions test this

Secure session cookies: Secure, HttpOnly, SameSite

Session cookies are hardened with three attributes: Secure (sent only over HTTPS, never plaintext HTTP), HttpOnly (unreadable by JavaScript/document.cookie, which blunts XSS token theft), and SameSite (limits whether the cookie rides cross-site requests, reducing CSRF exposure). Together they keep the session token off cleartext channels and out of reach of injected scripts and forged cross-site requests.

Trap Assuming the Secure flag stops script theft of the cookie, when Secure only forces HTTPS and HttpOnly is what hides the token from JavaScript.

Sandboxing isolates untrusted code from the host

Sandboxing runs untrusted code or files in an isolated environment with restricted access to host resources, so a malicious payload executes but stays contained. It is the standard way to detonate a suspicious file and observe its behavior before trusting it. "Run an unknown executable safely to watch what it does" → sandbox, not the production host.

2 questions test this

Monitoring is the detective backstop after preventive hardening

Hardening, input validation, and sandboxing are preventive; monitoring the computing resource is the detective layer that confirms it still matches its baseline and surfaces the behavior earlier controls were meant to block but might have missed. It closes objective 4.1's resource-security loop: prevention narrows the openings, monitoring catches what slips through.

Trap Classing monitoring as a preventive control, when it is detective, catching what slipped past hardening rather than blocking it up front.

Cloud-infrastructure hardening = least privilege plus no public exposure

Hardening cloud infrastructure centers on least-privilege IAM, tight security groups, disabling public access to storage and endpoints, encryption, and logging. Under shared responsibility the provider secures the underlying platform, but the customer owns hardening their own identity, network exposure, and resource configuration: a world-readable storage bucket is the customer's misconfiguration, not the provider's.

Trap Assuming the cloud provider hardens your resources: public buckets, over-broad IAM, and open security groups are the customer's side of shared responsibility.

MDM geofencing applies policy by device location

Geofencing uses GPS or network location to draw a virtual perimeter around a place, and an MDM automatically tightens or relaxes policy when a managed device crosses that boundary. It is the capability used to suspend sensitive apps, lock the work container, or disable the camera when a device leaves an approved facility: location becomes a policy condition rather than relying on the user to comply.

Trap Confusing geofencing with geotagging, when geofencing enforces policy across a location boundary while geotagging only stamps location metadata onto a file.

5 questions test this

Containerization and MAM isolate corporate data on personal devices

On employee-owned devices, containerization carves out an encrypted, isolated workspace that separates corporate apps and data from personal content and enables a selective wipe of only the corporate container. Mobile application management (MAM) applies the same app-level data-protection and DLP controls without enrolling the whole device, which sidesteps employees' privacy concerns about IT seeing their personal device, the common adoption blocker for BYOD.

Trap Choosing full-device MDM enrollment for a privacy-sensitive BYOD fleet, when MAM protects corporate apps without enrolling the whole personal device.

9 questions test this

Secure baselines and hardening targets

Hardening is per-target, not one checklist

Wireless and mobile device solutions

Wireless design: site surveys and heat maps

Mobile deployment models and MDM

Wireless security settings

Application security, sandboxing, and monitoring

Application security techniques

Sandboxing

Monitoring

Exam-pattern recognition

Mobile deployment model → device ownership → who controls it → typical fit

Decision tree

Cheat sheet

References