Updated to readme and template

Signed-off-by: Ian-Barbour <[email protected]>

docs/TTX/Andromeda_Gales/Andromeda_Template.md

@@ -0,0 +1,187 @@
+# Panelists & Contributors
+
+## Panelists
+
+- **Panelist 1**
+  - Role: Maintainer
+
+- **Panelist 2**
+  - Role: Maintainer
+
+- **Panelist 3**
+  - Role: Maintainer
+
+- **Panelist 4**
+  - Role: Maintainer
+
+- **Panelist 5**
+  - Role: Maintainer
+
+- **Panelist 6**
+  - Role: Repo package registry
+
+- **Panelist 7**
+  - Role: SOC/IRT
+
+- **Panelist 8**
+  - Role: End user
+
+- **Panelist 9**
+  - Role: End user
+
+- **Panelist 10**
+  - Role: End user
+
+- **Panelist 11**
+  - Role: End user
+
+- **Panelist 12**
+  - Role: End user
+
+## Contributors
+
+- **Contributor 1**
+  - Role: Maintainer
+
+- **Contributor 2**
+  - Role: Maintainer
+
+- **Contributor 3**
+  - Role: End user
+
+- **Contributor 4**
+  - Role: End user
+
+- **Contributor 5**
+  - Role: Public sector
+
+- **Contributor 6**
+  - Role: Public sector
+
+# Desired Outcomes
+
+1. Provide a TTX template/formula for maintainers, contributors, and open source consumers to adopt and customize to start running their own TTX and improve their incident response and overall security posture.
+2. Provide education for developers who are learning security.
+3. Demonstrate how current OpenSSF technologies may be helpful during a security incident.
+
+- **Welcome background description and desired outcomes for the TTX**
+
+## Breakthrough 1: Initial Incident
+
+A large mature organization has disclosed a cybersecurity incident as encouraged by the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). The details are initially sparse, but the known facts are:
+
+- A security analyst has identified anomalous egress connections from their Cloud estate.
+- The connections originated from workloads running on their Kubernetes cluster.
+- These workloads run a business application with access to confidential data.
+- Cluster logs show workloads running some commands against the cluster API, harvesting runtime environmental information.
+- The workloads have recently been updated as part of routine patching/updates, coinciding with the timing of some suspicious alerts generated.
+- The Incident Response Team (IRT) is still investigating ongoing threads.
+
+### Questions
+
+1. What are the typical steps an organization may take on initial security alert disclosure when initiating a Cyber Incident Response process?
+2. After initial cyber incident response processes have been carried out and the org has moved into in-depth investigation, what steps are typical at this stage of the IR process?
+
+## Breakthrough 2: Scenario Evolution
+
+As the investigation progresses, more details come to light:
+
+- From the CI/CD build account, the Incident Response Team (IRT) has traced the event back to a specific pipeline execution.
+- The pipeline includes several steps where external images are pulled from a public repository.
+- A specific container image pulled consists of a widely used open source application.
+- IRT obtains a copy of the image for further investigation but finds no signs of image tampering.
+- Enhanced monitoring was put in place on the suspicious workloads.
+- Signs of a possible Remote Code Execution (RCE) are detected, but the Vulnerability Management team reports no known CVEs affecting the open source application.
+- Everything points to a 0-day vulnerability affecting one or more applications components with an active exploitation campaign ongoing.
+
+### Questions
+
+1. In light of the latest investigation progress after inconclusive findings, the team have decided to focus some effort on the internal repository (e.g., GitLab self-hosted) and the CI/CD pipeline. What kind of actions should they be looking to carry out at this point and with what goals in mind?
+2. With the ongoing security incident and deep investigation, could you give some insight into how keeping a detailed inventory of both software and hardware, including open source software and dependencies, can be influential to incident response?
+3. Additionally, could you explain the concept and significance of a Software Bill of Materials (SBOM) in managing open source security and share how SBOMs can be instrumental in streamlining the investigation process particularly in identifying compromised components and mapping out dependencies for a more efficient incident response?
+
+## Breakthrough 3: Scenario Evolution
+
+The scenario further evolves:
+
+- Internal investigations have concluded and found that the exploit has spread across various resources, necessitating disclosure of the vulnerability.
+- The 0-day vulnerability is confirmed with exploitation replicated.
+- Open Source maintainers have been contacted through their vulnerability disclosure process to work on a fix.
+- Considering the active malicious campaign, the degree of urgency is communicated.
+- Threat intelligence organizations provide data on the active campaign:
+  - Malicious destination domains and IPs
+  - Malicious binary hashes
+  - Malicious process names
+  - Malicious exploitation strings
+
+### Questions
+
+1. With the recent information provided by the IRT (Incident Response Team), the scenario has grown to include open source maintainers at this stage; they're required to begin their vulnerability disclosure process. How does this typically work?
+2. In today's world, maintaining reputation across platforms is paramount. How can organizations and maintainers alike manage social media scrutiny and pressure, especially in 'crisis' events such as highly visible exploits targeting specific projects?
+3. How can you aim to protect the people working under pressure and stress throughout these events?
+
+## Breakthrough 4: Scenario Evolution
+
+The scenario evolves:
+
+- The maintainers have successfully produced and tested a fix.
+- The fix was incorporated into a new release of the application and made available to the general public.
+- Indicators of Compromise are available to aid detections.
+- The CVE now has a remediation/fix with a 9.5 score made available to the general public.
+
+### Questions
+
+1. In light of the recent successful development and release of a patch for a high-severity vulnerability, could you elaborate on best practices for coordinating efforts of maintainers and open source project teams to ensure the fix's security and authenticity, preventing it from becoming a secondary attack vector?
+2. Additionally, how can you collaborate with larger organizations or the initial disclosing entity to validate and publicize the remedy?
+
+3. Considering the recent CVE announcement, could you walk us through the process your organization employs to create a comprehensive and timely response to customers?
+4. Specifically, how do you integrate communication, patch management, and incident response strategies to address vulnerabilities and maintain trust in a cloud-native platform?
+
+5. When looking at enhancing security within open source projects, how does a collaborative project like GUAC contribute to this goal?
+6. How do projects like GUAC integrate with existing security practices to comprehensively secure open source software, and what unique advantages does GUAC provide in the broader context of open source security management?
+
+7. In light of our ongoing discussion and the scenario we've navigated, how can the OSV database and scanner be strategically used to support the identification, tracking, and resolution of vulnerabilities such as the one we've encountered?
+8. Could you share insights or experiences on how these tools have facilitated a more streamlined and effective response to vulnerabilities in past incidents?
+
+## Breakthrough 5: Postmortem / Open Discussion
+
+### Reflections on the Scenario
+
+### Questions
+
+1. What is CISA’s role in OSS security?
+2. A number of sectors have an inherent distrust in open source due to a number of factors including time to remediation, SLAs, enterprise-level support, and its 'open' nature. How do you think this could be tackled, and are there any initiatives that could support this?
+
+### End User(s) Discussion
+
+#### Forum Discussion Style Topic: 10-15 Minutes
+
+"Leveraging Corporate Resources for Open Source Security"
+- A conversation about how large organizations who have fully established policies, processes, and resources in place to respond to such incidents, invest and establish mutual beneficiary outcomes with open source maintainers and projects, potentially creating a framework for mutual support.
+
+"Collaborative Incident Response: Bridging the Gap between Large Organizations and Open Source Projects"
+- This discussion topic aims to explore how large organizations could potentially extend their incident response capabilities to support open source projects during security incidents.
+- It will focus on sharing actionable insights, resources, and best practices to enhance the resilience of open source software against emerging threats, emphasizing collaborative efforts, shared responsibility, and the alignment of incident response strategies for the collective benefit of the digital ecosystem.
+
+#### Forum Discussion Style Topic: 10-15 Minutes
+
+"Fostering Trust and Transparency: The Art of Communicating with Security Issue Reporters"
+- Discuss the importance of open lines of communication between project maintainers and Security issue reporters for enhancing project security and community trust.
+
+### Lesson Learnt, Final Observations
+
+### Closing Remarks
+
+### Q&A
+
+# Acknowledgments
+
+We thank all the panelists, contributors, and attendees for their active participation and valuable contributions to the success of this event. Special thanks to the organizing team for their efforts in coordinating and facilitating the session.
+
+# About This Document
+
+This document was created to provide a structured overview of the tabletop exercise (TTX) and to serve as a reference for future similar events.
+
+# Contact Information
+
+For any inquiries related to this document or the discussions held during the TTX, please contact OpenSSF

docs/TTX/readme.md

@@ -37,6 +37,8 @@ With this in mind we aim to produce two 'sides' to each TTX Exercise;
 ## Scenario
 The scenarios for the table top exercise typically occur after a cyber incident that has occurred. The scenarios are designed to be realistic and to test the organization's incident response plans and procedures. The scenario should includes a series of events that unfold over time, and the participants are required to respond to the events as they occur, and if technical members are in attendance you should be able to dive into attack flows, indicators and relevant data sources that correlate against the scenario.
 
+Included with every scenario should be a template (e.g. Within Andromeda_Gales there is a scenario_template.md) which covers the scenario walkthrough / roleplay, required attendees, questions and format to the TTX.
+
 ## Exercise Objectives
 The objectives of the table top exercise are to:
 - Test the organization's incident response plans and procedures