Comparison

A · Cline rules · repulsivityy/elevate_2025 B · Cline rules · repulsivityy/elevate_2025

What each file covers, counted
Dimension	Only in A	Only in B	Overlap
Sections	7	9	0%
Commands	0	0	—
Section tags	2	2	0%

What each file covers

Sections

0 shared · 7 only in A · 9 only in B

− Reporting Templates & Guidelines
− General Report Metadata Requirements
− Common Report Types (Placeholders - To be defined)
− Daily SOC Summary
− Post-Incident Report
− Threat Hunt Summary Report
− Vulnerability Triage Report
+ .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

Commands

neither file has any

Section tags

0 shared · 2 only in A · 2 only in B

− types
− security
+ setup
+ architecture

Line diff

+43 added−18 removed14 unchanged24.6% identical

repulsivityy/elevate_2025 · .clinerules/reporting_templates.md

@@ −1 @@

1# Reporting Templates & Guidelines

3This file outlines standard formats and required elements for common reports generated during security operations.

5## General Report Metadata Requirements

7* **Runbook Reference:** All reports generated via runbook execution **must** clearly state which runbook was used at the beginning of the report.

8 * *Example:* `**Runbook Used:** Alert Investigation Summary Report Runbook`

9* **Timestamp:** Include a generation timestamp in a consistent format (e.g., YYYY-MM-DD HH:MM Timezone).

10* **Case ID:** Reference the relevant SOAR Case ID(s).

11* **Workflow Diagram:** Include a Mermaid sequence diagram from the executed runbook, showing the actual MCP Servers and Tools used.

13## Common Report Types (Placeholders - To be defined)

15### Daily SOC Summary

17* *(Define required sections, e.g., Key Metrics, Notable Alerts, Ongoing Incidents, Shift Handover Notes)*

19### Post-Incident Report

21* *(Define required sections, e.g., Executive Summary, Incident Timeline, Root Cause Analysis, Impact Assessment, Actions Taken, Lessons Learned, Recommendations)*

23### Threat Hunt Summary Report

25* *(Define required sections, e.g., Hunt Hypothesis, Scope, Timeframe, Queries Used, Findings (Positive/Negative), Enrichment Details, Recommendations/Escalation)*

27### Vulnerability Triage Report

29* *(Define required sections, e.g., Vulnerability Details (CVE), Affected Assets, GTI/SIEM Context, Remediation Steps, Prioritization)*

31*(Add other relevant report templates as needed)*

repulsivityy/elevate_2025 · .clinerules/readme.md

@@ +1 @@

1# .clinerules Directory Overview

3This directory contains configuration files and documentation to provide context and guidance for LLM Agents operating within this security environment.

5## Existing Components

7### Personas (`./personas/`)

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.

13### Runbooks (`./run_books/`)

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.

22## Suggested Additional Context Files

24The following types of files could further enhance an LLM Agent's effectiveness:

26### 1. Environment & Infrastructure Context

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.).

33### 2. Tool Configuration & Usage

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.

42### 3. Organizational Policies & Procedures

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).

50### 4. Threat Intelligence & Context

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.

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.

@@ −1 +1 @@

1−# Reporting Templates & Guidelines

1+# .clinerules Directory Overview

3−This file outlines standard formats and required elements for common reports generated during security operations.

3+This directory contains configuration files and documentation to provide context and guidance for LLM Agents operating within this security environment.

5−## General Report Metadata Requirements

5+## Existing Components

7−* **Runbook Reference:** All reports generated via runbook execution **must** clearly state which runbook was used at the beginning of the report.

8− * *Example:* `**Runbook Used:** Alert Investigation Summary Report Runbook`

9−* **Timestamp:** Include a generation timestamp in a consistent format (e.g., YYYY-MM-DD HH:MM Timezone).

10−* **Case ID:** Reference the relevant SOAR Case ID(s).

11−* **Workflow Diagram:** Include a Mermaid sequence diagram from the executed runbook, showing the actual MCP Servers and Tools used.

7+### Personas (`./personas/`)

128

13−## Common Report Types (Placeholders - To be defined)

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.

1412

15−### Daily SOC Summary

13+### Runbooks (`./run_books/`)

1614

17−* *(Define required sections, e.g., Key Metrics, Notable Alerts, Ongoing Incidents, Shift Handover Notes)*

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.

1821

19−### Post-Incident Report

22+## Suggested Additional Context Files

2023

21−* *(Define required sections, e.g., Executive Summary, Incident Timeline, Root Cause Analysis, Impact Assessment, Actions Taken, Lessons Learned, Recommendations)*

24+The following types of files could further enhance an LLM Agent's effectiveness:

2225

23−### Threat Hunt Summary Report

26+### 1. Environment & Infrastructure Context

2427

25−* *(Define required sections, e.g., Hunt Hypothesis, Scope, Timeframe, Queries Used, Findings (Positive/Negative), Enrichment Details, Recommendations/Escalation)*

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.).

2632

27−### Vulnerability Triage Report

33+### 2. Tool Configuration & Usage

2834

29−* *(Define required sections, e.g., Vulnerability Details (CVE), Affected Assets, GTI/SIEM Context, Remediation Steps, Prioritization)*

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.

3041

31−*(Add other relevant report templates as needed)*

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+

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.

3257