CAS-005 Practice Questions

The core issue is password fatigue, where users must manage too many credentials, leading them to engage in insecure practices like writing passwords down. A Single Sign-On (SSO) solution directly addresses this root cause. By implementing SSO, users authenticate once to a central service and are then granted access to multiple integrated applications without re-entering credentials. This drastically reduces the number of passwords a user needs to remember, eliminating the primary motivation for writing them down. SSO also enhances security by providing a single, centrally managed, and auditable point of authentication that can be more robustly protected.

A. Increasing password complexity to require at least 16 characters: This would worsen the problem by making passwords even harder to remember, increasing the likelihood that users will write them down.

C. Requiring users to use an open-source password manager: While a password manager helps, SSO is a superior enterprise solution as it offers centralized control, policy enforcement, and auditing, rather than relying on individual user adoption and management.

D. Implementing an MFA solution to avoid reliance only on passwords: MFA mitigates the risk of a compromised password but does not solve the underlying issue of password fatigue that is causing the insecure behavior.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-63C

Digital Identity Guidelines: Federation and Assertions.

Reference: Section 5.1.1

"Benefits to the RP".

Content: This document explicitly states a key benefit of federation (the technology behind SSO) is the "Reduced need for the subscriber to remember a different username and password for each RP [Relying Party/application]." This directly supports SSO as the solution to the problem of managing too many passwords.

2. Carnegie Mellon University

CyLab

A Large-Scale Study of Password-Policy-Related Frustration and Issues.

Reference: Section 6

"Discussion".

Content: This academic study highlights that a high number of accounts and restrictive password policies lead to user frustration and coping mechanisms like writing passwords down. It suggests that solutions like SSO can alleviate this burden. (DOI: https://doi.org/10.1145/3460120.3484559)

3. University of California

Berkeley

Information Security Office

Single Sign-On (SSO).

Reference: "What are the benefits of SSO?" section.

Content: This university resource explains that a primary benefit of SSO is that it "eliminates the need for users to remember multiple sets of usernames and passwords

" which improves user experience and security by reducing password proliferation.

Local caching is the most effective solution for this scenario. A local caching server, often part of a proxy or WAN optimization controller, stores frequently accessed content within the satellite office's network. When a user requests this content again, it is delivered from the local cache at LAN speed, rather than being re-fetched over the constrained WAN link. This directly addresses the core requirements by preserving bandwidth and increasing speed for both internal and external resources. Modern caching proxies can also function as secure web gateways, inspecting traffic for threats and thus maintaining security visibility.

A. Distributed connection allocation primarily involves load balancing traffic across multiple servers or links, which does not inherently reduce bandwidth consumption for repeated content access.

C. A content delivery network (CDN) is a service used by content providers to distribute their data closer to end-users; it is not an architecture implemented by a consumer to optimize all inbound traffic.

D. SD-WAN optimizes traffic routing over various WAN links. While some solutions include caching, "local caching" is the specific technique that solves the problem, and "vertical heterogeneity" is not a standard SD-WAN term.

---

1. Internet Engineering Task Force (IETF). RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching.

Section 2

"Overview of Caching

" Paragraph 1: "The goal of caching in HTTP is to reduce request latency and network overhead... By reusing a prior response

a cache can reduce the amount of network traffic necessary to satisfy a request

which can be a significant cost savings for both the client and the service." This directly supports caching as a method to preserve bandwidth ("reduce network overhead") and increase speed ("reduce request latency").

2. Hari Balakrishnan

et al. 6.829 Computer Networks

Lecture 19: Web

Caching

CDNs. MIT OpenCourseWare

Fall 2002.

Slide 10

"Proxy Caching": The lecture notes describe proxy caching as a solution deployed "on behalf of a set of clients (e.g.

an enterprise)." It explicitly lists the benefits as "Reduces access latency" and "Reduces bandwidth on access link

" which aligns perfectly with the requirements of the satellite office.

3. Kaur

M.

& Singh

S. (2014). A Survey of WAN Optimization Techniques. International Journal of Computer Applications

99(12)

32-36. DOI: 10.5120/17430-8001

Section 3

"WAN Optimization Techniques

" Subsection "Caching/Proxy": "Caching is the most common technique used for WAN optimization. It works by storing frequently accessed data on a local device... This reduces the amount of data that needs to be transmitted over the WAN

which can improve performance and reduce bandwidth costs." This academic survey confirms that caching is a primary and direct method for solving the problem described.

Key stretching is a cryptographic technique specifically designed to enhance the security of password-based systems. It increases the computational work required to verify a password by repeatedly applying a cryptographic hash function to the password and a salt. This process, implemented by algorithms like PBKDF2, bcrypt, and scrypt, makes brute-force and dictionary attacks significantly slower and more resource-intensive for an attacker. This directly addresses the developer's need to improve the cryptographic strength of the password-storage component without replacing the entire crypto-module, as it builds upon existing hash functions.

A. Key splitting: A key management technique for availability and security by distributing parts of a key, not for strengthening password hashing.

B. Key escrow: A key recovery mechanism involving a trusted third party, which does not enhance the cryptographic strength of password storage.

C. Key rotation: A best practice for periodically changing encryption keys to limit the impact of a key compromise; it is not a technique applied to strengthen individual password hashes.

D. Key encryption: The practice of encrypting a key with another key (key wrapping), used for protecting keys at rest, not for strengthening the password hashing process itself.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-132

Recommendation for Password-Based Key Derivation.

Section 2

Introduction: This document states

"A password-based key derivation function (PBKDF) is used to derive a key from a password or passphrase. It is intended to be computationally intensive in order to discourage brute-force attacks on the password." This computational intensity is the core principle of key stretching.

2. National Institute of Standards and Technology (NIST) Special Publication 800-63B

Digital Identity Guidelines: Authentication and Lifecycle Management.

Section 5.1.1.2

Memorized Secret Verifiers: This section mandates that password verifiers (hashes) "SHALL be derived from the memorized secret using a key derivation function (KDF)

such as PBKDF2... The KDF SHALL include a salt and an iteration count." The iteration count is the mechanism for key stretching.

3. Boneh

D. (2020). CS 255: Introduction to Cryptography

Lecture 10 Notes. Stanford University.

Section on "Slowing down the attacker": The lecture notes explain that to defend against offline dictionary attacks

a slow hash function is needed. It introduces PBKDF2 as a standard that "stretches a short key" by applying a pseudorandom function (like HMAC-SHA256) a configurable number of times (e.g.

c=100

000).

4. Provos

N.

& Mazières

D. (1999). A Future-Adaptable Password Scheme. Proceedings of the 1999 USENIX Annual Technical Conference.

Section 2

"Design Goals": This seminal paper

which introduces the bcrypt algorithm

explicitly states a design goal is to make the hashing process slow and computationally expensive. It notes

"The time to check a password on a fast machine should be non-trivial... making a brute-force attack more difficult." This is the foundational concept of key stretching for password security.

Prompt injection is an attack technique that involves crafting malicious inputs to manipulate a Large Language Model (LLM) into performing unintended actions, such as ignoring previous instructions or revealing sensitive information. This attack fundamentally exploits the model's input processing channel. Input sanitation, a security control that involves filtering, validating, and cleaning user-provided data before it is processed, is a direct and primary countermeasure. By sanitizing the prompt, a system can attempt to remove or neutralize the malicious instructions, thereby mitigating the risk of the model being compromised by the injected content.

A. Model inversion: This is a privacy attack that reconstructs sensitive training data by repeatedly querying a model. It is mitigated by techniques like differential privacy, not primarily by input sanitation.

C. Data poisoning: This attack corrupts the model's training dataset to compromise its integrity. It occurs during the training phase, whereas input sanitation is applied during the inference (user interaction) phase.

D. Non-explainable model: This refers to the "black box" nature of complex AI, where it is difficult to understand its decision-making process. This is an inherent characteristic, addressed by Explainable AI (XAI) methods, not input controls.

---

1. OWASP Foundation. (2023). OWASP Top 10 for Large Language Model Applications. LLM01: Prompt Injection. This document identifies prompt injection as the top vulnerability for LLMs and lists "input validation and sanitization" as a key mitigation strategy. It states

"Implement robust input validation and sanitization to limit adversarial input."

2. NIST. (2023). Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST Special Publication 800-218A (Draft). This publication categorizes prompt injection as a type of evasion attack that manipulates inputs at inference time. Section 4 discusses defenses

including input sanitization

as a method to defend against such input-based attacks.

3. Parno

B.

et al. (2023). Living with the Trickster: A Foundational Perspective on AI/ML Trust and Safety. Stanford University

Center for Research on Foundation Models (CRFM). The paper discusses LLM vulnerabilities

including prompt injection

framing it as an input-based security problem where the model is tricked by crafted prompts

reinforcing that input control is the relevant defense domain.

The SIEM log displays classic indicators of a brute-force or password spraying attack: an extremely high count (1024) of failed login attempts for a privileged account ('admin') from a single source IP. The SIEM has correctly analyzed this, assigned a high-risk score (95), and provided a "Disable Account" recommendation. The most appropriate and mature security response is to implement automation, often via a Security Orchestration, Automation, and Response (SOAR) platform, to execute this recommendation automatically. This approach minimizes the mean time to respond (MTTR), contains the threat immediately, and hardens the security posture against future, similar attacks without requiring manual intervention for every incident.

A. The log is being captured and analyzed correctly, as evidenced by the detailed and high-risk alert in the SIEM.

B. Changing the password is a reactive measure that does not stop the ongoing attack; the immediate priority is containment by locking the account.

C. This is a general access control policy (least privilege) and does not address the specific, active brute-force attack shown.

1. NIST SP 800-61 Rev. 2

Computer Security Incident Handling Guide. Section 3.2.3

"Containment

" emphasizes the importance of taking action to prevent an incident from causing further damage. Disabling an account under active attack is a primary containment strategy. Implementing automation aligns with creating efficient and repeatable containment procedures.

2. NIST Cybersecurity Framework (CSF) v1.1. The "Respond" (RS) function

particularly category RS.RP ("Response Planning")

advocates for establishing processes to ensure timely response and recovery. Automating the response to a high-confidence SIEM alert

as suggested in option D

is a direct implementation of this principle (RS.RP-1: "Response plan is executed during or after an event").

3. Tounsi

W.

& Frikha

M. (2018). A survey of security orchestration and automation. Journal of Information Security and Applications

42

1-10. https://doi.org/10.1016/j.jisa.2018.06.003. This academic review discusses how Security Orchestration

Automation

and Response (SOAR) platforms integrate with SIEMs. On page 3

the paper describes the core function of SOAR as automating incident response workflows (playbooks) triggered by SIEM alerts

with common actions including "blocking an IP address... or disabling a user account." This directly supports the action in option D.

The most appropriate and robust solution to ensure logs are properly retained in an enterprise environment is to use a Security Information and Event Management (SIEM) system. A SIEM is specifically designed to collect, aggregate, normalize, and securely store logs from disparate sources, including legacy platforms. By forwarding the logs from the legacy system to the SIEM, the organization centralizes log management, overcomes the local storage limitations of the legacy platform, and ensures compliance with long-term retention policies mandated by the audit. This approach provides a scalable, secure, and searchable archive for forensic analysis and compliance reporting.

A. A scheduled task is a brittle, localized solution that lacks the centralized management, security, and analytical capabilities inherent in a proper log management infrastructure.

B. Event-based triggers are designed for alerting on specific conditions, not for comprehensive log collection, and would result in incomplete data retention for audit purposes.

D. Building a custom script and database is inefficient, costly to maintain, and less secure than using a dedicated, industry-standard SIEM platform designed for this purpose.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-92

Guide to Computer Security Log Management.

Section 3.1.3

"Log Storage and Retention

" states: "Organizations should also consider using a dedicated log server for centralized log storage... Centralized log storage facilitates long-term log retention and reduces the risk of logs on individual hosts being lost..." A SIEM is a primary example of a system providing this centralized function.

2. Carnegie Mellon University

Software Engineering Institute

"Common Sense Guide to Mitigating Insider Threats

5th Edition."

Practice 17: Deploy a Log Management System

Page 111

recommends organizations to "Aggregate and centrally store logs from all relevant sources (e.g.

network devices

servers

databases

applications)." This directly supports using a central system like a SIEM to solve the problem described.

3. Al-Abassi

A.

Karim

A.

& Al-Ogaili

A. (2017). A Survey of SIEM Tools. In Proceedings of the International Conference on Big Data and Internet of Things (BDIoT’17). ACM

New York

NY

USA

Article 29

pp. 1–6.

Section 2

"SIEM Architecture

" describes the fundamental components of a SIEM

highlighting the "Log collection" and "Log storage" functions. The text explains that a core purpose of a SIEM is to gather logs from various sources (agents or collectors) and store them in a central repository (database or file system) for analysis and retention.

DOI: https://doi.org/10.1145/3175828.3175857

The incident table reveals a 30-minute delay between the detection of the phone system outage (08:00) and the notification to IT support (08:30). This gap occurred because the notification method was reactive, relying on a user to report the problem. To accelerate future incident response, the organization must improve its proactive monitoring capabilities. Enabling dashboards for service status monitoring provides real-time, centralized visibility into the health of critical systems. This allows the IT and security teams to identify and begin investigating issues as soon as they are detected by monitoring tools, rather than waiting for manual user reports, thereby significantly reducing the Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR).

A. Automate alerting to IT support for phone system outages.

This is a valid but less comprehensive solution. Enabling dashboards (B) is a foundational step that provides visibility for numerous services, not just the phone system.

C. Send emails for failed log-In attempts on the public website.

This action is irrelevant to the incident described, which was a phone system outage, not a web application security issue.

D. Configure automated Isolation of human resources systems.

This is a containment or response action (SOAR), not a detection or notification improvement, and is unrelated to the phone system incident.

---

1. NIST Special Publication 800-61 Rev. 2

Computer Security Incident Handling Guide. Section 3.2

"Detection and Analysis

" emphasizes that timely and accurate detection is often the most challenging part of incident response. The guide discusses precursors and indicators

which are data points typically aggregated and visualized in monitoring dashboards to provide situational awareness and enable faster detection than manual user reports. (Page 22).

2. Carnegie Mellon University

Software Engineering Institute (SEI)

Ten Strategies of a World-Class Cybersecurity Operations Center. Strategy 4

"Gain and maintain situational awareness

" directly supports the use of dashboards. The publication states

"Situational awareness is the ability to identify

process

and comprehend the critical elements of information about what is happening to the team with regards to the mission." Dashboards are a primary tool for achieving this comprehension in a SOC or IT operations environment. (Page 13).

3. Splunk Documentation

Dashboards and Visualizations Manual. As official documentation for a major SIEM and monitoring platform

this source describes the function of dashboards: "Dashboards contain a collection of panels. Panels can include data visualizations... Dashboards are a way to monitor for activities and conditions in real time." This functionality directly addresses the need for proactive

real-time service status monitoring to reduce detection and notification delays. (Splunk Enterprise 9.x

"About Dashboards" section).

The problem describes emails being sent to spam, which is a common symptom of email authentication failure. Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are the three primary DNS-based technologies used to authenticate email and prevent spoofing.

SPF is a TXT record that lists authorized mail servers for a domain.

DKIM uses a public key published in a DNS TXT record to verify a digital signature on the email. A reissued certificate often involves new cryptographic keys, requiring an update to the DKIM record.

DMARC is a TXT record that defines the policy for handling emails that fail SPF or DKIM checks.

Updating these three records ensures that the sender's identity is properly authenticated by receiving mail servers, which resolves the issue of legitimate emails being marked as spam.

D. DNSSEC: Secures DNS records from tampering but does not directly authenticate the email sender's identity to prevent spam classification.

E. SASC: Not a standard DNS record type or a recognized acronym related to email security or DNS.

F. SAN: A field within a digital certificate specifying additional hostnames, not a type of DNS record to be updated.

G. SOA: Contains administrative zone data; updating it is a procedural step but does not fix the underlying email authentication failure.

H. MX: Directs email traffic to the correct mail server but does not authenticate the messages, which is the root cause of the spam issue.

---

1. Internet Engineering Task Force (IETF) RFC 7489

"Domain-based Message Authentication

Reporting

and Conformance (DMARC)": Section 3

"How DMARC Works

" explicitly states that DMARC is a mechanism that "uses the results of SPF and DKIM" to determine the authenticity of an email message and provides instructions to receiving mail servers on how to handle authentication failures. This establishes the interconnectedness of all three records.

2. Internet Engineering Task Force (IETF) RFC 6376

"DomainKeys Identified Mail (DKIM) Signatures": Section 3.6.2

"The TXT Resource Record

" details how the public key used to verify the email's signature is stored in a DNS TXT record. A change in the server's keys

which can occur during a certificate reissue

would necessitate updating this DNS record.

3. Internet Engineering Task Force (IETF) RFC 7208

"Sender Policy Framework (SPF) for Authorizing Use of Domains in Email": Section 3.1

"Publication

" specifies that the SPF policy for a domain is published as a TXT record in the DNS

which is used by receivers to verify the sending mail server's IP address.

4. MIT Information Systems and Technology (IS&T) Knowledge Base

"What are SPF

DKIM

and DMARC?": This university resource explains

"SPF

DKIM

and DMARC are three email authentication methods that help prevent spammers from sending messages on behalf of your domain... When properly configured

these records also help legitimate messages from being marked as spam." This directly links the three records to solving the problem described in the scenario.

5. Google Workspace Admin Help

"Ensure mail delivery & prevent spoofing (SPF

DKIM

DMARC)": This official vendor documentation states

"We strongly recommend you always set up these email authentication methods for Gmail: SPF

DKIM

DMARC... [They] help protect your domain against spoofing

and help prevent your outgoing messages from being marked as spam." This confirms that all three are required to fix deliverability issues.

The user's access was denied due to the failure of the "Require MFA from untrusted locations" Conditional Access Policy. This policy was triggered because the user's IP address (198.51.100.23) was geolocated to Argentina. If the user is a legitimate employee attempting to access resources from a known trusted location (e.g., a corporate office or home network), this log indicates the IP geolocation service used by the authentication server is inaccurate. This misidentification of the user's true location is the most likely root cause for the application of a stricter, location-based policy that the user subsequently failed.

A. The log explicitly shows that an MFA requirement was enforced and failed; it was not bypassed.

C. The denial was due to a failed MFA challenge, not a direct block policy. The "Block access" policy was not applied.

D. The evidence is specific to one user ("j.doe"), and the primary trigger is the location policy, making geolocation the most probable root cause.

1. Microsoft Entra Documentation

"Location condition in Microsoft Entra Conditional Access

" Microsoft Learn. This document details how Conditional Access policies use IP geolocation data to enforce controls. It states

"The locations condition is commonly used to... require multifactor authentication for users accessing a service when they're off the corporate network." The scenario in the question directly reflects a failure based on this mechanism

where the system's determination of the user's location is the pivotal factor. (Refer to the section "Locations condition").

2. Gharaibeh

M.

et al. (2017). "A Survey on IP Geolocation." IEEE Communications Surveys & Tutorials

19(4)

pp. 2844-2885. DOI: 10.1109/COMST.2017.2735667. This peer-reviewed survey discusses the techniques and inherent limitations of IP geolocation services. Section IV

"ACCURACY OF GEOLOCATION DATABASES

" highlights that inaccuracies are common

with country-level identification being generally high but still imperfect. Such inaccuracies can lead to incorrect policy enforcement in security systems that rely on this data

as seen in the question.

3. NIST Special Publication 800-207

"Zero Trust Architecture

" August 2020. Section 2.1

"Zero Trust Principles

" describes that access policies are dynamic and based on context

including "observable state of client identity

application/service

and the requesting asset." The network location is a key part of this observable state. An inaccurate location signal (misidentified geolocation) leads to an incorrect policy decision

which is a fundamental challenge in implementing a Zero Trust Architecture.

The log snippet indicates a successful DNS zone transfer (qrytype: AXFR) was executed from an external IP address (19.27.214.22). This type of query allows an attacker to download the entire DNS zone file, revealing the internal network topology, hostnames, and IP addresses of sensitive servers (e.g., directoryserver1, msn-crit-apcs). This information is invaluable for reconnaissance and subsequent lateral movement. The most direct and effective mitigation is to configure the DNS server to disable or strictly control zone transfers, permitting them only from the IP addresses of authorized secondary DNS servers and denying all others.

B. Restricting DNS traffic to UDP/53: This is incorrect because while most standard queries use UDP, zone transfers and large responses legitimately require TCP. Blocking TCP/53 entirely would break necessary DNS functions.

C. Implementing DNS masking on internal servers: This is incorrect because while split-horizon DNS is a good practice, it does not prevent the zone transfer itself. A misconfigured server could still allow the transfer of the internal zone view.

D. Permitting only clients from internal networks to query DNS: This is incorrect as it would block all legitimate external queries for public resources (e.g., the company website), rendering public-facing services inaccessible to the internet.

---

1. National Institute of Standards and Technology (NIST) Special Publication 800-81-2

Secure Domain Name System (DNS) Deployment Guide. Section 3.3.1

"Restrict Zone Transfers

" states

"Zone transfers should be restricted to prevent unauthorized users from obtaining a copy of a zone’s contents... DNS servers should be configured to allow zone transfers only to explicitly authorized servers." This directly supports disabling open zone transfers. (Page 16).

2. Internet Systems Consortium (ISC)

BIND 9.18.24 Administrator Reference Manual. The documentation for the allow-transfer option specifies its use for creating an access control list (ACL) of hosts permitted to receive zone transfers. The default is to allow transfers to all hosts

which is insecure. The manual guides administrators to restrict this to only known

trusted secondary servers. (Section: "The allow-transfer option").

3. University of California

Berkeley. CS 161: Computer Security

Lecture 18: Network Security II. Course materials discuss DNS security vulnerabilities

explicitly identifying zone transfers (AXFR) as a method for attackers to map an entire internal network. The recommended countermeasure is to configure DNS servers to restrict zone transfers to only authorized secondary name servers.