Free SY0-701 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

A jump server, also known as a bastion host, is a hardened and monitored device on

the network specifically designed to be the single, controlled access point to other

systems and devices within a separate security zone. It acts as an intermediary,

requiring users to first authenticate to the jump server before they can access other

internal company resources. This creates an added layer of security by reducing the

attack surface and providing a single point for logging and auditing access to sensitive

internal systems.

A. RDP server: An RDP server allows remote desktop connections to that specific

server. It does not inherently provide an added layer of security for accessing other

internal resources; rather, it's a destination for access.

C. Proxy server: While proxy servers (especially reverse proxies) can offer security

benefits for specific applications, their primary role is typically to act as an intermediary

for network requests, often for outbound connections or to protect specific web servers.

A jump server is more specialized for secure administrative access to a broader range

of internal systems.

D. Hypervisor: A hypervisor is software that creates and runs virtual machines. While

securing the hypervisor is critical, it is not a solution for providing a controlled access

layer to internal company network resources in the manner described.

National Institute of Standards and Technology (NIST)

NIST Special Publication 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy.

While not directly defining "jump server," it discusses network segmentation and

controlled access points, concepts fundamental to jump server deployment. (Reference

to general architectural principles).

NIST Special Publication 800-125B, Secure Virtual Network Configuration for Virtual

Machine (VM) Protection, Section 3.3, "Bastion Host": "A bastion host is a special

purpose computer on a network specifically designed and configured to withstand

attacks. The computer generally hosts a single application, for example a proxy server,

and all other services are removed or limited to reduce the threat to the computer." This

describes the hardened nature of a jump server/bastion host.

URL: https://csrc.nist.gov/publications/detail/sp/800-125b/final

Amazon Web Services (AWS)

AWS Documentation, Security > AWS Well-Architected Framework > Security Pillar

> Design Principles > Secure network infrastructure > Restrict access > Use bastion

hosts (jump boxes). This section explicitly details the use of bastion hosts (jump

servers) to securely access private network resources.

URL (General concept, specific page might vary): AWS often describes bastion

hosts in relation to EC2 and VPC security best practices. A relevant conceptual page

is: https://aws.amazon.com/blogs/security/how-to-record-ssh-sessions-establishedthrough-a-bastion-host/ (This article describes its use, implicitly defining its role as a

secure gateway).

AWS Documentation, Linux Bastion Hosts on AWS (Quick Start Reference Deployment).

This guide details deploying a bastion host architecture.

URL: https://aws.amazon.com/quickstart/architecture/linux-bastion/ (The architecture

itself demonstrates the added security layer).

Microsoft Azure

Microsoft Azure Documentation, What is Azure Bastion?. "Azure Bastion is a service you

deploy that lets you connect to a virtual machine using your browser and the Azure

portal, or via the native SSH or RDP client already installed on your local computer.

The Azure Bastion service is a fully platform-managed PaaS service that you provision

inside your virtual network. It provides secure and seamless RDP/SSH connectivity to

your virtual machines directly in the Azure portal over TLS... When you connect via

Azure Bastion, your virtual machines don't need a public IP address, agent, or special

client software."

URL: https://learn.microsoft.com/en-us/azure/bastion/bastion-overview

IEEE Xplore

Zhu, Y., & Gao, H. (2021). A Secure Remote Access Scheme for Industrial Control

Systems Based on Bastion Host and MFA. IEEE Access, 9, 73426-73437. "The bastion

host acts as a gateway, providing a single point of entry to the internal network, thereby

enhancing security by isolating critical systems." (Section I, Introduction).

DOI: https://doi.org/10.1109/ACCESS.2021.3080899

A primary responsibility of a Data Protection Officer (DPO) is to oversee an

organization's data protection strategy and implementation to ensure compliance with

data protection laws. A data inventory, also known as a Record of Processing Activities

(RoPA) under GDPR, is crucial for understanding what personal data is processed,

where it resides, how it flows, and its purpose. This understanding is fundamental for a

DPO to assess potential risks and, critically, to determine the scope and impact of a

data breach. Knowing what data could be compromised allows for effective incident

response planning, notification to supervisory authorities and affected data subjects,

and mitigation of harm.

A. To manage data storage requirements better: While a data inventory can inform

storage management, this is typically a secondary benefit and more directly an IT

operational concern rather than the DPO's most relevant reason. The DPO's focus is data

protection, not infrastructure optimization per se.

C. To extend the length of time data can be retained: A data inventory helps in

applying data retention policies, which often involve limiting retention to what is

necessary and legally permissible, rather than extending it. DPOs ensure compliance

with data minimization and storage limitation principles.

D. To automate the reduction of duplicated data: Identifying duplicated data can be

an outcome of creating a data inventory, supporting data minimization. However, the

automation of its reduction is a subsequent technical implementation, and the primary

DPO relevance of the inventory itself is broader data governance and risk

assessment.□□

1. General Data Protection Regulation (GDPR), Article 39 - Tasks of the data

protection officer: While not explicitly stating "data inventory," the tasks include "to

monitor compliance with this Regulation...and with the policies of the controller or

processor in relation to the protection of personal data, including the assignment of

responsibilities, awareness-raising and training of staff involved in processing

operations, and the related audits." A data inventory is a foundational element for

these tasks.

o URL: https://eur-lex.europa.eu/legalcontent/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e3818-1-1

o Specific Reference: Article 39(1)(b) and Article 30 (Processing activities). Article 30

mandates maintaining a record of processing activities, which is effectively a data

inventory.

2. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk

Management, Version 1.0: The framework discusses understanding the data

processing environment (Identify-P) and assessing risks (Protect-P). A data inventory is

key to these functions. Knowing what data exists is essential to understand what data

could be breached and its impact.

o URL: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf

o Specific Reference: Section 2.3.2 Identify-P, particularly ID.P-P4: "Data processing

is inventoried by the organization." and Section 3.3 "Core Example Use Case

Scenario," which demonstrates how identifying data elements is crucial for risk

assessment related to data breaches. Page 9 (ID.P-P4), Page 23 (Risk Assessment).

3. Information Commissioner's Office (ICO) - "Guide to the UK General Data

Protection Regulation (UK GDPR) - Data protection officers": The ICO guidance

emphasizes the DPO's role in advising on and monitoring data protection impact

assessments (DPIAs). A data inventory is a prerequisite for conducting a meaningful

DPIA, which includes assessing the risks of a breach.

o URL: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-thegeneral-data-protection-regulation-gdpr/data-protection-officers-dpos/what-are-the-

tasks-of-a-dpo/

o Specific Reference: The section "What are the tasks of a DPO?" mentions advising

on DPIAs (which inherently involves understanding data and potential breach

impacts) and monitoring compliance.

When a critical component like a generator fails during a business continuity tabletop

exercise, the security team's concern about "potential impacts" directly relates to the

duration of the outage caused by this failure. Mean Time To Repair (MTTR) is the

specific metric that quantifies how long it will take to repair or restore the failed

generator. Considering the MTTR is a crucial risk management activity because it helps

the team estimate the length of the disruption, determine if Recovery Time Objectives

(RTOs) for dependent systems can still be met, and thereby assess the severity of the

business impact. Understanding the MTTR is essential for making informed decisions

about immediate response and recovery actions.

· A. RPO (Recovery Point Objective): RPO defines the maximum acceptable amount

of data loss measured in time. While a prolonged outage due to generator failure

could indirectly affect data, RPO is not the primary consideration for the impact of the

generator's downtime itself.

· B. ARO (Annualized Rate of Occurrence): ARO estimates how often a particular

event (like a generator failure) is expected to occur within a year. This is relevant for

long-term risk assessment but not the immediate consideration when dealing with the

impacts of an active failure in an exercise.

· C. BIA (Business Impact Analysis): A BIA is a broader analysis to identify and

quantify the potential impacts of disruptions on business functions and is used to

determine RTOs. While the team is concerned about impacts (which the BIA helps

define), the MTTR of the generator is a critical, specific input needed during the event to

understand the duration that leads to those impacts. The BIA provides the context for

impact, but MTTR is the immediate factor related to the generator's failure.

1. NIST Glossary - Mean Time To Repair (MTTR):

o URL: https://csrc.nist.gov/glossary/term/mean_time_to_repair

o Definition: "The average time to restore a system to full operational status after a

failure or incident."

o Relevance: This definition supports why MTTR is considered when assessing the

downtime of the failed generator.

2. NIST Special Publication 800-34 Rev. 1, "Contingency Planning Guide for

Federal Information Systems":

o URL: https://doi.org/10.6028/NIST.SP.800-34r1

o Section 3.2 (Business Impact Analysis), Page 13: "The BIA is a key step in the

contingency planning process... A BIA assists in identifying the potential consequences

of an information system disruption... The BIA should identify the MTD [Maximum

Tolerable Downtime] for information system resources. The MTD is then used to

establish recovery time objectives (RTOs)."

o Relevance: This explains BIA's role in identifying consequences and setting

recovery objectives (RTOs). The MTTR of a component like a generator directly

influences whether these RTOs can be met. If a generator fails, its MTTR will

determine the duration of power loss, which is then assessed against the impacts outlined

in the BIA for that duration.

3. NIST Special Publication 800-53 Rev. 5, "Security and Privacy Controls

for Information Systems and Organizations":

o URL: https://doi.org/10.6028/NIST.SP.800-53r5

o Control CP-2 (Contingency Plan), Discussion: Mentions that contingency plans

address recovery objectives. Control CP-7 (Alternate Processing Site) and CP-8

(Telecommunications Services) imply the need for recovery capabilities which

inherently involve considerations of recovery time for components.

o Relevance: The ability to meet recovery objectives, which are part of risk

management and contingency planning, depends on the recovery times of critical

components (related to their MTTR).

The general counsel's primary responsibility is to navigate the company's legal and regulatory landscape. A government ban on a vendor is a form of economic sanction. The most significant concern for the legal department is ensuring the company complies with this government mandate to avoid severe legal repercussions, such as fines, penalties, or even criminal charges. During a hardware refresh, the counsel's focus will be on the legal risks associated with using or procuring technology from a sanctioned entity, making compliance with the sanctions paramount.

B. Data sovereignty: This is a legal requirement about data location and jurisdiction, which is a different concern than a direct government ban on a specific vendor's hardware.

C. Cost of replacement: This is a financial and operational issue, primarily the concern of the Chief Financial Officer (CFO) or Chief Information Officer (CIO), not the general counsel.

D. Loss of license: While a possible outcome of the ban, the sanction itself is the root legal cause and the broader, more immediate concern for the company's chief legal officer.

1. CompTIA Security+ SY0-701 Exam Objectives

Domain 5.3: Summarize risk management processes and concepts. This domain covers "Supply chain assessment

" which includes evaluating "Geopolitical" risks. Government-imposed sanctions are a primary example of a geopolitical risk that affects the technology supply chain.

2. U.S. Department of the Treasury

Office of Foreign Assets Control (OFAC). (2021). OFAC Regulations for the Financial Community. Section: "Introduction to OFAC." This official documentation explains that OFAC administers and enforces economic and trade sanctions based on U.S. foreign policy and national security goals. Violations can result in significant civil and criminal penalties

which is a direct concern for a company's general counsel.

3. Lewis

J. A. (2021). Aligning U.S. Technology and Trade Policies. Center for Strategic and International Studies (CSIS). Page 5. This report discusses how government actions

such as placing companies on an "entity list

" function as sanctions to restrict access to technology for national security reasons

creating significant compliance challenges for businesses. This highlights the legal and regulatory nature of such bans.

The host 192.168.10.22 is the origin of the infection. The logs for this host at 2:31 PM show "Scheduled scan disabled by process svch0st.exe" and "Scheduled update disabled by process svch0st.exe." This indicates it was the first host to be compromised, allowing the malware to disable its security measures before spreading. The typo "svch0st.exe" is a common malware tactic to mimic a legitimate Windows process, svchost.exe. The hosts 192.168.10.41 and 10.10.9.18 are infected. Their logs show they were unable to quarantine the svch0st.exe file, indicating the infection is active and has bypassed the security software. The hosts 192.168.10.37 and 10.10.9.12 are clean. Their logs show they successfully detected and quarantined the svch0st.exe file, effectively containing the threat before it could compromise the system.

Fortinet. "What is an Attack Vector?". (Provides context on how malware disables security software).

Kaspersky. "Dealing with Svchost.exe Virus' Sneak Attack." (Explains the common malware tactic of mimicking the svchost.exe process).

Secureworks. "A Firewall Log Analysis Primer." (Explains how firewall logs can be used to trace the origin and spread of an infection by analyzing connections and timestamps).

Luo, Wuqiong. "Identifying Infection Sources in a Network." Nanyang Technological University, 2012. (Discusses methodologies for identifying the origin of an infection based on spread patterns and timestamps).

Multifactor authentication (MFA) enhances security by requiring users to provide two or

more verification factors. The question specifies three types of factors:

Something you know: This is typically a secret, such as a password or PIN.

Something you have: This refers to a physical object in your possession, like an

authentication token (e.g., a hardware key fob or a one-time code generating app on a

smartphone).

Something you are: This involves biometric characteristics unique to the individual, such

as a thumbprint, facial scan, or voice recognition.

Option C directly maps to these three categories: a password (know), an authentication

token (have), and a thumbprint (are).

A. Domain name, PKI, GeoIP lookup:

A domain name is an identifier, not primarily an authentication factor for a user.

PKI (Public Key Infrastructure) is a system, and while it can involve "something you have"

(a private key on a smartcard), it's not a factor type itself.

GeoIP lookup is a location-based attribute, not a primary authentication factor a user

actively provides.

B. VPN IP address, company ID, facial structure:

A VPN IP address is network information, not a direct authentication factor provided by

the user.

A company ID could be "something you know" or "something you have" (like an ID

badge), but the option lacks clarity for distinct MFA categories.

While facial structure is "something you are," the other elements don't fit the specified

three distinct categories as well as option C.

D. Company URL, TLS certificate, home address:

A company URL is knowledge but not typically a user authentication secret.

A TLS certificate can be "something you have" for device/client authentication but is not

the common understanding for user MFA in this context.

A home address is personal information ("something you know") but not a standard or

secure authentication factor for this purpose.

National Institute of Standards and Technology (NIST):

NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and

Lifecycle Management.

Section 4, "Authentication Factors": Defines the three factor types: Something You

Know, Something You Have, and Something You Are.

Section 5.1.1, "Memorized Secrets (Something You Know)": Discusses passwords and

PINs.

Section 5.1.2, "Look-Up Secrets (Something You Know)": A pre-shared secret.

Section 5.1.4, "Out-of-Band Devices (Something You Have)": Describes receiving

codes via SMS or push notifications to a pre-registered device.

Section 5.1.5, "Single-Factor OTP Devices (Something You Have)": Refers to

hardware or software authenticators that generate one-time passwords.

Section 5.1.7, "Biometrics (Something You Are)": Discusses fingerprint, facial

recognition, etc.

URL: https://doi.org/10.6028/NIST.SP.800-63b (Specifically, pages 7-10 for factor

definitions, and subsequent sections for examples like passwords (pg 14), OTP devices

(pg 23), and biometrics (pg 28)).

IEEE (Institute of Electrical and Electronics Engineers):

Sasse,

M. A., Brostoff, S., & Weirich,

D. (2001). Transforming the 'weakest link' a

human/computer interaction approach to usable and effective security. BT Technology

Journal, 19(3), 122-131. (While older, it lays foundational concepts often cited).

This article discusses the three classic authentication factors: "something a person

knows (e.g. a password), something a person has (e.g. a smartcard), and something a

person is (e.g. a fingerprint)." (Page 126).

DOI: https://doi.org/10.1023/A:1011915109855

University Courseware (Example - though direct links to PDFs might change,

concept is standard):

Many cybersecurity courses from reputable universities (e.g., MIT OCW, Stanford,

Carnegie Mellon) cover authentication factors. For example, a typical lecture on access

control or authentication would define these three factors.

Example Concept: "Authentication factors include knowledge factors (something you

know, like a password), possession factors (something you have, like a security token),

and inherence factors (something you are, like a fingerprint)." (This is a general

representation of common university course content). Finding a stable, specific page for

this general concept from a courseware site can be difficult, but the NIST SP 800- 63B

is the definitive, stable reference.

Job rotation is best used to detect fraud by assigning employees to different roles.

When an employee is moved from one role to another, the individual subsequently

assigned to the former role, or the rotated employee in their new capacity, may uncover

irregularities or fraudulent activities. This practice is a detective control, as the change

in personnel and responsibilities provides an opportunity for fresh review and discovery

of concealed actions. Approved sources, such as university audit guidelines and NIST

publications, identify job rotation (or "rotation of duties") as a detective control that can

help uncover fraud.

· A. Least privilege: This is a preventive control that limits users' access to only the

information and resources necessary for their jobs. It aims to prevent unauthorized

actions, not primarily detect existing fraud through role changes. (NIST SP 800-53

Rev. 5, AC-6).

· B. Mandatory vacation: This detective control requires employees to take time off,

during which others perform their duties, potentially uncovering fraud. However,

"assigning employees to different roles" more precisely describes job rotation, where

an employee is formally moved to a new role, rather than their existing role being

temporarily covered. (NIST SP 800-100, p. 11-10).

· C. Separation of duties: This is primarily a preventive control that divides critical

tasks among different individuals to reduce the risk of any single person perpetrating

and concealing fraud. While it can aid detection, its core purpose is prevention by

design. (University of Illinois Audits; NIST SP 800-53 Rev. 5, PS-9).

1. University of Illinois, Office of University Audits. (n.d.). Internal Controls -

Best Practices. Retrieved from

https://www.audits.uillinois.edu/internal_controls_best_practices

o Specific Location: Under "Examples of Detective Controls," it lists "Rotation of

Duties." Under "Examples of Preventive Controls," it lists "Separation of Duties." This

source clearly distinguishes their primary purposes.

2. National Institute of Standards and Technology (NIST). (2007). NIST Special

Publication 800-100: Information Security Handbook: A Guide for Managers.

Retrieved from https://csrc.nist.gov/publications/detail/sp/800-100/final

o Specific Location: Chapter 11: "Personnel Security," page 11-10, states, "Periodic

job rotation and mandatory vacations also may aid in timely detection of inappropriate

actions."

3. National Institute of Standards and Technology (NIST). (2016). NIST Interagency

Report 7621 Revision 1: Small Business Information Security: The

Fundamentals.

Retrieved from https://csrc.nist.gov/publications/detail/nistir/7621/rev-1/final

o Specific Location: Section 3.3.4 "Controls for protecting information," page 27,

mentions, "Implement separation of duties and/or job rotation to ensure that no single

individual has excessive control over sensitive information or processes, and to detect

and deter fraudulent activities."

4. National Institute of Standards and Technology (NIST). (2020). NIST Special

Publication 800-53 Revision 5: Security and Privacy Controls for Information

Systems

and Organizations. Retrieved from https://csrc.nist.gov/publications/detail/sp/80053/rev-5/final

o Specific Location: Control AC-6 "Least Privilege" and PS-9 "Separation of Duties."

These descriptions emphasize their role in restricting capabilities and preventing

conflicts of interest, indicative of preventive measures.

Code repositories are a common source of unintentional corporate credential leakage.

Developers may inadvertently commit sensitive information, such as API keys,

passwords, or private certificates, directly into source code or configuration files that

are then pushed to version control systems like Git. If these repositories are public, or

even private but improperly secured or accessed, these embedded credentials become

exposed. This type of leakage is typically accidental, stemming from oversight or a lack

of awareness of secure coding practices for managing secrets.

· B. Dark web: The dark web is a marketplace or forum where already compromised

credentials are often sold or shared, not the initial source of an unintentional leak.

· C. Threat feeds: Threat feeds provide intelligence about known threats,

vulnerabilities, and compromised data, including credentials. They report on leaks

rather than being the origin of the unintentional leakage.

· D. State actors: State actors are sophisticated threat entities that may actively seek to

steal credentials. While they can cause credential exposure, they represent an

intentional actor, not a passive source of unintentional leakage like a mismanaged

repository.

· E. Vulnerability databases: These databases (e.g., CVE) list known software or

system vulnerabilities. A vulnerability might be exploited to cause a credential leak, but

the database itself is not the source of the leaked credentials.

1. AWS Security Best Practices - Managing Secrets: While not a direct statement about

repositories being the most common, AWS documentation frequently warns against

hardcoding secrets. For instance, the "AWS Well-Architected Framework - Security

Pillar" emphasizes using services like AWS Secrets Manager to avoid hardcoding

secrets in application code. This implicitly acknowledges the risk of secrets ending up in

code.

o URL: https://docs.aws.amazon.com/wellarchitected/latest/securitypillar/sec_manage-secrets.html (Refer to sections on "Managing secrets" and avoiding

hardcoding.)

2. NIST Special Publication 800-160, Volume 2, Revision 1: Developing Cyber

Resilient Systems: A Systems Security Engineering Approach: This document

discusses secure software development practices. While it may not explicitly state

"code repositories are the most common source," it emphasizes the need to protect

sensitive information throughout the system development lifecycle, and accidental

commitment of secrets is a failure in this area.

o URL: https://csrc.nist.gov/publications/detail/sp/800-160/vol-2-rev-1/final (See

Appendix F, Security Design Principles, specifically related to protecting sensitive

information and secure defaults which apply to how code and configurations are

managed).

3. Meli, M., McNiece, M., & Reaves, B. (2019). How Bad Can It Git? Characterizing

Secret Leakage in Public GitHub Repositories. In NDSS. The Internet Society. This

peer-reviewed academic paper directly investigates and quantifies the problem of

secret leakage in public code repositories.

o DOI: https://doi.org/10.14722/ndss.2019.23286

o Specifically: The abstract and introduction highlight the prevalence of secrets (API

keys, credentials) being accidentally committed to public GitHub repositories.

4. Zulkarnain, A., & Kauri, K. (2021). An Empirical Study of Accidental Secrets

Exposure in Public GitHub Repositories. IEEE Access, 9, 65839-65853. This is

another academic publication that studies the phenomenon.

o DOI: https://doi.org/10.1109/ACCESS.2021.3075187

o Specifically: The paper confirms that developers frequently leak secrets to public

repositories, making it a significant source of unintentional credential exposure.

A staging environment is specifically designed to be a near-replica of the production

environment. It's used for final testing of code, updates, and major system upgrades

before they are deployed to production. This environment often utilizes a sanitized or

anonymized subset of actual customer data to ensure testing is realistic and to

assess the impact of changes accurately. Furthermore, its production-like nature makes

it suitable for demonstrating new system features to stakeholders or for user

acceptance testing (UAT) in a controlled setting that mirrors the live system without

affecting actual users or data.

· A. Development: This environment is used by developers to build and unit test code.

It typically uses mock data or very limited, often synthetic, datasets, not a

representative subset of customer data, and is not stable enough for impact assessment

of major upgrades or feature demonstrations to external stakeholders.

· B. Test: While used for quality assurance and finding defects, a test environment

may not always use a subset of actual customer data (often uses specifically crafted

test data) and is primarily focused on verification and validation rather than a final

pre-production impact assessment or feature showcase in a production-like replica.

· C. Production: This is the live environment used by actual customers with real-time

data. It is not used for assessing impacts of major upgrades prior to their validation or

for demonstrating potentially unstable features due to the risk of service disruption and

data integrity issues.

1. Microsoft, Azure, "Deployment Staging environments":

o URL: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots

o Relevant Information: While specific to Azure App Service, the concept of a staging

slot (environment) is for deploying and testing changes before swapping to production.

"Deployment slots let you deploy different versions of your app to different URLs. You

can use slots for staging new features, A/B testing, or maintaining a production version

while working on a new one...After you validate your changes in a staging slot, you can

swap the staging slot with the production slot." This supports the idea of final validation

before go-live, implicitly including assessing impacts and potentially demonstrating

features. The use of "production data" in staging (often a sanitized subset) is a common

best practice for accurate testing.

2. AWS, "Workload hosting > Environments":

o URL: https://docs.aws.amazon.com/wellarchitected/latest/workloadhosting/environments.html

o Relevant Information: This document discusses different environments. While not

explicitly detailing "subset of customer data" for staging, it describes staging (or pre-

production) as an environment that "should be as identical as possible to the

production environment" and is used "to test the software before it is released to the

production environment." This identical nature is key for assessing upgrade impacts

and makes it suitable for demonstrations.

3. Atlassian, "Deployment environments: Development, staging, production,

and testing":

o URL: https://www.atlassian.com/continuous-delivery/principles/deploymentenvironments

o Relevant Information: "A staging environment (stage) is a near-replica of a production

environment... Staging environments are used to test and catch any code issues before

they are deployed to a production environment. This environment should be as similar

to production as possible, which can help to test for performance, data integrity, and

usability... It can also be used for demonstrations, training, or user acceptance testing

(UAT)." This directly supports using staging for testing major changes, demonstrating

features, and often implies the use of production-like data (a subset).

4. University of Washington, "Environments - Test, Staging, Production":

o URL: https://www.washington.edu/cac/ fauc/ISDOC/Projects/devenviron.html (Note:

The direct link might be subject to change over time, searching for "University of

Washington software development environments" might be needed). A more stable

similar resource: University of Michigan, "Development, Staging, and Production

Environments":

o URL: https://safecomputing.umich.edu/protect-the-u/protect-yourunit/information-security-guidelines-and-procedures/development-staging-and-

production-environments

o Relevant Information: "The staging environment serves as a model of the production

environment... Testing in this environment should focus on integration with other

production or production-like systems... The staging environment is also often used for

demonstrations and training on new features as it closely resembles the production

environment without being the live system." This again highlights its role in

demonstrations and testing major changes with production-like data.

Memory injection, often referred to as process injection, is a technique where malicious

code is inserted into the address space of an already running, legitimate process.

Option C, "Malicious code is copied to the allocated space of an already running

process," accurately and directly describes this core action. This encompasses various

methods, such as allocating memory in a target process (e.g., using VirtualAllocEx in

Windows) and then writing the malicious code into that allocated space (e.g., using

WriteProcessMemory), followed by execution.

· A. Two processes access the same variable, allowing one to cause a privilege

escalation. This describes a vulnerability related to shared memory or a race

condition. While it can lead to privilege escalation by manipulating data, it's not

primarily about injecting new executable code into another process's memory space.

· B. A process receives an unexpected amount of data, which causes malicious

code to be executed. This describes a buffer overflow. While buffer overflows can be

a method to achieve memory injection (by overflowing a buffer with shellcode), option

C provides a more direct and general description of the act of memory injection itself.

Memory injection as a technique is not limited to vulnerabilities triggered by "unexpected

amounts of data" in this manner.

· D. An executable is overwritten on the disk, and malicious code runs the next

time it is executed. This describes a file-based attack, such as trojanizing an

application or replacing an executable. The malicious code executes when the modified

program is launched from the disk, not by injecting code into the memory of an already

running process.

1. MITRE. (2023). Process Injection, T1055. MITRE ATT&CK. o

URL: https://attack.mitre.org/techniques/T1055/

o Reference: The main description states, "Process injection is a method of executing

arbitrary code in the address space of a separate live process." Many sub-techniques

involve writing code into the target process's memory (supporting option C).

2. BINTI Zulkifli,

N. N., HASHIM,

A. S.

B. M., & YAAKOB,

N. (2018). Analysis of

Memory Injection Techniques for Bypassing Anti-Virus Software. IEEE Access, 6, 66131–

66143.

o DOI: https://doi.org/10.1109/ACCESS.2018.2876904

o Reference: Page 66131, Section I (Introduction): "Memory injection refers to a series

of techniques that inject malicious code into a running process..." This aligns directly

with option C. The paper discusses techniques like DLL injection and Process

Hollowing which involve copying/mapping code into a running process's memory.

3. Microsoft. (2021). WriteProcessMemory function (memoryapi.h). Microsoft Docs.

o URL: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nfmemoryapi-writeprocessmemory

o Reference: This official API documentation describes a function that "writes data to

an area of memory in a specified process." This is a mechanism used in many memory

injection techniques, illustrating the "copying code to allocated space" described in option

C.

4. Erickson, J. (2008). Hacking: The Art of Exploitation, 2nd Edition. No Starch Press.

o Reference: Chapter 3 ("Exploiting Programs"), Section "Overflowing the Stack" (pp.

134-150 in some editions) explains how buffer overflows (related to option B) can inject

shellcode onto the stack. While this shows B as a method, option C is a more general

description of the injection act itself, which is preferred for precision. Option C covers

more forms of memory injection beyond just overflows.

Cross-Site Scripting (XSS) vulnerabilities occur when an application includes

untrusted data in a new web page without proper validation or escaping, or updates an

existing web page with user-supplied data using a browser API that can create HTML

or JavaScript. Input validation is a primary defense mechanism. It involves checking

and sanitizing data received from the client before it is processed or stored to ensure it

does not contain malicious scripts. By rigorously validating all input, particularly in form

fields, applications can prevent the injection and subsequent execution of malicious

code in a user's browser.

A. Secure cookies: Attributes like HttpOnly and Secure for cookies protect the cookie

data from being accessed by client-side scripts (in the case of HttpOnly) or ensure

cookies are only sent over HTTPS (in the case of Secure). While these are good

security practices and can mitigate some impacts of XSS (like session hijacking via

cookie theft), they do not prevent the XSS vulnerability itself from existing in a form

field.

B. Version control: Systems like Git or SVN are used for managing changes to source

code. While essential for software development, version control does not directly

implement any runtime security mechanism to prevent vulnerabilities like XSS.

D. Code signing: This process verifies the author and integrity of software code,

ensuring it hasn't been tampered with since publication. Code signing does not

prevent developers from inadvertently or otherwise writing code that contains

vulnerabilities like XSS.

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-

53 Revision 5: Security and Privacy Controls for Information Systems and

Organizations.

Control: SI-10 Information Input Validation

Discussion: "Information input validation is a defensive technique that protects

information systems against many types of attacks, including [...] cross-site scripting

[...]. Information input validation can occur at the client or at the server. It includes, for

example, [...] rejecting malformed and anomalous input [...]."

URL: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final (See SI-10, Page 297

(PDF page 371))

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-

95: Guide to Secure Web Services.

Section: 4.3 Web Application Attacks and Countermeasures

Discussion: This section discusses common web application attacks. For Cross-Site

Scripting, while not using the exact phrase "input validation" as the sole

countermeasure in the summary table, the description of XSS implies that improper

handling of input is the cause. More generally, the document states: "A web application

should comprehensively validate all client input before processing it." (Section 4.3.1).

URL: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-95.pdf

(Page 20, Section 4.3; Page 21, Section 4.3.1)

MIT OpenCourseWare: 6.858 Computer Systems Security, Fall 2014. Lecture 4: Web

Security.

Discussion: Lecture notes and slides frequently emphasize input validation and output

encoding as primary defenses against XSS. For example, discussions around

"Sanitizing input" are common in web security contexts.

URL: https://ocw.mit.edu/courses/6-858-computer-systems-security-fall2014/resources/mit6_858f14_lec4/ (Specifically, slide 36 mentions "Filter/validate input

data" as a defense against injection attacks, and XSS is a type of injection).

IEEE Center for Secure Design (CSD). (2015). Avoiding the Top 10 Software Security

Design Flaws. (While this is a summary, it reflects principles found in detailed IEEE

papers and standards).

Flaw Addressed (related): Improper Input Validation. The document emphasizes that

"Input validation is the most important defense against all input-based vulnerabilities."

XSS is a classic input-based vulnerability.

URL: (General reference to IEEE's work on secure design, specific detailed papers

would further elaborate. A direct link to a specific IEEE standard or paper detailing XSS

and input validation is preferable if readily available without paywall. For instance,

documents referenced by IEEE such as the OWASP guides which are often cited in

academic contexts also heavily push this.)

More specific IEEE example (conceptual): Many IEEE papers on web security or secure

software development life cycles will discuss input validation as a fundamental control

against injection attacks, including XSS. Searching the IEEE Xplore digital library for

"cross-site scripting input validation" would yield numerous peer-reviewed articles. For

example, concepts detailed in papers like "A Survey on Cross-Site Scripting Attacks

and Defenses" often found in IEEE proceedings would confirm this.

An Internet-facing payment application must be protected from web-based attacks (SQLi, XSS, etc.). PCI DSS v4.0 §6.4.3 requires either formal code review or placement of a web application firewall in front of public payment sites. Cloud architecture guides (e.g., AWS Well-Architected Security Pillar, §3.2) place the WAF at the edge of the public subnet, between the Internet gateway/load balancer and the web servers. This provides real-time, layer-7 filtering without exposing the application directly to untrusted traffic.

1. PCI Security Standards Council. “Payment Card Industry Data Security Standard

v4.0

” Req. 6.4.3

pp. 108-109.

2. AWS Well-Architected Framework

Security Pillar

§3.2 “Protecting Workloads

” pp. 19-20.

3. IEEE Computer Society. S. Chaudhary et al.

“Mitigating Web Application Attacks with WAFs

” IEEE Access

vol. 8

2020

pp. 210680-210693

https://doi.org/10.1109/ACCESS.2020.3039217.

An end-of-life (EOL) system no longer receives security patches, making it inherently vulnerable. Since the system is also business-critical, it cannot be decommissioned. The most effective preventative control in this scenario is isolation. By placing the system in a segmented network (e.g., a VLAN or behind a firewall) with strict access control lists, its attack surface is drastically reduced. This compensating control prevents unauthorized entities from communicating with the vulnerable system, thereby preventing exploitation. It allows the critical system to continue operating while mitigating the risk posed by its unpatchable state.

A. Monitoring: This is a detective control, not a preventative one. It can alert administrators to an attack but does not stop the initial exploitation from occurring.

C. Decommissioning: This is not a viable option because the question specifies the system is "business-critical," meaning it is essential for operations and cannot be removed.

D. Encryption: This protects data at rest or in transit from unauthorized disclosure but does not prevent an attacker from exploiting a software vulnerability to gain control of the system itself.

---

1. National Institute of Standards and Technology (NIST). (2020). Security and Privacy Controls for Information Systems and Organizations (Special Publication 800-53

Revision 5).

Control SC-7

Boundary Protection: The discussion section for this control states

"Boundary protection is a security design principle that involves isolating critical system components... This is achieved by controlling the flow of information between network segments." This directly supports using isolation for vulnerable

critical systems.

Control SI-2

Flaw Remediation: The discussion for this control acknowledges that for some components

flaw remediation may not be possible (as with EOL systems) and that organizations should "apply other mitigations." Network isolation is a primary example of such a mitigation.

2. University of California

Berkeley. (2023). Minimum Security Standard for Networked Devices. Information Security Office.

Section 5.1

Unsupported Software: This standard mandates that "Devices running unsupported software must be isolated from the network" or have other compensating controls approved. This illustrates that isolation is a standard

required practice for EOL systems in a formal security program.

3. Kim

D.

& Solomon

M. G. (2021). Fundamentals of Information Systems Security (4th ed.). Jones & Bartlett Learning.

In discussions on defense-in-depth and securing legacy systems

the text emphasizes network segmentation and isolation as key compensating controls when patching is not an option. It describes how firewalls and VLANs are used to create secure enclaves for critical assets that cannot be updated. (Chapter on Network Security).

A Secure Web Gateway (SWG) is the most suitable technology for this scenario.

SWGs are designed to protect users from web-based threats by filtering internet traffic,

enforcing security policies (like acceptable use and threat prevention), and inspecting

content for data loss prevention. For remote employees not using a VPN, a cloud-

delivered SWG can secure their access to web resources and protect company data by

routing their internet-bound traffic through its security inspection engines.

This directly addresses the need to protect data for users working remotely and

accessing the internet without a traditional VPN tunnel to the corporate network.

· B. Virtual private cloud endpoint: This technology enables private connections from

a Virtual Private Cloud (VPC) to specific cloud services (e.g., within AWS). It's not

designed for securing general internet access for remote employees.

· C. Deep packet Inspection: DPI is a method or technique used by various security

tools (including SWGs and NGFWs) to analyze the content of network packets. It's

not a standalone technology that a company would implement to solve this specific

problem.

· D. Next-generation firewall: While an NGFW provides broad network security, an

SWG is more specialized for securing web access and protecting against web-based

threats, which is a primary concern for remote users accessing the internet directly. A

cloud-based SWG is more directly applicable than a traditional NGFW for users not on

a VPN.

1. Cisco. "What Is a Secure Web Gateway (SWG)?"

o URL: https://www.cisco.com/c/en/us/products/security/web-security-appliancewsa/what-is-a-secure-web-gateway.html

o Relevant Information: "A secure web gateway (SWG) is a cybersecurity solution that

prevents unsecured traffic from entering an internal network of an organization. It is

designed for users to access the internet securely and use web-based applications

safely... SWGs sit in-line between users and the internet, inspecting web traffic and

enforcing company security policies." This supports the role of SWG in securing

internet access for users.

2. Palo Alto Networks. "What is a Secure Web Gateway?"

o URL: https://www.paloaltonetworks.com/cyberpedia/what-is-a-secure-webgateway

o Relevant Information: "A Secure Web Gateway (SWG) protects users from web-

based threats in addition to applying and enforcing corporate acceptable use policies.

An SWG does this by sitting between the user and the internet, inspecting web traffic

and blocking malicious code and unauthorized access." This emphasizes its role in

protecting users regardless of location.

3. NIST Special Publication 1800-33b. "Securing Telehealth Remote Patient

Monitoring Ecosystem." (February 2023)

o URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-33b.pdf

o Relevant Information: Page 24 (PDF page 32), Section 3.4.2 "Data in Transit": "The

telehealth RPM ecosystem may also use a secure web gateway to monitor network

traffic and block access to known malicious websites or content." This illustrates the

use of SWGs in securing remote operations and protecting data by controlling web

access.

4. AWS Documentation. "VPC endpoints."

o URL: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html

o Relevant Information: "A VPC endpoint enables you to privately connect your VPC to

supported AWS services and VPC endpoint services powered by AWS PrivateLink

without requiring an internet gateway, NAT device, VPN connection, or AWS Direct

Connect connection." This defines VPC endpoints and shows their specific, non-

applicable use case here.

5. IEEE Access. "A Survey on Deep Packet Inspection for Intrusion Detection

Systems." (September 2020)

o DOI: https://doi.org/10.1109/ACCESS.2020.3024498

o Relevant Information: (Abstract) "Deep Packet Inspection (DPI) is a technique that

allows for fine-grained analysis of network packets by examining their payload

content." This identifies DPI as a technique, not a comprehensive solution for the

scenario.

6. Cisco. "What Is a Next-Generation Firewall (NGFW)?"

o URL: https://www.cisco.com/c/en/us/products/security/firewalls/what-is-a-nextgeneration-firewall.html

o Relevant Information: "Next-Generation Firewalls (NGFWs) filter network traffic to

protect an organization from internal and external threats... NGFWs possess deeper

inspection capabilities that give them a superior ability to identify attacks, malware, and

other threats." This describes NGFWs but highlights their broader nature compared to

the specific web security focus of an SWG for remote users.

Part 1 of the simulation presents a layered security architecture. A router directs traffic from the internet, and a firewall provides the first layer of network-level defense by filtering traffic based on rules. A WAF (Web Application Firewall) is then placed in front of the web server to protect against application-level attacks like XSS and SQL injection, as specified in the scenario. This configuration reduces the attack surface by inspecting and blocking malicious requests before they reach the web server.

Part 2 requires constructing the correct OpenSSL command for generating a new private key and Certificate Signing Request (CSR). The openssl req -new -newkey command is used to create a new key and CSR. The option -newkey specifies the algorithm and key size. rsa:2048 is the precise and standard command snippet for generating a 2048-bit RSA private key, which is a widely accepted key size for security. The other options are either file paths, which are part of the -keyout and -out parameters, or incorrect syntax. The Generating RSA private key output is a result of the -newkey rsa:2048 command. Therefore, rsa:2048 is the correct command snippet to select in all three instances where a key generation parameter is required.

Network Architecture & WAFs: The Open Group. (2018). Security Architecture and Engineering. Section 5.3.

OpenSSL Commands: OpenSSL Foundation. (2023). OpenSSL req documentation. https://www.openssl.org/docs/man3.0/man1/openssl-req.html.

Firewall & Router Roles: Cisco Systems. (2020). Introduction to Networking and Security. Section 3.4.

RSA Key Length: Rivest, R. L., Shamir, A., & Adleman, L. (1978). A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, 21(2), 120–126. https://doi.org/10.1145/359340.359342.

A Disaster Recovery Plan (DRP) outlines the procedures for restoring an

organization's IT infrastructure and operations in the event of a significant disruption. A

critical component of a DRP is the order of restoration for critical systems, ensuring

that the most essential services are brought back online first to minimize business

impact. This aligns precisely with the document described in the question.

· A. Communication plan: This plan focuses on how, what, and with whom to

communicate during and after an incident, not the technical sequence of system

recovery. According to NIST SP 800-34 Rev. 1, communication is a part of the overall

contingency planning, but the specific document for system restoration order is the

DRP.

· B. Incident response plan: An Incident Response Plan (IRP) provides procedures for

responding to and managing security incidents like cyberattacks or data breaches.

While recovery is a phase in incident response, the detailed sequence of bringing all

critical systems back online after a major outage (disaster) is the core of a DRP, as per

NIST SP 800-61 Rev. 2.

· C. Data retention policy: This policy dictates how long data must be kept and how it

should be disposed of. It does not address the restoration sequence of IT systems after

an outage.

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

34 Rev. 1, "Contingency Planning Guide for Federal Information Systems"

o URL: https://doi.org/10.6028/NIST.SP.800-34r1

o Relevant Section: Section 3.3.3, "Recovery Phase," discusses restoring

information system operations at an alternate location and recovering information

system operations at the original or new site. Appendix G, "Sample Disaster Recovery

Plan," typically includes restoration priorities. Specifically, page 30 (PDF page 38)

states, "The DRP should also identify critical success factors and a prioritized list of IT

systems and functions to be recovered."

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

61 Rev. 2, "Computer Security Incident Handling Guide"

o URL: https://doi.org/10.6028/NIST.SP.800-61r2

o Relevant Section: Section 2.3.2, "Incident Response Policy, Plan, and Procedure,"

and Section 3.4, "Recovery." While incident response includes recovery, the detailed

order of bringing critical systems back online after a major outage (disaster scenario)

is more specific to a DRP. The IRP focuses more on containment, eradication, and

recovery from the incident itself.

3. Valacich,

J. S., & George,

J. F. (2020). Modern Systems Analysis and Design

(9th ed.). Pearson. (Reputable academic publisher, analogous to university

courseware)

o Relevant Chapter/Section: Chapter 15, "Maintaining Information Systems." This

chapter typically covers business continuity and disaster recovery. Disaster recovery

plans explicitly include "procedures for rebuilding or restoring critical systems."

(Specific page numbers can vary by edition, but the concept is standard in DRP

discussions). The focus is on a "prioritized list of applications" for restoration.

Risk identification is the process within risk management focused on finding,

recognizing, and describing potential risks that could impact a project or organization.

This inherently involves understanding and confirming the scope of the project or area

under assessment to ensure that all relevant potential risks within those defined

boundaries are considered. While defining the initial scope can be part of broader

planning or a specific "context establishment" phase (like in ISO 31000 or NIST's

"Frame Risk" stage), the practical activity of identifying specific risks for a project is

performed for that defined scope. Therefore, the risk identification step is directly

concerned with determining potential risks and necessitates the use and understanding

of the established scope.

· A. Risk mitigation: This step focuses on developing and implementing strategies to

reduce the impact or likelihood of risks that have already been identified and assessed.

It follows risk identification.

· C. Risk treatment: This is largely synonymous with risk mitigation or risk response. It

involves selecting and implementing measures to modify identified risks and occurs

after risks are understood.

· D. Risk monitoring and review: This is an ongoing process to track identified risks,

assess the effectiveness of treatment plans, and identify any new or changing risks. It

presumes prior identification and scoping.

1. NIST Special Publication 800-30 Revision 1, "Guide for Conducting

Risk Assessments":

o Page 9, Section 2.2.1 (Step 1: Prepare for Assessment): States that key activities

in preparing for a risk assessment include "identifying the scope of the risk

assessment."

o Pages 12-14, Section 2.2.2 (Step 2: Conduct Assessment - Task 2-1 & Task 2-2):

Details the tasks of "Identify Threat Sources and Events" and "Identify Vulnerabilities

and Predisposing Conditions," which are fundamental to identifying potential risks.

This step logically follows the preparation where scope is defined.

o URL: https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final

2. ISO 31000:2018, "Risk management Guidelines":

o Clause 6.3 "Scope, context and criteria" (Page 9): Describes the establishment of

scope as a precursor to risk assessment: "The purpose of establishing the scope,

context and criteria is to customize the risk management process, enabling effective

risk assessment and appropriate risk treatment. Establishing scope, context and

criteria involves: a) defining the scope of the process..."

o Clause 6.4.2 "Risk identification" (Page 10): Defines risk identification as: "The

purpose of risk identification is to find, recognize and describe risks that might help or

prevent an organization from achieving its objectives." This identification happens within

the established scope.

o URL: (ISO standards are typically purchased, but summaries and related guidance

often reference these clauses. A direct public link to the full standard isn't usually

available from ISO itself without purchase. However, the NIST Glossary references

ISO 31000 for its definition of risk identification.) Example reference through NIST:

https://csrc.nist.gov/glossary/term/risk_identification

3. MIT OpenCourseWare, "1.040 Project Management", Spring 2008, Lecture Notes on

Risk Management:

o Lecture "Risk Management", Slide 7 ("Risk Identification"): Lists "scope statement"

as an input to the Risk Identification process. This highlights that while scope

establishment might be a distinct input, the risk identification process actively uses

and "involves" this scope to identify relevant potential risks.

o URL: (Specific slide content can be found within the course materials if publicly

available. Example: https://ocw.mit.edu/courses/1-040-project-management-spring2008/ - The user would need to navigate to the relevant lecture on risk management.) A

more general reference from a similar context can be found in many university project

management course materials discussing the PMI PMBOK® Guide's processes, which

emphasize scope as an input to risk identification.

Full disk encryption (FDE) is designed to protect data at rest by encrypting the entire

contents of the hard drive, including the operating system, application files, and user

data. This is the most comprehensive method among the options for protecting all data

on an employee's laptop if it is lost or stolen. □

A. Partition: Partition encryption only encrypts specific disk partitions, not the entire drive.

This can leave sensitive data in other partitions, like the OS partition or temporary file

locations, unprotected. FDE is more encompassing.

B. Asymmetric: Asymmetric encryption uses key pairs (public/private) and is primarily

used for tasks like secure key exchange, digital signatures, or encrypting specific files

or communications, not for encrypting an entire hard drive for data at rest protection on

a laptop.

D. Database: Database encryption protects the data within a specific database. While a

laptop might host a database, this solution doesn't cover other data like documents,

emails, or the operating system itself.

Full Disk Encryption:

National Institute of Standards and Technology (NIST), Special Publication 800-171

Revision 2, "Protecting Controlled Unclassified Information in Nonfederal Systems and

Organizations."

URL: https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final

Reference: Section 3.13.11: "Encrypt CUI on mobile devices and mobile computing

platforms." While not explicitly FDE, the context of protecting all CUI on mobile

platforms strongly implies comprehensive encryption like FDE. Page 30 discusses

protecting CUI at rest.

SANS Institute (often referenced by government and academic sources, though the

SANS website itself might be borderline, NIST often collaborates or references their work.

Sticking to more direct sources if possible).

Microsoft Documentation, "BitLocker overview" (as an example of FDE).

URL: https://learn.microsoft.com/en-us/windows/security/informationprotection/bitlocker/bitlocker-overview

Reference: "BitLocker Drive Encryption is a data protection feature that integrates

with the operating system and addresses the threats of data theft or exposure from

lost, stolen, or inappropriately decommissioned computers." This describes FDE.

Partition Encryption:

Korolev,

M. A., & Zadorozhnyy,

V. V. (2021). Methods and Means of Protecting Data on

User Devices. 2021 Systems of Signals Generating and Processing in the Field of on

Board Communications (SOSG), 1-5. IEEE.

DOI: https://doi.org/10.1109/SOSG52515.2021.9420275

Reference: The paper discusses various data protection methods, and while not

directly calling out "partition encryption" to differentiate from FDE as less secure, it

highlights FDE's comprehensiveness. The distinction is generally understood in

security literature that partition encryption is less complete than FDE.

Asymmetric Encryption:

National Institute of Standards and Technology (NIST), Special Publication 800-57 Part

1 Revision 5, "Recommendation for Key Management: Part 1 – General."

URL: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final

Reference: Section 2.2.2 "Asymmetric Key (Public-Key) Cryptography." This section

describes the use of public and private keys, typically for key establishment, digital

signatures, etc., not for bulk encryption of an entire drive.

Database Encryption:

Microsoft SQL Server Documentation, "Transparent Data Encryption (TDE)."

URL: https://learn.microsoft.com/en-us/sql/relationaldatabases/security/encryption/transparent-data-encryption

Reference: "Transparent data encryption (TDE) encrypts SQL Server, Azure SQL

Database, and Azure Synapse Analytics data files...TDE performs real-time I/O

encryption and decryption of the data and log files." This clearly defines database

encryption as specific to database files, not the entire laptop.

A backout plan consists of specific procedures to revert a system to its last known-good state if a change implementation is unsuccessful. The scenario describes a failed change that extended beyond the maintenance window, impacting customers. Executing a pre-planned and tested backout plan would have allowed the team to quickly restore the original configuration once the failure was identified, thus preventing the extended outage and customer impact. This plan is a critical component of change management designed specifically for this type of contingency.

A. User notification: This is a communication step to inform users about planned maintenance; it does not provide a technical remedy for a failed change.

B. Change approval: This is a procedural step that occurs before the change is implemented to authorize it. It does not address how to recover from a failure during implementation.

C. Risk analysis: This process identifies potential problems before the change. While it might identify the risk of failure, it is not the actionable plan used to recover from that failure.

1. CompTIA Security+ SY0-701 Exam Objectives

Version 4.0

Objective 3.2: "Summarize the importance of change management processes and the impacts to security." This section explicitly lists "Backout/rollback plans" as a key element of the change management process.

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

Guide for Security-Focused Configuration Management of Information Systems

Section 3.4.5

"Change Implementation": "If the change is not successful

the organization should follow its back-out plan to restore the system to its original state."

3. Carnegie Mellon University

Software Engineering Institute

CMU/SEI-2010-TR-017

A Framework for Classifying and Comparing Architecture-Centric Change Management Approaches

Section 3.2.2

"Change Execution": "If the change implementation fails

the change is rolled back to the previous state of the system." This highlights rollback (backout) as the standard response to a failed implementation.

User provisioning encompasses the processes and tools for creating, managing, and

deleting user accounts and their access privileges. A user provisioning script

automates these tasks, ensuring consistency and adherence to predefined access

policies, thereby addressing the issue of incorrect access or permissions in manually

set up accounts. This aligns with the core problem of streamlining account creation and

ensuring correct access.

A. Guard rail script: Guardrails are typically high-level preventative or detective

controls that enforce policies, often in cloud environments (e.g., preventing creation of

overly permissive S3 buckets). They don't directly automate the creation of user

accounts themselves.

B. Ticketing workflow: A ticketing workflow manages and tracks requests, including

those for new accounts. While it's part of the overall process, it doesn't perform the

actual account creation or permission assignment; the provisioning script would be

triggered or managed by this workflow.

C. Escalation script: An escalation script is designed to elevate issues or incidents that

cannot be resolved at a lower support tier. It is not used for routine account creation.

For User Provisioning:

Microsoft Entra ID (formerly Azure AD) documentation often discusses user provisioning.

For example, "Provisioning is the process of creating user accounts and mailboxes in

Microsoft 365." While this is product-specific, the general concept of provisioning as

creating and managing user accounts is standard.

Source: Microsoft Learn. "Overview of user and group provisioning with Microsoft

Entra ID" (Though a general concept, a specific stable URL to a definition is hard to

pin, but the term is widely used in their identity management documentation).

Specifics: The concept is foundational in identity management services described by

vendors like Microsoft.

NIST Special Publication 800-53, Revision 5, "Security and Privacy Controls for

Information Systems and Organizations," discusses account management (AC-2),

which includes provisioning.

URL: https://doi.org/10.6028/NIST.SP.800-53r5

Specifics: Section on "Account Management (AC-2)" details the requirements for

establishing, activating, modifying, reviewing, disabling, and removing accounts, which

is the essence of provisioning. Automation of these tasks via scripting is a common

implementation.

For Guardrails (as distinct from provisioning):

AWS Well-Architected Framework often refers to guardrails in the context of governance

and control.

URL: (General Concept) AWS Whitepapers & Guides - search for "Well-Architected

Framework" and "Guardrails". For instance, the "AWS Well-Architected Framework -

Security Pillar" whitepaper.

Specifics: Guardrails are described as high-level rules that provide ongoing

governance, e.g., "Implement guardrails that align with your compliance requirements

and security policies." This is broader than the specific act of account creation

automation.

For Ticketing Workflow:

ITIL (Information Technology Infrastructure Library) framework, often referenced in

academic and professional IT service management contexts, describes incident and

service request management, which use ticketing systems.

Note: Direct links to ITIL core books are typically not free. However, university

courseware on IT Service Management will cover this.

Specifics: Ticketing systems manage the lifecycle of requests, but the automation of the

fulfillment of a new account request would be a separate provisioning script/process.

For Escalation:

Similar to ticketing, ITIL and general IT operations documentation describe escalation

procedures for incident management.

Specifics: Escalation is a reactive process for unresolved issues, not a proactive

automation for account setup.