CompTIA SecOT + SOT-001 (V1) Exam Practice Test 5

Hardened physical interfaces, using port blockers or port lockers, physically prevent unauthorized devices from being connected to unused ports without a specific removal key, directly addressing a common and historically significant OT threat vector involving removable media and rogue device connections. Drive encryption instead protects data at rest if a drive is removed, which is a different protection goal from physically preventing a port connection in the first place. Physically hardening unused ports is a simple, low-cost control that can meaningfully reduce the risk of an unauthorized device connection, particularly in physically accessible OT environments where unauthorized personnel access cannot always be perfectly prevented.

Looking for a deviation from baseline compares current system documentation and behavior against previously established normal operating parameters, which is exactly why maintaining an accurate baseline in the first place, as part of ongoing security operations, pays off so directly during incident investigation. Without a well-established baseline to compare against, analysts would have a much harder time distinguishing a genuinely meaningful deviation from ordinary variation that might simply reflect normal operational changes over time. This is the same underlying baselining concept used proactively in network security monitoring, now applied retrospectively during an actual incident investigation to help pinpoint exactly when and how a compromise may have begun affecting the system.

A playbook documents step-by-step response procedures for a specific incident scenario, such as ransomware, providing responders with a structured, scenario-specific guide during a high-pressure security event. A runbook instead typically documents step-by-step procedures for routine operational tasks, which may or may not be related to security incidents at all, making it a broader operational documentation tool rather than one specifically focused on incident response. Maintaining both playbooks for likely incident scenarios and runbooks for routine tasks ensures responders and operators alike have clear, pre-established guidance rather than needing to improvise procedures under pressure.

Coordination with facilities personnel, including operations, engineering, and maintenance, reflects the reality that a major OT incident's response effort typically cannot be handled by cybersecurity staff alone, since restoring and validating the actual physical process requires deep involvement from the people who understand that specific facility's equipment and operations. This differs from mutual aid, which instead addresses assistance from external peer organizations, rather than coordination with internal facility personnel at the affected site itself. Recognizing upfront that facilities personnel are essential incident response participants, not just cybersecurity staff, helps ensure the response plan actually accounts for how physical operations recovery will be coordinated alongside the cybersecurity response.

The identify phase of the PICERL model involves investigating unusual behavior to determine whether it actually represents a genuine security incident or a benign anomaly, occurring after the earlier prepare phase but before any containment action is taken. Prepare instead addresses readiness activities completed before any specific incident occurs, such as drafting response plans and conducting exercises, which is a distinct earlier phase from actively investigating a specific suspicious observation. Correctly identifying a genuine incident, rather than either dismissing a real threat as benign or overreacting to a false alarm, is a critical judgment call that shapes everything that follows in the response process.

Physical location attributes, including specific site and panel information, support faster response during an incident by allowing responders to quickly locate a specific device physically, rather than only knowing it exists somewhere within a large facility or across multiple sites. Vendor and function attributes instead describe who made the device and what role it performs, which are useful but do not by themselves help a responder physically find the device during a time-sensitive incident. Maintaining detailed physical location attributes as part of routine asset inventory work pays off specifically during high-pressure incident response, when time spent searching for a physical device can meaningfully extend overall incident duration.

Mobile devices in an OT security context extend beyond just phones and tablets to include specialized equipment like calibration tools, which connect to OT systems just as a laptop would and therefore require the same kind of security consideration, such as authentication and posture validation, before being allowed to connect. Overlooking specialized equipment like calibration tools simply because it does not look like a typical mobile device risks leaving a genuine connection point without appropriate security controls. Recognizing the full breadth of what counts as a mobile device in an OT environment, rather than narrowly focusing only on phones and tablets, supports a more complete mobile device security program.

An SBOM provides visibility into embedded components that might not otherwise be apparent from a vendor's product name alone, since a single application can bundle numerous open-source libraries a customer would have no way of knowing about without this kind of disclosure. This visibility directly helps the team quickly determine whether a newly disclosed vulnerability in a specific embedded component actually affects their deployed systems, rather than needing to guess or wait for the vendor to separately confirm applicability. Without an SBOM, a vulnerability buried within an embedded component is often far from obvious, since it would not appear anywhere in the vendor's own marketed product description or version number.

Scheduling planned downtime coordinates exactly when a production line will be taken offline for a required patch, aligning the disruption with an already-planned maintenance window rather than during active production hours, which minimizes the operational impact of an otherwise necessary security remediation. This differs from testing, which instead validates the patch itself works correctly, and from rollback plan availability, which ensures a recovery path exists if the patch causes a problem, both of which are related but distinct remediation coordination elements. Proactively scheduling downtime around existing maintenance windows, rather than treating every patch as requiring its own separate unplanned outage, reflects mature coordination between security and operations teams.

Security management system tuning adjusts detection rules, such as IDS or firewall rules, to reduce excessive low-value alert noise while still catching genuinely suspicious activity, which is an ongoing operational necessity since poorly tuned detection systems can bury genuinely important alerts under a flood of low-value ones. This differs from initially creating an asset inventory, which is a foundational activity that happens earlier and separately from ongoing detection rule tuning. Neglecting to regularly tune detection systems risks a security team becoming desensitized to alerts entirely, potentially causing a genuinely critical alert to be overlooked simply because it is buried among too many low-value ones.

A collection management framework defines a structured approach for deciding what data actually needs to be collected, from where, and how often, ensuring collection efforts are deliberately prioritized rather than ad hoc and potentially missing critical sources or wasting effort on low-value ones. A CMDB instead stores the actual configuration and relationship data once collected, which is a related but distinct concept from the framework that governs collection priorities in the first place. Establishing a deliberate collection management framework helps ensure limited collection and analysis resources are focused on the asset and threat data sources that actually matter most for the organization's specific risk profile.

Baselining establishes what normal traffic patterns look like for a specific network segment, providing the reference point needed to recognize future deviations as potentially suspicious, which is especially valuable in OT environments where traffic patterns are often far more predictable and stable than in typical IT networks. This predictability actually makes baselining a particularly powerful OT security monitoring technique, since even a subtle deviation from an established, highly stable pattern can be a meaningful signal of a problem. DNS security and out-of-band management instead address different specific monitoring and management concerns, which are related but distinct from the broader practice of establishing and monitoring against a traffic baseline.

Endpoint privilege management tightly controls which specific elevated actions are permitted, ensuring even a compromised standard user account cannot simply escalate to full administrative privileges, which significantly limits what an attacker could accomplish even after successfully compromising a lower-privileged account. An EPP instead focuses on preventing and detecting malware broadly, which is a different, though complementary, endpoint protection function from specifically controlling privilege escalation. Layering EPM alongside EDR and EPP provides a more comprehensive endpoint security posture than relying on any single one of these capabilities alone.

A job safety analysis documents the steps of a specific task, identifies potential hazards at each individual step, and defines the precautions needed to address each hazard, providing a structured, task-specific safety planning tool. A safety outbrief instead occurs after a task or shift is complete, reviewing what happened, which is a different point in the safety process than the proactive planning a JSA provides beforehand. Conducting a thorough JSA before beginning an unfamiliar or hazardous task helps surface risks that might not be obvious without this kind of deliberate, structured review.

Combining a proximity card reader with fingerprint biometric verification provides layered physical access control, requiring both something the person possesses, the card, and something inherent to them, their fingerprint, which is significantly harder for an unauthorized person to defeat than either single factor alone. This layered approach does not eliminate the value of surveillance as an additional, complementary physical security layer, since access control and surveillance address somewhat different aspects of physical security. Whether this specific combination satisfies a particular regulatory requirement depends on the specific regulation in question, rather than being an automatic guarantee simply because two factors are being used.

Auditability ensures a system logs configuration changes and access attempts in a way that allows later reconstruction of exactly what happened and who was responsible, which is essential both for security investigations and for demonstrating compliance with governance and regulatory requirements. Simplicity and performance instead address different architectural priorities, namely ease of understanding and operational speed, which are related but distinct concerns from the ability to reconstruct historical activity after the fact. Designing for auditability from the outset, rather than trying to add comprehensive logging after an incident has already occurred, ensures the necessary historical record actually exists when it is needed most.

STIX, Structured Threat Information Expression, provides a standardized format for expressing threat information, including indicators, threat actors, and attack patterns, consistently between different tools and organizations, which enables automated sharing and processing of threat intelligence rather than relying on unstructured text reports alone. This standardization is especially valuable when sharing threat intelligence across organizational boundaries, such as through an ISAC, since a consistent format allows recipient organizations to automatically ingest and act on shared intelligence rather than manually reformatting it. Recognizing STIX as a specific structured format, distinct from a general-purpose file type like YARA rules used for malware detection signatures, helps clarify what role each format actually plays in a threat intelligence workflow.

BlackEnergy 2 and BlackEnergy 3 were specifically used in coordinated attacks against a national power grid, directly causing widespread electricity outages for civilian populations, representing a landmark direct-impact demonstration of a cyberattack's ability to cause real-world physical consequences at national scale. Colonial Pipeline instead is typically cited as an indirect-impact event, where IT compromise led to a precautionary operational shutdown rather than the malware itself directly manipulating grid equipment. Recognizing BlackEnergy as a direct grid-targeting attack helps illustrate the genuine, demonstrated real-world stakes that justify the level of security attention critical infrastructure sectors like power generation receive.

Imagery intelligence derives insight from visual imagery, such as satellite photographs, which is exactly what is being used here to assess a facility's physical security measures from an external visual perspective. Signals intelligence instead involves intercepting electronic communications, and human intelligence relies on interpersonal sources, both of which are fundamentally different collection methods from analyzing visual imagery. Combining imagery intelligence with other intelligence types, such as OSINT, can provide a more complete threat assessment picture than relying on any single intelligence type alone.

Transferring a risk shifts the financial or operational consequence to a third party, such as through an insurance policy, which matches exactly the scenario of purchasing insurance to cover potential losses from a residual risk. Mitigating instead would involve additional technical controls to reduce the risk's probability or impact directly, which the team explicitly decided not to pursue further in this scenario. Avoiding the risk would mean eliminating the underlying activity or exposure entirely, which is a different and often more disruptive disposition option than simply transferring the financial consequence through insurance.

Scenario-based risk assessment develops a specific narrative describing how an attack might unfold step by step against a particular system, helping stakeholders understand risk in a concrete, relatable way rather than through abstract numerical scores alone. Failure mode and criticality analysis instead examines how a specific component's failure would cascade through the broader process, which is a more engineering-oriented method focused on physical and operational failure propagation rather than adversary behavior specifically. Both methods provide valuable, complementary perspectives on risk, one focused on adversary-driven scenarios and the other on component failure consequences, regardless of whether that failure was caused by an attack or an ordinary equipment fault.

Training and awareness regularly educates personnel, such as control engineers, on recognizing threats like phishing and understanding safe practices for their specific operational context, building a more security-conscious workforce as a complement to technical controls. A risk registry instead tracks specific identified risks, and metrics and measures track quantitative program performance indicators, both of which are distinct program management elements from ongoing personnel education. Investing in OT-specific training and awareness, rather than generic IT security training alone, helps address threat vectors like social engineering that specifically target OT personnel's unique operational context.

Balancing security versus operations reflects exactly this kind of tradeoff, weighing a security control's risk reduction benefit against its potential impact on time-sensitive physical operations, which is a governance consideration especially prominent in OT environments where operational and safety priorities can directly conflict with a security measure's overhead. This differs from a purely compliance-driven decision, since balancing security and operations often involves genuine judgment calls beyond simply satisfying a specific regulatory requirement. Explicitly recognizing and documenting this balancing consideration, rather than treating security recommendations as automatically overriding operational concerns, reflects a mature governance approach to OT risk decisions.

OPC UA, Open Platform Communications Unified Architecture, provides a secure, platform-independent standard for different vendors' systems to exchange data, representing an evolution from the earlier OPC DA standard, which lacked the same built-in security capabilities. This improvement reflects a broader industry trend toward building security into industrial protocols from the ground up, rather than relying entirely on external network controls to compensate for protocols that were never designed with security in mind. Recognizing whether an OT environment uses the older, less secure OPC DA or the newer OPC UA standard is directly relevant to assessing that environment's inherent protocol-level security posture.

Critical infrastructure sectors specifically categorize industries like water treatment, energy, and transportation whose disruption would have a severe impact on public safety and the economy, which is why these sectors typically receive heightened regulatory attention and security expectations compared to less critical industries. This categorization helps explain why certain OT environments, such as those in power generation or water utilities, often face specific, sector-tailored regulatory requirements that a less critical industry might not encounter. Understanding which critical infrastructure sector a given OT environment belongs to provides important context for anticipating its specific regulatory and threat landscape.