Refer to the Exhibit Practice Questions

10.0.0.5:22 to 10.0.0.1:50001

Why it fails: This connection represents a standard SSH session where an internal host (10.0.0.5) is securely connecting to another internal host (10.0.0.1) for administrative purposes. SSH operates on the well-known port 22, and the destination port 50001 is an ephemeral port assigned to the client side of the connection, which is normal for client-initiated traffic. This is typical, legitimate management traffic within an organization's network.

All connections are normal.

Why it fails: This statement is incorrect because not all connections observed are normal. Specifically, the outbound connection from an internal host to an external IP address on port 4444 (10.0.0.5:54321 to 198.51.100.20:4444) is highly anomalous and indicative of potential malicious activity, such as command and control traffic. Therefore, asserting that all connections are normal overlooks a significant security event that warrants immediate investigation.

10.0.0.5:3389 to 192.168.1.10:54321

Why it fails: This connection depicts a legitimate Remote Desktop Protocol (RDP) session between two internal hosts. Host 10.0.0.5 is initiating an RDP connection, which typically uses port 3389, to another internal system at 192.168.1.10. The destination port 54321 is an ephemeral port used by the client, while the RDP server would be listening on its standard port 3389. This is common administrative traffic for managing Windows systems within a private network.

Update the Suricata signature to block the traffic.

Why it fails: Updating Suricata signatures to block traffic is a proactive measure typically undertaken by security engineers or threat hunters after a new, persistent threat pattern has been thoroughly analyzed and validated. For a single, immediate alert indicating a potential exploit, the priority is incident response and investigation, not the time-consuming process of signature development and deployment, which could also lead to false positives if not carefully crafted.

Run a full antivirus scan on destination host 10.0.0.1.

Why it fails: Running a full antivirus scan on the destination host (10.0.0.1) is generally not the most effective immediate response for a potential web-based exploit. Antivirus software primarily detects known file-based malware, whereas this alert likely indicates an attempt to exploit a vulnerability in a web application or server, which may not involve dropping or executing traditional malware files. Furthermore, a full scan on a production web server can introduce performance degradation.

Escalate the alert to the incident response team.

Why it fails: Escalating the alert to the incident response (IR) team is the most appropriate immediate action for a high-severity SIEM alert indicating a potential exploit. This ensures that trained specialists with defined roles and established procedures can promptly investigate the potential compromise, determine its scope, and initiate the necessary containment, eradication, and recovery efforts. A structured, coordinated response is crucial for effective incident management.

Immediately block the source IP at the firewall

Why it fails: Immediately blocking a source IP based solely on a SIEM alert, without prior verification, carries a significant risk of disrupting legitimate business operations. Many SIEM alerts can be false positives or indicate benign activity, especially if the alert threshold is low or the signature is overly broad. A security analyst's initial step should involve validating the alert's legitimacy to avoid impacting critical services or users.

Update the signature database

Why it fails: Updating the signature database is not an appropriate immediate response to an active SIEM alert that has already triggered. The alert indicates that an existing signature successfully identified a pattern, meaning the current database was sufficient to detect this specific event. While regular signature updates are vital for proactive defense against new threats, they do not directly address the investigation or remediation of an alert that has already been generated by an existing rule.

Isolate the affected system for forensic analysis

Why it fails: Isolating an affected system for forensic analysis is a containment strategy typically employed after an analyst has confirmed malicious activity and determined the scope of the compromise. Performing isolation as the very first step, without initial investigation or verification, could prematurely disrupt critical business functions or hinder the collection of live evidence. Initial steps should focus on validating the alert and understanding the nature of the potential incident before enacting such a disruptive measure.

22

Why it fails: Port 22 is the standard port for Secure Shell (SSH), a cryptographic network protocol used for secure remote access and file transfers. While SSH can be a target for brute-force attacks or used maliciously if compromised, its presence as an established connection is generally expected for legitimate system administration. Without further context indicating unauthorized access or unusual traffic patterns, SSH itself is not inherently anomalous.

53

Why it fails: Port 53 is dedicated to the Domain Name System (DNS), a critical service for translating human-readable domain names into IP addresses. Both UDP and TCP port 53 are fundamental for nearly all internet communication, making its presence in network traffic entirely expected. Although DNS can be exploited for tunneling or data exfiltration, the mere observation of traffic on port 53 does not, by itself, indicate an anomaly or compromise.

80

Why it fails: Port 80 is the well-known port for the Hypertext Transfer Protocol (HTTP), which is the foundation of data communication for the World Wide Web. Web browsers and servers routinely communicate over this port for unencrypted web traffic. Therefore, seeing established connections on port 80 is a common and legitimate occurrence in almost any network environment, reflecting normal user activity or server functions.

The policy is missing a NotAction element

Why it fails: The NotAction element is an optional IAM policy component used to specify explicit exceptions to a list of allowed actions. Its absence does not constitute a policy defect or misconfiguration, as the primary security flaw is the overly permissive use of the wildcard action on all resources.

The policy allows read-only access

Why it fails: This statement is incorrect because the policy specifies s3:* as the action, which grants full administrative control over the S3 service. This includes highly destructive and modification-based privileges such as DeleteBucket, PutBucketPolicy, and DeleteObject, rather than restricting permissions to read-only actions like GetObject.

The policy uses a wildcard resource

Why it fails: Although specifying a wildcard resource is a significant security concern that violates the principle of least privilege, it is not the primary driver of the critical risk in isolation. The critical vulnerability stems from combining this broad resource scope with unrestricted S3 actions, which elevates the policy from a broad resource target to a catastrophic data exposure risk.

The server is running a legitimate SSH service on port 4444

Why it fails: While administrators sometimes change the default SSH port to mitigate automated brute-force attacks, SSH natively defaults to port 22. Port 4444 is highly non-standard for SSH, and a security analyst should not assume a service on this port is legitimate SSH without verifying the service banner or cryptographic handshake.

The server is hosting a web service on a non-standard port

Why it fails: Web services commonly use ports 80, 443, or alternative development ports like 8080 and 8443. Port 4444 is not standard for HTTP/HTTPS traffic, and assuming it is a web server without protocol-specific evidence (such as GET/POST requests in traffic logs) overlooks the high probability of malicious activity associated with this port.

The server is being used as a proxy for internal clients

Why it fails: Proxy services, such as Squid or SOCKS proxies, typically listen on standard ports like 3128, 8080, or 1080 to route outbound traffic for internal clients. There is no architectural or protocol-level evidence in the command output to suggest the system is acting as an intermediary proxy, making this explanation highly unlikely compared to a malware infection.