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

A Trusted Platform Module is a dedicated hardware chip that securely stores cryptographic keys and provides a hardware-based root of trust, which underpins capabilities like Secure Boot by giving the system a tamper-resistant foundation for verifying its own integrity. A port blocker instead physically prevents unauthorized device connections to physical ports, which is a related but distinct hardware security control from the cryptographic root-of-trust function a TPM provides. Devices equipped with a TPM offer significantly stronger integrity assurance than relying purely on software-based checks, since the TPM's hardware isolation makes it much harder for malware to tamper with the stored keys or trust verification process.

Chain of custody documents evidence handling at every step, from initial collection through storage and analysis, ensuring the evidence remains admissible and its integrity cannot be credibly questioned later, whether for internal investigation purposes or potential legal proceedings. Breaking the chain of custody, even briefly or through a simple documentation gap, can undermine confidence in evidence that might otherwise have been perfectly valid, which is why this process is treated with such strict procedural rigor. Maintaining proper chain of custody is especially important in OT incidents that might involve regulatory investigation or law enforcement involvement, where evidentiary standards can be particularly demanding.

Leveraging understanding of high-value assets identifies which specific systems are most critical to safety and production ahead of time, so that if multiple systems are affected simultaneously during an incident, response efforts can be prioritized toward what matters most rather than treated as equally urgent. This proactive understanding is a distinct preparedness activity from drafting the incident response plan document itself, though the two clearly inform and support each other. Without this kind of pre-established prioritization, a team facing a wide-ranging incident risks spreading response effort too thinly across systems of very different actual criticality.

Mutual aid describes receiving assistance from peer organizations, often coordinated through mechanisms like an ISAC, which can provide valuable additional expertise and resources during a major incident that exceeds a single organization's own internal capacity. This differs from escalation and notification, which instead addresses internally and externally reporting an incident's status, rather than actively receiving hands-on assistance from peers. Established mutual aid relationships, built before an incident occurs rather than improvised during one, can significantly improve an organization's ability to respond effectively to a major incident affecting critical infrastructure.

The lessons learned phase of the PICERL model formally documents what worked well, what did not, and what changes should be made to prevent recurrence, occurring after the incident has already been fully resolved and systems restored. This differs from the earlier identify phase, which instead focuses on recognizing that an incident is occurring in the first place, well before the incident has been resolved. Treating lessons learned as a formal, required phase, rather than an optional afterthought, helps ensure an organization actually improves its posture based on real incident experience rather than repeating the same mistakes in a future incident.

Obsolescence tracks whether a device is no longer receiving vendor support or security updates, which is a critical asset attribute for planning eventual replacement and for understanding which devices may require additional compensating controls since they can no longer be patched through normal vendor channels. Physical location and function instead describe where a device sits and what role it performs, which are useful attributes but do not by themselves indicate anything about the device's ongoing vendor support status. Tracking obsolescence proactively, rather than only discovering it when a critical vulnerability affecting that device is disclosed, supports better long-term OT security planning.

Dedicated devices, used exclusively for connecting to OT systems and never for general-purpose activities like web browsing or personal email, significantly reduce the chance a device has already been exposed to malware before it ever connects to sensitive OT equipment. This differs from sanitization, which instead refers to securely wiping data from a device or media, rather than restricting what activities a device is used for in the first place. Enforcing dedicated-use policies for OT-connecting devices is a practical and effective way to shrink the attack surface a technician's own device could introduce into a sensitive environment.

Derived detection infers likely vulnerabilities based on known device and software version information, without directly scanning or querying the device itself, which avoids the risk of disrupting sensitive control system operations that direct active scanning could pose. Active detection instead directly queries or scans a device, providing more certain results but carrying a higher risk of disruption, which is exactly what derived detection is designed to avoid for particularly sensitive devices. Choosing derived detection for the most sensitive, disruption-intolerant devices, while still using active or passive methods elsewhere, reflects a risk-aware approach to vulnerability identification across a mixed OT environment.

Availability specifically checks whether a patch actually exists and is provided by the vendor for that particular device, since many legacy OT devices may never receive a patch for a given vulnerability at all. Dependency checking instead verifies that applying the patch will not break some other critical function or integration the device relies on, which is a common and serious concern in OT environments where devices often have narrow, carefully validated configurations. Both considerations, along with applicability and viability, must be weighed together before committing to a patch remediation approach, rather than assuming a patch is automatically safe simply because it exists.

Threat hunting proactively searches through historical logs and network data for subtle signs of compromise that automated detection did not catch, reflecting an assumption that some threats may already be present without having triggered any existing alert. This differs from simply reviewing and responding to automated alerts as they fire, since threat hunting deliberately looks for what automated tools might have missed entirely. Regularly conducting threat hunts, informed by current threat intelligence about likely adversary techniques, helps catch sophisticated or patient adversaries that are specifically designed to evade standard automated detection.

Active discovery sends controlled queries directly to devices to confirm identity and software version, providing more detailed and current information than passive observation alone, though it accepts some added risk of potentially disrupting sensitive devices compared to purely passive methods. Manual discovery instead relies on human-driven inventory efforts, such as physically walking a facility and recording devices by hand, which is a different, typically slower approach than automated active querying. Choosing when active discovery's added risk is acceptable, versus when passive or manual methods are safer, depends heavily on the specific criticality and known sensitivity of the devices being inventoried.

Certificate-based NAC verifies a device's identity using a digital certificate issued by a trusted certificate authority, providing stronger assurance than MAC-based NAC, which relies on a MAC address that can be relatively easily spoofed by an attacker. Token-based NAC instead relies on a physical or software token for verification, which is a different mechanism still from certificate-based cryptographic identity verification. Choosing certificate-based NAC over simpler MAC-based approaches reflects a meaningful security improvement for network access control in environments where device identity assurance genuinely matters.

A data diode, or unidirectional gateway, physically enforces one-way data flow at the hardware level, guaranteeing that no traffic can flow back into the OT network regardless of any software misconfiguration, since the physical hardware itself simply lacks the capability to transmit in the reverse direction. A standard firewall rule, by contrast, is a software-based, logical control that could in principle be misconfigured or bypassed, providing a fundamentally weaker guarantee than a data diode's physical one-way enforcement. This kind of strict one-way data flow requirement is common in OT environments that need to share data outward with business systems while maintaining the strongest possible protection against any reverse path back into sensitive control systems.

Industrial ratings certify that equipment is appropriately designed and tested for specific hazardous conditions, such as environments containing flammable vapors, ensuring the equipment itself cannot serve as an ignition source in that setting. A JSA instead analyzes the broader hazards of a specific job task, which is a valuable planning tool but does not itself certify equipment for use in a hazardous environment. Selecting correctly rated equipment for the specific hazard present, rather than relying on general-purpose equipment, is a foundational physical safety practice in OT environments handling flammable or explosive materials.

A spectrum analyzer detects wireless transmissions across a range of frequencies, which can reveal unauthorized wireless devices or transmissions near a sensitive area that standard video cameras or motion detectors would never identify, since those tools only observe physical movement or visual activity. Video surveillance and motion detection instead address visual and physical movement monitoring, which is a different and complementary security layer from detecting unauthorized radio frequency activity. Using a spectrum analyzer during a physical security walkdown of a sensitive facility can help uncover a hidden rogue wireless device that might otherwise go completely undetected by conventional physical security measures.

Least privilege and functionality grants an account or system only the specific permissions and functions it genuinely needs, disabling or removing everything else, which minimizes the potential damage if that account or system is ever compromised. Compartmentalization instead isolates components from each other structurally, which is a related but distinct architectural principle from restricting what a single account or system is actually permitted to do. Applying least privilege and functionality consistently across OT accounts and systems significantly reduces the attack surface available to an adversary who manages to compromise any single credential or device.

Third-party vendor remote access represents a threat vector that should be tightly controlled and monitored, since an external party's own security posture is generally less visible and controllable than an internal user's. Internal user remote access also represents a genuine threat vector, even for a trusted employee, since a compromised home network or stolen credential could still be used to reach sensitive OT systems remotely. Assuming internal access carries zero risk simply because the user is a trusted employee overlooks the very real possibility of credential compromise or an insider threat, which is exactly why both categories are explicitly recognized as distinct remote access threat vectors.

Industroyer was specifically designed to interact directly with electrical grid protocols to manipulate circuit breakers, representing a direct-impact attack targeting power grid infrastructure specifically, similar in category to other direct-impact events like Stuxnet and TRISIS. SolarWinds and Maersk instead are commonly cited as indirect-impact events, where a broader IT compromise caused significant operational disruption without the malware itself being specifically engineered to manipulate industrial protocols the way Industroyer was. Recognizing which historical events represent genuinely direct OT-targeting malware, versus broader IT compromises with indirect OT consequences, helps illustrate the range of sophistication and intent across different real-world OT-relevant incidents.

The intelligence life cycle structures threat intelligence work into a repeating process of planning, collection, processing, analysis, dissemination, and feedback, providing an overarching operational framework for how a threat intelligence function actually runs day to day. The Diamond Model instead analyzes the structure of a specific individual intrusion event, which is a different, more narrowly scoped application than the intelligence life cycle's broader operational process. Following a structured intelligence life cycle helps ensure a threat intelligence program produces genuinely useful, actionable output rather than simply collecting data without a clear process for turning it into disseminated intelligence.

Applicability evaluates whether a proposed change actually applies to the specific system in question, avoiding wasted effort implementing a change that does not genuinely address that system's actual configuration or vulnerabilities. Availability instead evaluates whether the change can actually be implemented within existing operational constraints, such as an established maintenance window, without unacceptably disrupting production. Evaluating both factors during change determination, before moving on to testing and approval, helps filter out changes that are either irrelevant or operationally infeasible before investing further effort in them.

ISA/IEC guidance is jointly developed by the International Society of Automation and the International Electrotechnical Commission, specifically tailored to industrial automation and control systems, making it particularly well suited to OT-specific risk assessment compared to more general-purpose frameworks. NIST also publishes widely used risk management guidance, but the ISA/IEC framework is specifically called out as tailored to the industrial automation and control systems context this scenario describes. Choosing an OT-specific framework like ISA/IEC over a purely general-purpose IT risk framework helps ensure the assessment properly accounts for the unique operational and safety considerations present in industrial environments.

Stakeholder management identifies which executives and other parties need to be regularly briefed and engaged on program status, ensuring the right people stay informed and supportive of the security program's direction. The RACI model instead provides a specific structured framework, Responsible, Accountable, Consulted, Informed, for documenting exactly who holds which type of responsibility for specific decisions, which is a more precise accountability tool than general stakeholder management alone. Both elements support effective program governance, but they serve different purposes: one manages ongoing relationships and communication, and the other precisely defines decision-making accountability.

Reputational impact specifically addresses damage to an organization's public standing and trust, which is a distinct consideration from the direct financial cost of an incident, even though the two can certainly be related. Financial impact instead addresses direct monetary costs, and operational impact addresses disruption to the organization's ability to function, both of which are separate business impact categories from reputation specifically. Considering all of these distinct impact categories together during risk assessment provides a more complete picture of an incident's true business cost than focusing on financial impact alone.

Modbus TCP adapts the widely used Modbus protocol, originally designed for serial communication, to run over Ethernet networks using TCP, making it one of the most common industrial protocols found on modern OT Ethernet networks. Because Modbus was designed decades ago with no built-in authentication or encryption, Modbus TCP traffic on an OT network represents a protocol that security monitoring tools need to specifically understand and inspect, since a generic network security tool may not parse its industrial-specific structure. Recognizing Modbus TCP traffic on a network is often one of the first signs that OT-aware monitoring tools, rather than purely IT-focused tools, are needed for adequate visibility.

An intelligent electronic device combines measurement capability with embedded processing and digital communication, allowing it to make protection decisions, such as tripping a breaker, directly rather than simply relaying raw measurements elsewhere for a decision. A remote terminal unit instead primarily gathers field data and relays it to a central SCADA system, which is a related but distinct role from an IED's embedded decision-making capability. Recognizing that IEDs can make autonomous protective decisions is important context for understanding both their operational value and the potential consequences if one were compromised.