| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 9 | 1 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 2 | 2 | 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
- + Coding Conventions
Commands
neither file has anySection tags
0 shared · 2 only in A · 2 only in B- − setup
- − architecture
- + code-style
- + docs
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/coding_conventions.md
@@ +1 @@
1# Coding Conventions
2
3This document outlines the coding conventions for the Python code within the `google-mcp-security` project. The project aims to follow the [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html).
4
5Code formatting and import sorting are enforced automatically using `pyink` and `isort`, respectively. These tools are configured in the `pyproject.toml` files within each server subdirectory and are run via `pre-commit` hooks and `Makefile` targets.
6
7Key aspects enforced by the tools include:
8
9* **Line Length:** 88 characters (configured for both `pyink` and `isort`).
10* **Indentation:** 2 spaces is preferred for new work but 4 spaces is allowable for existing files. Do not mix within a file.
11* **Quotes:** Primarily double quotes (`"`), but `pyink` may adjust based on context.
12* **Imports:** Sorted according to the Google style profile in `isort`.
13* **Docstrings:** Use triple double quotes (`"""Docstring"""`). While not automatically formatted for content by `pyink`, follow Google style guide recommendations (e.g., for `Args:`, `Returns:`, `Raises:`).
14
15While the tools handle most formatting, developers should still adhere to other aspects of the Google style guide, such as naming conventions and general best practices.
16
@@ −1 +1 @@
1−# .clinerules Directory Overview
1+# Coding Conventions
22
3−This directory contains configuration files and documentation to provide context and guidance for LLM Agents operating within this security environment.
3+This document outlines the coding conventions for the Python code within the `google-mcp-security` project. The project aims to follow the [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html).
44
5−## Existing Components
5+Code formatting and import sorting are enforced automatically using `pyink` and `isort`, respectively. These tools are configured in the `pyproject.toml` files within each server subdirectory and are run via `pre-commit` hooks and `Makefile` targets.
66
7−### Personas (`./personas/`)
7+Key aspects enforced by the tools include:
88
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.
9+* **Line Length:** 88 characters (configured for both `pyink` and `isort`).
10+* **Indentation:** 2 spaces is preferred for new work but 4 spaces is allowable for existing files. Do not mix within a file.
11+* **Quotes:** Primarily double quotes (`"`), but `pyink` may adjust based on context.
12+* **Imports:** Sorted according to the Google style profile in `isort`.
13+* **Docstrings:** Use triple double quotes (`"""Docstring"""`). While not automatically formatted for content by `pyink`, follow Google style guide recommendations (e.g., for `Args:`, `Returns:`, `Raises:`).
1214
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−
24−The 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−
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.
15+While the tools handle most formatting, developers should still adhere to other aspects of the Google style guide, such as naming conventions and general best practices.
5716
