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
Security Rules currently apply globally, and prebuilt Elastic rules cannot be modified to use index patterns with specific namespaces. This makes it difficult to manage rules in a multi-tenant environment, as duplicating and manually updating them whenever Elastic pushes an update is tedious. The lack of space awareness in security rules means that prebuilt Elastic rules do not respect Kibana spaces, making them unsuitable for MSSP environments. There is no native way to customize prebuilt rules to use tenant-specific index patterns, which leads to operational overhead and the risk of outdated or inconsistent rule configurations. Additionally, users restricted to a specific space should only see alerts related to that space, but the inability to dynamically restrict index patterns (e.g., logs-* vs. logs-customerA-*) creates a serious security risk, potentially exposing alerts from one tenant to another. Furthermore, there is no built-in mechanism to automate the update of duplicated rules while maintaining tenant-specific index patterns, requiring manual intervention and increasing the likelihood of human error.
To address these challenges, security rules should be made space-aware so that prebuilt rules automatically inherit Kibana space restrictions, ensuring that rule execution and alerts are confined to their respective spaces. Additionally, prebuilt rules should support dynamic index patterns, allowing variables like logs-{{namespace}}-* instead of hardcoded logs-*, ensuring each tenant sees only its own logs. A efficient rule update mechanism should also be introduced for MSSPs, enabling bulk updates of prebuilt rules. Implementing an API or UI-driven feature to track prebuilt rule updates and selectively apply changes would significantly improve rule management and security.
Describe a specific use case for the feature:
For an MSSP, this limitation is a critical issue because users should only have access to alerts and rules relevant to their assigned space. A human error in a multi-tenant deployment with multiple customers in different spaces could lead to serious security breaches, potentially exposing alerts from one customer (e.g., spaceB) to another customer (e.g., spaceA). By making security rules space-aware and allowing dynamic index pattern customization, MSSPs can ensure proper data segmentation, reduce operational overhead, and maintain security and compliance.
The text was updated successfully, but these errors were encountered:
Describe the feature:
Security Rules currently apply globally, and prebuilt Elastic rules cannot be modified to use index patterns with specific namespaces. This makes it difficult to manage rules in a multi-tenant environment, as duplicating and manually updating them whenever Elastic pushes an update is tedious. The lack of space awareness in security rules means that prebuilt Elastic rules do not respect Kibana spaces, making them unsuitable for MSSP environments. There is no native way to customize prebuilt rules to use tenant-specific index patterns, which leads to operational overhead and the risk of outdated or inconsistent rule configurations. Additionally, users restricted to a specific space should only see alerts related to that space, but the inability to dynamically restrict index patterns (e.g., logs-* vs. logs-customerA-*) creates a serious security risk, potentially exposing alerts from one tenant to another. Furthermore, there is no built-in mechanism to automate the update of duplicated rules while maintaining tenant-specific index patterns, requiring manual intervention and increasing the likelihood of human error.
To address these challenges, security rules should be made space-aware so that prebuilt rules automatically inherit Kibana space restrictions, ensuring that rule execution and alerts are confined to their respective spaces. Additionally, prebuilt rules should support dynamic index patterns, allowing variables like logs-{{namespace}}-* instead of hardcoded logs-*, ensuring each tenant sees only its own logs. A efficient rule update mechanism should also be introduced for MSSPs, enabling bulk updates of prebuilt rules. Implementing an API or UI-driven feature to track prebuilt rule updates and selectively apply changes would significantly improve rule management and security.
Describe a specific use case for the feature:
For an MSSP, this limitation is a critical issue because users should only have access to alerts and rules relevant to their assigned space. A human error in a multi-tenant deployment with multiple customers in different spaces could lead to serious security breaches, potentially exposing alerts from one customer (e.g., spaceB) to another customer (e.g., spaceA). By making security rules space-aware and allowing dynamic index pattern customization, MSSPs can ensure proper data segmentation, reduce operational overhead, and maintain security and compliance.
The text was updated successfully, but these errors were encountered: