You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/PULL_REQUEST_GUIDELINES/hunt_tuning_guidelines.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,4 +27,4 @@ These guidelines serve as a reminder set of considerations when tuning an existi
27
27
-[ ] Evidence of testing and valid query usage.
28
28
-[ ] Markdown Generated: Run `python -m hunting generate-markdown` with specific parameters to ensure a markdown version of the hunting TOML files is created.
29
29
-[ ] Index Refreshed: Run `python -m hunting refresh-index` to refresh indexes.
30
-
-[ ] Run Unit Tests: Run `pytest tests/test_hunt_data.py` to run unit tests.
30
+
-[ ] Run Unit Tests: Run `pytest tests/test_hunt_data.py` to run unit tests.
Copy file name to clipboardExpand all lines: .github/PULL_REQUEST_TEMPLATE.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,7 +36,7 @@ from your submission, but they are here to help bring them to your attention.
36
36
37
37
<!-- Delete any items that are not applicable to this PR. -->
38
38
39
-
-[ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated
39
+
-[ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `maintenance`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated
40
40
-[ ] Added the `meta:rapid-merge` label if planning to merge within 24 hours
41
41
-[ ] Secret and sensitive material has been managed correctly
42
42
-[ ] Automated testing was updated or added to match the most common scenarios
Copy file name to clipboardExpand all lines: docs/versioning.md
+136-1Lines changed: 136 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Supported Versions and Releases
1
+
# Rule Supported Versions and Releases
2
2
3
3
This document provides detailed information about the different versions that are supported and released for prebuilt detection rules.
4
4
@@ -24,3 +24,138 @@ The following version(s) are maintained along with the current version.
24
24
## End of Life Policy
25
25
26
26
Our policy is to support and provide public releases for `Current`, `Current-1`, `Current-2`, `Current-3` versions. We maintain and do not release `Current-4` and `Current-5` versions.
27
+
28
+
29
+
# Code Supported Versions and Releases
30
+
31
+
This outlines the versioning strategy and release process for the [detection-rules](https://github.com/elastic/detection-rules) repository, covering the core code, `kql` and `kibana` libraries, configuration files, and the `hunting` folder. The strategy follows semantic versioning to ensure clear communication of changes to users and compatibility with different Elastic Stack versions.
32
+
33
+
> [!IMPORTANT]
34
+
> This versioning process **excludes** the detection rules themselves. Detection rules are released separately and are not tied to the following process.
35
+
36
+
---
37
+
38
+
## Versioning Strategy
39
+
40
+
### Components Covered by Versioning:
41
+
-**Core Detection-Rules Code**: Handles logic for rule management, CLI, etc.
42
+
-**Libraries**:
43
+
-**`kql`**: Manages Kibana Query Language parsing and operations.
44
+
-**`kibana`**: Handles integrations and API interactions with Kibana.
45
+
-**Configuration Files**: Under the `etc/` folder that impact schema and DAC.
46
+
-**Hunting Logic**: The `hunting/` folder, which manages hunting rules.
47
+
48
+
49
+
### Semantic Versioning Approach:
50
+
We will use **Semantic Versioning** with the format `MAJOR.MINOR.PATCH`:
51
+
-**MAJOR version (`X.0.0`)**: For backward-incompatible changes.
52
+
-**MINOR version (`0.Y.0`)**: For backward-compatible new features.
53
+
-**PATCH version (`0.0.Z`)**: For backward-compatible bug fixes or small improvements.
54
+
55
+
> [!NOTE]
56
+
> The GitHub labels `patch`, `minor`, or `major` will be used in PRs to indicate the type of change being made.
57
+
58
+
---
59
+
60
+
## Versioning Guidelines
61
+
62
+
### Patch Version (`0.0.Z`):
63
+
Increment the patch version when making bug fixes, performance improvements, or small enhancements that do not break backward compatibility. Open a PR to ensure the proper `pyproject.toml` files and any other `version` related files are bumped.
64
+
65
+
<details><summary>Expand for Examples</summary>
66
+
<p>
67
+
68
+
**Examples**:
69
+
-**Kibana Library**:
70
+
- Minor fixes to API calls to ensure correct data retrieval.
71
+
- Updates to the `kibana` lib without adding new features.
72
+
-**KQL Library**:
73
+
- Small bug fixes in the query parsing logic.
74
+
- Optimizations that don't alter functionality.
75
+
-**Core Detection-Rules Code**:
76
+
- Fixes for CLI bugs or performance tweaks.
77
+
- Minor enhancements to rule management that don’t require users to change workflows.
78
+
-**Hunting Folder**:
79
+
- Bug fixes in hunting rules logic.
80
+
- Small performance tweaks for the hunting rule management.
81
+
-**Docs Folder**:
82
+
- Updates to documentation.
83
+
84
+
</p>
85
+
</details>
86
+
87
+
---
88
+
89
+
### Minor Version (`0.Y.0`):
90
+
Increment the minor version when adding backward-compatible new features, enhancements, or functionality.
91
+
92
+
<details><summary>Expand for Examples</summary>
93
+
<p>
94
+
95
+
**Examples**:
96
+
-**Kibana Library**:
97
+
- Adding a new API endpoint to interact with Elastic Kibana X.Y while maintaining backward compatibility with older versions.
98
+
-**KQL Library**:
99
+
- Adding new query parsing functionality that is backward-compatible with previous Elastic Stack versions.
100
+
-**Core Detection-Rules Code**:
101
+
- New CLI commands or functionality for managing detection rules.
102
+
- New optional fields in rule schemas that have minimum compatibility requirements. (e.g adding `alert_suppression` with `min_compat=8.14`).
103
+
-**Hunting Folder**:
104
+
- Adding new hunting rule management features that are optional and backward-compatible.
105
+
- Enhancements in generating hunting rule markdown or CLI features.
106
+
107
+
</p>
108
+
</details>
109
+
110
+
> [!NOTE]
111
+
> When bumping this version, the patch version should be reset to `0` and the major version should remain the same.
112
+
113
+
---
114
+
115
+
### Major Version (`X.0.0`):
116
+
Increment the major version when introducing backward-incompatible changes that require users to update workflows, Elastic Stack versions, or rule management strategies.
117
+
118
+
<details><summary>Expand for Examples</summary>
119
+
<p>
120
+
121
+
**Examples**:
122
+
-**Kibana Library**:
123
+
- Replacing or removing an existing API endpoint that forces users to upgrade to Elastic X.Y
124
+
-**KQL Library**:
125
+
- Structural changes to query parsing logic that break compatibility with previous Elastic Stack versions.
126
+
-**Core Detection-Rules Code**:
127
+
- Breaking changes to rule schema definitions or CLI workflows that require user updates.
128
+
- Forcing users to migrate to a newer Elastic Stack version due to changes in core code or schema compatibility.
129
+
-**Hunting Folder**:
130
+
- Major refactors of the hunting logic that break existing workflows.
131
+
- Changes to how hunting rules are defined or managed, requiring users to adjust configurations.
132
+
133
+
</p>
134
+
</details>
135
+
136
+
> [!NOTE]
137
+
> When bumping this version, the minor version and patch version should be reset to `0`.
138
+
139
+
---
140
+
141
+
## Tagging Process
142
+
143
+
Each release will be tagged using the following format:
-**Single Tag for Combined Releases**: If there are changes to the core detection-rules code or libraries (`kql`, `kibana`), they will be tagged together as a single release with the core detection-rules versioning.
146
+
-**Hunting Folder**: Changes to the hunting logic will be included in the combined release.
147
+
148
+
> [!CAUTION]
149
+
> When a version is bumped in a lib, we need to also bump the core `pyproject.toml` file *(e.g A version bump in `kql` will also require a similar version bump in the core detection-rules versioning)*.
150
+
---
151
+
152
+
## When to Trigger a GitHub Release
153
+
154
+
A draft release will be triggered in the following cases:
155
+
-**New Feature or Bug Fix**: Once a feature or bug fix is merged into `main`, a version bump is made according to the semantic versioning rules.
156
+
-**Version Bump**: After the version bump, a GitHub release will be created using **release-drafter** CI workflow to automate draft release generation.
157
+
158
+
As pull requests are merged, a draft release is kept up-to-date listing the changes, ready to publish quarterly.
159
+
160
+
> [!IMPORTANT]
161
+
> Proper PR labels need to be added for this to properly be labeled and added to the draft.
# AWS IAM Customer-Managed Policy Attachment for Privilege Escalation
2
+
3
+
---
4
+
5
+
## Metadata
6
+
7
+
-**Author:** Elastic
8
+
-**Description:** This hunting query identifies instances where customer-managed IAM policies are attached to existing roles, potentially indicating a privilege escalation attempt. By detecting unexpected actors attaching customer-managed policies with elevated permissions to roles, this query helps identify potential abuse or misuse within AWS. Adversaries may attach these policies to gain unauthorized permissions or enable lateral movement and persistence within the environment.
-**Source File:**[AWS IAM Customer-Managed Policy Attachment for Privilege Escalation](../queries/iam_customer_managed_policies_attached_to_existing_roles.toml)
actor_attaching_role_count =count(*) by aws.cloudtrail.user_identity.arn, attached_policy_name, target_role_name
28
+
```
29
+
30
+
## Notes
31
+
32
+
- Review the `target_account_id` field to verify the AWS account in which the role is being modified, especially if this account is outside of your organization’s typical accounts.
33
+
- Examine `aws.cloudtrail.request_parameters` for details on the role and attached policy. Customer-managed policies granting overly permissive access, such as `AdministratorAccess`, may signal unauthorized privilege escalation.
34
+
- Cross-reference `event.action` values where `AttachRolePolicy` appears to further investigate attached policies that could enable lateral movement or persistence.
35
+
- Evaluate `aws.cloudtrail.user_identity.arn` to confirm if the actor attaching the policy has legitimate permissions for this action. Anomalous or unauthorized actors may indicate privilege abuse.
36
+
- Look for patterns of multiple `AttachRolePolicy` actions across roles by the same user or entity. High frequency of these actions could suggest an attempt to establish persistent control across roles within your AWS environment.
0 commit comments