| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 9 | 1 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 2 | 1 | 0% |
What each file covers
Sections
0 shared · 9 only in A · 1 only in B- − .clinerules Directory Overview
- − Existing Components
- − Personas (`./personas/`)
- − Runbooks (`./run_books/`)
- − Suggested Additional Context Files
- − 1. Environment & Infrastructure Context
- − 2. Tool Configuration & Usage
- − 3. Organizational Policies & Procedures
- − 4. Threat Intelligence & Context
- + Project Plan: Enhance LLM Agent Context
Commands
neither file has anySection tags
0 shared · 2 only in A · 1 only in B- − setup
- − architecture
- + agent-behaviour
Line diff
repulsivityy/elevate_2025 · .clinerules/readme.md
@@ −1 @@
1# .clinerules Directory Overview
2
3This directory contains configuration files and documentation to provide context and guidance for LLM Agents operating within this security environment.
4
5## Existing Components
6
7### Personas (`./personas/`)
8
9* **Purpose:** These files define standard roles within the security operations team (e.g., SOC Analyst Tiers 1-3, Incident Responder, Threat Hunter, CTI Researcher, Security Engineer, Compliance Manager, SOC Manager).
10* **Content:** Each persona description outlines typical responsibilities, required skills, commonly used MCP tools, and relevant runbooks.
11* **Usage by LLM Agent:** Helps the agent understand user intent, tailor responses and actions to the user's likely role and perspective, and select appropriate tools and runbooks.
12
13### Runbooks (`./run_books/`)
14
15* **Purpose:** These files contain documented, step-by-step procedures or workflows for specific security operations tasks (e.g., triaging alerts, investigating IOCs, hunting for threats, responding to phishing).
16* **Content:** They often include objectives, scope, required inputs, specific MCP tools to use, workflow steps (sometimes visualized with diagrams like Mermaid), and expected outcomes.
17* **Usage by LLM Agent:** Serves as a primary plan for executing common security workflows, ensuring adherence to established procedures, guiding tool selection and sequencing, and promoting consistency.
18* **IRP vs. Runbook Distinction:** While all files here serve as procedural guides, we differentiate between:
19 * **Incident Response Plans (IRPs):** Located in the `./run_books/irps/` subdirectory, these outline the *end-to-end strategy* for handling major incident types (e.g., malware, phishing) following the full PICERL lifecycle. They orchestrate multiple steps and often call other runbooks. Use these as the starting point for major incident types.
20 * **Runbooks:** Located directly within `./run_books/` or in `./run_books/common_steps/`, these provide detailed, *tactical steps* for specific tasks (e.g., enriching an IOC, triaging an alert, isolating an endpoint) or reusable procedures. They are often components within a larger IRP.
21
22## Suggested Additional Context Files
23
24The following types of files could further enhance an LLM Agent's effectiveness:
25
26### 1. Environment & Infrastructure Context
27
28* **`network_map.md`**: Describes key network segments (e.g., DMZ, production servers, user subnets), their IP ranges, and primary functions. Helps in understanding the context of network events and potential lateral movement.
29* **`asset_inventory_guidelines.md`**: Outlines naming conventions for hosts/servers, common OS types, and potentially maps critical assets to their roles or owners. Helps contextualize alerts involving specific hosts.
30* **`critical_applications.md`**: Lists key business applications, their associated servers/IPs, and expected communication patterns. Useful for identifying anomalous behavior related to core services.
31* **`cloud_architecture.md`**: Provides an overview of the cloud environment structure (e.g., GCP project organization, key services like GKE, Cloud SQL), relevant for cloud-focused investigations (using SCC, etc.).
32
33### 2. Tool Configuration & Usage
34
35* **`tool_configurations.md`**: Details specific configurations crucial for tool usage, like:
36 * Important Chronicle Reference List names (e.g., `IP_Blocklist`, `Domain_Allowlist`) and their purpose.
37 * Key SOAR playbook names/IDs and what triggers them.
38 * Default timeframes or limits preferred for certain searches.
39* **`mcp_tool_best_practices.md`**: Offers tips or preferred syntax for using specific MCP tools effectively (e.g., optimizing `search_security_events` queries, interpreting specific GTI fields).
40* **`tool_rate_limits.md`**: Explicitly lists known rate limits or quotas for tools (like the Chronicle UDM query limit mentioned for a SOAR action) to help manage usage.
41
42### 3. Organizational Policies & Procedures
43
44* **`incident_severity_matrix.md`**: Defines how incident severity (Low, Medium, High, Critical) is determined based on impact and threat type. Aids in prioritization.
45* **`escalation_paths.md`**: Outlines who to notify or escalate to under specific circumstances (e.g., confirmed ransomware, PII exposure).
46* **`reporting_templates.md`**: Provides standard formats or key sections required for different types of reports (e.g., daily SOC summary, post-incident report).
47* **`approved_remediations.md`**: Lists standard, pre-approved containment or remediation actions for common, lower-severity findings.
48* **`key_contacts.md`**: Lists relevant teams or individuals for specific issues (e.g., Network Ops, Identity Team, Legal).
49
50### 4. Threat Intelligence & Context
51
52* **`internal_threat_profile.md`**: Details specific threat actors, campaigns, or TTPs that are of high concern to *this specific organization*.
53* **`allowlists.md`**: Lists organization-specific known-good IPs, domains, file hashes, or process names that should generally be ignored unless context suggests otherwise.
54* **`common_benign_alerts.md`**: Describes alerts often triggered by known benign activity (e.g., vulnerability scans, specific admin scripts) and how to typically handle them.
55
56Having these additional context files would allow the LLM Agent to perform more nuanced analysis, make better-informed decisions, adhere more closely to organizational standards, and require less clarification during complex tasks.
57
repulsivityy/elevate_2025 · .clinerules/project_plan.md
@@ +1 @@
1# Project Plan: Enhance LLM Agent Context
2
3**Project Goal:** To create a comprehensive set of context files within the `.clinerules` directory, improving the LLM Agent's understanding of the environment, tools, policies, and relevant threats.
4
5**Project Phases & Tasks:**
6
7**Phase 1: Environment & Infrastructure Context**
8* **Objective:** Document the technical environment to provide operational context.
9* **Tasks:**
10 1. **Create `network_map.md`**:
11 * Gather information on key network segments (DMZ, Prod, User nets).
12 * Document IP ranges and primary functions for each segment.
13 * *Potential Action:* Ask user/Network Team for this information or relevant documentation.
14 2. **Create `asset_inventory_guidelines.md`**:
15 * Document host/server naming conventions.
16 * List common OS types deployed.
17 * Identify and map critical assets to roles/owners (if possible).
18 * *Potential Action:* Ask user/IT Asset Management for guidelines or inventory access.
19 3. **Create `critical_applications.md`**:
20 * List key business applications.
21 * Map applications to supporting servers/IPs.
22 * Describe expected communication patterns.
23 * *Potential Action:* Ask user/Application Owners for this information.
24 4. **Create `cloud_architecture.md`**:
25 * Outline GCP project structure.
26 * List key cloud services in use (GKE, Cloud SQL, etc.).
27 * Describe basic cloud network topology (VPCs, subnets).
28 * *Potential Action:* Ask user/Cloud Team for architecture diagrams or descriptions.
29 5. **Create `security_products_inventory.md`**:
30 * List key security products deployed (e.g., EDR vendor/product, Firewall vendor/product, Email Gateway, Vulnerability Scanner, etc.).
31 * Briefly note the primary function of each product.
32 * *Potential Action:* Ask user/Security Engineering/SOC Manager for this inventory.
33 6. **Create `baseline_behavior.md`**:
34 * Document known normal operational patterns (e.g., expected administrative script activity times/sources, typical outbound traffic patterns for key servers, common benign scan activity).
35 * This can help differentiate anomalous activity from expected noise.
36 * *Potential Action:* Gather this from user/SOC team experience/historical analysis.
37 7. **Create `log_source_overview.md`**:
38 * Identify critical log sources (OS, network, cloud, application, security tools).
39 * Document primary location/ingestion method (e.g., Chronicle Parser, Splunk Index).
40 * Note typical retention periods.
41 * *Potential Action:* Ask user/Security Engineering/Platform Admins.
42 * **Rationale:** Inspired by the heavy reliance on log analysis in both NIST SP 800-61r3 and CISA Playbooks. Provides essential context for detection and investigation.
43
44**Phase 2: Tool Configuration & Usage**
45* **Objective:** Document specific tool configurations and best practices.
46* **Tasks:**
47 1. **Create `tool_configurations.md`**:
48 * Identify and list important Chronicle Reference List names (Blocklists, Allowlists).
49 * Document key SOAR playbook names/IDs and their triggers.
50 * Define preferred default timeframes/limits for searches.
51 * *Potential Action:* Ask user/Security Engineering about these configurations.
52 2. **Create `mcp_tool_best_practices.md`**:
53 * Compile tips for optimizing `search_security_events`.
54 * Note important fields or interpretation guidance for GTI tools.
55 * Add any other tool-specific usage advice.
56 * *Potential Action:* Gather this information iteratively based on experience or ask user/senior analysts.
57 3. **Create `tool_rate_limits.md`**:
58 * Document known rate limits (e.g., Chronicle UDM query limits per hour).
59 * *Potential Action:* Check tool documentation or ask user/tool administrators.
60 4. **Create `detection_strategy.md`**:
61 * Outline the high-level strategy for detection development (e.g., focus areas, use of MITRE ATT&CK, threat intelligence driven).
62 * Mention key detection platforms (e.g., Chronicle SIEM, EDR).
63 * Include key detection thresholds or sensitivity levels where applicable.
64 * Reference `internal_threat_profile.md` for priority threats.
65 * *Potential Action:* Ask user/Detection Engineering Lead/SOC Manager.
66 * **Rationale:** Aligns with the "Detect" function of NIST CSF 2.0 and provides context for how detections are created and prioritized.
67
68**Phase 3: Governance, Policies & Procedures**
69* **Objective:** Codify key organizational processes relevant to security operations and governance. (Aligned with NIST CSF 2.0 "Govern" function).
70* **Tasks:**
71 1. **Create `governance_overview.md`**:
72 * Describe the overall cybersecurity governance structure.
73 * Outline the risk management approach and appetite.
74 * Reference key policies (linking to where they might exist if not directly in `.clinerules`).
75 * *Potential Action:* Ask user/CISO Office/Compliance Manager.
76 * **Rationale:** Directly addresses the "Govern" function of NIST CSF 2.0.
77 2. **Create `incident_severity_matrix.md`**:
78 * Define criteria for Low, Medium, High, Critical incidents.
79 * *Potential Action:* Ask user/SOC Manager for the existing matrix or definitions.
80 2. **Create `escalation_paths.md`**:
81 * Document who to notify for specific incident types (Ransomware, PII exposure, etc.).
82 * *Potential Action:* Ask user/IR Lead/SOC Manager for escalation procedures.
83 3. **Create `reporting_templates.md`**:
84 * Provide standard formats/sections for common reports (Daily Summary, Post-Incident).
85 * *Potential Action:* Ask user/SOC Manager for existing templates.
86 4. **Create `approved_remediations.md`**:
87 * List pre-approved actions for common low-severity findings.
88 * *Potential Action:* Ask user/Security Engineering/SOC Manager for this list.
89 5. **Create `key_contacts.md`**:
90 * List relevant teams/individuals (Network Ops, Identity, Legal).
91 * *Potential Action:* Ask user/SOC Manager for contact points.
92 6. **Create `vulnerability_management_process.md`**:
93 * Describe the tools used for vulnerability scanning (e.g., SCC, Tenable).
94 * Outline scanning frequency and scope.
95 * Explain the prioritization process (linking to `incident_severity_matrix.md`).
96 * Describe standard remediation workflows and timelines.
97 * *Potential Action:* Ask user/Vulnerability Management Team/Security Engineering.
98 * **Rationale:** Incorporates insights from the CISA Vulnerability Response Playbook.
99 7. **Create `communication_plan_templates.md`**:
100 * Provide templates/guidelines for internal and external communications during different incident stages/types.
101 * Reference `escalation_paths.md` and `key_contacts.md`.
102 * *Potential Action:* Ask user/IR Lead/Corporate Communications.
103 * **Rationale:** Addresses communication needs highlighted in both NIST SP 800-61r3 and CISA playbooks.
104
105**Phase 4: Threat Intelligence & Context**
106* **Objective:** Document organization-specific threat context and known benign activity.
107* **Tasks:**
108 1. **Create `internal_threat_profile.md`**:
109 * List high-concern threat actors, campaigns, or TTPs specific to the organization.
110 * *Potential Action:* Ask user/CTI Team for this profile.
111 2. **Create `allowlists.md`**:
112 * List known-good IPs, domains, hashes, process names specific to the environment.
113 * *Potential Action:* Gather this from user/Security Engineering/existing documentation.
114 3. **Create `common_benign_alerts.md`**:
115 * Describe alerts often triggered by benign activity (scans, admin scripts).
116 * Outline typical handling procedures for these.
117 * *Potential Action:* Gather this from user/SOC team experience.
118
119**Phase 5: Recovery & Resilience**
120* **Objective:** Document plans and procedures related to recovering from cybersecurity incidents. (Aligned with NIST CSF 2.0 "Recover" function).
121* **Tasks:**
122 1. **Create `disaster_recovery_plan_summary.md`**:
123 * Provide a high-level summary of DR/BCP plans relevant to SOC/IR activities.
124 * Outline key recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical systems.
125 * *Potential Action:* Ask user/Business Continuity Team/IT Operations for summaries.
126 2. **Create `backup_strategy_overview.md`**:
127 * Summarize backup methods, locations, and frequency for critical systems (identified in Phase 1).
128 * Outline general procedures for data restoration validation.
129 * *Potential Action:* Ask user/Backup Administrators/IT Operations.
130
131**Phase 6: Runbook Refinement & Optimization**
132* **Objective:** Continuously improve the clarity, efficiency, and robustness of existing runbooks based on operational experience and evolving capabilities.
133* **Tasks (Ongoing/Iterative):**
134 1. **Enhance Error Handling & Fallbacks:**
135 * Review `enrich_ioc.md` and other runbooks to add specific guidance for handling tool errors (e.g., "If GTI lookup fails due to quota, note limitation and rely on SIEM context").
136 * Suggest concrete alternative steps (e.g., "If primary SIEM search fails, try broader time window or alternative query structure").
137 * Integrate checks against `tool_rate_limits.md` before calling tools with known limits.
138 2. **Improve Context Integration:**
139 * Modify `triage_alerts.md` to suggest checking `common_benign_alerts.md`.
140 * Update investigation runbooks to prompt referencing `network_map.md` or `asset_inventory_guidelines.md` when assessing internal entity criticality.
141 3. **Refine Common Steps:**
142 * Analyze `enrich_ioc.md` - could it be split into `enrich_ip.md`, `enrich_domain.md`, etc., for more specific logic/fallbacks?
143 * Review other common steps for potential modularization.
144 4. **Clarify Decision Logic:**
145 * Refine assessment steps in runbooks like `triage_alerts.md` with specific examples (e.g., "If source IP is internal AND user is known admin AND target is domain controller AND time matches known patching window -> Likely BTP. Else -> Investigate further.").
146 * Explicitly link decision criteria to `incident_severity_matrix.md` where applicable.
147 5. **Standardize Reporting Outputs:**
148 * Define a standard "Key Findings" structure in `reporting_templates.md` to be used across triage, investigation, and hunt reports.
149 6. **Align with Personas:**
150 * Review runbooks like `deep_dive_ioc_analysis.md` or `advanced_threat_hunting.md` and add "*(Tier 2+/Tier 3 Recommended)*" annotations to particularly complex steps or tool usage.
151 7. **Incorporate Visualizations:**
152 * Update `case_event_timeline_and_process_analysis.md` to explicitly require a Mermaid process tree diagram in the report.
153 * Encourage adding simple relationship diagrams (e.g., `graph LR; Host-->IP; IP-->Domain;`) in investigation reports.
154 8. **Address Tool Limitations:**
155 * Ensure `find_relevant_soar_case.md` clearly documents the `list_cases` entity search limitation and suggests specific workarounds (manual search, SIEM correlation).
156 * **Rationale:** Ensures runbooks remain effective, reflect real-world conditions, incorporate lessons learned (like tool errors), and leverage the full context available within the `.clinerules` directory.
157
158**Next Steps:**
159
160This plan outlines the creation of the suggested files. We can tackle these phases and tasks sequentially or prioritize based on which information would provide the most immediate value.
161
162Would you like to start working on creating one of these files, perhaps beginning with Phase 1? Or would you like to adjust this plan? Please let me know how you'd like to proceed and toggle to ACT MODE when you're ready for me to start creating the files.
163
164**For inspiration:**
165
166Here are some references and projects that might be helpful when looking for inspiration:
167
168 1. Incident Response Recommendations and Considerations for Cybersecurity Risk Management
169 * A CSF 2.0 Community Profile. NIST Special Publication 800.
170 * URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf
171 1. Cybersecurity Incident & Vulnerability Response Playbooks
172 * Operational Procedures for Planning and Conducting Cybersecurity Incident and Vulnerability Response Activities in FCEB Information Systems
173 * URL: https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
174 1. The NIST Cybersecurity Framework (CSF) 2.0
175 * URL: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
176 1. Cybersecurity Log Management Planning Guide
177 * NIST Special Publication NIST SP 800-92r1 (Initial Public Draft)
178 * URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-92r1.ipd.pdf
179 1. SOCFortress Playbooks
180 * This repository contains incident response playbooks and workflows organized according to NIST-800.61 r2 standards. Each playbook is broken down into 6 sections and includes PDF versions for auditors and customers. It's designed specifically for SOC analysts.
181 * GitHub URL: https://github.com/socfortress/Playbooks
182 * [Incident Response Plan for Malware](https://github.com/socfortress/Playbooks/blob/main/IRP-Malware/README.md)
183 * [Incident Response Plan for Compromised Account](https://github.com/socfortress/Playbooks/blob/main/IRP-AccountCompromised/README.md)
184 * [Incident Reponse Plan for Phishing](https://github.com/socfortress/Playbooks/blob/main/IRP-Phishing/README.md)
185 * [Incident Reponse Plan for Ransomware](https://github.com/socfortress/Playbooks/blob/main/IRP-Ransom/README.md)
186 1. Open Source SOC Documentation (OSSOCDOCS)
187 * This comprehensive project provides a complete library of SOC documentation including SOPs, policies, processes, and best practices. It follows a structured pyramid approach with detailed runbooks that offer step-by-step instructions for specific security operations like investigating malicious URLs or responding to specific alerts.
188 * GitHub URL: https://github.com/madirish/ossocdocs
189 1. Microsoft Student SOC Toolkit
190 * This toolkit provides resources to prepare students for SOC work, including structured learning modules, hands-on experience, and certification pathways. It contains implementation guidance, a comprehensive training course, and simulated security incidents to build practical knowledge in incident response and threat detection.
191 * GitHub URL: https://github.com/microsoft/SOC
192 1. Awesome SOC Collection
193 * This is a collection of documentation sources and field best practices for building and running a SOC. It includes strategies for structuring SOCs, communication practices, performance metrics, and advanced SOC functionalities like threat hunting and red teaming.
194 * GitHub URL: https://github.com/cyb3rxp/awesome-soc
195 1. Security Operations Center Topic on GitHub
196 * The GitHub "security-operations-center" topic page lists numerous projects related to SOC operations, including Python modules for SOC enhancement, security maturity tracking matrices, and automation tools that integrate platforms like Wazuh, Shuffle, and TheHive.
197 * GitHub URL: https://github.com/topics/security-operations-center
198
@@ −1 +1 @@
1−# .clinerules Directory Overview
1+# Project Plan: Enhance LLM Agent Context
22
3−This directory contains configuration files and documentation to provide context and guidance for LLM Agents operating within this security environment.
3+**Project Goal:** To create a comprehensive set of context files within the `.clinerules` directory, improving the LLM Agent's understanding of the environment, tools, policies, and relevant threats.
44
5−## Existing Components
5+**Project Phases & Tasks:**
66
7−### Personas (`./personas/`)
7+**Phase 1: Environment & Infrastructure Context**
8+* **Objective:** Document the technical environment to provide operational context.
9+* **Tasks:**
10+ 1. **Create `network_map.md`**:
11+ * Gather information on key network segments (DMZ, Prod, User nets).
12+ * Document IP ranges and primary functions for each segment.
13+ * *Potential Action:* Ask user/Network Team for this information or relevant documentation.
14+ 2. **Create `asset_inventory_guidelines.md`**:
15+ * Document host/server naming conventions.
16+ * List common OS types deployed.
17+ * Identify and map critical assets to roles/owners (if possible).
18+ * *Potential Action:* Ask user/IT Asset Management for guidelines or inventory access.
19+ 3. **Create `critical_applications.md`**:
20+ * List key business applications.
21+ * Map applications to supporting servers/IPs.
22+ * Describe expected communication patterns.
23+ * *Potential Action:* Ask user/Application Owners for this information.
24+ 4. **Create `cloud_architecture.md`**:
25+ * Outline GCP project structure.
26+ * List key cloud services in use (GKE, Cloud SQL, etc.).
27+ * Describe basic cloud network topology (VPCs, subnets).
28+ * *Potential Action:* Ask user/Cloud Team for architecture diagrams or descriptions.
29+ 5. **Create `security_products_inventory.md`**:
30+ * List key security products deployed (e.g., EDR vendor/product, Firewall vendor/product, Email Gateway, Vulnerability Scanner, etc.).
31+ * Briefly note the primary function of each product.
32+ * *Potential Action:* Ask user/Security Engineering/SOC Manager for this inventory.
33+ 6. **Create `baseline_behavior.md`**:
34+ * Document known normal operational patterns (e.g., expected administrative script activity times/sources, typical outbound traffic patterns for key servers, common benign scan activity).
35+ * This can help differentiate anomalous activity from expected noise.
36+ * *Potential Action:* Gather this from user/SOC team experience/historical analysis.
37+ 7. **Create `log_source_overview.md`**:
38+ * Identify critical log sources (OS, network, cloud, application, security tools).
39+ * Document primary location/ingestion method (e.g., Chronicle Parser, Splunk Index).
40+ * Note typical retention periods.
41+ * *Potential Action:* Ask user/Security Engineering/Platform Admins.
42+ * **Rationale:** Inspired by the heavy reliance on log analysis in both NIST SP 800-61r3 and CISA Playbooks. Provides essential context for detection and investigation.
843
9−* **Purpose:** These files define standard roles within the security operations team (e.g., SOC Analyst Tiers 1-3, Incident Responder, Threat Hunter, CTI Researcher, Security Engineer, Compliance Manager, SOC Manager).
10−* **Content:** Each persona description outlines typical responsibilities, required skills, commonly used MCP tools, and relevant runbooks.
11−* **Usage by LLM Agent:** Helps the agent understand user intent, tailor responses and actions to the user's likely role and perspective, and select appropriate tools and runbooks.
44+**Phase 2: Tool Configuration & Usage**
45+* **Objective:** Document specific tool configurations and best practices.
46+* **Tasks:**
47+ 1. **Create `tool_configurations.md`**:
48+ * Identify and list important Chronicle Reference List names (Blocklists, Allowlists).
49+ * Document key SOAR playbook names/IDs and their triggers.
50+ * Define preferred default timeframes/limits for searches.
51+ * *Potential Action:* Ask user/Security Engineering about these configurations.
52+ 2. **Create `mcp_tool_best_practices.md`**:
53+ * Compile tips for optimizing `search_security_events`.
54+ * Note important fields or interpretation guidance for GTI tools.
55+ * Add any other tool-specific usage advice.
56+ * *Potential Action:* Gather this information iteratively based on experience or ask user/senior analysts.
57+ 3. **Create `tool_rate_limits.md`**:
58+ * Document known rate limits (e.g., Chronicle UDM query limits per hour).
59+ * *Potential Action:* Check tool documentation or ask user/tool administrators.
60+ 4. **Create `detection_strategy.md`**:
61+ * Outline the high-level strategy for detection development (e.g., focus areas, use of MITRE ATT&CK, threat intelligence driven).
62+ * Mention key detection platforms (e.g., Chronicle SIEM, EDR).
63+ * Include key detection thresholds or sensitivity levels where applicable.
64+ * Reference `internal_threat_profile.md` for priority threats.
65+ * *Potential Action:* Ask user/Detection Engineering Lead/SOC Manager.
66+ * **Rationale:** Aligns with the "Detect" function of NIST CSF 2.0 and provides context for how detections are created and prioritized.
1267
13−### Runbooks (`./run_books/`)
68+**Phase 3: Governance, Policies & Procedures**
69+* **Objective:** Codify key organizational processes relevant to security operations and governance. (Aligned with NIST CSF 2.0 "Govern" function).
70+* **Tasks:**
71+ 1. **Create `governance_overview.md`**:
72+ * Describe the overall cybersecurity governance structure.
73+ * Outline the risk management approach and appetite.
74+ * Reference key policies (linking to where they might exist if not directly in `.clinerules`).
75+ * *Potential Action:* Ask user/CISO Office/Compliance Manager.
76+ * **Rationale:** Directly addresses the "Govern" function of NIST CSF 2.0.
77+ 2. **Create `incident_severity_matrix.md`**:
78+ * Define criteria for Low, Medium, High, Critical incidents.
79+ * *Potential Action:* Ask user/SOC Manager for the existing matrix or definitions.
80+ 2. **Create `escalation_paths.md`**:
81+ * Document who to notify for specific incident types (Ransomware, PII exposure, etc.).
82+ * *Potential Action:* Ask user/IR Lead/SOC Manager for escalation procedures.
83+ 3. **Create `reporting_templates.md`**:
84+ * Provide standard formats/sections for common reports (Daily Summary, Post-Incident).
85+ * *Potential Action:* Ask user/SOC Manager for existing templates.
86+ 4. **Create `approved_remediations.md`**:
87+ * List pre-approved actions for common low-severity findings.
88+ * *Potential Action:* Ask user/Security Engineering/SOC Manager for this list.
89+ 5. **Create `key_contacts.md`**:
90+ * List relevant teams/individuals (Network Ops, Identity, Legal).
91+ * *Potential Action:* Ask user/SOC Manager for contact points.
92+ 6. **Create `vulnerability_management_process.md`**:
93+ * Describe the tools used for vulnerability scanning (e.g., SCC, Tenable).
94+ * Outline scanning frequency and scope.
95+ * Explain the prioritization process (linking to `incident_severity_matrix.md`).
96+ * Describe standard remediation workflows and timelines.
97+ * *Potential Action:* Ask user/Vulnerability Management Team/Security Engineering.
98+ * **Rationale:** Incorporates insights from the CISA Vulnerability Response Playbook.
99+ 7. **Create `communication_plan_templates.md`**:
100+ * Provide templates/guidelines for internal and external communications during different incident stages/types.
101+ * Reference `escalation_paths.md` and `key_contacts.md`.
102+ * *Potential Action:* Ask user/IR Lead/Corporate Communications.
103+ * **Rationale:** Addresses communication needs highlighted in both NIST SP 800-61r3 and CISA playbooks.
14104
15−* **Purpose:** These files contain documented, step-by-step procedures or workflows for specific security operations tasks (e.g., triaging alerts, investigating IOCs, hunting for threats, responding to phishing).
16−* **Content:** They often include objectives, scope, required inputs, specific MCP tools to use, workflow steps (sometimes visualized with diagrams like Mermaid), and expected outcomes.
17−* **Usage by LLM Agent:** Serves as a primary plan for executing common security workflows, ensuring adherence to established procedures, guiding tool selection and sequencing, and promoting consistency.
18−* **IRP vs. Runbook Distinction:** While all files here serve as procedural guides, we differentiate between:
19− * **Incident Response Plans (IRPs):** Located in the `./run_books/irps/` subdirectory, these outline the *end-to-end strategy* for handling major incident types (e.g., malware, phishing) following the full PICERL lifecycle. They orchestrate multiple steps and often call other runbooks. Use these as the starting point for major incident types.
20− * **Runbooks:** Located directly within `./run_books/` or in `./run_books/common_steps/`, these provide detailed, *tactical steps* for specific tasks (e.g., enriching an IOC, triaging an alert, isolating an endpoint) or reusable procedures. They are often components within a larger IRP.
105+**Phase 4: Threat Intelligence & Context**
106+* **Objective:** Document organization-specific threat context and known benign activity.
107+* **Tasks:**
108+ 1. **Create `internal_threat_profile.md`**:
109+ * List high-concern threat actors, campaigns, or TTPs specific to the organization.
110+ * *Potential Action:* Ask user/CTI Team for this profile.
111+ 2. **Create `allowlists.md`**:
112+ * List known-good IPs, domains, hashes, process names specific to the environment.
113+ * *Potential Action:* Gather this from user/Security Engineering/existing documentation.
114+ 3. **Create `common_benign_alerts.md`**:
115+ * Describe alerts often triggered by benign activity (scans, admin scripts).
116+ * Outline typical handling procedures for these.
117+ * *Potential Action:* Gather this from user/SOC team experience.
21118
22−## Suggested Additional Context Files
119+**Phase 5: Recovery & Resilience**
120+* **Objective:** Document plans and procedures related to recovering from cybersecurity incidents. (Aligned with NIST CSF 2.0 "Recover" function).
121+* **Tasks:**
122+ 1. **Create `disaster_recovery_plan_summary.md`**:
123+ * Provide a high-level summary of DR/BCP plans relevant to SOC/IR activities.
124+ * Outline key recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical systems.
125+ * *Potential Action:* Ask user/Business Continuity Team/IT Operations for summaries.
126+ 2. **Create `backup_strategy_overview.md`**:
127+ * Summarize backup methods, locations, and frequency for critical systems (identified in Phase 1).
128+ * Outline general procedures for data restoration validation.
129+ * *Potential Action:* Ask user/Backup Administrators/IT Operations.
23130
24−The following types of files could further enhance an LLM Agent's effectiveness:
131+**Phase 6: Runbook Refinement & Optimization**
132+* **Objective:** Continuously improve the clarity, efficiency, and robustness of existing runbooks based on operational experience and evolving capabilities.
133+* **Tasks (Ongoing/Iterative):**
134+ 1. **Enhance Error Handling & Fallbacks:**
135+ * Review `enrich_ioc.md` and other runbooks to add specific guidance for handling tool errors (e.g., "If GTI lookup fails due to quota, note limitation and rely on SIEM context").
136+ * Suggest concrete alternative steps (e.g., "If primary SIEM search fails, try broader time window or alternative query structure").
137+ * Integrate checks against `tool_rate_limits.md` before calling tools with known limits.
138+ 2. **Improve Context Integration:**
139+ * Modify `triage_alerts.md` to suggest checking `common_benign_alerts.md`.
140+ * Update investigation runbooks to prompt referencing `network_map.md` or `asset_inventory_guidelines.md` when assessing internal entity criticality.
141+ 3. **Refine Common Steps:**
142+ * Analyze `enrich_ioc.md` - could it be split into `enrich_ip.md`, `enrich_domain.md`, etc., for more specific logic/fallbacks?
143+ * Review other common steps for potential modularization.
144+ 4. **Clarify Decision Logic:**
145+ * Refine assessment steps in runbooks like `triage_alerts.md` with specific examples (e.g., "If source IP is internal AND user is known admin AND target is domain controller AND time matches known patching window -> Likely BTP. Else -> Investigate further.").
146+ * Explicitly link decision criteria to `incident_severity_matrix.md` where applicable.
147+ 5. **Standardize Reporting Outputs:**
148+ * Define a standard "Key Findings" structure in `reporting_templates.md` to be used across triage, investigation, and hunt reports.
149+ 6. **Align with Personas:**
150+ * Review runbooks like `deep_dive_ioc_analysis.md` or `advanced_threat_hunting.md` and add "*(Tier 2+/Tier 3 Recommended)*" annotations to particularly complex steps or tool usage.
151+ 7. **Incorporate Visualizations:**
152+ * Update `case_event_timeline_and_process_analysis.md` to explicitly require a Mermaid process tree diagram in the report.
153+ * Encourage adding simple relationship diagrams (e.g., `graph LR; Host-->IP; IP-->Domain;`) in investigation reports.
154+ 8. **Address Tool Limitations:**
155+ * Ensure `find_relevant_soar_case.md` clearly documents the `list_cases` entity search limitation and suggests specific workarounds (manual search, SIEM correlation).
156+ * **Rationale:** Ensures runbooks remain effective, reflect real-world conditions, incorporate lessons learned (like tool errors), and leverage the full context available within the `.clinerules` directory.
25157
26−### 1. Environment & Infrastructure Context
158+**Next Steps:**
27159
28−* **`network_map.md`**: Describes key network segments (e.g., DMZ, production servers, user subnets), their IP ranges, and primary functions. Helps in understanding the context of network events and potential lateral movement.
29−* **`asset_inventory_guidelines.md`**: Outlines naming conventions for hosts/servers, common OS types, and potentially maps critical assets to their roles or owners. Helps contextualize alerts involving specific hosts.
30−* **`critical_applications.md`**: Lists key business applications, their associated servers/IPs, and expected communication patterns. Useful for identifying anomalous behavior related to core services.
31−* **`cloud_architecture.md`**: Provides an overview of the cloud environment structure (e.g., GCP project organization, key services like GKE, Cloud SQL), relevant for cloud-focused investigations (using SCC, etc.).
160+This plan outlines the creation of the suggested files. We can tackle these phases and tasks sequentially or prioritize based on which information would provide the most immediate value.
32161
33−### 2. Tool Configuration & Usage
162+Would you like to start working on creating one of these files, perhaps beginning with Phase 1? Or would you like to adjust this plan? Please let me know how you'd like to proceed and toggle to ACT MODE when you're ready for me to start creating the files.
34163
35−* **`tool_configurations.md`**: Details specific configurations crucial for tool usage, like:
36− * Important Chronicle Reference List names (e.g., `IP_Blocklist`, `Domain_Allowlist`) and their purpose.
37− * Key SOAR playbook names/IDs and what triggers them.
38− * Default timeframes or limits preferred for certain searches.
39−* **`mcp_tool_best_practices.md`**: Offers tips or preferred syntax for using specific MCP tools effectively (e.g., optimizing `search_security_events` queries, interpreting specific GTI fields).
40−* **`tool_rate_limits.md`**: Explicitly lists known rate limits or quotas for tools (like the Chronicle UDM query limit mentioned for a SOAR action) to help manage usage.
164+**For inspiration:**
41165
42−### 3. Organizational Policies & Procedures
166+Here are some references and projects that might be helpful when looking for inspiration:
43167
44−* **`incident_severity_matrix.md`**: Defines how incident severity (Low, Medium, High, Critical) is determined based on impact and threat type. Aids in prioritization.
45−* **`escalation_paths.md`**: Outlines who to notify or escalate to under specific circumstances (e.g., confirmed ransomware, PII exposure).
46−* **`reporting_templates.md`**: Provides standard formats or key sections required for different types of reports (e.g., daily SOC summary, post-incident report).
47−* **`approved_remediations.md`**: Lists standard, pre-approved containment or remediation actions for common, lower-severity findings.
48−* **`key_contacts.md`**: Lists relevant teams or individuals for specific issues (e.g., Network Ops, Identity Team, Legal).
49−
50−### 4. Threat Intelligence & Context
51−
52−* **`internal_threat_profile.md`**: Details specific threat actors, campaigns, or TTPs that are of high concern to *this specific organization*.
53−* **`allowlists.md`**: Lists organization-specific known-good IPs, domains, file hashes, or process names that should generally be ignored unless context suggests otherwise.
54−* **`common_benign_alerts.md`**: Describes alerts often triggered by known benign activity (e.g., vulnerability scans, specific admin scripts) and how to typically handle them.
55−
56−Having these additional context files would allow the LLM Agent to perform more nuanced analysis, make better-informed decisions, adhere more closely to organizational standards, and require less clarification during complex tasks.
168+ 1. Incident Response Recommendations and Considerations for Cybersecurity Risk Management
169+ * A CSF 2.0 Community Profile. NIST Special Publication 800.
170+ * URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf
171+ 1. Cybersecurity Incident & Vulnerability Response Playbooks
172+ * Operational Procedures for Planning and Conducting Cybersecurity Incident and Vulnerability Response Activities in FCEB Information Systems
173+ * URL: https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
174+ 1. The NIST Cybersecurity Framework (CSF) 2.0
175+ * URL: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
176+ 1. Cybersecurity Log Management Planning Guide
177+ * NIST Special Publication NIST SP 800-92r1 (Initial Public Draft)
178+ * URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-92r1.ipd.pdf
179+ 1. SOCFortress Playbooks
180+ * This repository contains incident response playbooks and workflows organized according to NIST-800.61 r2 standards. Each playbook is broken down into 6 sections and includes PDF versions for auditors and customers. It's designed specifically for SOC analysts.
181+ * GitHub URL: https://github.com/socfortress/Playbooks
182+ * [Incident Response Plan for Malware](https://github.com/socfortress/Playbooks/blob/main/IRP-Malware/README.md)
183+ * [Incident Response Plan for Compromised Account](https://github.com/socfortress/Playbooks/blob/main/IRP-AccountCompromised/README.md)
184+ * [Incident Reponse Plan for Phishing](https://github.com/socfortress/Playbooks/blob/main/IRP-Phishing/README.md)
185+ * [Incident Reponse Plan for Ransomware](https://github.com/socfortress/Playbooks/blob/main/IRP-Ransom/README.md)
186+ 1. Open Source SOC Documentation (OSSOCDOCS)
187+ * This comprehensive project provides a complete library of SOC documentation including SOPs, policies, processes, and best practices. It follows a structured pyramid approach with detailed runbooks that offer step-by-step instructions for specific security operations like investigating malicious URLs or responding to specific alerts.
188+ * GitHub URL: https://github.com/madirish/ossocdocs
189+ 1. Microsoft Student SOC Toolkit
190+ * This toolkit provides resources to prepare students for SOC work, including structured learning modules, hands-on experience, and certification pathways. It contains implementation guidance, a comprehensive training course, and simulated security incidents to build practical knowledge in incident response and threat detection.
191+ * GitHub URL: https://github.com/microsoft/SOC
192+ 1. Awesome SOC Collection
193+ * This is a collection of documentation sources and field best practices for building and running a SOC. It includes strategies for structuring SOCs, communication practices, performance metrics, and advanced SOC functionalities like threat hunting and red teaming.
194+ * GitHub URL: https://github.com/cyb3rxp/awesome-soc
195+ 1. Security Operations Center Topic on GitHub
196+ * The GitHub "security-operations-center" topic page lists numerous projects related to SOC operations, including Python modules for SOC enhancement, security maturity tracking matrices, and automation tools that integrate platforms like Wazuh, Shuffle, and TheHive.
197+ * GitHub URL: https://github.com/topics/security-operations-center
57198
