MANAGING-CLOUD-SECURITY Practice Questions

A sandbox is a security mechanism specifically designed to provide an isolated and controlled environment for executing untrusted code. This containment prevents potentially malicious software from accessing or affecting the host operating system, network, or other applications. Security analysts use sandboxes to safely run and observe malware, analyzing its behavior—such as network connections, file system modifications, and registry changes—without risking damage to production systems. This process is a cornerstone of dynamic malware analysis.

A. Encryption: This is a process for encoding data to protect its confidentiality. It does not provide an environment for executing or analyzing malware.

B. Gateway: A network gateway connects different networks and controls traffic flow. While security gateways can inspect traffic, they do not provide an isolated execution environment for malware analysis.

D. Controller: In cloud or SDN contexts, a controller is a centralized management component for orchestrating resources. It is not a tool for containing and analyzing malware.

1. National Institute of Standards and Technology (NIST). (2005). Special Publication 800-83: Guide to Malware Incident Prevention and Handling. Section 4.3

"Analyzing Malware

" describes dynamic analysis techniques

stating

"Dynamic analysis is typically performed by executing the malware in a sandbox environment—a tightly controlled environment that allows security analysts to observe the malware’s conduct without affecting their own network." (p. 4-5).

2. Cloud Security Alliance (CSA). (2017). Security Guidance for Critical Areas of Focus in Cloud Computing v4.0. Domain 6: "Management Plane and Business Continuity

" discusses the need for isolated environments for testing and analysis

a principle embodied by sandboxing for security purposes. (p. 73).

3. Sikorski

M.

& Honig

A. (2012). Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software. No Starch Press. Chapter 1

"Basic Dynamic Analysis

" extensively covers the use of sandboxes as the primary tool for safely executing and observing malware behavior in a controlled environment. (p. 15-16).

4. Papamartzivanos

D.

Mármol

F. G.

& Kambourakis

G. (2019). "Introducing a new dataset for malware traffic analysis." Digital Threats: Research and Practice

1(1)

1-23. The paper discusses malware analysis methods

noting

"Dynamic analysis is performed by executing the malware in a controlled environment (e.g.

sandbox) and monitoring its behavior." (Section 2.1

para. 2). DOI: https://doi.org/10.1145/3369998.

A Denial of Service (DoS) attack is specifically designed to make a machine, network, or service unavailable to its intended users. The primary goal is to disrupt the availability of the resource by overwhelming it with superfluous requests or by sending it information that triggers a crash. This directly aligns with the definition provided in the question, which is a threat that "prohibits the use of data by preventing access to it." DoS attacks are a direct assault on the 'Availability' component of the Confidentiality, Integrity, and Availability (CIA) security triad.

A. Brute force: This is a credential attack method focused on compromising confidentiality by guessing passwords, not on preventing service access for legitimate users.

B. Encryption: This is a security control to protect data confidentiality. While used maliciously in ransomware, encryption itself is a defensive mechanism, not an attack vector.

C. Rainbow tables: This is a technique for cracking password hashes to breach confidentiality, not a method for denying access to a system or its data.

1. National Institute of Standards and Technology (NIST). (2008). Technical Guide to Information Security Testing and Assessment (NIST Special Publication 800-115). Section 3.3

"Network-Based Attacks

" p. 3-4. "The goal of a DoS attack is to prevent legitimate users from accessing a particular computer system or network resource."

2. Cloud Security Alliance (CSA). (2017). Security Guidance for Critical Areas of Focus in Cloud Computing v4.0. Domain 6: Infrastructure & Virtualization Security

p. 81. The document describes Denial of Service as a key threat to the availability of cloud infrastructure.

3. Zeltser

L. (2014). Network Security: Denial of Service Attacks. MIT OpenCourseWare

6.858 Computer Systems Security

Fall 2014. Lecture 10 notes. The lecture defines DoS as an attack that "prevents legitimate users from using a service." Available at: https://ocw.mit.edu/courses/6-858-computer-systems-security-fall-2014/resources/mit6858f14lec10/

A cloud service partner is an organization that establishes a business relationship with a cloud service provider (CSP) to offer products or services that augment, integrate with, or are built upon the CSP's primary offerings. These partners extend the capabilities of the core cloud platform by providing specialized software (e.g., security tools, databases), professional services (e.g., migration, managed services), or hardware. Their role is to create a richer ecosystem around the CSP's services, providing additional value to the end customers. This directly matches the description of providing products that interact with the primary offering.

A. Regulator: A regulator is a governmental or industry body that sets policies and ensures compliance; it does not provide commercial products or services that interact with a CSP.

C. Customer: A customer (or cloud consumer) is the end-user that consumes cloud services. They do not provide services to the ecosystem but rather utilize them.

D. Cloud service developer: This is an individual role responsible for building applications. The "cloud service partner" is the organizational entity that offers these applications or services commercially.

1. ISO/IEC 17788:2014 | ITU-T Y.3500: Information technology — Cloud computing — Overview and vocabulary. This international standard defines the roles in the cloud ecosystem.

Section 3.1.6

Cloud Service Partner (CSN): Defines a CSN as a "party which is in a business relationship with either the cloud service customer or the cloud service provider

or both

and has a role in providing or using cloud services." This formal definition directly supports the concept of a partner providing services that interact with the provider's offerings.

2. Amazon Web Services (AWS) Documentation: What is the AWS Partner Network (APN)?

AWS Partner Network Overview: This official documentation states

"AWS Partners are organizations that leverage AWS to build solutions and services for customers." This exemplifies the role of a partner in providing services that interact with and are built upon the primary CSP's platform.

3. Microsoft Azure Documentation: Microsoft Cloud Partner Program.

Program Overview: Microsoft describes its partners as companies that "develop and sell solutions with Microsoft

" which includes building applications

services

and devices on top of the Microsoft Cloud platform. This further validates the role of a partner in providing interactive services.

The Zero Trust security model is founded on the principle of "never trust, always verify." It eliminates the outdated concept of a trusted internal network and an untrusted external network. Instead, it requires that all users, whether inside or outside the organization’s network, be continuously authenticated, authorized, and validated before being granted or keeping access to applications and data. This involves strict identity verification and authorization checks for every single access request, ensuring that trust is never implicit and access is granted on a least-privilege, need-to-know basis.

A. Traffic inspection: This process analyzes network data packets for malicious content or policy violations, not the continuous verification of user identity for data access.

C. Intrusion prevention: This is a threat prevention technology that examines network traffic to detect and block vulnerability exploits, rather than a model for continuous identity validation.

D. Secret management: This refers to the tools and practices for managing credentials like API keys and passwords, which is a component of security but not the overarching concept itself.

1. National Institute of Standards and Technology (NIST). (2020). Zero Trust Architecture (NIST Special Publication 800-207).

Section 2.1

Tenet 2: "Access to resources is determined by dynamic policy—including the observable state of client identity

application/service

and the requesting asset—and may include other behavioral and environmental attributes." This highlights the continuous

dynamic nature of authorization checks.

2. Microsoft. (2023). What is Zero Trust?

Guiding Principles Section: "Verify explicitly. Always authenticate and authorize based on all available data points

including user identity

location

device health

service or workload

data classification

and anomalies." This directly supports the concept of continuous checks.

3. Google Cloud. (n.d.). BeyondCorp Overview.

Introduction: "BeyondCorp is Google's implementation of the zero trust model. It builds upon a decade of experience at Google

combined with ideas and best practices from the community. By shifting access controls from the network perimeter to individual users

BeyondCorp enables secure work from any location without the need for a traditional VPN." This illustrates the shift to user-centric

continuous verification.

4. Rose

S.

Borchert

O.

Mitchell

S.

& Connelly

S. (2020). Zero Trust Architecture. (NIST Special Publication 800-207). National Institute of Standards and Technology.

DOI: https://doi.org/10.6028/NIST.SP.800-207

Page 6

Section 2.1

Tenet 1: "All data sources and computing services are considered resources. A network connection must not be the sole determining factor for trust in a network." This establishes the foundation that requires every resource access to be checked independently.

When an organization (the data controller) shares personal information with a third party (the data processor), it retains accountability for the protection of that data. To fulfill this responsibility, the organization must provide the third party with clear, explicit instructions on how the data is to be handled. This is accomplished by sharing its privacy policy and associated handling practices. This communication ensures the third party understands the specific requirements for data processing, storage, security, and disposal, thereby contractually obligating them to uphold the same privacy commitments the organization has made to its users.

A. Audit results reflect the organization's past compliance status; they do not provide the specific, forward-looking handling instructions required for the data being shared.

B. Sharing data when contractual obligations and privacy policies are misaligned is a serious compliance violation. This issue must be resolved before sharing, not simply communicated.

C. While the third party must comply with federal laws, the organization is responsible for communicating its own, potentially more stringent, policies and specific handling requirements.

1. NIST Special Publication 800-53 Revision 5

Security and Privacy Controls for Information Systems and Organizations. Control PT-7

"Third-Party Use

" requires organizations to "Establish and enforce agreements with third parties that require the protection of PII." The discussion section elaborates that these agreements must specify the authorized uses and disclosures of PII

which are derived from the organization's policies and practices.

2. General Data Protection Regulation (GDPR)

Article 28

"Processor." As a foundational framework for modern privacy taught in university curricula

GDPR mandates that a contract must govern processing by a third party. This contract must stipulate the "nature and purpose of the processing" and the "obligations and rights of the controller

" which directly translates to communicating the organization's policies and handling practices.

3. Solove

D. J.

& Schwartz

P. M. (2021). Information Privacy Law (7th ed.). Wolters Kluwer. In discussions on information sharing with third parties (Chapter 7

Section C)

the text emphasizes the necessity of contracts that limit the use and disclosure of personal information according to the primary organization's privacy policy.

The procurement department is fundamentally responsible for the entire lifecycle of vendor and supplier relationships, from initial sourcing and vetting to contracting, performance management, and renewal. Within an Enterprise Risk Management (ERM) framework, conducting formal risk assessments is a critical due diligence step managed by procurement. This process evaluates potential financial, operational, compliance, and security risks associated with a third party before entering into or renewing a business relationship. This function is central to managing an organization's supply chain and third-party risk exposure, making it the correct business area concerned with these formal assessments.

A. Software development: This area focuses on creating and maintaining software; while they may assess a vendor's technology, they do not own the formal business relationship or its overall risk assessment.

C. Quality assurance: This function tests whether a vendor's product or service meets predefined quality standards, which is only one component of a comprehensive risk assessment.

D. Marketing: This department is focused on promotion and sales and is not involved in the formal risk assessment or management of procurement and vendor relationships.

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

Managing Information Security Risk. Section 2.3

"Risk Management and the System Development Life Cycle

" explicitly lists "Acquisition/Procurement" as a key phase where risk management activities

including assessments

are essential for managing risks associated with externally provided systems and services.

2. Committee of Sponsoring Organizations of the Treadway Commission (COSO). (2017). Enterprise Risk Management — Integrating with Strategy and Performance. Principle 14

"Assesses Substantial Change

" emphasizes that organizations must assess risks arising from significant changes

including new or changing business partners (vendors). The procurement function is the primary owner of the due diligence process for these relationships. (See Component: Review and Revision

Page 59).

3. Hallikas

J.

Karvonen

I.

Pulkkinen

U.

Virolainen

V. M.

& Tuominen

M. (2004). Risk management processes in supplier networks. International Journal of Production Economics

90(1)

47-58. This academic paper details the risk management process in supply chains

highlighting that risk assessment is a core part of the supplier selection and procurement process. (Section 3

"A framework for risk management in supplier networks"). https://doi.org/10.1016/j.ijpe.2004.02.007

The organization's stated problem is a lack of a "complete understanding of the infrastructure and software." The foundational step to address this gap is to perform a comprehensive inventory of all hardware, software, and data assets. This inventory is a prerequisite for all subsequent disaster recovery (DR) planning activities, such as conducting a business impact analysis (BIA), identifying critical systems, and developing recovery strategies. Without a detailed asset inventory, it is impossible to formulate an accurate or effective DR plan because the scope of what needs to be recovered is unknown.

A. Creating a checklist of tasks is a subsequent planning step that cannot be completed accurately without first knowing which assets need recovery tasks assigned to them.

B. Determining the criteria of a disaster defines the trigger for activating the plan but does not help in identifying the assets that need to be recovered.

C. Identifying key roles establishes the human command structure for a disaster response but does not address the lack of knowledge about the technical infrastructure.

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

Contingency Planning Guide for Federal Information Systems.

Section 3.3

"Conduct the Business Impact Analysis (BIA)

" outlines the initial steps of contingency planning. The BIA process requires identifying and prioritizing mission/business processes and the information systems that support them. This cannot be done without a thorough understanding and inventory of the organization's assets. The guide states

"The BIA is the first step in the contingency planning process."

2. Brotby

K.

& Huda

F. (2021). Cloud Security for Dummies. John Wiley & Sons.

Chapter 15

"Ensuring Business Continuity

" emphasizes that a business impact analysis (BIA) is a foundational element. A key input to the BIA is a complete inventory of assets. The text explains that you must first "identify the critical business functions and the assets that support them" before you can determine recovery objectives.

3. Snedaker

S. (2013). Business Continuity and Disaster Recovery Planning for IT Professionals (2nd ed.). Syngress.

Chapter 4

"Phase 1: Project Initiation and Management

" details the initial steps of BCDR planning. It explicitly states that a key task in this phase is to "Identify the people

processes

technologies

facilities

and other resources that support each business process

" which is fundamentally an asset inventory.

In Agile software development methodologies, which are central to modern cloud application lifecycles, "User Stories" are the standard tool for describing requirements. A user story is a concise, informal description of a feature or improvement from the end-user's perspective. It captures the "who," "what," and "why" of a requirement without delving into technical implementation details. This makes it the ideal artifact for a developer to articulate the requirements they have gathered for a specific code improvement task within a release cycle, ensuring clarity and alignment with user needs.

A. Cases: This term is ambiguous. While it could refer to "use cases," "stories" are the more specific and standard artifact for this purpose in Agile development frameworks like Scrum.

C. Cookies: Cookies are small data files stored on a user's computer by a web browser. They are a technical component for session management, not a tool for documenting requirements.

D. Notes: While a developer may take personal notes, this is an informal and unstructured method. It is not a formal tool for communicating requirements to a team or tracking work.

1. Cohn

M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional. In Chapter 2

"Writing Stories

" Cohn defines user stories as a primary means to express functional requirements in Agile projects (pp. 15-17).

2. Atlassian. (n.d.). User stories | Examples and template. Atlassian Agile Coach. Retrieved from https://www.atlassian.com/agile/project-management/user-stories. This official vendor documentation defines a user story as "an informal

general explanation of a software feature written from the perspective of the end user or customer."

3. Lucassen

G.

Dalpiaz

F.

van der Werf

J. M. E.

& Brinkkemper

S. (2016). The use and effectiveness of user stories in practice. In 2016 IEEE 24th International Requirements Engineering Conference (RE) (pp. 205-214). IEEE. https://doi.org/10.1109/RE.2016.29. This peer-reviewed paper analyzes the practical application of user stories as a central tool for requirements elicitation and documentation in software projects.

Baselining is the process of establishing and documenting a known, trusted, and secure state for a system or network. This "baseline" serves as a reference point. By continuously monitoring the system against this baseline, any deviations or changes can be quickly identified. This allows security teams to investigate whether a change was authorized (e.g., an approved patch) or unauthorized (e.g., malicious activity), enabling proper approval or remediation actions. This practice is a fundamental component of configuration management and security monitoring.

B. Patch management: This is the specific process of identifying, testing, and applying software updates (patches) to systems, not the broader process of documenting a standard state.

C. Deployment: This refers to the process of installing and configuring a system or application for operational use, which precedes the creation of a baseline for ongoing monitoring.

D. Capacity management: This discipline focuses on ensuring that IT resources are sufficient to meet current and future performance and availability requirements, not on tracking configuration changes.

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

Guide for Security-Focused Configuration Management of Information Systems. Section 2.2

"Configuration Management Terms

" defines a configuration baseline as "The set of specifications for an information system...that has been formally reviewed and agreed on at a given point in time

and which can be changed only through change control procedures."

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

Security and Privacy Controls for Information Systems and Organizations. Control CM-2

"Baseline Configuration

" states that the organization must "develop

document

and maintain...a current baseline configuration of the information system." The discussion section clarifies that this is used to manage and control changes to the system.

3. Carnegie Mellon University

Software Engineering Institute (SEI)

Configuration Management. The SEI defines a baseline as a "formally accepted version of a configuration item." It emphasizes that baselines serve as the basis for further development and can only be changed through formal change control procedures

which directly aligns with the question's intent. (Reference: CMMI for Development

Version 1.3

November 2010

p. 249).

The Sarbanes-Oxley (SOX) Act of 2002 is a United States federal law enacted in response to major corporate and accounting scandals. Its primary purpose is to protect investors by improving the accuracy, reliability, and transparency of corporate financial disclosures. SOX mandates that the management of publicly traded companies establish, assess, and report on the effectiveness of their internal controls over financial reporting (ICFR). This includes controls over the information technology systems that store and process financial data, making IT and cloud security controls a critical component of SOX compliance.

A. The Gramm-Leach-Bliley Act (GLBA): This law requires financial institutions to explain their information-sharing practices to their customers and to safeguard sensitive nonpublic personal information.

B. The General Data Protection Regulation (GDPR): This is a European Union (EU) regulation focused on data protection and privacy for individuals within the EU, not a U.S. law on corporate financial reporting.

D. The Clarifying Lawful Overseas Use of Data (CLOUD) Act: This U.S. law governs law enforcement access to electronic data held by U.S.-based technology companies, regardless of where the data is stored globally.

1. Wallace

L.

Lin

Z.

& Cefaratti

M. (2011). The impact of the Sarbanes-Oxley Act on information security. Journal of Information Systems

25(1)

143-167. (See Abstract and Introduction

pp. 143-144

for a summary of SOX's purpose regarding financial reporting and internal controls). DOI: https://doi.org/10.2308/jis.2011.25.1.143

2. Amazon Web Services (AWS). (2022). AWS User Guide to Financial Services Regulations and Guidelines in the US. Section: "Sarbanes-Oxley Act (SOX)

" p. 11. This document states

"The Sarbanes-Oxley Act of 2002... is designed to protect investors and the public by increasing the accuracy and reliability of corporate disclosures."

3. MIT OpenCourseWare. (2011). 15.219 Global Economic Challenges and Opportunities

Fall 2011. Lecture Notes

Session 10: Corporate Governance. The notes discuss the enactment of SOX as a response to accounting scandals to restore investor confidence through enhanced corporate responsibility and financial disclosures.