Which documentation entry BEST reflects appropriate nursing…
Questions
Which dоcumentаtiоn entry BEST reflects аpprоpriаte nursing documentation?
Cоntext & Scenаriо: Yоur engineering teаm hаs drafted a Data Flow Diagram (DFD) to model a cloud-native microservice architecture hosted on AWS that handles Personally Identifiable Information (PII), specifically, customer phone numbers. According to the diagram layout: An external User submits their Phone number over an HTTPS channel to an edge routing component (Amazon CloudFront), which forwards an encrypted version down to an internal processing zone. Separately, an Administrator accesses the AWS Management Console to monitor or manage decrypted entries. This console communicates with an internal data-processing component (AWS Lambda), which retrieves a Private Encryption Key stored in AWS Secrets Manager. In a parallel execution path inside the Amazon Boundary, an Amazon API Gateway ingests an Encrypted Phone number, passes it to a separate AWS Lambda function, which eventually commits the record to a persistent DynamoDB NoSQL data store. IF THE FIGURE IS NOT VISIBLE ABOVE, PLEASE CLICK HERE: https://github.com/GMU-CYSE/CYSE411_FIGURES-EVALUATIONS/blob/main/Q5_FIGURE.png Critical Security Update (The Threat Context): Recent log audits and configuration reviews have revealed that no internal authentication or authorization headers are verified between the AWS Management Console and the AWS Lambda process handling the encryption keys. Furthermore, the data labeled "Decrypted phone number" is transmitted internally via an unencrypted HTTP backend link, and the system relies entirely on client-side controls in the console interface to restrict what the Administrator can access. Part 1: DFD Syntax & Structural Review – 10 points Before evaluating vulnerabilities, a security architect must verify that the DFD strictly adheres to formal system modeling rules. There are two explicit, classic structural syntax errors in this diagram. Your Task: Identify and name the specific components in the diagram that contain an error. Explain why these represent violations of standard data flow logic. Part 2: Threat Enumeration (STRIDE) – 15 points Assume the architectural errors from Part 1 are noted. Based strictly on the Critical Security Update (The Threat Context) provided above, you must now perform a formal Threat Modeling exercise targeting this specific section of architecture. Your Task: Enumerate at least one (1) distinct security threat targeting different elements (boundaries, processes, or data flows) within this vulnerable section. For each threat, you must provide a description/justification using the standard classroom structure below: Targeted Element & STRIDE Category: Explicitly state which system element is targeted and which STRIDE category applies. OWASP Top 10 Classification Mapping: Map the vulnerability directly to a specific category from the OWASP Top 10 to justify your core analysis. Threat Description & Scenario: Describe a specific, realistic attack vector demonstrating how an adversary could exploit this layout, focusing on the prerequisites required and the sensitivity of the data (PII phone numbers or private encryption keys). Security Impact: Briefly summarize the operational, legal, or technical consequences if this threat successfully materializes, laying the groundwork for a subsequent risk-rating phase. Rubric Evaluation Criteria Excellent (100%) Good (85%) Average (70%) Weak (50% or Less) Part 1: DFD Syntax & Structural Review (Weight: 10 Points) Identification (4 pts): Both components are flawlessly identified. Identification (3 pts): Both components are identified, but one may be weakly named. Identification (2 pts): Only one structural error component is correctly identified. Identification (0-1 pts): Fails to identify the faulty components. Technical Logic (6 pts): Clearly and accurately explains why these anomalies violate formal data flow mechanics (contextual boundaries, input-to-output data transformation rules). Technical Logic (5 pts): Explains the structural error well, but misses minor depth regarding standard data flow architectural logic. Technical Logic (4 pts): The explanation is superficial or vague, treating the errors as generic coding bugs rather than architectural syntax flaws. Technical Logic (0-3 pts): Misunderstands the concept of DFD process modeling rules; explanation is absent, incoherent, or completely incorrect. Part 2: Threat Modeling (STRIDE Taxonomy) (Weight: 8 Points) Elicitation (4 pts): Enumerates at least two distinct, realistic security threats that cleanly align with the provided operational update/threat context. Elicitation (3.5 pts): Enumerates two threats, but one is somewhat generic or deviates slightly from the provided update constraints. Elicitation (3 pts): Explains only one distinct threat effectively or provides two that are functionally identical. Elicitation (0-2 pts): Fails to provide realistic threat scenarios or generic bullet points that don't match the architecture. STRIDE Mapping (4 pts): Correctly attributes the precise STRIDE categories to the chosen system elements without confusion. STRIDE Mapping (3.5 pts): Applies the STRIDE framework correctly, but with minor precision errors in classification. STRIDE Mapping (3 pts): Misapplies STRIDE taxonomy (e.g., confusing Tampering with Spoofing in the scenario). STRIDE Mapping (0-2 pts): Missing or completely arbitrary application of STRIDE categories. Part 2: Justification (Weight: 7 Points) Justification & Impact (7 pts): Provides a robust, highly technical description of prerequisites/attack vectors, focusing on PII/key sensitivity, and clearly details downstream security impacts. Justification & Impact (3.5 pts): Good technical scenario write-up, but lacks minor analytical depth regarding prerequisites or granular business impact. Justification & Impact (3 pts): The scenario relies on shallow buzzwords rather than a concrete attack flow; the impact statements are overly general. Justification & Impact (0-2 pts): Fails to define a realistic threat execution model or ignores data sensitivity (PII/keys) entirely.
Scenаriо In 2021, аn аttacker explоited a vulnerability inside a clоud-hosted infrastructure layer. The malicious actor manipulated an unvalidated parameter within an internal proxy service to execute a Server-Side Request Forgery (SSRF) attack. This allowed the attacker to reach an internal microservice instance containing temporary access keys. With these privileges, the attacker mapped and downloaded records containing sensitive user data from an unencrypted cloud storage repository. A risk analysis team is conducting a post-incident review using the DREAD model, utilizing a quantitative rating scale from 1 (Low) to 3 (High) for each category: Damage Potential (D): Massive regulatory exposure and leak of unencrypted records. (Assigned Rating: 3 - High) Reproducibility (R): The exploit depends on static configuration choices and succeeds predictably on every attempt. (Assigned Rating: 3 - High) Exploitability (E): Requires setting up specific internal headers and mimicking multi-stage routing requests. (Assigned Rating: 2 - Medium) Affected Users (A): The target repository housed data representing the full customer database. (Assigned Rating: 3 - High) Discoverability (D): The vulnerability sits inside internal, non-public endpoints not visible to standard external asset scanning tools. (Assigned Rating: 1 - Low) Question Risk evaluation frameworks allow teams to transform raw DREAD vectors into structured Impact and Probability parameters. Given the specific formulas utilized in class to define risk impact and likelihood through DREAD, select ALL the correct statements regarding the risk calculation metrics for this cloud threat scenario:
Scenаriо: Yоu аre mаnaging a sоftware module using Git. While you were away from your terminal, a continuous integration alert flagged an issue: an unauthorized user compromised your remote repository server and pushed a rogue commit containing an obfuscated script to a remote branch named patch-v2. Your local database contains a tracking branch named patch-v2 that points to your last known-safe, audited commit. You need to inspect the metadata and contents of the unauthorized remote commits to determine which files were touched, but you must ensure that the untrusted code is not merged or applied to your current working tree files under any circumstances during the download. Question Which of the following basic Git operations must you run to safely pull down the remote changes into your local repository database for isolated analysis without altering or automatically merging code into your active workspace files?