Cline rules

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