Systems and Application Security practice questions

Use PAM to log authentication events to /var/log/secure

Why it fails: PAM can be configured to log, but typically uses syslog; auditd is the standard for comprehensive auditing.

Set up SELinux to audit login attempts

Why it fails: SELinux provides mandatory access control and can audit denials, but is not primarily for login logging.

Configure syslog to monitor /var/log/auth.log

Why it fails: syslog can forward logs, but does not enable auditing itself; auth.log may already exist but needs auditd to populate it.

Snapshots can be used to bypass authentication

Why it fails: Snapshots do not bypass authentication; they represent a system state.

Snapshots can be exported and stolen

Why it fails: While theft is a risk, it is not unique to snapshots; the primary security concern is vulnerability reintroduction.

Snapshots consume excessive storage space

Why it fails: Storage consumption is an operational concern, not a primary security issue.

Disable auto-run on user workstations

Why it fails: Auto-run is a system hardening measure, not directly related to web application security.

Use a host-based intrusion detection system on the database server

Why it fails: HIDS on database is good practice but does not directly protect against OWASP Top 10 web attacks.

Identity and Access Management (IAM)

Why it fails: IAM manages access, not workload protection.

Cloud Security Posture Management (CSPM)

Why it fails: CSPM detects misconfigurations but does not protect workloads at runtime.

Security Information and Event Management (SIEM)

Why it fails: SIEM aggregates logs but is not specifically for workload protection.

Configure SELinux to enforce mandatory access control on the /etc/shadow file

Why it fails: SELinux can protect the shadow file but does not prevent brute-force logins; it controls file access.

Change the root password every 30 days

Why it fails: Password aging does not mitigate brute-force attacks; it only limits the window of exposure if a password is compromised.

Disable root login entirely and require sudo for all administrative tasks

Why it fails: While this reduces risk, it does not prevent brute-force attacks on other accounts. The question specifically mentions root account failures; lockout is more direct.

Create an inbound block rule for all ports and then exclude HTTPS

Why it fails: Creating an inbound block rule for all ports and then excluding HTTPS is not a valid configuration in Windows Firewall; you cannot 'exclude' from a block rule. Instead, you must create separate allow rules. This approach is overly complex and not recommended.

Create an inbound allow rule for HTTPS and set the firewall default action to block

Why it fails: Setting the firewall default action to block and creating an allow rule for HTTPS would work, but it is not the most explicit method. The default inbound action in Windows Firewall is already block unless an allow rule exists. This option is less precise than creating a dedicated block rule for all other ports, as specified in option D.

Create an outbound allow rule for HTTPS only

Why it fails: This rule is for outbound traffic, but the requirement is to allow inbound HTTPS traffic. Outbound rules do not control inbound traffic, so this configuration fails to meet the requirement.

Man-in-the-Middle (MitM)

Why it fails: MitM is a network attack, not specifically an OWASP Top 10 category.

Buffer overflow

Why it fails: Buffer overflow is not in the OWASP Top 10; it is more of a memory corruption issue.

Outdated OS patches on cloud VMs

Why it fails: CSPM reads cloud control-plane configuration, not the patch level inside a guest operating system, so missing OS updates fall to vulnerability management or patch tooling. It is tempting because patch status feels like posture, and CSPM would correctly flag an unencrypted volume or a publicly accessible database.

Runtime malware in a virtual machine

Why it fails: CSPM evaluates configuration against benchmarks, so it inspects control-plane settings such as public buckets or permissive security groups; runtime malware inside a VM is workload behaviour detected by CWPP or endpoint agents. It is tempting because both address cloud security posture, but CSPM has no runtime telemetry.

netstat -tuln

Why it fails: netstat displays network connections and listening ports, which might reveal suspicious activity, but it does not verify the integrity of system binaries. A rootkit could also hide its network connections. This command is not designed for rootkit detection via hash comparison.

ps aux

Why it fails: ps aux lists running processes, but a rootkit can hide malicious processes from this command. It does not compare binaries against known good hashes, so it is not effective for rootkit detection. It may show normal processes while the rootkit remains hidden.

chkrootkit

Why it fails: chkrootkit is another rootkit detection tool, but it primarily checks for known signatures and anomalies rather than comparing binaries against a baseline of hashes. While useful, rkhunter is more focused on hash comparison for system binaries. The question specifies comparing against known good hashes, which is a core feature of rkhunter.

Store session tokens in local storage instead of cookies.

Why it fails: Local storage is accessible via JavaScript, making tokens vulnerable to XSS attacks. Cookies with HttpOnly are more secure because they are not accessible to JavaScript. Storing tokens in local storage increases the risk of theft, so this is not an effective measure.

Rotate the session token after successful authentication.

Why it fails: Rotating the session token after login prevents session fixation attacks, where an attacker sets a known token before authentication. However, it does not prevent theft or reuse of the token after login. While it is a good practice, it is not among the most effective for preventing hijacking of an active session.

Use a long session timeout to improve user experience.

Why it fails: A long session timeout increases the window of opportunity for an attacker to use a stolen token. It does not prevent theft or reuse; it exacerbates the risk. Best practice is to use short timeouts and re-authentication for sensitive operations. This option is counterproductive to the goal.

Use Task Manager to end the svchost.exe process immediately to stop the connection.

Why it fails: Ending the process could disrupt critical system services and may not stop the malware if it has persistence mechanisms. It also destroys volatile evidence. The analyst should first investigate to confirm malicious activity before taking action that could harm the system or investigation.

Check the digital signature of the svchost.exe process to verify it is signed by Microsoft.

Why it fails: Checking the digital signature is a good step, but malware can inject into a legitimate signed process like svchost.exe. The signature alone does not confirm the process is benign; it only verifies the file's integrity. The analyst needs to examine the actual behavior and network connections first.

Run a full antivirus scan to detect and remove the malware.

Why it fails: A full antivirus scan can be part of the response, but it is not the first step. It may take time and could alert the attacker if they have persistence. The analyst should first perform quick triage to understand the process, as antivirus might not detect advanced malware.

Role-based access control (RBAC) that limits the service account to read-only access to secrets.

Why it fails: RBAC restricts what the Kubernetes API allows the service account to do, such as reading secrets. It does not govern whether a pod can mount a hostPath volume or reach the cloud metadata endpoint. A compromised container could still access the metadata service directly, so RBAC alone does not satisfy the scenario's requirements.

A mutating admission controller that injects a sidecar proxy to inspect all outbound traffic.

Why it fails: A sidecar proxy can inspect and filter traffic, potentially blocking metadata service access, but it does not prevent the container from mounting host paths. Additionally, a compromised container may bypass the proxy for some traffic. The scenario requires a control that blocks both metadata access and host path mounts, which a sidecar alone does not provide.

Network policies that deny all egress traffic from the application's namespace.

Why it fails: Network policies control pod-to-pod and pod-to-external traffic, and a default-deny egress policy would block access to the metadata service. However, network policies do not prevent a container from mounting host paths or accessing the host file system. The scenario requires protection against both metadata access and host path mounts, so network policy alone is insufficient.

File name

Why it fails: File name rules are not a standard AppLocker condition. AppLocker uses publisher, path, and file hash conditions. Even if file name were available, it is easily spoofed and does not verify digital signatures, so it would not meet the requirement.

Path

Why it fails: Path rules allow or block applications based on their file path or folder location. This is not based on digital signatures, so it cannot ensure that only signed applications from trusted publishers run. It could be bypassed by placing an unsigned executable in an allowed path.

File hash

Why it fails: File hash rules allow or block specific files based on their cryptographic hash. While useful for pinpointing exact files, they do not scale well for allowing all signed applications from a publisher, as each update changes the hash. This condition does not meet the requirement of allowing signed apps from trusted publishers broadly.

Move the server to a more secure network segment and implement network access controls.

Why it fails: Segmentation and network access controls limit reachability but leave Telnet, FTP and unpatched software running on the host, so the vulnerabilities persist. This approach suits containing a compromised or legacy system, not hardening the server itself, which requires disabling services and applying patches.

Enable SELinux and configure a host-based firewall using iptables.

Why it fails: SELinux and iptables restrict access and filter traffic, but Telnet and FTP remain installed and listening, and the missing patches stay unapplied. These controls suit limiting lateral movement or enforcing least privilege, yet they do not satisfy the stem's requirement to eliminate unnecessary services and remediate patch gaps.

Install a host-based intrusion detection system (HIDS) to monitor for attacks.

Why it fails: A HIDS only detects and alerts on malicious activity after it occurs; it neither removes Telnet and FTP nor applies missing patches, leaving the actual exposures open. Monitoring suits environments where detection of ongoing compromise is the goal, but hardening here demands disabling unnecessary services and patching.

User Account Control (UAC)

Why it fails: UAC prompts for elevation when an application requests administrative rights; it does not maintain an allow list of permitted binaries, so standard-user applications still execute. It is tempting because it gates privileged actions, but its mechanism is consent and token elevation, not execution blocking, so it fails the whitelisting requirement.

Windows Firewall with Advanced Security

Why it fails: Windows Firewall with Advanced Security filters network traffic by port, protocol and address; it cannot inspect or block local executable launches. It is tempting because it enforces rules centrally via Group Policy, but that scope covers inbound and outbound connections, not application execution, so a locally installed program still runs.

Windows Defender Antivirus

Why it fails: Windows Defender Antivirus blocks known malicious code through signature and heuristic detection, not by permitting only approved applications. It is tempting because it prevents some unwanted software, but its mechanism is threat identification rather than an allow list, so any unrecognised but non-malicious program still runs.

Network infrastructure security such as DDoS protection at the provider edge

Why it fails: Edge DDoS protection forms part of the provider's network infrastructure on IaaS, not the customer's remit. It tempts because DDoS mitigation is a genuine customer duty when running dedicated internet circuits into an on-premises data centre that the organisation controls end to end.

Hypervisor security and vulnerability management

Why it fails: Hypervisor hardening sits with the provider on IaaS, since it virtualises the customer's instances; the customer secures only the guest OS and above. It tempts because hypervisor patching is a genuine customer duty under on-premises virtualisation, where the organisation owns the entire stack.

Physical security of the data center hosting the servers

Why it fails: Physical security of the data centre remains the provider's responsibility on IaaS, as the customer never accesses the facility. It tempts because physical controls are a real customer obligation in on-premises or colocation hosting, where the organisation owns or leases the building.

Use a separate network for VM management traffic

Why it fails: Separating management traffic onto its own network segments administrative access; it does nothing to stop a guest VM exploiting the hypervisor. It is tempting because network isolation correctly limits lateral movement between workloads, but VM escape is contained through hypervisor hardening and isolation controls.

Deploy a host-based firewall on each VM

Why it fails: A host-based firewall filters network traffic inside the guest, but VM escape exploits hypervisor or virtualisation bugs, not network paths, so filtering packets cannot stop it. Host-based firewalls suit controlling inbound and outbound traffic per instance, not hypervisor isolation.

Enable VM snapshots to restore in case of compromise

Why it fails: Snapshots capture point-in-time disk state for recovery; they do not constrain a guest's access to hypervisor interfaces, so an escape exploit still succeeds. Snapshots are the right choice for rollback after corruption or a failed patch, not for isolating VMs from the hypervisor.

chown 600 file.txt

Why it fails: chown changes file ownership (user and group), not permission bits, so it cannot set read/write-only-for-owner. It is the right command when transferring a file to a different user or group, for example reassigning ownership after a staff change.

umask 077 file.txt

Why it fails: umask sets the default permission mask for newly created files; it does not alter an existing file's mode, and passing a filename is invalid syntax. It is correctly used in shell profiles to control permissions on future file creation.

setfacl -m u::rw file.txt

Why it fails: setfacl with only a user entry modifies the access control list, leaving group and other permissions untouched rather than removing them. It is correct when granting an additional named user access beyond the standard owner/group/other model.

Cross-Site Scripting (XSS)

Why it fails: Cross-Site Scripting targets the browser by injecting script into pages other users view, whereas the stem describes input altering an SQL query's structure — that is injection. XSS is tempting because both stem from unsanitised input, and it would be correct if the payload executed in a victim's browser rather than the database.

Security Misconfiguration

Why it fails: Security Misconfiguration covers insecure settings such as default credentials or verbose errors, not the coding flaw of concatenating input into a query. It is tempting because both stem from poor security hygiene, and misconfiguration is correct when the weakness lies in deployed configuration rather than application source code.

Broken Access Control

Why it fails: Broken Access Control concerns enforcement of authorisation over resources, not query construction, so concatenating unsanitised input into SQL does not fit it. It is tempting because injection can bypass access checks, and Broken Access Control is the correct answer when users reach records or functions beyond their granted permissions.

An application running on a cloud VM has a memory leak causing performance degradation

Why it fails: A memory leak is a runtime application defect, surfaced by APM or host monitoring, not by comparing resource configuration against a secure baseline. It is tempting because CSPM inventories cloud VMs and reports on them, but it assesses settings such as exposed ports or missing patches, not process memory behaviour.

A cloud-based database is experiencing slow query response times

Why it fails: Slow query response times are a performance metric, detected by database monitoring or APM tooling rather than configuration assessment. It is tempting because CSPM dashboards display cloud resource health data, yet query latency reflects workload and tuning, not a deviation from a secure configuration baseline.

An employee's credentials were used from an unusual geographic location

Why it fails: Credential use from an unusual location is behavioural anomaly detection, which belongs to UEBA or SIEM analytics, not posture scanning. It is tempting because CSPM platforms often surface identity findings alongside configuration ones, and unusual geolocation would legitimately be flagged by a UEBA tool monitoring sign-in patterns.