Skip to content

Latest commit

 

History

History
121 lines (92 loc) · 7.92 KB

mitigations.md

File metadata and controls

121 lines (92 loc) · 7.92 KB

Mitigation Strategies Analysis for serilog/serilog

Mitigation Strategy: 1. Data Masking/Redaction (Serilog-Centric)

  • Mitigation Strategy: Implement data masking and redaction within Serilog using IDestructuringPolicy or Destructure.ByMasking().

  • Description:

    1. Identify Sensitive Data: Create a list of sensitive data fields.
    2. Choose a Redaction Method:
      • Custom IDestructuringPolicy (Recommended): Create a class implementing IDestructuringPolicy. In the TryDestructure method:
        • Check the object type.
        • If sensitive, iterate through properties.
        • Redact sensitive properties (replace with "[REDACTED]", "****", a hash, etc.).
        • Return true if handled, false otherwise.
      • Destructure.ByMasking(): For simple cases, use Destructure.ByMasking() in Serilog's configuration. Specify properties to mask and the masking value.
    3. Integrate with Serilog:
      • IDestructuringPolicy: Register with Serilog: .Destructure.With<MyRedactionPolicy>().
      • Destructure.ByMasking(): Use directly in configuration: .Destructure.ByMasking(x => x.Password, "****").
    4. Testing: Thoroughly test redaction with unit tests, including negative tests.
    5. Regular Review: Periodically review sensitive data lists and redaction logic.

  • Threats Mitigated:

    • Sensitive Data Exposure in Logs (Severity: High): Prevents sensitive data from being written to logs.
    • Compliance Violations (Severity: High): Helps meet compliance requirements.

  • Impact:

    • Sensitive Data Exposure: Risk significantly reduced. Effectiveness depends on thoroughness.
    • Compliance Violations: Risk significantly reduced.

  • Currently Implemented:

    • Example: Partially implemented. Basic IDestructuringPolicy redacts "Password" and "ApiKey".
    • Example: Not implemented.

  • Missing Implementation:

    • Example: Current policy needs expansion to cover all sensitive data sources and complex objects. Lacks comprehensive unit tests.
    • Example: Need to implement IDestructuringPolicy in LoggingService and add unit tests.

Mitigation Strategy: 2. Selective Logging (Serilog Filters)

  • Mitigation Strategy: Use Serilog's filtering capabilities (.Filter.ByExcluding(), .Filter.ByIncluding()) to control which log events are written.

  • Description:

    1. Identify Log Events to Filter: Determine which log events are unnecessary or contain potentially sensitive information. Consider filtering by:
      • Source Context: Exclude logs from specific classes or modules (e.g., authentication modules).
      • Property Values: Exclude logs where a specific property has a certain value (e.g., exclude logs with a "Status" of "Debug").
      • Log Level: Exclude logs below a certain level (e.g., exclude Verbose and Debug in production).
    2. Implement Filters:
      • .Filter.ByExcluding(): Exclude events matching a predicate. Example: .Filter.ByExcluding(Matching.FromSource("AuthenticationModule")).
      • .Filter.ByIncluding(): Include only events matching a predicate.
    3. Combine Filters: Use multiple filters to create complex filtering logic.
    4. Test Filters: Verify that filters are working as expected. Create log events that should be included and excluded, and check the output.

  • Threats Mitigated:

    • Sensitive Data Exposure in Logs (Severity: High): Reduces the likelihood of logging sensitive data by filtering out unnecessary logs.
    • Log Volume and Storage Costs (Severity: Low): Reduces log volume.

  • Impact:

    • Sensitive Data Exposure: Risk reduced, but not eliminated. Complements data redaction.
    • Log Volume: Can significantly reduce volume.

  • Currently Implemented:

    • Example: Not implemented.
    • Example: Implemented.

  • Missing Implementation:

    • Example: Serilog filters are not currently used. Implement filters to exclude logs from sensitive modules and to control log levels in different environments.
      • Example: Need to add unit tests for filters.

Mitigation Strategy: 3. Structured Logging (Enforcement via Serilog)

  • Mitigation Strategy: Enforce structured logging through Serilog's configuration and usage, preventing direct string concatenation. This is less about a specific feature and more about how Serilog is used.

  • Description:

    1. Consistent Message Templates: Always use message templates and named properties: Log.Information("User {Username} did {Action}.", username, action);.
    2. Avoid String Concatenation: Never concatenate user input directly: Log.Information("User " + username + " did " + action);.
    3. Centralized Configuration (Best Practice with Serilog): Use a centralized configuration to enforce consistent logging practices across the application. This helps ensure that all developers are using Serilog in the same way.

  • Threats Mitigated:

    • Log Injection Attacks (Severity: High): Prevents log forging, log poisoning, and some DoS attacks.
    • Log Forging (Severity: High): Prevents fake log entries.
    • Log Poisoning (Severity: High): Prevents code injection into logs.

  • Impact:

    • Log Injection Attacks: Risk significantly reduced with consistent enforcement.
    • Log Forging/Poisoning: Risk virtually eliminated with correct usage.

  • Currently Implemented:

    • Example: Partially implemented. Developers are aware, but no strict enforcement.
    • Example: Not implemented.

  • Missing Implementation:

    • Example: Stricter code review guidelines are needed. While external tools can help, the core principle is how Serilog's API is used.
    • Example: Need to implement code review guidelines.

Mitigation Strategy: 4. Log Enrichment Control (Serilog Enrichers)

  • Mitigation Strategy: Carefully review and control Serilog enrichers to prevent them from adding sensitive data to log events.

  • Description:

    1. Review Existing Enrichers: Examine all configured enrichers (both built-in and custom).
    2. Identify Potential Risks: Determine if any enrichers are adding sensitive data (e.g., user IDs, IP addresses, request headers).
    3. Modify or Remove Enrichers:
      • If an enricher is adding sensitive data unnecessarily, remove it or modify it to exclude the sensitive information.
      • If an enricher must add potentially sensitive data, ensure that data redaction (Mitigation #1) is in place to handle it.
    4. LogContext Caution: Be extremely careful with LogContext. Avoid pushing sensitive data onto the context unless absolutely necessary and redaction is robust.
    5. Custom Enricher Review: Thoroughly review any custom enrichers to ensure they are not introducing security risks.

  • Threats Mitigated:

    • Sensitive Data Exposure in Logs (Severity: High): Prevents enrichers from inadvertently adding sensitive data.

  • Impact:

    • Sensitive Data Exposure: Risk reduced, depending on the specific enrichers used.

  • Currently Implemented:

    • Example: Not implemented. No specific review of enrichers has been performed.
    • Example: Implemented.

  • Missing Implementation:

    • Example: A comprehensive review of all configured enrichers is needed. Specific attention should be paid to LogContext usage.
    • Example: Need to add unit tests for enrichers.