Practice Test #3

"encryption=off" is not a standard or universal indicator of non-encrypted web traffic. It might appear as a custom query-string parameter on a specific website (e.g., ?encryption=off), but most HTTP sites will not contain this text in the URL. Using this string would miss the vast majority of non-encrypted websites and is therefore ineffective for enforcing HTTPS-only browsing.

"www.*.com" is not an encryption-related indicator; it is an attempt at a wildcard domain pattern. It would also be overly broad and could block many legitimate sites regardless of whether they use HTTPS. Additionally, many valid websites do not use "www" and many are not in the .com TLD, so it is both inaccurate and unrelated to the goal of blocking non-encrypted access.

":443" refers to the common TCP port for HTTPS, but it is not a reliable string to detect encryption in a URL. Most users do not explicitly specify ":443" in URLs, so the filter would miss most HTTPS/HTTP cases. Also, port numbers do not guarantee encryption—services can run on 443 without TLS, and HTTPS can be served on nonstandard ports.

This denies inbound traffic from any source (0.0.0.0/0) to destination 10.1.4.9/32. That would block traffic headed to 10.1.4.9, effectively protecting that specific destination host (if it is inside your network). It does not block traffic originating from 10.1.4.9, so it fails the requirement to stop the malicious IP from accessing the organization.

This is the opposite of what is needed: it permits inbound traffic from source 10.1.4.9/32 to any destination. During an incident, a permit rule would explicitly allow the malicious host to continue communicating with internal targets, increasing risk and undermining containment efforts.

This permits inbound traffic from any source to destination 10.1.4.9/32. It not only fails to block the malicious IP, but it also explicitly allows traffic to 10.1.4.9. Like option A, it focuses on the destination being 10.1.4.9 rather than blocking 10.1.4.9 as the source of malicious inbound traffic.

Configuring the correct VLAN is a strong security architecture practice (segmentation of IoT/cameras, limiting lateral movement, applying ACLs). However, it’s not the most fundamental first step for “deploying a new security camera.” You typically perform a site survey first to determine placement and connectivity needs, then implement the VLAN and firewall rules once you know the camera’s network path and recording architecture.

A vulnerability scan can help identify outdated firmware, weak services, or misconfigurations after the camera is deployed. It is not usually the primary action during initial deployment because embedded/IoT devices can be sensitive to scanning, and scanning doesn’t solve the core deployment challenge of ensuring proper coverage, lighting, and placement. Scanning is better categorized as validation/operations after installation.

Disabling unnecessary ports/services (e.g., Telnet, UPnP, unused management interfaces) is a best practice for hardening cameras and reducing attack surface. Still, the question focuses on deploying a new camera, where the most critical initial activity is ensuring the camera will meet surveillance objectives in its physical environment. Hardening is important but typically follows placement and connectivity planning.

Application logs record events generated by a specific application (e.g., web server access logs, database logs, email server logs). They can help if the suspicious activity is clearly tied to that application’s own logging, but they generally do not provide comprehensive OS-level details about arbitrary executables, parent/child processes, or file hashes across the endpoint.

IPS/IDS logs provide detections based on network signatures, anomalies, or policy violations. They are excellent for identifying potentially malicious network traffic and indicators of compromise on the wire, but they typically cannot attribute the traffic to a specific executable on the host without additional endpoint telemetry or advanced network-to-host correlation data.

Network logs (e.g., NetFlow, firewall logs, proxy logs, DNS logs) show source/destination IPs, ports, protocols, domains, and sometimes URLs. They help confirm what the laptop communicated with and when, but they usually do not identify the exact process/executable responsible for generating the traffic on the endpoint.

Private can describe information intended to be kept from public disclosure, and patient records are certainly private in a general sense. However, “Private” is not a standard, consistently used classification label in many formal classification schemes tested on Security+. Exams more commonly use “Sensitive” or “Confidential” to indicate regulated personal data requiring strict controls.

Critical typically refers to data or systems essential to mission/business operations where loss of availability or integrity would cause major disruption (e.g., life-safety systems, core EHR uptime). While hospital systems can be critical, the question is about securing patient data specifically, which is primarily a confidentiality and privacy classification issue rather than operational criticality.

Public data is intended for anyone to access and generally requires minimal confidentiality controls (e.g., marketing materials, published hospital visiting hours). Patient data is the opposite of public; classifying it as public would lead to insufficient safeguards and would violate privacy expectations and likely regulatory requirements.

Typosquatting involves registering or using a look-alike domain name (e.g., payroII.example.com vs payroll.example.com) to trick users into visiting a malicious site. The scenario describes a text message requesting credential verification, not a deceptive domain or URL manipulation technique. Typosquatting could be involved if a link used a similar domain, but that detail is not provided.

Phishing is the general category of attempts to trick users into revealing sensitive information through fraudulent communications. This scenario is phishing in a broad sense, but the exam typically expects the more specific term based on the channel. Because the message is a text message, “smishing” is the best match rather than the generic “phishing.”

Vishing is voice phishing conducted over phone calls or voice systems (live calls, IVR, voicemail). The scenario explicitly states the employee receives a text message, not a call. If the attacker had called claiming to be payroll and asked for credentials, vishing would apply. Here, the correct channel-specific term is smishing.

Misinformation refers to false or misleading information spread to influence opinions or cause confusion, often in the context of propaganda or disinformation campaigns. While the text message is deceptive, its goal is credential theft rather than shaping beliefs or narratives. Therefore, misinformation is not the best classification for this credential-harvesting social engineering attempt.

Supply chain analysis evaluates risks introduced by third parties and dependencies (vendors, software components, logistics, service providers). It focuses on identifying and mitigating supplier-related threats (e.g., compromised updates, counterfeit hardware, vendor access risks). It does not provide the operational terms and boundaries for conducting a specific penetration test engagement.

A right to audit clause is a contract provision allowing a customer to audit a vendor’s controls, processes, or compliance (e.g., SOC reports, onsite assessments) to verify security obligations. While related to third-party oversight, it does not specify the detailed conduct of a penetration test (scope, timing, allowed techniques) like rules of engagement do.

Due diligence is the process of evaluating a third party before entering or continuing a business relationship. It includes reviewing security posture, financial stability, compliance, and risk controls. Due diligence may lead to requiring a pentest, but it does not define the specific terms, constraints, and procedures for the pentest itself.

MTTR (Mean Time To Repair/Recover) measures the average time required to restore a system/service after a failure or incident. It’s useful for operational resilience and incident response performance, and it can affect downtime costs. However, it does not directly measure the annual likelihood of ransomware events, which is the key factor in deciding whether to carry or drop annual insurance coverage.

RTO (Recovery Time Objective) is the maximum acceptable downtime for a business process after an outage. It is a business continuity metric used to design DR strategies (hot/warm/cold sites, backups, replication). While ransomware can impact RTO planning, RTO is not an insurance risk frequency metric and is less directly tied to the decision to remove ransomware coverage to reduce premiums.

MTBF (Mean Time Between Failures) is a reliability/availability metric indicating the average time between inherent failures of a system or component. It is commonly used in hardware lifecycle planning and uptime engineering. Ransomware is an intentional threat event, not an inherent equipment failure, so MTBF is not the appropriate analysis element for deciding on ransomware insurance coverage.

A disaster recovery plan (DRP) focuses on restoring IT systems after a major outage or disaster (e.g., ransomware, fire, data center failure). It covers recovery strategies, RTO/RPO targets, backups, and restoration steps. While firewall configurations may be included as part of recovery documentation, DRP is not the procedure you follow for routine creation of new firewall rules in normal operations.

An incident response procedure guides detection, containment, eradication, and recovery during a security incident. Firewall rule changes can be part of containment (e.g., blocking an IP or port during an attack), but the question asks about setting up a new set of rules generally. For planned rule changes, the correct governance control is change management; IR is for active or suspected incidents.

A business continuity plan (BCP) ensures critical business functions continue during and after a disruption, often using alternate processes, sites, or workarounds. It is broader than IT and focuses on maintaining operations. Although firewall availability can affect continuity, BCP does not define the approval, testing, documentation, and rollback workflow required for implementing new firewall rules.