Skip to content

Latest commit

 

History

History
225 lines (196 loc) · 31.6 KB

mitigations.md

File metadata and controls

225 lines (196 loc) · 31.6 KB

Mitigation Strategies Analysis for cortexproject/cortex

Mitigation Strategy: Strict Tenant ID Enforcement

  • Description:
    1. Code Review: Developers must meticulously review all code paths in Cortex components (ingesters, distributors, queriers, rulers, compactor, etc.) to ensure Tenant ID is checked at every stage of data processing and access.
    2. API Gateway Validation: Implement validation at the API Gateway level to ensure every incoming request includes a valid Tenant ID in headers or query parameters. Reject requests without a valid Tenant ID.
    3. Internal Function Calls: Verify that Tenant ID is passed as an argument to all internal functions and methods that handle data access or manipulation within Cortex components.
    4. Automated Testing: Create comprehensive automated tests, including unit, integration, and end-to-end tests, specifically designed to verify tenant isolation within Cortex. These tests should cover various scenarios like cross-tenant data access attempts, edge cases, and error handling within Cortex.
    5. Security Audits: Conduct regular security audits to manually review Cortex code and configurations for potential Tenant ID enforcement bypasses.
  • Threats Mitigated:
    • Cross-Tenant Data Access (High Severity): Unauthorized access by one tenant to another tenant's metrics or logs within Cortex.
    • Data Leakage (High Severity): Accidental exposure of sensitive data to unintended tenants through Cortex components.
    • Data Corruption (Medium Severity): One tenant potentially modifying or deleting another tenant's data due to lack of isolation within Cortex processing.
  • Impact: Significantly Reduces risk of cross-tenant data access, leakage, and corruption within Cortex.
  • Currently Implemented: Partially implemented. Tenant ID validation is implemented at the API Gateway and in distributors.
  • Missing Implementation: Tenant ID enforcement needs to be strengthened in queriers and rulers, especially in complex query processing logic within Cortex. Automated testing for tenant isolation needs to be expanded specifically for Cortex components.

Mitigation Strategy: Tenant-Based Rate Limiting and Quotas

  • Description:
    1. Configuration: Define configurable rate limits and resource quotas (storage, memory, CPU usage within Cortex components) per tenant. These configurations should be adjustable based on tenant tiers or SLAs within Cortex configuration.
    2. Ingestion Rate Limiting: Implement rate limiting in distributors and ingesters to control the number of metrics and logs ingested per tenant per time unit within Cortex. Use token bucket or leaky bucket algorithms for effective rate limiting within Cortex ingestion pipeline.
    3. Query Rate Limiting: Implement rate limiting in queriers to control the number of queries executed per tenant per time unit within Cortex.
    4. Resource Quota Enforcement: Integrate resource quota enforcement in all Cortex components that consume resources (ingesters, compactor, queriers). Monitor resource usage per tenant within Cortex and reject requests exceeding quotas.
    5. Monitoring and Alerting: Set up monitoring and alerting for rate limit and quota breaches within Cortex to identify potential abuse or misconfigurations.
  • Threats Mitigated:
    • Noisy Neighbor Problem (Medium Severity): One tenant consuming excessive resources within Cortex and impacting the performance of other tenants.
    • Denial of Service (DoS) - Resource Exhaustion (High Severity): A malicious or misconfigured tenant overwhelming Cortex with requests, leading to service unavailability for all tenants.
    • Resource Abuse (Medium Severity): Tenants exceeding fair usage of Cortex resources, potentially impacting overall system stability and cost.
  • Impact: Moderately Reduces the impact of noisy neighbors and significantly reduces the risk of resource exhaustion DoS attacks on Cortex.
  • Currently Implemented: Partially implemented. Ingestion rate limiting is configured in distributors. Basic query rate limiting is in place but needs refinement.
  • Missing Implementation: Resource quotas are not fully implemented across all Cortex components, especially for storage and memory usage per tenant within Cortex. Dynamic adjustment of limits based on tenant tiers is not yet automated within Cortex configuration.

Mitigation Strategy: Input Validation and Sanitization

  • Description:
    1. Schema Definition: Define strict schemas for incoming metrics and logs that Cortex ingests, specifying data types, allowed characters, and format constraints relevant to Cortex processing.
    2. Validation at Ingestion Points: Implement validation logic in Cortex ingesters and distributors to check incoming data against the defined schemas. Reject data that does not conform to the schema within Cortex ingestion pipeline.
    3. Sanitization: Sanitize labels and metric names within Cortex to remove or escape potentially harmful characters or code. Implement allow-lists for characters and patterns instead of deny-lists for better security within Cortex sanitization logic.
    4. Error Handling: Implement robust error handling for invalid data within Cortex ingestion pipeline. Log rejected data for auditing and debugging purposes, but avoid processing or storing it within Cortex.
    5. Regular Updates: Regularly review and update validation and sanitization rules within Cortex to address new attack vectors and evolving data formats relevant to Cortex.
  • Threats Mitigated:
    • Injection Attacks (High Severity): Prevention of code injection or command injection through malicious metric names, labels, or log data processed by Cortex.
    • Data Corruption (Medium Severity): Prevention of malformed data from corrupting the Cortex data store or causing processing errors within Cortex.
    • System Instability (Medium Severity): Protection against unexpected data formats that could lead to crashes or performance degradation in Cortex components.
  • Impact: Significantly Reduces the risk of injection attacks and data corruption within Cortex. Improves system stability by ensuring data integrity within Cortex processing.
  • Currently Implemented: Partially implemented. Basic validation for metric names and label formats is in place within Cortex. Sanitization is limited to removing some special characters within Cortex.
  • Missing Implementation: More comprehensive schema definition and enforcement within Cortex ingestion pipeline. Stronger sanitization rules, especially for log data ingested by Cortex. Automated testing for input validation and sanitization bypasses within Cortex.

Mitigation Strategy: Ingestion Rate Limiting and Traffic Shaping

  • Description:
    1. Rate Limiting Configuration: Configure rate limits on Cortex distributors and ingesters to control the overall ingestion rate. Use different rate limiting strategies (e.g., token bucket, leaky bucket) based on traffic patterns and requirements within Cortex configuration.
    2. Traffic Shaping: Implement traffic shaping techniques within Cortex ingestion pipeline to prioritize legitimate traffic and smooth out traffic spikes. This could involve queueing mechanisms or priority-based processing within Cortex.
    3. Dynamic Adjustment: Consider implementing dynamic rate limiting within Cortex that adjusts based on system load and available resources.
    4. Monitoring and Alerting: Monitor ingestion rates within Cortex and set up alerts for unusual spikes or patterns that might indicate a DoS attack or misconfiguration.
    5. Source Identification: Implement mechanisms within Cortex to identify the source of ingestion traffic to differentiate between legitimate sources and potential attackers.
  • Threats Mitigated:
    • Denial of Service (DoS) - Ingestion Overload (High Severity): Preventing attackers from overwhelming the Cortex ingestion pipeline with excessive data, leading to service unavailability.
    • Resource Exhaustion (Medium Severity): Protecting Cortex system resources (CPU, memory, network bandwidth) from being exhausted by excessive ingestion traffic.
    • System Instability (Medium Severity): Preventing ingestion spikes from causing instability or performance degradation in Cortex components.
  • Impact: Significantly Reduces the risk of ingestion overload DoS attacks and resource exhaustion on Cortex. Improves system stability under heavy load within Cortex.
  • Currently Implemented: Partially implemented. Basic rate limiting is configured in distributors. Traffic shaping is not yet implemented within Cortex.
  • Missing Implementation: Implementation of traffic shaping within Cortex ingestion pipeline. Dynamic rate limiting based on Cortex system load. More granular rate limiting policies based on source or tenant within Cortex.

Mitigation Strategy: Secure Ingestion Protocols

  • Description:
    1. HTTPS/TLS Enforcement: Enforce HTTPS/TLS for all Cortex ingestion endpoints exposed to external clients or untrusted networks. Disable HTTP endpoints if possible for Cortex ingestion.
    2. Certificate Management: Implement proper certificate management for TLS used by Cortex ingestion, including using valid certificates from trusted CAs, regular certificate rotation, and secure storage of private keys used by Cortex.
    3. Authentication and Authorization: For push-based ingestion into Cortex, implement strong authentication and authorization mechanisms to verify the identity of data sources. Use API keys, OAuth 2.0, or mutual TLS (mTLS) for authentication with Cortex ingestion endpoints.
    4. Protocol Hardening: Harden the TLS configuration used by Cortex ingestion by disabling weak ciphers and protocols. Follow security best practices for TLS configuration for Cortex ingestion.
    5. Regular Security Audits: Regularly audit the security configurations of Cortex ingestion endpoints and protocols to identify and address any vulnerabilities.
  • Threats Mitigated:
    • Man-in-the-Middle (MitM) Attacks (High Severity): Preventing attackers from intercepting and eavesdropping on data in transit during ingestion to Cortex.
    • Data Tampering (Medium Severity): Protecting data integrity by preventing attackers from modifying data during transit to Cortex.
    • Unauthorized Data Ingestion (Medium Severity): Preventing unauthorized sources from pushing data into Cortex.
  • Impact: Significantly Reduces the risk of MitM attacks and data tampering during ingestion to Cortex. Moderately reduces the risk of unauthorized data ingestion into Cortex.
  • Currently Implemented: Implemented. HTTPS/TLS is enforced for all external Cortex ingestion endpoints. Basic API key authentication is used.
  • Missing Implementation: mTLS for Cortex ingestion endpoints for stronger authentication. More robust certificate management and rotation processes for Cortex ingestion. Regular security audits of Cortex ingestion protocol configurations.

Mitigation Strategy: Query Validation and Sanitization (LogQL & PromQL)

  • Description:
    1. Query Parsing and Validation: Implement robust parsing and validation of LogQL and PromQL queries within Cortex queriers before execution. Use a secure query parser within Cortex that can detect and reject potentially malicious or invalid queries.
    2. Parameterized Queries: Where possible within Cortex query engine, use parameterized queries or prepared statements to separate query logic from user-provided input, reducing the risk of injection attacks.
    3. Sanitization of User Input: Sanitize user-provided inputs within Cortex queries (e.g., label values, regex patterns) to prevent injection of malicious code or unexpected characters.
    4. Query Allow-listing/Deny-listing: Consider implementing query allow-lists or deny-lists within Cortex to restrict the types of queries that can be executed. This can be useful for enforcing security policies or preventing resource-intensive queries within Cortex.
    5. Security Audits: Regularly audit Cortex query validation and sanitization logic to identify and address any potential bypasses or vulnerabilities.
  • Threats Mitigated:
    • Query Injection Attacks (High Severity): Preventing attackers from injecting malicious code or commands into LogQL/PromQL queries executed by Cortex to gain unauthorized access or manipulate data.
    • Information Disclosure (Medium Severity): Preventing attackers from crafting queries to extract sensitive information they are not authorized to access through Cortex query engine.
    • Denial of Service (DoS) - Query Overload (Medium Severity): Preventing attackers from crafting malicious queries that consume excessive resources and lead to Cortex query engine overload.
  • Impact: Significantly Reduces the risk of query injection attacks and information disclosure through Cortex query engine. Moderately reduces the risk of query overload DoS on Cortex.
  • Currently Implemented: Partially implemented. Basic query parsing and validation are in place within Cortex queriers. Limited sanitization of user input is performed within Cortex.
  • Missing Implementation: More comprehensive query validation and sanitization within Cortex, especially for complex LogQL and PromQL features. Parameterized queries are not fully utilized within Cortex query engine. Query allow-listing/deny-listing is not implemented within Cortex.

Mitigation Strategy: Query Complexity Limits and Resource Control

  • Description:
    1. Query Cost Estimation: Implement query cost estimation within Cortex queriers to predict the resource consumption of queries before execution. Base cost estimation on factors like query complexity, data volume, and time range within Cortex.
    2. Resource Limits: Define configurable limits within Cortex on query complexity and resource usage (e.g., maximum query execution time, memory usage, number of series accessed).
    3. Query Cancellation: Implement query cancellation mechanisms within Cortex queriers to terminate queries that exceed resource limits or take too long to execute.
    4. Priority Queues: Consider using priority queues within Cortex queriers to prioritize important queries and ensure they are executed even under heavy load.
    5. Monitoring and Alerting: Monitor query resource consumption within Cortex and set up alerts for queries exceeding limits or exhibiting unusual resource usage patterns.
  • Threats Mitigated:
    • Denial of Service (DoS) - Query Overload (High Severity): Preventing attackers from crafting overly complex or resource-intensive queries that can overload the Cortex query engine.
    • Resource Exhaustion (Medium Severity): Protecting Cortex system resources from being exhausted by poorly written or malicious queries.
    • Performance Degradation (Medium Severity): Preventing resource-intensive queries from impacting the performance of other queries and the overall Cortex system.
  • Impact: Significantly Reduces the risk of query overload DoS and resource exhaustion on Cortex. Improves system stability and performance under heavy query load within Cortex.
  • Currently Implemented: Partially implemented. Limits on query execution time are configured within Cortex. Basic query cancellation is in place within Cortex.
  • Missing Implementation: Query cost estimation is not fully implemented within Cortex. Limits on memory usage and number of series accessed are not enforced within Cortex. Priority queues are not implemented within Cortex queriers.

Mitigation Strategy: Query Result Sanitization and Filtering

  • Description:
    1. Data Masking/Redaction: Implement data masking or redaction techniques within Cortex queriers to remove or obscure sensitive data in query results based on user roles or permissions.
    2. Result Filtering: Implement filtering mechanisms within Cortex queriers to ensure users only see data they are authorized to access, even within their own tenant. This can be based on labels, metric names, or other data attributes within Cortex.
    3. Access Control Enforcement: Enforce access control policies at the query result level within Cortex queriers to prevent unauthorized data access. Integrate with RBAC or other authorization systems within Cortex.
    4. Audit Logging: Log all query executions and result access within Cortex for auditing and security monitoring purposes.
    5. Regular Review: Regularly review and update sanitization and filtering rules within Cortex to address new data sensitivity requirements and access control policies.
  • Threats Mitigated:
    • Information Disclosure (High Severity): Preventing unauthorized users from accessing sensitive data through Cortex query results.
    • Data Leakage (High Severity): Preventing accidental or intentional leakage of sensitive data through Cortex query results.
    • Privilege Escalation (Medium Severity): Preventing users from bypassing access controls by crafting queries to access data they are not authorized to see through Cortex query engine.
  • Impact: Significantly Reduces the risk of information disclosure and data leakage through Cortex query engine. Moderately reduces the risk of privilege escalation through query manipulation within Cortex.
  • Currently Implemented: Partially implemented. Basic result filtering based on tenant ID is in place within Cortex. Data masking/redaction is not implemented within Cortex.
  • Missing Implementation: Implementation of data masking/redaction for sensitive data within Cortex queriers. More granular result filtering based on user roles and permissions within Cortex. Integration with RBAC for result-level access control within Cortex.

Mitigation Strategy: Mutual TLS (mTLS) for Inter-Component Communication

  • Description:
    1. Certificate Generation and Distribution: Generate certificates for each Cortex component and securely distribute them for mTLS. Use a certificate authority (CA) for certificate signing and management for Cortex components.
    2. mTLS Configuration: Configure all Cortex components to use mTLS for inter-component communication. This involves configuring both server-side and client-side TLS with certificate verification within Cortex.
    3. Certificate Verification: Ensure that each Cortex component verifies the certificate presented by the connecting component to authenticate its identity during mTLS handshake.
    4. Certificate Rotation: Implement a process for regular certificate rotation for Cortex components to minimize the impact of certificate compromise.
    5. Monitoring and Alerting: Monitor mTLS connections between Cortex components and certificate validity. Set up alerts for certificate expiration or connection failures within Cortex.
  • Threats Mitigated:
    • Man-in-the-Middle (MitM) Attacks (High Severity): Preventing attackers from intercepting and eavesdropping on inter-component communication within Cortex.
    • Spoofing/Impersonation (High Severity): Preventing attackers from impersonating legitimate Cortex components to gain unauthorized access or disrupt operations within Cortex.
    • Data Tampering - Inter-Component (Medium Severity): Protecting data integrity by preventing attackers from modifying data during inter-component communication within Cortex.
  • Impact: Significantly Reduces the risk of MitM attacks and spoofing/impersonation within Cortex component communication. Moderately reduces the risk of data tampering during inter-component communication within Cortex.
  • Currently Implemented: Partially implemented. TLS is used for inter-component communication, but mutual TLS is not fully implemented across all Cortex components.
  • Missing Implementation: Full implementation of mTLS for all inter-component communication paths within Cortex. Robust certificate management and rotation processes for Cortex components. Monitoring and alerting for mTLS connections within Cortex.

Mitigation Strategy: Secure Service Discovery and Registration

  • Description:
    1. Authentication and Authorization: Implement authentication and authorization for Cortex service discovery and registration mechanisms. Ensure only legitimate Cortex components can register and discover services.
    2. Secure Communication Channels: Use secure communication channels (e.g., TLS) for Cortex service discovery and registration communication.
    3. Access Control for Service Registry: Implement access control for the service registry used by Cortex to restrict who can read and write service information.
    4. Mutual Authentication: Consider using mutual authentication for Cortex service discovery and registration to verify the identity of both the service provider and the service consumer.
    5. Monitoring and Alerting: Monitor Cortex service discovery and registration activity for suspicious patterns or unauthorized registrations. Set up alerts for anomalies.
  • Threats Mitigated:
    • Unauthorized Component Joining (Medium Severity): Preventing malicious or rogue components from joining the Cortex cluster and potentially disrupting operations or gaining unauthorized access to Cortex.
    • Service Discovery Spoofing (Medium Severity): Preventing attackers from spoofing service discovery responses to redirect traffic or intercept communication within Cortex.
    • Information Disclosure - Service Registry (Low Severity): Protecting sensitive information potentially stored in the service registry used by Cortex from unauthorized access.
  • Impact: Moderately Reduces the risk of unauthorized component joining and service discovery spoofing within Cortex. Minimally reduces the risk of information disclosure from the service registry used by Cortex.
  • Currently Implemented: Partially implemented. Basic authentication is used for Cortex service discovery. TLS is used for communication with the service registry.
  • Missing Implementation: More robust authentication and authorization for Cortex service discovery and registration. Mutual authentication is not implemented for Cortex service discovery. Access control for the service registry used by Cortex needs to be strengthened. Monitoring and alerting for Cortex service discovery activity needs to be enhanced.

Mitigation Strategy: Strong Authentication Mechanisms

  • Description:
    1. OAuth 2.0/OIDC Integration: Implement OAuth 2.0 or OpenID Connect (OIDC) for authentication of users and applications accessing Cortex APIs and UIs. Integrate with an identity provider (IdP) for Cortex authentication.
    2. Multi-Factor Authentication (MFA): Enforce multi-factor authentication (MFA) for administrative access and sensitive operations within Cortex.
    3. API Key Management: If using API keys for Cortex access, implement secure API key generation, storage, rotation, and revocation mechanisms within Cortex.
    4. Session Management: Implement secure session management practices for Cortex UIs and APIs, including session timeouts, secure session cookies, and protection against session hijacking.
  • Threats Mitigated:
    • Unauthorized Access (High Severity): Preventing unauthorized users or applications from accessing Cortex APIs and UIs.
    • Credential Theft/Compromise (High Severity): Reducing the risk of credential theft or compromise for Cortex access through strong authentication mechanisms like MFA and robust API key management.
    • Brute-Force Attacks (Medium Severity): Mitigating brute-force attacks against Cortex login credentials through strong API key management and account lockout mechanisms (if applicable).
  • Impact: Significantly Reduces the risk of unauthorized access and credential theft/compromise for Cortex. Moderately reduces the risk of brute-force attacks against Cortex authentication.
  • Currently Implemented: Partially implemented. Basic API key authentication is used for Cortex. OAuth 2.0/OIDC integration is planned but not yet implemented for Cortex. MFA is not enforced for Cortex access.
  • Missing Implementation: Full OAuth 2.0/OIDC integration for Cortex. Enforcement of MFA for administrative access to Cortex. Robust API key management system for Cortex.

Mitigation Strategy: Role-Based Access Control (RBAC)

  • Description:
    1. Role Definition: Define granular roles with specific permissions for different actions within Cortex (e.g., read-only access, query execution, configuration management, tenant administration).
    2. Role Assignment: Assign users and applications to Cortex roles based on the principle of least privilege. Grant only the necessary permissions for their tasks within Cortex.
    3. Policy Enforcement: Implement RBAC policy enforcement in all Cortex components that handle access control decisions.
    4. Centralized Policy Management: Use a centralized policy management system to manage Cortex RBAC policies and role assignments.
    5. Regular Review and Audit: Regularly review and audit Cortex RBAC policies and role assignments to ensure they are correctly configured and up-to-date.
  • Threats Mitigated:
    • Unauthorized Access (High Severity): Preventing users from accessing Cortex resources or performing actions they are not authorized to within Cortex.
    • Privilege Escalation (Medium Severity): Preventing users from gaining elevated privileges beyond their assigned Cortex roles.
    • Data Breach - Internal Threat (Medium Severity): Limiting the potential damage from insider threats within Cortex by restricting access based on roles.
  • Impact: Significantly Reduces the risk of unauthorized access and privilege escalation within Cortex. Moderately reduces the risk of data breaches from internal threats within Cortex.
  • Currently Implemented: Partially implemented. Basic RBAC is in place for tenant administration within Cortex. More granular roles and permissions are needed for other Cortex functionalities.
  • Missing Implementation: Granular RBAC for query execution, configuration management, and other Cortex operations. Centralized policy management system for Cortex RBAC. Regular audits of Cortex RBAC policies and role assignments are not consistently performed.

Mitigation Strategy: Audit Logging and Security Monitoring

  • Description:
    1. Comprehensive Audit Logging: Enable comprehensive audit logging for all security-relevant events within Cortex, including authentication attempts, authorization decisions, access to sensitive resources, configuration changes, and security policy modifications.
    2. Centralized Log Management: Centralize Cortex audit logs in a secure and reliable log management system (SIEM).
    3. Real-time Monitoring: Implement real-time security monitoring of Cortex audit logs to detect suspicious activity and security incidents within Cortex.
    4. Alerting and Notifications: Set up alerts and notifications for critical security events within Cortex, such as failed login attempts, unauthorized access attempts, privilege escalation attempts, and security policy violations.
    5. Log Retention and Analysis: Define log retention policies for Cortex audit logs and implement log analysis capabilities to investigate security incidents and identify trends within Cortex.
  • Threats Mitigated:
    • Security Incident Detection (High Severity): Improving the ability to detect security incidents and breaches within Cortex in a timely manner.
    • Incident Response (Medium Severity): Providing valuable information for incident response and forensic analysis related to Cortex security events.
    • Compliance and Accountability (Medium Severity): Meeting compliance requirements for audit logging and accountability for Cortex operations.
  • Impact: Significantly Improves security incident detection capabilities within Cortex. Moderately improves incident response and compliance posture for Cortex.
  • Currently Implemented: Partially implemented. Basic audit logging is enabled for authentication events within Cortex. Centralized log management is in place, but needs better integration with Cortex audit logs.
  • Missing Implementation: More comprehensive audit logging for all security-relevant events within Cortex. Real-time security monitoring and alerting for Cortex audit logs. Log analysis capabilities need to be enhanced for Cortex audit logs.

Mitigation Strategy: Secure Configuration Management

  • Description:
    1. Configuration as Code: Manage Cortex configurations as code using version control systems.
    2. Configuration Validation: Implement configuration validation tools to automatically check Cortex configurations for security misconfigurations and compliance with security best practices specific to Cortex.
    3. Immutable Infrastructure: Consider using immutable infrastructure principles for Cortex deployment to minimize configuration drift and ensure consistent security configurations.
    4. Secret Management: Use dedicated secret management solutions (e.g., HashiCorp Vault, Kubernetes Secrets) to securely store and manage sensitive Cortex configuration data (secrets, API keys, certificates).
    5. Regular Configuration Audits: Regularly audit Cortex configurations to identify and remediate any security misconfigurations.
  • Threats Mitigated:
    • Misconfiguration Exploitation (High Severity): Preventing attackers from exploiting security misconfigurations in Cortex components.
    • Configuration Drift (Medium Severity): Maintaining consistent security configurations for Cortex and preventing configuration drift that could introduce vulnerabilities.
    • Secret Exposure (High Severity): Protecting sensitive Cortex configuration data (secrets) from unauthorized access or exposure.
  • Impact: Significantly Reduces the risk of misconfiguration exploitation and secret exposure in Cortex. Moderately reduces the risk of configuration drift in Cortex.
  • Currently Implemented: Partially implemented. Configuration is managed as code using Git for Cortex. Basic configuration validation is in place for Cortex. Kubernetes Secrets are used for some secrets in Cortex.
  • Missing Implementation: More comprehensive configuration validation tools for Cortex. Immutable infrastructure principles are not fully adopted for Cortex deployment. Dedicated secret management solution (e.g., HashiCorp Vault) is not fully integrated with Cortex. Regular configuration audits are not consistently performed for Cortex.