mitigations.md

Mitigation Strategies Analysis for uber-go/zap

Mitigation Strategy: Data Masking/Redaction with Custom zapcore.Core Wrapper

• 1. Mitigation Strategy: Data Masking/Redaction with Custom zapcore.Core Wrapper

  • Description:

    1. Identify Sensitive Fields: Create a comprehensive list of all data fields potentially containing sensitive information.
    2. Develop Redaction Logic: Create Go functions to redact sensitive data using regular expressions, keyword lists, hashing, or truncation.
    3. Create Custom zapcore.Core: Implement a custom zapcore.Core that wraps the existing core.
       • Override the Write method.
       • Iterate through zapcore.Fields.
       • Apply redaction logic to sensitive fields.
       • Call the original zapcore.Core's Write method.
    4. Integrate the Wrapper: Replace the default zapcore.Core in your zap logger configuration.
    5. Testing: Thoroughly test redaction with various inputs.
    6. Regular Audits: Periodically review redaction rules and sensitive field lists.

  • Threats Mitigated:

    • Sensitive Data Exposure (PII, Credentials, Secrets): Severity: High
    • Log Injection (Indirectly): Severity: Medium

  • Impact:

    • Sensitive Data Exposure: Risk reduction: High
    • Log Injection: Risk reduction: Low

  • Currently Implemented:

    • Example: "Partially implemented. Basic redaction function for credit cards in utils/logmask.go, not integrated into zapcore.Core."

  • Missing Implementation:

    • Example: "Comprehensive zapcore.Core wrapper missing. Redaction needs expansion. Wrapper needs integration in config/logger.go. Testing and audits missing."

Mitigation Strategy: Log Level Management and Dynamic Adjustment (using zap's features)

• 2. Mitigation Strategy: Log Level Management and Dynamic Adjustment (using zap's features)

  • Description:

    1. Define Log Levels: Ensure developers understand zap log levels.
    2. Production Configuration: Configure production to use Info or Warn. Avoid Debug in production.
    3. Dynamic Adjustment Mechanism: Implement runtime log level changes using zap's atomic level:
       • Use zap.AtomicLevel to create a level that can be changed atomically.
       • Create an HTTP handler (or other mechanism) to modify the zap.AtomicLevel. This handler should be secured appropriately.
       • Use the zap.AtomicLevel when creating your logger.
    4. Monitoring and Alerting: Track the current log level and alert on unexpected changes.

  • Threats Mitigated:

    • Sensitive Data Exposure: Severity: High
    • Performance Issues (Excessive Logging): Severity: Medium
    • Disk Space Exhaustion: Severity: Medium

  • Impact:

    • Sensitive Data Exposure: Risk reduction: High
    • Performance Issues: Risk reduction: Medium
    • Disk Space Exhaustion: Risk reduction: Medium

  • Currently Implemented:

    • Example: "Different log levels for dev/prod via environment variable. No dynamic runtime adjustment."

  • Missing Implementation:

    • Example: "Implement dynamic adjustment using zap.AtomicLevel and a secure handler. Add monitoring."

Mitigation Strategy: Log Throttling (using a custom zapcore.Core)

• 3. Mitigation Strategy: Log Throttling (using a custom zapcore.Core)

  • Description:

    1. Create Custom zapcore.Core: Implement a custom zapcore.Core wrapper.
    2. Implement Throttling Logic:
       • Override the Write method.
       • Track log events based on criteria (e.g., IP, user ID, error type).
       • Drop or delay log entries if the rate exceeds a threshold.
       • Use a time window (sliding or fixed) to track the rate.
    3. Integrate the Wrapper: Replace the default zapcore.Core in your logger configuration.
    4. Monitoring and Alerting: Set up monitoring to track the number of log entries being throttled.

  • Threats Mitigated:

    • Denial of Service (DoS) via Log Flooding: Severity: High
    • Performance Issues (Excessive Logging): Severity: Medium
    • Disk Space Exhaustion: Severity: Medium

  • Impact:

    • Denial of Service (DoS): Risk reduction: High
    • Performance Issues: Risk reduction: Medium
    • Disk Space Exhaustion: Risk reduction: Medium

  • Currently Implemented:

    • Example: "No log throttling implemented."

  • Missing Implementation:

    • Example: "Implement throttling with a custom zapcore.Core. Define thresholds. Set up monitoring."

Mitigation Strategy: Avoid zap.Any with Untrusted Data (and use specific field types)

• 4. Mitigation Strategy: Avoid zap.Any with Untrusted Data (and use specific field types)

  • Description:

    1. Identify Untrusted Sources: Define what constitutes "untrusted data."
    2. Prefer Specific Field Types: Use zap.String, zap.Int, zap.Bool, zap.Error, etc., instead of zap.Any for untrusted data.
    3. Sanitize and Validate: Validate and sanitize untrusted data before logging, even with specific field types.
    4. Code Reviews: Check for zap.Any misuse during code reviews.
    5. Static Analysis: Consider static analysis tools to flag unsafe zap.Any usage.

  • Threats Mitigated:

    • Sensitive Data Exposure (Object Structures): Severity: Medium
    • Log Injection (Indirectly): Severity: Low

  • Impact:

    • Sensitive Data Exposure: Risk reduction: Medium
    • Log Injection: Risk reduction: Low

  • Currently Implemented:

    • Example: "Developers aware of risks, but no formal policy. Some zap.Any misuse might exist."

  • Missing Implementation:

    • Example: "Establish a policy prohibiting zap.Any with untrusted data. Enforce via reviews/static analysis. Refactor existing code."

Mitigation Strategy: Using zap.RegisterSink for custom secure sinks

• 5. Mitigation Strategy: Using zap.RegisterSink for custom secure sinks

  • Description:

    1. Identify Security Requirements: Determine the specific security needs for your log output (e.g., encryption, remote secure storage, integrity checks).
    2. Implement zap.Sink interface:
       • Create a custom struct that implements the zap.Sink interface. This interface requires implementing Write, Sync, and Close methods.
       • Within the Write method, implement the logic to handle log entries according to your security requirements. This might involve:
         • Encrypting the log data before writing.
         • Sending the log data to a remote secure location (e.g., via HTTPS).
         • Adding digital signatures or other integrity checks.
       • Implement Sync and Close methods to handle flushing and closing the sink properly.
    3. Register the Custom Sink:
       • Use zap.RegisterSink to register your custom sink with a unique URL scheme (e.g., "mysecuresink://").
    4. Configure Zap to Use the Sink:
       • In your zap configuration, specify the output path using the URL scheme you registered (e.g., "mysecuresink://logs").

  • Threats Mitigated:

    • Log Tampering/Deletion: Severity: High (if implemented with integrity checks and secure remote storage).
    • Unauthorized Access to Logs: Severity: High (if implemented with encryption and secure remote storage).
    • Data Loss: Severity: Medium (if implemented with reliable remote storage).

  • Impact:

    • Log Tampering/Deletion: Risk reduction: High
    • Unauthorized Access to Logs: Risk reduction: High
    • Data Loss: Risk reduction: Medium

  • Currently Implemented:

    • Example: "Currently using standard file output. No custom sinks are registered."

  • Missing Implementation:

    • Example: "Implement a custom zap.Sink to encrypt logs and send them to a secure remote logging service. Register the sink using zap.RegisterSink and update the logger configuration."

Mitigation Strategy: Using zap.SamplingConfig

• 6. Mitigation Strategy: Using zap.SamplingConfig

  • Description:

    1. Identify Log Levels for Sampling: Determine which log levels (e.g., Debug, Info) are generating excessive log volume and could benefit from sampling.
    2. Configure zap.SamplingConfig:
       • Create a zap.SamplingConfig struct.
       • Set Initial: The number of entries of a given level to log per second, without sampling.
       • Set Thereafter: The number of entries, after Initial, to allow through before sampling. For example, if Initial is 100, and Thereafter is 100, then the logger will emit the first 100 log entries of a given level each second, then emit 1 out of every 100 entries after that.
    3. Integrate Sampling into Logger Configuration:
       • Create a zap.Config struct.
       • Set the Sampling field of the zap.Config to your configured zap.SamplingConfig.
       • Build your logger using zap.New(zapcore.NewCore(encoder, writer, level), zap.AddCaller(), zap.AddStacktrace(zap.ErrorLevel), zap.WrapCore(func(core zapcore.Core) zapcore.Core { return zapcore.NewSamplerWithOptions(core, time.Second, samplingConfig.Initial, samplingConfig.Thereafter)})).

  • Threats Mitigated:

    • Performance Issues (Excessive Logging): Severity: Medium
    • Disk Space Exhaustion: Severity: Medium
    • Denial of Service (DoS) via Log Flooding (Partial): Severity: Medium (Sampling helps, but rate limiting and throttling are more effective).

  • Impact:

    • Performance Issues: Risk reduction: Medium
    • Disk Space Exhaustion: Risk reduction: Medium
    • Denial of Service (DoS): Risk reduction: Low (as a primary mitigation; it's a supporting measure).

  • Currently Implemented:

    • Example: "No sampling is currently configured."

  • Missing Implementation:

    • Example: "Configure zap.SamplingConfig for Info level logs to reduce volume. Integrate the sampling configuration into the logger setup." This refined list focuses solely on actions directly related to zap's API and configuration, providing a clear and actionable set of mitigations.