The matching aligns each access control model with its defining characteristic.

• Mandatory Access Control (MAC) is a centralized model where a system authority enforces access based on security labels (e.g., clearances and classifications). The owners or end users of objects do not have the authority to change these access rules.
• Discretionary Access Control (DAC) is a decentralized model where the owner (a subject) of a resource (an object) has the discretion to grant or deny access to other subjects. This gives the subject total control over the objects they own.
• Role Based Access Control (RBAC) simplifies administration by assigning permissions to roles that correspond to job functions. Users are then assigned to these roles, inheriting the associated permissions necessary for their duties.
• Rule-based access control uses a set of configurable rules or criteria to make access decisions. The specific scenario described—dynamically assigning roles based on criteria—is a form of rule-based logic applied to an RBAC framework, often seen in modern identity management systems.

National Institute of Standards and Technology (NIST). (2017). NIST Special Publication 800-192: Verification and Test Methods for Access Control Policies/Models. Section 2.1, "Access Control Policies/Models Definitions". This document defines MAC as non-discretionary and DAC as allowing owners to specify access. DOI: https://doi.org/10.6028/NIST.SP.800-192

National Institute of Standards and Technology (NIST). (n.d.). Glossary: Role-Based Access Control. Computer Security Resource Center. Retrieved from https://csrc.nist.gov/glossary/term/role_based_access_control. This source defines RBAC as being "based on user roles...Role permissions may be inherited through a role hierarchy and typically reflect the permissions needed to perform defined functions within an organization."

Stallings, W., & Brown, L. (2018). Computer Security: Principles and Practice (4th ed.). Pearson. Chapter 4, "Access Control". This textbook provides foundational academic descriptions, explaining that with DAC, "an entity may be granted access rights that enable the entity, by its own volition, to enable another entity to access some resource" (p. 116), whereas with MAC, controls are "not subject to the object owner's discretion" (p. 120).

Hu, V. C., Ferraiolo, D., Kuhn, R., Friedman, A. R., Lang, A. J., et al. (2013). Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST Special Publication 800-162. Section 2.3.4 discusses how ABAC (a form of rule-based control) can be used to implement dynamic role assignment, stating, "In some cases the subject's assigned role...may be determined dynamically from subject attributes." This directly supports the match for rule-based access control. DOI: https://doi.org/10.6028/NIST.SP.800-162

The question asks to identify the value comparison that accurately reflects the agile development approach. The Agile Manifesto outlines four core values that prioritize certain aspects of software development over others. The second value stated in the manifesto is "Working software over comprehensive documentation." This emphasizes the delivery of functional, valuable software to the end-user as the primary measure of progress, rather than the creation of extensive documentation which was common in traditional, plan-driven models like the Waterfall methodology. The other options present inverted versions of the remaining three agile values.

1. Beck

K.

Beedle

M.

van Bennekum

A.

Cockburn

A.

Cunningham

W.

Fowler

M.

Grenning

J.

Highsmith

J.

Hunt

A.

Jeffries

R.

Kern

J.

Marick

B.

Martin

R. C.

Mellor

S.

Schwaber

K.

Sutherland

J.

& Thomas

D. (2001). Manifesto for Agile Software Development. AgileManifesto.org. Retrieved from https://agilemanifesto.org/. The document explicitly states the four core values

including "Working software over comprehensive documentation."

2. Fox

A.

& Patterson

D. (2015). CS 169: Software Engineering

Lecture 2: Agile/XP. University of California

Berkeley

EECS Department. Slide 11

"Agile Manifesto

" directly quotes the four values

confirming that options A

B

and C are inversions of the stated principles.

3. Abrahamsson

P.

Salo

O.

Ronkainen

J.

& Warsta

J. (2002). Agile software development methods: Review and analysis. VTT Publications 478. Section 3.1

"The Agile Manifesto

" p. 19

lists and discusses the four values

corroborating that "Working software over comprehensive documentation" is a core tenet.

The deployment phase of establishing a vulnerability management program focuses on implementing the designed program and making it operational. A fundamental task in this phase is to select, procure, and configure the necessary supporting technologies, such as vulnerability scanners, patch management systems, and ticketing systems. These tools form the technical foundation of the program, and their deployment is a prerequisite for subsequent operational activities like scanning, analysis, and remediation.

1. Carnegie Mellon University

Software Engineering Institute (CMU/SEI). In the technical note "A Framework for a Vulnerability Management Program

" the authors state

"The selection of tools is a critical step in the implementation of a vulnerability management program." The deployment phase is synonymous with the implementation phase

where the planned program is put into action.

Source: Alberts

C.

& Dorofee

A. (2005). A Framework for a Vulnerability Management Program (CMU/SEI-2005-TN-028). Carnegie Mellon University. (See Section 3.3

"Tool Selection").

2. NIST Special Publication 800-100

"Information Security Handbook: A Guide for Managers." This guide outlines the information security program life cycle

which includes initiation

development/acquisition

implementation

operation/maintenance

and disposal. The selection and procurement of technologies fall squarely within the "development/acquisition" phase

which directly precedes the "implementation" (or deployment) phase. In the context of establishing a new program

these are often grouped as deployment activities.

Source: NIST SP 800-100

Chapter 3

"Information Security Program Management

" Section 3.3

"Information Security Program Life Cycle."

3. University of California

Berkeley

Information Security Office. Courseware and guidance on establishing security programs consistently place budgeting and charter development in the initial "Strategy & Plan" phase

while tool acquisition and implementation occur in the "Build/Deploy" phase. Measuring metrics occurs in the final "Measure & Improve" phase.

Source: UC Berkeley Security

"Vulnerability Management Program

" Program Development Lifecycle documentation. (Illustrates the standard phased approach to program creation).

Software security functional requirements must be defined early in the Software Development Life Cycle (SDLC) to ensure security is built-in, not bolted on. This process logically follows the initial analysis of the system's purpose and the data it will handle. First, the business functional analysis determines what the system needs to do. Second, data security categorization (e.g., per FIPS 199) assesses the sensitivity of the information being processed. Only after understanding both the system's function and the data's value can appropriate and specific security requirements (e.g., access controls, encryption levels) be defined. This "shift left" approach is fundamental to secure systems engineering.

1. NIST Special Publication 800-64 Revision 2

Security Considerations in the System Development Life Cycle.

Section 2.1

Initiation Phase: This section states

"During the Initiation Phase

the need for a system is expressed and the purpose of the system is documented... Security requirements should be identified and discussed at this early stage." It explicitly links the initial business need and the security categorization (based on FIPS 199) as precursors to defining these requirements.

2. NIST Special Publication 800-160 Volume 1

Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems.

Section 2.3.2

Stakeholder Needs and Requirements Definition Process: This section describes the process to "define the stakeholder requirements for a system." It emphasizes that this occurs at the beginning of the life cycle to capture all needs

including security

which are derived from the business or mission objectives and the required level of protection for assets.

3. Federal Information Processing Standards Publication (FIPS) 199

Standards for Security Categorization of Federal Information and Information Systems.

Section 3

Categorizing Information and Information Systems: This standard establishes the importance of categorizing information based on confidentiality

integrity

and availability impacts. This categorization is a foundational step in the risk management process and directly informs the selection of security controls and requirements early in the SDLC.

A Cost-Benefit Analysis (CBA) is a fundamental financial process used in risk management to evaluate the viability of a security initiative. It directly compares the monetary cost of implementing and maintaining a control against its projected financial benefit. This benefit is typically measured as the reduction in risk, often quantified by the decrease in the Annualized Loss Expectancy (ALE). The final output of a CBA is a data-driven, financial argument (e.g., Return on Security Investment - ROSI) that provides a quantifiable justification for management to decide whether to approve the expenditure. It translates a technical security requirement into a business-centric financial decision.

1. National Institute of Standards and Technology (NIST). (2012). Guide for Conducting Risk Assessments (NIST Special Publication 800-30

Revision 1).

Section 3.3.3

Analysis of Alternatives: This section describes the process of evaluating different courses of action for risk response. It states that organizations should "evaluate the relative advantages and disadvantages (e.g.

effectiveness

feasibility

cost-benefit) of the alternative courses of action." This highlights that the CBA is the tool for providing a justifiable comparison.

2. Gordon

L. A.

& Loeb

M. P. (2002). The Economics of Information Security Investment. ACM Transactions on Information and System Security

5(4)

438–457. https://doi.org/10.1145/581271.581274

Page 440: The paper introduces an economic model for information security investment

stating

"The model shows how the optimal amount to invest in information security is an increasing function of the vulnerability of the information to security breaches." The entire premise is to provide a quantifiable

economic justification for security spending

which is the core of a CBA.

3. Van Oorschot

P. C. (2020). Computer Security and the Internet: Tools and Jewels. Springer.

Chapter 10

Section 10.2.2

Risk Analysis: This section discusses quantitative risk analysis

explaining that the goal is to assign monetary values to assets and the impact of threats. It notes that the results

such as the ALE

are used in a cost-benefit analysis to "justify the cost of countermeasures." This directly supports that the result of a CBA is justification.

A Tier 4 data center is defined by the Uptime Institute as having "Fault Tolerant Site Infrastructure." This means it has 2N+1 fully redundant infrastructure for power, cooling, and network connectivity, ensuring that a single, unplanned failure of any infrastructure component will not affect IT operations. Given that the physical infrastructure risks (power, network, and the environment for storage) are significantly mitigated by the Tier 4 design, the IT manager's focus in Business Continuity Planning (BCP) must shift to areas not covered by the facility's rating. Application failures—resulting from software bugs, flawed logic, data corruption, or misconfiguration—are independent of the physical infrastructure's resilience and thus represent a more prominent remaining risk.

1. Uptime Institute. (2021). Tier Standard: Topology. TUI3026E. Section 7.0

"Tier IV: Fault Tolerant Site Infrastructure

" states

"A Tier IV data center has multiple

independent

and physically isolated systems that each have redundant capacity components... A single failure of any equipment or distribution element will not impact the IT equipment." This standard focuses on power

cooling

and network as the core infrastructure components covered.

2. National Institute of Standards and Technology (NIST). (2010). Special Publication 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems. Page 11

Section 2.3

"Types of Disruptions." The guide categorizes disruptions

listing "System/Application Failure or Malfunction" separately from facility-level issues like "Disruption of Power" or "Disruption of Telecommunications." This highlights that application failure is a distinct concern from the infrastructure failures mitigated by a Tier 4 design.

3. Patterson

D. A. (2014). CS 162: Operating Systems and Systems Programming

Lecture 21: "Data Centers." University of California

Berkeley. The lecture notes discuss data center reliability

emphasizing that while top-tier data centers (like Tier 4) solve for power and cooling failures

failures still occur due to software bugs

operator error

and network issues within the software stack

which are outside the scope of the facility's physical tier rating.

The network segment labeled LAN 4 represents a Demilitarized Zone (DMZ), which is a perimeter network located between two firewalls. A DMZ is the most secure location to deploy services for less-trusted users, such as contractors, because it isolates their traffic from the highly secured internal network (LAN 2). Placing the Wireless Access Point (WAP) in the DMZ allows contractors to access the Internet through the external firewall while the internal firewall can enforce strict rules, granting access only to specific, authorized enterprise services. This architecture upholds the principle of least privilege and protects critical assets on the internal network, such as the Database Server in LAN 2.

Stallings, W. (2017). Network Security Essentials: Applications and Standards (6th ed.). Pearson.

Reference: Chapter 9, Section 9.2, "Firewall Configurations," particularly the discussion on the "Screened Subnet Firewall System" (p. 297, Figure 9.5c). This section details the dual-firewall architecture where the DMZ is the isolated network between an external and internal firewall, which is the standard design for securely hosting systems that require external access without exposing the internal network.

Zwicky, E. D., Cooper, S., & Chapman, D. B. (2000). Building Internet Firewalls (2nd ed.). O'Reilly & Associates.

Reference: Chapter 6, "Firewall Architectures," specifically the section on "Screened Subnet" (pp. 138-142). This source describes the screened subnet (DMZ) as the canonical solution for allowing access from the Internet to selected hosts while protecting the internal network. Placing a WAP for semi-trusted users in this zone is a direct application of this principle.

Cheswick, W. R., Bellovin, S. M., & Rubin, A. D. (2003). Firewalls and Internet Security: Repelling the Wily Hacker (2nd ed.). Addison-Wesley Professional.

Reference: Chapter 4, "Firewall-Friendly Protocols and the DMZ." The chapter explains that the purpose of a DMZ is to create a "neutral zone" for machines that need to be accessible from the outside but should not be trusted on the internal network. This concept directly applies to creating a network segment for contractors.

This ranking is based on the security of how credentials are handled and the underlying cryptographic protocols.

• Basic authentication is the weakest because it sends the username and password over the network in a plaintext-equivalent form (Base64 encoding), offering no confidentiality.
• Digest authentication is an improvement, using a challenge-response protocol that avoids sending the password in the clear. However, it typically relies on the MD5 hashing algorithm, which is now considered cryptographically weak and vulnerable.
• Integrated Windows Authentication (IWA) is strong as it leverages secure, ticket-based protocols like Kerberos or the NTLMv2 challenge-response mechanism. These protocols are designed to prove a user's identity without transmitting passwords across the network.
• Client Certificate authentication is the strongest. It uses Public Key Infrastructure (PKI) for mutual authentication between the client and server. The client must possess a private key corresponding to its public certificate, providing a much higher level of identity assurance than password-based systems.

Internet Engineering Task Force (IETF). (2015). RFC 7617: The 'Basic' HTTP Authentication Scheme. Section 4: Security Considerations. This section explicitly states, "In the absence of a secure channel, the 'Basic' authentication scheme transmits credentials in the clear."

Internet Engineering Task Force (IETF). (2015). RFC 7616: HTTP Digest Access Authentication. Section 5: Security Considerations. This document discusses the advantages of Digest over Basic but notes its vulnerabilities, including the weakness of the default MD5 algorithm.

Stallings, W., & Brown, L. (2018). Computer Security: Principles and Practice (4th ed.). Pearson. In Chapter 20.3, "HTTPS," the text discusses client certificates as a strong authentication mechanism as part of TLS mutual authentication.

Microsoft Documentation. (2021). Integrated Windows Authentication. Microsoft Learn. This document details how IWA uses Kerberos and NTLM, stating, "With Integrated Windows authentication, user credentials aren't sent to the server." This inherent design makes it stronger than schemes that transmit credentials or their weak derivatives.

The activities described—allowing only necessary services (least functionality), changing default passwords, and configuring antivirus updates—are all core components of establishing and maintaining a secure system baseline. This process is known as secure Configuration Management. It involves hardening systems by defining, implementing, and enforcing a secure state to reduce the attack surface. These actions are not primarily about managing user identities, applying patches, or auditing for compliance, but rather about setting the system's configuration parameters to a known, secure standard.

1. NIST Special Publication 800-128

"Guide for Security-Focused Configuration Management of Information Systems." Section 2.1 defines Security-Focused Configuration Management (SecCM) as the management and control of configurations for an information system to enable security and manage risk. The activities listed in the question are examples of establishing a secure configuration baseline.

2. NIST Special Publication 800-53 Revision 5

"Security and Privacy Controls for Information Systems and Organizations." The Configuration Management (CM) control family directly addresses this. Specifically

control CM-7 "Least Functionality" requires the organization to configure systems to provide only essential capabilities

which includes disabling unnecessary services. Changing default passwords (IA-5) and configuring antivirus (SI-3) are also part of establishing a secure baseline configuration (CM-2).

3. Purdue University

"Information Security Policy (VII.B.2)." University policies on information security

often used in courseware

define configuration management as a key process. For example

Purdue's policy states that "System hardening and configuration management standards must be followed to protect University IT Resources from unauthorized access and misuse

" explicitly linking hardening activities to configuration management. (See Section on System Administration Practices).

The matching is based on the defining characteristics of each access control model.

• Mandatory Access Control (MAC) is a non-discretionary model where a central authority defines access policies based on security labels (e.g., clearance levels). The end user has no authority to change these system-enforced rules.
• Discretionary Access Control (DAC) allows the owner (subject) of a resource (object) to determine the access permissions for other users at their discretion.
• Role Based Access Control (RBAC) simplifies administration by grouping permissions into roles that correspond to job functions. Users are assigned roles, thereby acquiring the permissions associated with those duties.
• Rule Based Access Control uses specific rules or policies that evaluate conditions (criteria) to grant or deny access. A sophisticated implementation of this model can dynamically assign roles to a subject if certain criteria, set by an administrator (custodian), are met.

For MAC and DAC: Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Communications of the ACM, 17(7), 38-41. (In Section I.A.3, "Design Principles," the document contrasts centrally-managed, mandatory controls with schemes where individual users control access to their own data, which is the core of the MAC vs. DAC distinction). DOI: https://doi.org/10.1145/361011.361062

For RBAC: Ferraiolo, D. F., & Kuhn, D. R. (1992). Role-Based Access Control. Proceedings of the 15th National Computer Security Conference, (pp. 554-563). (This foundational paper defines RBAC as a method of restricting system access to authorized users based on their roles within an organization. Section 3, "The Model," explicitly links roles to job functions). Available via NIST: https://csrc.nist.gov/csrc/media/projects/role-based-access-control/documents/ferraiolo-kuhn-92.pdf

For Rule-Based/Attribute-Based Control: Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., & Scarfone, K. (2014). Guide to Attribute Based Access Control (ABAC) Definition and Considerations (NIST Special Publication 800-162). National Institute of Standards and Technology. (Section 2.1 defines ABAC, a modern form of rule-based control, as a model where rules evaluate attributes—or criteria—to make access decisions. This can include dynamically managing a subject's privileges or role memberships based on these attributes). DOI: https://doi.org/10.6028/NIST.SP.800-162