Free CompTIA CAS-005 Practice Questions 2026 - Page 7

Explanation:
Homomorphic encryption (HE) is a revolutionary form of encryption that allows computations to be performed directly on encrypted data without needing to decrypt it first. The primary barrier to its widespread adoption is performance.

Computational Overhead:
Homomorphic encryption operations are incredibly computationally intensive, often orders of magnitude slower than performing the same operations on unencrypted data. This massive performance hit makes it impractical for most real-time applications.

The Role of Coprocessors:
To overcome this performance barrier, specialized hardware is required. Coprocessors (like GPUs, FPGAs, or ASICs specifically designed for cryptographic operations) can accelerate these calculations by providing the massive parallel processing power needed. The current lack of widespread, standardized, and cost-effective hardware support for these intensive operations is a fundamental challenge to adoption. Without this specialized hardware, HE remains too slow for most practical, large-scale uses.

Analysis of Incorrect Options:

A. Incomplete mathematical primitives:
The core mathematical theories for homomorphic encryption (e.g., Fully Homomorphic Encryption schemes like BGV, BFV, CKKS) are well-established and proven. The challenge is not that the math is incomplete, but that implementing it efficiently is extremely difficult.

B. No use cases to drive adoption:
This is incorrect. There are numerous compelling use cases that drive adoption, such as:

Secure Cloud Computing:
Process sensitive data in the cloud without the cloud provider ever seeing the decrypted dat

Private Data Analysis:
Enable researchers to analyze encrypted medical or financial records without violating privacy.

Secure Outsourcing:
Allow companies to outsource data processing without giving the processor access to the raw data.

The demand for these use cases is high; the technology's performance is the limiting factor.

C. Quantum computers not yet capable:
This is a distractor. Homomorphic encryption is a classical computing technique. Its purpose is to provide security in a classical computing environment. It is actually seen as a potential tool for post-quantum cryptography. The development of quantum computers is unrelated to the technical challenges of implementing efficient HE on classical systems.

Reference:
This topic aligns with Domain 3.0: Security Engineering of the CAS-005 exam, specifically concerning cryptographic techniques and their implementation challenges. The performance overhead of advanced cryptographic methods is a key consideration for security architects.

The widespread adoption of homomorphic encryption is hindered by its immense computational requirements, which currently necessitate specialized, and not yet ubiquitous, hardware support (coprocessors) to be practical.

Explanation:
The core issue is the review of data sovereignty laws in countries where the organization has no physical presence (no offices, employees, etc.). Data sovereignty laws mandate that data is subject to the laws of the country in which it is collected or stored.

Extraterritorial Scope of Laws:
Modern data privacy and sovereignty regulations, such as the European Union's GDPR, have extraterritorial reach. This means they can apply to an organization even if it is not physically located in that country or region. If the organization collects, processes, or stores the personal data of individuals (e.g., customers, website visitors) residing in those countries, it must comply with those local data laws.

Proactive Compliance:
A compliance officer reviewing these laws is engaging in proactive due diligence. The goal is to understand the legal obligations before offering services or processing data from individuals in those regions. This helps the organization avoid significant fines, penalties, and legal action from foreign regulators for non-compliance. The officer is identifying potential new markets or assessing the risk of existing online interactions with residents of those countries.

Analysis of Incorrect Options:

A. The organization is performing due diligence for potential tax issues.
While due diligence is correct, data sovereignty laws are specifically concerned with the storage, processing, and transfer of data, not corporate taxation. Tax issues are governed by different sets of laws and treaties.

B. The organization has been subject to legal proceedings in countries where it has a presence.
This is reactive. The question specifies the officer is reviewing laws in countries where the organization has no presence. If legal proceedings were already happening in countries where it does have a presence, the company's legal team would already be deeply familiar with those specific local laws. This review is broader and more proactive.

D. The organization has suffered brand reputation damage from incorrect media coverage.
Reputation damage is a public relations issue. While complying with data laws is good for reputation, reviewing foreign data sovereignty laws is a specific, legal/compliance activity that is not a direct response to media coverage. The connection is too indirect; the primary driver is legal risk, not P

Reference:
This scenario falls under Domain 1.0: Governance, Risk, and Compliance of the CAS-005 exam, specifically:

1.2: Understand legal and regulatory issues that pertain to information security, including data sovereignty and extraterritoriality.

1.4: Understand data privacy principles and ensuring compliance with evolving global regulations (e.g., GDPR, CCPA).

The most logical reason is that the organization is expanding its digital footprint (e.g., its website and online services are accessible globally) and must ensure it complies with the data protection laws of any country whose citizens' data it processes, regardless of physical presence.

Explanation:
The key detail in this scenario is the exfiltration method: the attacker used steganography within LDAP. LDAP (Lightweight Directory Access Protocol) is a standard protocol used for accessing and maintaining directory services, like Microsoft Active Directory on a domain controller. It typically operates on ports 389 (unencrypted) and 636 (encrypted).

Steganography in LDAP:
This means the attacker was hiding stolen data within what appeared to be normal, allowed LDAP network traffic. Because LDAP is a legitimate and essential protocol for a domain controller, this malicious traffic would easily blend in and not be blocked by standard firewall rules that allow LDAP.

Network Allow Lists (Zero Trust):
The most effective way to prevent this type of data exfiltration is to implement strict egress filtering based on an allow list. This means:

The organization would define precisely which systems are authorized to make outbound connections.

It would define precisely which protocols and ports those systems are allowed to use to communicate externally.

Any outbound traffic that does not match this strict allow list (e.g., an LDAP connection from a domain controller to an unknown external IP address) would be blocked.

This control would have prevented the exfiltration, even if the attacker successfully compromised the system and hid data in LDAP packets, because the destination would not have been an authorized recipient.

Analysis of Incorrect Options:

B. Measuring and attesting to the entire boot chain:
The question states that the forensic team already "cryptographically validated that the underlying firmware... and the operating system had not been compromised." The hardware static root of trust and boot process were verified as intact. Therefore, while this is a good practice, it would not have prevented this specific attack, as the boot chain was not the vector for persistence or exfiltration.

C. Rolling the cryptographic keys used for hardware security modules (HSMs):
Key rotation is a important security practice, but it is primarily for limiting the blast radius of a potential key compromise. An HSM protects cryptographic keys. The attack described did not involve stealing cryptographic keys; it involved exfiltrating general data via a covert channel. Rotating keys would do nothing to prevent data from being hidden in LDAP traffic.

D. Using code signing to verify the source of OS updates:
Code signing ensures the integrity and authenticity of software updates. Again, the forensic team confirmed the OS was not compromised. The attack was not achieved by tampering with OS updates. This control is vital for preventing initial compromise but is irrelevant to the exfiltration method used after the compromise occurred.

Reference:

This scenario addresses Domain 3.0:
Security Engineering, specifically designing and implementing secure network architecture principles:

Microsegmentation and Egress Filtering:
Controlling east-west and north-south traffic flows is a core tenet of a Zero Trust architecture. Preventing unauthorized data exfiltration requires monitoring and controlling outbound (egress) traffic, not just inbound.

MITRE ATT&CK Exfiltration Technique:
This aligns with technique T1048.003: Exfiltration Over Alternative Protocol - LDAP. The recommended mitigation for such techniques is precisely "Network Intrusion Prevention System (NIPS) and network allow lists" to block traffic to unknown malicious destinations.

Explanation:
The problem is that deployments fail due to "minor code issues" and "security control check failures" in the development environment. The goal is to catch these problems earlier in the process, before the code is ever saved to the repository and triggers an automated deployment.

B. Pre-commit code linting:
A "linter" is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. Pre-commit hooks are scripts that run on the developer's machine before the code is even committed to the local repository. Implementing pre-commit linting would catch those "minor code issues" (e.g., syntax errors, formatting problems) immediately, preventing the flawed code from ever being saved to the remote repository and triggering a failed deployment.

F. Pipeline compliance scanning:
This involves integrating security and compliance checks directly into the CI/CD pipeline before the deployment stage. These scans would validate the infrastructure code (e.g., Terraform, CloudFormation) against security policies (e.g., using tools like Checkov, Terrascan). This would catch the "security control check failures" early in the pipeline, fail the build, and provide feedback to the developer without ever attempting a deployment to the development environment. This is often called "shift-left" security.

Together, these two recommendations shift the discovery and blocking of errors leftward—to the developer's machine and the early stages of the pipeline—preventing them from causing deployment failures later.

Analysis of Incorrect Options:
A. Software composition analysis (SCA):
SCA tools scan open-source libraries and dependencies for known vulnerabilities. This is crucial for application security, but the problem describes failures with infrastructure code and its security controls, not third-party library vulnerabilities. It's a good practice but doesn't address the specific failures mentioned.

C. Repository branch protection:
Branch protection rules (e.g., requiring pull requests, status checks) are excellent for ensuring code quality and review before merging into a main branch. However, the problem states that deployments happen "every time the code is saved to the repository," which implies commits are being made directly to a branch that triggers deployments. While branch protection might be a good additional recommendation to change the workflow, the immediate need is to fix the code quality and security issues themselves, not just to gate the process.

D. Automated regression testing:
Regression testing ensures that new code changes don't break existing functionality. This is typically run after a deployment to a testing environment. The failures are happening during deployment to development, which is earlier in the process. Regression testing wouldn't prevent a deployment failure caused by a syntax error or a security policy violation in the code itself.

E. Code submit authorization workflow:
This is similar to branch protection. It involves requiring approvals (e.g., from a peer) before code can be submitted. This is a process control to improve quality but does not automatically find the "minor code issues" or "security control check failures." It relies on a human reviewer to spot them, which is less reliable and efficient than automated tools like linters and compliance scanners.

Reference:
This solution aligns with Domain 4.3: Automation of Security Operations and secure development practices within Domain 2.0: Security Architecture of the CAS-005 exam.The core concepts are:

Shift-Left Security:
Integrating security and quality checks earlier in the software development lifecycle (SDLC).

CI/CD Security:
Implementing automated gates and checks within the pipeline to fail fast and provide immediate feedback.

Infrastructure as Code (IaC) Security:
Specifically scanning IaC templates for misconfigurations before they are deployed.

The most direct way to reduce these deployment failures is to implement automated, early-stage checks for both code quality (linting) and security compliance (scanning).

A. Incorrectly typed password

Explanation:
If the user is occasionally mistyping their password, this could cause intermittent authentication failures. However, the scenario emphasizes that an analyst is reviewing logs, which suggests a deeper investigation beyond simple user error. Logs typically show authentication attempts, including whether the credentials were incorrect, but repeated password errors would likely be consistent rather than intermittent unless the user is inconsistently mistyping. This option is plausible but less likely in a technical investigation context unless the logs explicitly show "invalid credentials" errors sporadically.

Likelihood:
Moderate, but not the strongest fit without log evidence of repeated incorrect password entries.

B. Time-based access restrictions

Explanation:
Time-based access restrictions limit user access to specific time windows (e.g., business hours only). If the user attempts to authenticate outside these allowed times, access would be denied, and this could appear as intermittent if the user’s attempts vary across allowed and restricted times. Authentication logs would likely show a pattern of denials corresponding to specific times, with error messages like “access denied due to time restrictions.” This is a common enterprise security control and aligns well with intermittent issues, especially if the user is unaware of the policy.

Likelihood:
High, as time-based restrictions are a standard access control mechanism and could explain sporadic denials.

C. Account compromis:

Explanation:
Account compromise implies unauthorized access or changes to the account (e.g., password changed by an attacker, triggering lockouts, or multi-factor authentication (MFA) failures). Intermittent issues could arise if the attacker’s actions (e.g., failed login attempts from different locations) cause temporary lockouts or if MFA prompts are not reaching the user. Logs might show unusual login attempts (e.g., from unrecognized IPs or devices). However, without specific log evidence of suspicious activity, this option is less certain and assumes a more severe issue than the scenario suggests.

Likelihood:
Moderate, but requires log evidence of compromise (e.g., unusual IPs, excessive failed attempts).

D. Invalid user-to-device bindings

Explanation:
User-to-device bindings restrict authentication to specific devices (e.g., via device certificates or MAC address whitelisting). If the user switches devices or uses an unrecognized device, authentication could fail intermittently, depending on the device used. Logs might show errors like “unrecognized device” or “device not authorized.” This is plausible in environments with strict device-based access controls, but it’s less common than time-based restrictions and would require specific log entries to confirm.

Likelihood:
Moderate, but less likely unless the scenario involves multiple devices or strict device policies.

Reasoning Process

Intermittent nature:
The key clue is that authentication fails "sometimes," suggesting a conditional restriction rather than a consistent issue like a permanently incorrect password or fully compromised account.

Log analysis:
The analyst’s review of logs implies the answer lies in a pattern detectable in authentication logs, such as time-based denials, device-specific issues, or compromise indicators.

Enterprise context:
CASP+ focuses on advanced security controls in enterprise environments, where time-based access restrictions (option B) and device bindings (option D) are common. ime-based restrictions are more frequently implemented and easier to verify in logs via timestamps and policy-related error codes.

Elimination:
A: Incorrect passwords are user-driven and less likely to be intermittent unless the user is inconsistent, which logs would confirm but isn’t strongly implied.

C: Account compromise is a serious issue but requires evidence like unusual login patterns, which isn’t mentioned.

D:Invalid device bindings are plausible but less common than time-based restrictions and would depend on device-specific log errors.

B: Time-based restrictions align best with intermittent failures, as they depend on when the user attempts to log in, and logs would show a clear pattern of denials outside allowed times.

Correct Answer

B. Time-based access restrictions

Explanation
The most likely reason for the user’s intermittent authentication failures is time-based access restrictions. In enterprise environments, access control policies often restrict logins to specific time windows (e.g., 9 AM–5 PM). If the user attempts to authenticate outside these hours, the system denies access, resulting in intermittent failures. Authentication logs would show denials with error messages tied to time-based policies, which an analyst could easily identify. This aligns with CASP+ objectives around identity and access management (IAM) and is a common cause of such issues in secure environments.

References
CompTIA CASP+ Study Guide (CAS-005): Covers identity and access management, including time-based access controls as part of role-based and attribute-based access control (ABAC) policies.

NIST SP 800-53 (Security and Privacy Controls): Discusses access control policies (AC-3), including time-based restrictions as a mechanism to enforce least privilege.

General Knowledge: Authentication logs in systems like Active Directory or IAM platforms (e.g., Okta, Azure AD) often include error codes for time-based denials, such as “access denied due to policy” or “outside permitted hours.”

Explanation:
The scenario describes a likely MFA fatigue attack (also called push bombing or prompt spamming). In this attack, an attacker who has obtained a user's password repeatedly sends MFA push notifications to the user's device in the hope that the user will eventually accidentally approve one or get frustrated and approve it to stop the notifications.

FIDO2/WebAuthn:
FIDO2 security keys (e.g., YubiKey, Google Titan) use public key cryptography to perform authentication. The user must physically possess the key and perform an action (e.g., touch a sensor) to complete login.

Why it's the Best Solution:
FIDO2 is fundamentally resistant to MFA fatigue attacks. An attacker cannot spam push notifications to a FIDO2 key. The authentication process only begins after the user has inserted their key and entered their PIN. It requires explicit, physical user interaction on the local device for every login attempt, making remote bombing impossible. This completely eliminates the nuisance and the security risk described.

Analysis of Incorrect Options:

B. Deploying a text message based on MFA (SMS):
This is a terrible solution. SMS-based MFA is considered insecure due to its vulnerability to SIM swapping attacks and interception. Switching from push notifications to SMS does not stop the attack; the user would instead be spammed with text messages at night. It exchanges one type of spam for another while potentially lowering security.

C. Enabling OTP via email:
This is also a poor choice. If an attacker is spamming login attempts, the user would be spammed with emails containing one-time passwords. Furthermore, if the user's email account is compromised, the attacker could intercept these OTPs. This method is not considered secure for high-value accounts.

D. Configuring prompt-driven MFA:
This is the problem, not the solution. "Prompt-driven MFA" is exactly what is being abused in the attack—a prompt (push notification) is sent to the user's device for approval. Reconfiguring settings within the same system (e.g., changing the number of prompts) might slightly inconvenience the attacker but does not address the fundamental vulnerability of the method.

Reference:

This scenario addresses Domain 3.5:
Identity and Access Management of the CAS-005 exam, focusing on implementing strong authentication mechanisms. Key concepts include:

Understanding MFA Strengths and Weaknesses:
Knowing that push notifications are susceptible to social engineering and fatigue attacks.

Implementing Phishing-Resistant MFA:
FIDO2 is currently the gold standard for phishing-resistant MFA, as defined by frameworks from CISA and NIST. It is explicitly recommended to mitigate these exact types of attacks.

The best way to restrict the notifications is to eliminate the attack vector entirely by replacing the vulnerable method (push notifications) with a phishing-resistant and fatigue-proof method (FIDO2).

A. Spear-phishing campaign

Explanation:
Spear-phishing is a targeted form of phishing where an attacker tailors messages to specific individuals or groups, often impersonating a trusted entity (e.g., a recruiter) to trick victims into revealing sensitive information or performing actions. If multiple employees received similar messages from the same individual impersonating a recruiter, this indicates a coordinated, targeted attack. Correlating these incidents in reports would point to a spear-phishing campaign, as the pattern shows deliberate targeting of specific employees with a common pretext.

Likelihood:
High, as the scenario describes a single impersonator targeting multiple employees, which aligns with the definition of a spear-phishing campaign.

B. Threat modeling

Explanation:
Threat modeling is a proactive process used to identify, assess, and prioritize potential threats to a system or organization, often during system design or risk assessment. It involves creating models of threats (e.g., STRIDE or MITRE ATT&CK) to understand attack vectors. While useful for preparing against phishing, threat modeling is not a correlation activity and doesn’t describe the act of identifying a pattern in reports about employee contacts.

Likelihood:
Low, as threat modeling is a planning activity, not a reactive analysis of incidents.

C. Red team assessmen:

Explanation:
A red team assessment involves authorized security professionals simulating attacks to test an organization’s defenses. While a red team might simulate phishing, the scenario describes an external individual (implying a real attacker) and a security officer analyzing reports, not a controlled test. Correlating incidents in reports doesn’t align with a red team’s activities, which focus on attack simulation rather than log analysis.

Likelihood:
Low, as the scenario suggests a real attack, not a simulated one.

D. Attack pattern analysis

Explanation:
Attack pattern analysis involves identifying and categorizing patterns in attack methods, often using frameworks like MITRE ATT&CK to understand tactics, techniques, and procedures (TTPs). While the security officer’s correlation of incidents could contribute to attack pattern analysis, the specific scenario of multiple employees being targeted by an impersonator points more directly to a spear-phishing campaign. Attack pattern analysis is broader and might occur after identifying the campaign to study its TTPs, but it’s not the best description of the initial correlation.

Likelihood:
Moderate, as it’s related to correlation but less specific than spear-phishing.

Reasoning Process

Key clues:
The scenario highlights “several employees” contacted by the “same individual” impersonating a recruiter, with the correlation found in reports. This suggests a targeted, coordinated effort by an attacker, which aligns with spear-phishing.

Correlation focus:
The act of correlation involves recognizing that multiple incidents (contacts) share a common actor and method (impersonation of a recruiter), pointing to a specific attack type.

CASP+ context:
The CAS-005 exam emphasizes threat detection, incident response, and social engineering attacks. Spear-phishing (option A) is a specific type of social engineering attack, while attack pattern analysis (option D) is a broader analytical process. The scenario’s specificity about impersonation and targeting makes spear-phishing the best fit.

Elimination:
B: Threat modeling is proactive and not about correlating incidents in reports.

C: Red team assessments are simulated, not real attacks, and don’t involve report correlation.

D: Attack pattern analysis is too broad and less specific than identifying a spear-phishing campaign.

A: Spear-phishing directly describes the attack type indicated by the correlated incidents.

Correct Answer

A. Spear-phishing campaign

Explanation:
The correlation described in the scenario best aligns with identifying a spear-phishing campaign. Spear-phishing involves targeted attacks where an individual (here, impersonating a recruiter) sends tailored messages to specific victims (employees) to deceive them. The security officer’s discovery that multiple employees were contacted by the same impersonator, as found in reports, indicates a pattern consistent with a spear-phishing campaign. This type of correlation involves recognizing the common attacker and method across incidents, a key skill in security operations and incident response.

References:
CompTIA CASP+ Study Guide (CAS-005): Covers social engineering attacks, including spear-phishing, as part of threat identification and incident response (Domain 2: Security Operations).

NIST SP 800-61 (Incident Handling Guide): Discusses correlation of incident data to identify attack patterns, such as phishing campaigns, in the detection and analysis phase.

MITRE ATT&CK Framework:Lists spear-phishing (T1566) as a technique under Initial Access, describing targeted emails or messages impersonating trusted entities.

Explanation:
The core problem is a dynamic environment where the inventory of assets (devices/IPs) is constantly changing. This leads to vulnerability scans that are out of date the moment they are finished, missing new assets and wasting time scanning decommissioned ones.

Discovery Scanning:
Modern vulnerability management tools include a discovery scan function. This is a lightweight scan that rapidly identifies live hosts on a network, their IP addresses, and basic information (like OS type). It does not perform deep vulnerability checks.

Improving the Process:
By performing frequent, automated discovery scans (e.g., daily), the vulnerability management system can maintain an accurate and current asset inventory. This updated inventory then serves as the target list for the more intensive, in-depth vulnerability assessment scans. This ensures that the vulnerability reports are consistent and reflect the actual, current state of the network, as they are based on the most recent asset data.

Analysis of Incorrect Options:

A. Request a weekly report with all new assets deployed and decommissioned.
This is a manual, administrative process that is prone to error and delay. It relies on humans to remember to report changes and for the security team to manually update the scanner. In a fast-paced environment where changes happen "regularly," a weekly report is too infrequent and will not keep the scanner's target list current. Automation is always superior to manual processes for this task.

B. Extend the DHCP lease time to allow the devices to remain with the same address for a longer period.
This might slightly reduce IP churn for some devices but is not a solution to the vulnerability management problem. Many critical assets (servers, network devices) use static IPs, and this does nothing for devices that are physically added or removed from the network. The problem is asset inventory management, not just IP stability. A vulnerability scanner must find all assets, regardless of how they get their IP.

C. Implement a shadow IT detection process to avoid rogue devices on the network.
While detecting unauthorized devices is an important security practice, it is not the direct solution to this problem. The issue is the scanner's lack of awareness of authorized devices that are being added and dropped regularly. The goal is to have a complete picture of all assets, not just to find rogue ones. A shadow IT process might use similar discovery techniques, but option D is the more direct and comprehensive answer.

Reference:
This solution is a best practice in Domain 4.4: Vulnerability Management of the CAS-005 exam. The process is often described as:

Discover:
Identify all assets across the network.

Prioritize:
Classify assets based on criticality.

Assess:
Scan prioritized assets for vulnerabilities.

Report:
Define and communicate vulnerabilities.

Remediate:
Fix vulnerabilities.

Verify:
Confirm that vulnerabilities are resolved.

The problem occurs at the very first step (Discover). Without an automated and frequent discovery process, the entire vulnerability management program is built on an inaccurate foundation. Therefore, performing regular discovery scanning is the most direct and effective way to improve the process.

Explanation:
This scenario involves providing access from a less secure network (the business/enterprise network) to a highly sensitive network (the SCADA/Operational Technology (OT) environment). The core security principle here is to provide access without compromising the security integrity of the SCADA network.

Screened Subnet (Demilitarized Zone - DMZ):
This is a classic and recommended architecture for this purpose. A screened subnet is a perimeter network segmented off from both the internal IT network and the critical SCADA network.

How it Works:
The historian server, or a replica of it, would be placed in this DMZ. The SCADA network can push data to the server in the DMZ through a firewall with restrictive rules. The business users can then pull the metrics they need from the server in the DMZ. This creates a "buffer zone."

Security Benefit:
This architecture prevents a direct network path from the enterprise network to the SCADA network. If the historian server in the DMZ is compromised, the attacker still cannot directly access the critical control systems, as the firewall between the DMZ and the SCADA network will block unauthorized traffic.

Analysis of Incorrect Options:

A. Isolating the historian server for connections only from the SCADA environment.
This is the default, most secure posture for a SCADA system. However, it directly contradicts the business requirement which is to provide access to business users who are not on the SCADA network. This action would deny the required access.

B. Publishing the C$ share from SCADA to the enterprise.
This is an extremely dangerous and insecure action. The C$ share is a default administrative share for the entire C: drive. Publishing this from a critical SCADA system to the enterprise network would provide widespread, privileged access to the most sensitive systems, making them incredibly vulnerable to attack, data theft, and ransomware. It completely violates the principle of least privilege.

D. Adding the business workstations to the SCADA domain.
This deeply integrates the business workstations into the most sensitive security domain. It creates a direct trust path from the enterprise network to the SCADA domain, significantly increasing the attack surface. If a business workstation is compromised (a common event), the attacker could easily move laterally into the SCADA domain and disrupt critical operations.

Reference:
This solution is a foundational principle in Domain 3.0: Security Architecture of the CAS-005 exam, specifically:

Secure Network Architecture:
Designing segmented networks (e.g., using the Purdue Model for ICS security) is essential for protecting critical environments like SCADA/ICS.

The Purdue Model:
This model explicitly defines a "Demilitarized Zone (DMZ)" level (Level 3.5) for precisely this purpose—to host historians and other data brokers that facilitate communication between the Industrial Control System (ICS) levels (Levels 0-3) and the Enterprise IT levels (Levels 4-5).

Using a screened subnet (DMZ) is the industry-standard way to securely facilitate data flow from an OT environment to business users without jeopardizing the safety and reliability of the industrial control processes.

Explanation:
The question specifies the goal is to secure remote access connections to Linux systems. The primary method for remote administrative access to Linux systems is SSH (Secure Shell).

Cipher-Block Chaining (CBC):
CBC is an older mode of operation for block ciphers. Vulnerabilities (e.g., the Lucky Thirteen attack) have made CBC-based ciphers in SSH weak and undesirable for secure communications.

SSH Server Configuration:
The configuration file for the SSH daemon (the service that accepts incoming SSH connections) is typically located at /etc/ssh/sshd_config.

Modifying Ciphers:
This file contains a directive called Ciphers. To disable weak CBC ciphers, the security engineer would edit this file and specify a list of strong, modern ciphers (e.g., AES in GCM or CTR mode, ChaCha20-Poly1305), explicitly omitting any ciphers that use CBC mode (e.g., aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc).

Analysis of Incorrect Options:

A. The /etc/openssl.conf file, updating the virtual site parameter:
The openssl.conf file is used to configure the OpenSSL library, which provides cryptographic functions for many applications. It is not the primary configuration file for the SSH service. While OpenSSL is used by SSH, the specific configuration for SSH's ciphers is handled within its own sshd_config file.

B. The /etc/nsswitch.conf file, updating the name server:
The nsswitch.conf (Name Service Switch configuration) file controls how the system resolves sources for different databases, such as passwords (passwd) and hostnames (hosts). It has nothing to do with configuring encryption algorithms or remote access protocols.

C. The /etc/hosts file, updating the IP parameter:
The hosts file is a static table for mapping hostnames to IP addresses. It is a simple form of local name resolution and is completely unrelated to the encryption protocols used for network connections.

Reference:
This task falls under Domain 3.0: Security Engineering of the CAS-005 exam, specifically:

Cryptography (3.6): Implementing cryptographic protocols and understanding weak ciphers.

Secure Network Protocols (3.4): Securing administration channels like SSH by hardening their configuration.

The action of disabling weak CBC ciphers in SSH is a standard system hardening step found in benchmarks from the CIS (Center for Internet Security) and other security guides. The correct file to modify to control SSH server behavior is unequivocally /etc/ssh/sshd_config.