Security Operations and Administration practice questions

Daily full backups to disk

Why it fails: Could lose up to 24 hours of data; recovery may be feasible but not optimal.

Weekly full backups to tape

Why it fails: Tape restoration is slow; weekly frequency may not meet 4-hour RTO.

Monthly full backups with daily differentials to tape

Why it fails: Tape is slow; may not meet RTO.

Immediately apply a patch

Why it fails: May not be available; rollback is safer.

Blame the change implementer

Why it fails: Not constructive; focus on process improvement.

Proceed and accept the risk

Why it fails: Not acceptable if vulnerability is significant.

Procedures for data backup and recovery

Why it fails: Backup procedures are typically part of a backup policy or operational procedure, not the AUP.

Guidelines for responding to security incidents

Why it fails: Incident response procedures are documented in an incident response plan, not in the AUP.

A list of approved social media platforms

Why it fails: Social media platforms may be covered in a separate policy or section, but the core of AUP for personal devices is about permissible use and security controls.

Configuration management database (CMDB)

Why it fails: A CMDB stores configuration information but does not actively detect changes; it is a repository, not a monitoring tool.

Vulnerability scanner

Why it fails: Vulnerability scanners identify known vulnerabilities but do not continuously monitor configuration changes.

Patch management tool

Why it fails: Patch management tools deploy updates but do not typically detect configuration changes.

Biometric readers on workstations

Why it fails: Biometric readers control access to the workstation but do not prevent connecting external devices.

Mantrap at building entrance

Why it fails: Mantraps control entry to the building but do not address workstation-level device connections.

CCTV monitoring

Why it fails: CCTV can record incidents but does not prevent unauthorized device connections.

The email contains an attachment from an unknown sender

Why it fails: Attachments are a common vector, but some legitimate emails have attachments. Urgency is a stronger indicator.

The email has grammatical errors or misspellings

Why it fails: While common, errors are not always present; some phishing emails are well-written.

The email address of the sender closely resembles a legitimate domain

Why it fails: Spoofed domains are common, but not all such emails are phishing. The urgency is more telling.

Weekly full backups and daily differential backups

Why it fails: Differential backups taken daily still result in up to 24 hours of potential data loss, exceeding the 1-hour RPO.

Monthly full backups and weekly incremental backups

Why it fails: This approach has an RPO of up to a week, far exceeding 1 hour.

Daily full backups with no incremental backups

Why it fails: Daily full backups cannot meet a 1-hour RPO because data loss could be up to 24 hours.

One copy stored in a different geographic location

Why it fails: The rule requires one copy offsite, which is a different location, but the phrase 'different geographic location' is ambiguous; the correct term is offsite.

Daily full backups

Why it fails: The rule does not specify backup frequency.

All backups must be encrypted

Why it fails: Encryption is recommended but not part of the 3-2-1 rule.

Smishing

Why it fails: Smishing uses SMS messages, not email.

Spear phishing

Why it fails: Spear phishing is a targeted form of phishing aimed at a specific individual or organization, but in this scenario the email is generic and not necessarily targeted.

Whaling

Why it fails: Whaling targets high-profile executives, but the email is from the CEO, not targeting the CEO.

Patch compliance

Why it fails: Patch compliance counts systems at approved patch levels; it says nothing about login sequences or source IP addresses. It is tempting because it is a standard vulnerability-management metric, and it would be correct when measuring exposure from unpatched hosts, not when detecting a brute-force attempt followed by a successful login.

Training completion

Why it fails: Training completion measures awareness programme participation, not authentication behaviour, so it cannot capture failed logins followed by a suspicious success. It is tempting because security programmes track it for compliance reporting, and it would be the right metric when evidencing staff phishing-awareness coverage rather than detecting an intrusion event.

Mean time to detect (MTTD)

Why it fails: MTTD measures elapsed time from compromise to detection, not the event itself, so it cannot capture the failed-then-successful login pattern. It is tempting because it is a security-operations metric, and it would be correct when assessing how quickly the SOC identified this intrusion after it occurred.

Perform post-implementation review

Why it fails: Post-implementation review occurs after the change is implemented.

Develop a rollback plan

Why it fails: A rollback plan should be developed before implementation, but testing comes after approval.

Implement the change in production

Why it fails: Implementation comes after testing to ensure the change is safe.

One copy in the cloud

Why it fails: The rule specifies one copy offsite, not necessarily cloud.

Daily full backups

Why it fails: Frequency is not part of the 3-2-1 rule.

All copies on the same media

Why it fails: The rule requires two different media types, not all on same.

Data Handling Policy

Why it fails: Data handling policy governs data classification and protection, not password sharing.

Password Policy

Why it fails: Password policy covers complexity, expiration, and reuse, but the specific prohibition of sharing is often in the AUP.

Remote Access Policy

Why it fails: Remote access policy covers how to connect remotely, not password sharing.

Implement the change immediately

Why it fails: Implementation should occur after testing and rollback planning.

Document the rollback plan

Why it fails: Rollback plan should be documented before approval, not after.

Perform a post-implementation review

Why it fails: This occurs after implementation, not before.

Implement a clean desk policy

Why it fails: Clean desk policy is unrelated to physical access controls.

Install a CCTV camera to monitor the mantrap

Why it fails: CCTV is detective, not preventive.

Use biometric readers on both doors

Why it fails: Biometrics don't prevent propping open doors.

Enable multi-factor authentication (MFA) for all interactive logons.

Why it fails: MFA strengthens authentication for interactive logons, but service accounts typically run as non-interactive processes and cannot easily use MFA. The attack exploited excessive privileges, not weak authentication. MFA would not prevent an attacker from leveraging the service account's domain admin rights once the account is compromised.

Conduct regular vulnerability scans on all servers.

Why it fails: Vulnerability scans identify missing patches and known weaknesses but are unlikely to detect an over-privileged service account, which is a configuration issue. Scanning does not remediate excessive permissions. It is a detective control that might miss this type of logical flaw.

Deploy a privileged access management (PAM) solution to vault service account credentials.

Why it fails: PAM vaults credentials and can rotate passwords, reducing the risk of credential theft, but it does not remove excessive privileges from the service account. If the account still has domain admin rights, an attacker who compromises it can still cause damage. PAM is a valuable control but not the most effective for this specific misconfiguration.

Assign the same employee to both enter invoices and reconcile the corresponding bank statements.

Why it fails: Combining invoice entry with reconciliation lets one person conceal unauthorized payments by adjusting records to match. This is a direct conflict of duties. Reconciliation should be performed by someone independent of transaction entry so discrepancies are detected rather than hidden.

Allow the system administrator to approve payments when the normal approver is on leave.

Why it fails: Letting a system administrator approve payments blends technical administration with financial authorization, creating a separation of duties conflict. It also bypasses the intended approval chain. A better approach is a designated backup approver within the business function, not the administrator who controls the platform.

Grant the accounts payable manager full administrative rights to the payment application to resolve issues quickly.

Why it fails: Concentrating full administrative rights in one manager violates separation of duties by allowing that person to both configure and execute payments. It increases the risk of undetected fraud and errors. Administrative privilege should be limited and monitored, not expanded, when separation of duties is the goal.

Reset the user's password.

Why it fails: Resetting the password might lock out the legitimate user, but if the account is compromised, the attacker may have other persistence mechanisms. It does not immediately stop access if the attacker has already established a session or backdoor. Disabling the account is a stronger containment measure.

Notify law enforcement.

Why it fails: Notifying law enforcement may be required eventually, but it is not the first step. Immediate containment is necessary to prevent further damage. Law enforcement involvement typically follows internal investigation and containment, and may be subject to legal and regulatory considerations.

Review the file's contents to determine sensitivity.

Why it fails: Reviewing the file's contents may be part of the investigation, but it does not stop the ongoing threat. The account could still be used for further malicious activity. The first priority is to contain the incident, not to assess data sensitivity, which can be done after the account is secured.

To provide a basis for access control decisions.

Why it fails: Access control decisions are indeed influenced by classification, but this is a secondary use rather than a primary objective. The core objectives are determining protection levels and meeting compliance requirements. While classification informs access control, it is not the main goal; it is a downstream application.

To enable faster backup and recovery operations.

Why it fails: Faster backup and recovery is an operational benefit that may result from tiered storage strategies, but it is not a primary objective of data classification. Classification focuses on security and compliance, not backup performance. This option misrepresents the purpose of classification.

To reduce storage costs by identifying redundant data.

Why it fails: Reducing storage costs through deduplication is a data management goal, not a primary objective of classification. While classification can help identify data that can be archived or deleted, its main purpose is to ensure proper handling and protection, not cost reduction. This distractor confuses classification with storage optimization.

Mean time to failure (MTTF)

Why it fails: MTTF is the expected time until a system or component fails. It is used for reliability engineering, not for defining recovery time frames. It does not specify how quickly a system must be restored, so it is not relevant to meeting the restoration time requirement.

Service level agreement (SLA)

Why it fails: An SLA is a contract between a service provider and a customer that defines expected service levels. While it may include recovery requirements, it is not a technical objective used to design disaster recovery. RTO and RPO are the specific metrics that drive recovery planning.

Maximum tolerable downtime (MTD)

Why it fails: MTD is the maximum time a system can be down before unacceptable consequences occur. While related, it is a business-driven limit, not a technical recovery objective. RTO and RPO are the specific parameters used to plan and measure recovery capabilities. MTD is broader and not one of the two primary objectives.