Securing Assets practice questions

Modify the 'Administrative Templates' to set 'Prevent installation of removable devices'.

Why it fails: This is a legacy GPO setting that prevents the device driver from installing, which is too restrictive for an allow-listing scenario.

Set the 'USB Connection' state to 'Restricted' within the Defender for Endpoint configuration baseline.

Why it fails: This is not a valid configuration path for MDE device control.

Configure the 'Allow installation of devices that match any of these device IDs' policy.

Why it fails: This setting controls driver installation, not the runtime access to removable storage volumes.

The scanner is configured to run 'Non-Credentialed' scans only, resulting in false positives.

Why it fails: Non-credentialed scans typically do not return detailed patch-level vulnerabilities.

The Linux server is hosting a Windows VM, and the scanner is reporting on the guest OS.

Why it fails: Nessus scanners do not automatically cross-map guest OS vulnerabilities in this manner without specific hypervisor-level integration.

The Linux server has Samba installed, and the vulnerability scanner is correctly identifying a vulnerability in the SMB stack.

Why it fails: While possible, reporting a 'Remote Windows SMB' service on a Linux target is a diagnostic error in the scan configuration rather than a legitimate service identification.

Disable the administrative account immediately without further analysis.

Why it fails: Disabling the account interrupts business operations without confirming if the activity was a false positive or a true security incident.

Restart the database service to clear the connection pool.

Why it fails: Restarting services does not help in identifying the source or nature of the attack.

Increase the logging level on the database to 'Debug' to capture the password hash being transmitted.

Why it fails: Increasing log levels to debug is rarely necessary and introduces risks of logging sensitive data.

The VM is not joined to an Microsoft Entra ID domain.

Why it fails: JIT VM access does not require a domain-joined state.

The developer lacks the 'Security Reader' role, which is mandatory for requesting JIT access.

Why it fails: Security Reader is a lower-level role and does not grant the write permissions needed to modify NSG rules via JIT.

The developer has not enabled 'Multi-Factor Authentication' on their local machine.

Why it fails: While MFA is good practice, it is not a requirement for the JIT request process itself.

Inbound: TCP 80, 443 from 0.0.0.0/0; Outbound: All traffic.

Why it fails: 'All traffic' outbound is generally too broad for a hardened web server.

Inbound: All TCP from 0.0.0.0/0; Outbound: All traffic.

Why it fails: This is essentially no security at all.

Inbound: TCP 22, 80, 443 from 0.0.0.0/0; Outbound: All traffic.

Why it fails: Opening SSH (22) to the world is a major security risk.

Wireshark to analyze the encrypted traffic.

Why it fails: Wireshark captures packets, but TLS handshake records are encrypted, so it cannot reveal chain validation errors such as an untrusted or expired intermediate. It is tempting because it inspects handshake alerts, and would be correct for diagnosing plaintext protocol negotiation issues.

'certutil -verify -urlfetch' on the Linux server.

Why it fails: certutil is a Windows-only utility; it does not exist on Linux, so the command cannot run there. It is tempting because certutil -verify -urlfetch genuinely validates certificate chains and revocation via AIA and CRL fetching, and would be correct on a Windows server.

Nmap with the '--script ssl-enum-ciphers' flag.

Why it fails: ssl-enum-ciphers enumerates supported protocols and cipher suites; it does not retrieve or validate the certificate chain, issuer trust, or revocation status. It is tempting because it diagnoses TLS handshake failures, and would be correct if the failure stemmed from a cipher or protocol mismatch.

Granting the application access to all internal databases 'just in case' it needs them later.

Why it fails: This violates the principle of least privilege.

Granting the application service account 'Owner' role on the entire Azure Subscription.

Why it fails: Granting 'Owner' is the opposite of least privilege.

Enable full disk encryption on the application server to protect any cached key material.

Why it fails: Full disk encryption protects data at rest on the server's disk, but the attacker already has root access and can read keys from memory or intercept them in use. It does not prevent misuse of the HSM itself, and the keys are stored in the HSM, not on the server's disk.

Enforce strict network segmentation so that only the application server can communicate with the HSM.

Why it fails: Network segmentation limits which hosts can reach the HSM but does not stop a compromised application server from issuing legitimate-looking crypto requests. Since the attacker has root on that server, they can still misuse the HSM through the allowed channel, failing to meet the requirement.

Configure the HSM to require a quorum of smart cards for key export operations.

Why it fails: Quorum-based export controls protect against unauthorized key export but do not prevent an attacker with root access from using the HSM to perform cryptographic operations, such as decrypting data, without exporting the key. The scenario requires preventing misuse, not just extraction, so this control is insufficient.

Kerberoasting

Why it fails: Kerberoasting targets service accounts by requesting Kerberos service tickets (TGS) and cracking their passwords offline. It does not directly access NTDS.dit; instead, it exploits weak service account passwords. The alert specifically mentions NTDS.dit access, which is not typical for Kerberoasting, making it an incorrect assumption here.

Pass-the-Hash

Why it fails: Pass-the-Hash involves using a captured NTLM hash to authenticate without knowing the plaintext password. It does not require direct access to NTDS.dit; the hash is typically obtained from memory (e.g., LSASS) or other sources. The scenario explicitly notes NTDS.dit file access, which is not a characteristic of Pass-the-Hash.

Golden Ticket

Why it fails: A Golden Ticket attack forges a Kerberos TGT using the KRBTGT account hash. While it requires obtaining the KRBTGT hash (often from NTDS.dit), the attack itself does not directly access NTDS.dit; it uses the hash to create tickets. The alert indicates direct file access, which is more aligned with DCSync or other extraction methods.

Configure a Group Policy to deny log on locally for the local Administrator account.

Why it fails: Denying local logon for the local Administrator account may break operational requirements if that account is needed for recovery or specific tasks. Moreover, it does not prevent remote lateral movement using the account, as the account could still be used for network logons or pass-the-hash attacks.

Disable the local Administrator account and use a domain account with complex password for administration.

Why it fails: Disabling the local Administrator account is a good practice, but using a domain account for administration increases the risk of credential theft and lateral movement because domain accounts often have broader access. The scenario requires mitigating lateral movement, and a domain account could be used to compromise other systems if stolen.

Rename the local Administrator account and set a strong, unique password.

Why it fails: Renaming and setting a strong password improves security but does not prevent lateral movement if the password is compromised through other means, such as pass-the-hash. The account remains enabled and could still be used for lateral movement if an attacker obtains the hash or password.

Transcription

Why it fails: Transcription logs all input and output of a PowerShell session to a text file. While it can capture executed commands, it does not de-obfuscate scripts and may miss encoded commands. It is more of an auditing feature and not designed for detecting obfuscated malicious code, so it is not the most critical capability here.

AMSI integration

Why it fails: AMSI (Antimalware Scan Interface) allows antivirus and EDR to scan PowerShell scripts before execution. It can detect known malicious patterns, but sophisticated obfuscation may bypass AMSI if not properly integrated. Script block logging is more reliable for capturing de-obfuscated code, making it the better choice for this requirement.

Module logging

Why it fails: Module logging records pipeline execution details for specific PowerShell modules. It is useful for auditing but does not capture the full script content, especially for obfuscated scripts that do not use modules. It would not reliably detect obfuscated malicious scripts, making it less critical than script block logging.

Enable server-side encryption with provider-managed keys and use security groups to control access.

Why it fails: Provider-managed keys mean the cloud provider controls the encryption keys, which may not meet compliance requirements for customer control. Security groups are network-level controls, not identity-based access controls, so they do not meet the requirement for access control based on user identity.

Use HTTPS for data in transit and enable versioning for data at rest.

Why it fails: HTTPS protects data in transit, not at rest, and versioning provides data recovery but not encryption. Neither addresses the requirement for encryption at rest or identity-based access control. This option is insufficient for the stated security objectives.

Use client-side encryption with a shared symmetric key and rely on network ACLs for access control.

Why it fails: Client-side encryption encrypts data before it is sent to the cloud, but using a shared symmetric key reduces security because the key is distributed to all users, increasing the risk of compromise. Network ACLs are not identity-based; they control traffic by IP, not user identity, so access control is not based on user identity as required.

Network segmentation between administrative workstations and servers

Why it fails: Network segmentation is a valuable defense-in-depth measure to limit lateral movement, but it does not directly enforce least privilege or accountability for administrative actions. It can reduce the attack surface but does not control the permissions granted to an account or log what that account does. It complements PAM but is not one of the two most critical controls for the stated goals.

Multi-factor authentication (MFA) for all administrative logins

Why it fails: MFA adds a critical layer of authentication security, but it does not enforce least privilege or provide accountability for what an administrator does after login. It protects against credential compromise but does not limit the scope of access or record actions. The scenario requires controls that restrict privileges and ensure actions are traceable, which MFA alone does not achieve.

Password vaulting with automatic rotation

Why it fails: Password vaulting with rotation is important for managing credentials, but it does not directly enforce least privilege or provide accountability for actions. It can prevent credential theft but does not control what an administrator can do once authenticated. Without JIT and session monitoring, a vaulted password still grants full access, failing to meet the specific goals.

The bucket was created in a region that does not enforce data residency restrictions

Why it fails: Region selection affects latency, cost, and regulatory residency obligations, but it has no bearing on whether an object is publicly readable. A bucket in any region remains private unless a policy, access control list, or account-level setting permits anonymous access, so regional placement is not a plausible cause of the unintended public exposure.

The objects were encrypted with a customer-managed key that the public cannot use

Why it fails: Customer-managed encryption keys control who can decrypt data, not who can retrieve it. An unauthenticated requester who lacks the key would receive an access denied or decryption failure rather than the object contents. Encryption therefore cannot explain a successful public read of the invoice objects, making this an unlikely cause of the reported exposure.

The bucket has versioning disabled, allowing older object versions to remain publicly readable

Why it fails: Versioning governs whether prior versions of an object are retained after overwrite or deletion; it does not create public readability. Disabling versioning may affect recovery and ransomware resilience, but it cannot make a private object reachable by an unauthenticated party, so it is not the cause of the observed exposure described in the scenario.

Local Security Policy on each workstation

Why it fails: Local policies apply only to the individual machine and are not centrally managed. Configuring each workstation manually is inefficient, error-prone, and does not ensure consistent enforcement. Domain-based Group Policy is the correct method for domain-wide settings.

Fine-Grained Password Policy

Why it fails: Fine-Grained Password Policies are used to apply different password policies to specific users or groups, not to set a domain-wide policy. They are exceptions to the Default Domain Policy and require careful planning. For a uniform policy across all users, the Default Domain Policy is appropriate.

Default Domain Controllers Policy

Why it fails: This policy applies only to domain controllers, not to workstations. While it is used for domain controller security settings, it does not affect password policies for regular domain users or workstations. Therefore, it would not enforce the required settings on all domain-joined workstations.

BitLocker Drive Encryption for encryption at rest and share permissions for access control.

Why it fails: While BitLocker handles encryption, share permissions alone are insufficient for restricting access to authorized finance personnel. Share permissions apply only to network access and are coarser than NTFS permissions, which are needed for detailed access control on a file server.

Encrypting File System (EFS) for encryption at rest and share permissions for access control.

Why it fails: EFS encrypts individual files and folders, but it is more complex to manage at scale and may not cover all files on the volume. Share permissions are less granular than NTFS permissions and cannot restrict access to specific users or groups as precisely. This combination is not ideal for a file server storing financial records.

EFS for encryption at rest and NTFS permissions for access control.

Why it fails: EFS can encrypt files, but it is not designed for full-volume encryption and can be bypassed if files are moved to unencrypted locations. NTFS permissions are appropriate for access control, but the encryption method does not meet the policy requirement for encrypting the entire file share at rest as robustly as BitLocker.

Attribute-Based Access Control (ABAC)

Why it fails: ABAC uses attributes (e.g., user department, time of day) to make access decisions. While powerful, it is more granular and complex than needed here. The requirement is clearly role-based, making RBAC simpler and more appropriate. ABAC would require defining and managing many attributes.

Mandatory Access Control (MAC)

Why it fails: MAC uses security labels and clearances to control access, typically in high-security environments. It is more rigid and not based on user roles. While it could enforce the policy, it is overly complex and not the best fit for a scenario that naturally maps to roles like DB_Admins and App_Service.

Discretionary Access Control (DAC)

Why it fails: DAC allows resource owners to set permissions at their discretion. This does not provide the centralized, role-based control required. It could lead to inconsistent permissions and does not inherently support the distinction between interactive and service account logins based on group membership.

Computer Configuration > System Settings > Advanced > Security

Why it fails: No such node exists in the Group Policy hierarchy; System Settings contains no Advanced security container. It is tempting because it sounds like a security location, but password complexity is enforced through Computer Configuration > Windows Settings > Security Settings > Account Policies.

User Configuration > Preferences > Control Panel Settings > Local Users and Groups

Why it fails: This path configures local user and group objects through Preferences, which applies settings non-enforced and outside the Security Settings extension. It would suit creating or modifying local accounts, not enforcing CIS password complexity, which lives under Account Policies.

Computer Configuration > Administrative Templates > Windows Components > Password

Why it fails: Administrative Templates hold registry-based policy for components such as Windows Update or BitLocker, not account password rules. This path would be right for configuring component behaviour, but password complexity is enforced via Security Settings Account Policies.

Use an IAM Group and add the EC2 instance to the group.

Why it fails: IAM groups hold IAM users, not EC2 instances, so the instance gains no permissions and cannot authenticate to S3. Groups are tempting because they simplify permission management, and they are correct when several human users need identical, centrally administered access.

Create an IAM user with access keys and embed them in the application configuration file.

Why it fails: Long-lived access keys stored in configuration files are static credentials that leak through code repositories and cannot be scoped to the instance. They are tempting because they work anywhere, and they are correct for external systems outside AWS that cannot assume an IAM role.

Modify the S3 bucket policy to allow 'All Principals' and restrict by IP address.

Why it fails: Allowing 'All Principals' with an IP condition grants access to any identity originating from that address range, not the instance's role, so a compromised host elsewhere in the range also gains entry. It is tempting because IP-based bucket policies suit fixed on-premises egress addresses, not dynamic EC2 identity.

Reinstall the Nessus Agent using the 'Force Install' flag.

Why it fails: Reinstallation discards the agent's existing configuration and link keys without first checking whether the agent service is running or linked to the correct container. It is tempting because a corrupt agent install genuinely causes silent non-reporting, but that is diagnosed after connectivity and linking are verified.

Manually add the IP address of the endpoint to the 'Allowed Assets' list in Tenable.io.

Why it fails: Allow-listing governs scan targeting, not agent registration; an agent reports over port 443 to the cloud, so an IP allow-list entry changes nothing. It is tempting because allow-lists do restrict which assets Tenable.io scans, which matters when excluding sensitive subnets from discovery scans.

Restart the Windows Management Instrumentation (WMI) service.

Why it fails: WMI supplies Windows host data to credentialed scans, not agent telemetry; Nessus Agents push results independently of WMI. It is tempting because a stalled WMI service does break credentialed patch and inventory collection on Windows endpoints, so restarting it is a valid fix in that scanning context.