Logging Sensitive Information - PII

---

What is is?

Logging sensitive data refers to the unintended or inappropriate recording of confidential or personal information in application or system logs. Sensitive data, including Personally Identifiable Information (PII), includes details that can uniquely identify an individual or compromise security if exposed. While not an exhaustive list, examples of sensitive data include:

• Full Name (First Name, Last Name)
• Social Security Number (SSN)
• Driver's License Number
• Passport Number
• Email Address
• Home Address
• Date of Birth
• Phone Number
• Taxpayer Identification Number
• Financial Account Numbers (e.g., Bank Account or Credit Card Numbers)

While logging is essential for monitoring and debugging applications, including sensitive data can pose significant security risks. Unauthorized individuals may access logs, leading to data loss and potential compliance violations.

What Can Go Wrong?

When sensitive data is logged, it introduces substantial risks that can compromise individual privacy and organizational security. Often designed for troubleshooting and monitoring, logs may inadvertently expose confidential information to unauthorized personnel, third-party tools, or even malicious actors. These issues can lead to data loss, potential regulatory non-compliance, and operational risks that undermine trust and reputation. If not properly sanitized, sensitive data in logs may persist in backups or archives, making it even more challenging to mitigate exposure over time.

Some of the most common issues that can arise from logging sensitive data include:

Name	Discription	Example
Unauthorized Access	Sensitive data in logs that can be accessed by unauthorized personnel, leading to potential loss.	A log containing usernames and passwords is accessible to all system administrators.
Regulatory Non-complicance	Logging PII without appropriate protections may violate regulatory requirements or industry guidance and standards.	Logging PII without protection may violate GDPR, CCPA, or ISO/IEC 27001 regulations
Identity Theft	Attackers can exploit exposed sensitive data to impersonate individuals.	Social Security Numbers are logged during user registration and stored in plain text.
Targeted Attacks	Logs containing system architecture details can help attackers craft more effective attacks.	Stack traces logged in production reveal sensitive API endpoints and keys.
Persistent Exposure	Sensitive information in backups or archives remains vulnerable even after logs are deleted.	Archived logs from six months ago contain unencrypted customer addresses and payment details.

Organizations can help protect confidential information, ensure compliance, and maintain trust by not logging sensitive data. This proactive approach is key to minimizing exposure and reducing potential security vulnerabilities.

What Are The Impacts?

Logging sensitive data can introduce significant security and operational risks that organizations must mitigate. Exposure to sensitive information through logs can have far-reaching consequences, from financial losses to damage to customer trust.

The following are risks that could be introduced:

1. Data Loss: Unauthorized access to logs containing sensitive data can lead to identity theft, financial loss, and reputational harm.
2. Regulatory Non-compliance: Logging sensitive data may run afoul of regulatory requirements or industry guidance and standards, leading to potential fines and other consequences.
3. Loss of Trust: Exposing sensitive information through logs can erode customer confidence and harm your organization's reputation.
4. Revealing System Vulnerabilities: Detailed logs can reveal vulnerabilities in your system architecture, providing attackers with insights to launch targeted attacks.
5. Increased Attack Surface: Improper logging practices can give attackers access to valuable data, increasing the likelihood of exploitation across your network.

What Are The Defense Strategies?

To address this issue, many organizations may start by creating a list of items that should not be logged and then attempt to avoid logging them. While this approach seems reasonable at first glance, it is more difficult than it seems. Maintaining an exhaustive list can be challenging, and it’s nearly impossible to anticipate future combinations of non-sensitive data that may be classified as Personally Identifiable Information (PII), or that could be associated with existing or future standards and guidelines. Instead, a better approach is to only log the essential data necessary for troubleshooting. The following practices should be considered to protect against the exposure of sensitive data within logs.

Focus On An Allowlist Approach For Logging

Optimize your logging practices to reduce the risk of exposing sensitive information by recording only the essential data required for debugging or monitoring. Avoid unnecessary logging and adopt an allowlist approach by explicitly defining non-sensitive fields to include in logs. This proactive strategy is more secure and reliable than relying on a denylist, where sensitive data could inadvertently be logged. By carefully managing what is logged, you enhance security while maintaining the functionality of your monitoring and debugging processes.

// Bad Practice: Logging sensitive policy information
logger.info("The policy number has been updated to " + policyPeriod.getPolicyNumber())

// Good Practice: Logging without exposing sensitive data
logger.info("The policy has been successfully updated.")

// Bad Practice: Logging usernames
logger.info("A user account was created for " + username)

// Good Practice: Logging generic user creation message
logger.info("A user account was successfully created.")

To help you construct your allowlist for logging, refer to Guidewire Cloud Standard IS-SEC-1008: Personally Identifiable Information. For guidance on what log levels to use for various data types, refer to Guidewire Cloud Standard IS-IMP-1017: Logging.

Be Aware Of Hidden PII In Logged Objects

When logging objects, be cautious of hidden sensitive data that may be unintentionally included. For example, logging entire payloads, beans, or all objects in a bundle can expose sensitive data. Continually review and selectively log only the necessary non-sensitive information.

// Bad Practice: Logging an entire payload containing sensitive data
logger.info("Request payload: " + requestPayload.toString())

// Good Practice: Logging only non-sensitive fields from the payload
logger.info("Request received with operation: " + requestPayload.getOperation())

// Bad Practice: Logging all beans in a bundle, potentially exposing sensitive information
logger.info("All beans in bundle: " + bundle.getAllBeans())

// Good Practice: Logging only relevant non-sensitive bean details
logger.info("Processing bean with ID: " + bean.getId())

Proper Error Handling

Ensure that stack traces and detailed exception messages are not printed in production logs, as they can reveal sensitive system information. Instead, present user-friendly error messages that provide necessary feedback without exposing internal implementation details or compromising security.

// Bad Practice: Printing stack trace directly
try {
    response = new DocumentHandler().createOrUpdateDocumentEntity(body)
} catch (Exception ex) {
    ex.printStackTrace()
}

// Good Practice: Handling exceptions without exposing details
try {
    response = new DocumentHandler().createOrUpdateDocumentEntity(body)
} catch (Exception ex) {
    logger.error("An error occurred while updating the document.")
    // Optionally, log ex.getMessage() to a secure location if necessary
}

Anonymize and Aggregate Logged Data

Where possible, anonymize data in your logs by replacing sensitive identifiers with non-sensitive values. Additionally, consider logging aggregated trends instead of individual events to reduce the exposure of sensitive information while maintaining valuable insights.

Anonymization Replace sensitive data, such as email addresses or usernames, with non-sensitive identifiers:

// Bad Practice: Logging sensitive user details
logger.info("User johndoe@gmail.com logged in at 10:00 AM")

// Good Practice: Logging anonymized user details
logger.info("User ID: 12345 logged in at 10:00 AM")

Aggregation Log aggregated trends instead of detailed individual events to protect sensitive information while still capturing useful metrics:

'''java // Bad Practice: Logging every failed login attempt logger.info("Failed login for user johndoe@gmail.com at 9:01 AM") logger.info("Failed login for user janedoe@gmail.com at 9:02 AM")

// Good Practice: Logging aggregated login failure trends logger.info("Total login failures: 50 in the last hour")

'''

Validate Logging With Unit Tests

Develop unit tests to ensure that log entries comply with your logging policy and do not contain PII or other sensitive information. This proactive step helps maintain secure logging practices and adherence to compliance requirements. Enhance this validation by leveraging automated tools to identify potential leaks of sensitive data in logs. An example of a unit test script is included below.

@Test
public void testLogEntriesExcludeSensitiveInformation() {
    // Simulate a log message generation
    String logMessage = simulateLog("Policy details: PolicyNumber=123456789, InsuredSSN=987-65-4321")

    // Define a regular expression to detect sensitive insurance-related data
    // Example: SSNs and Policy Numbers
    String sensitiveDataPattern = "(\\b\\d{3}-\\d{2}-\\d{4}\\b|\\bPolicyNumber=\\d+\\b)"; 
    
    Pattern pattern = Pattern.compile(sensitiveDataPattern);
    Matcher matcher = pattern.matcher(logMessage);

    // Assert that no sensitive data is present in the log message
    assertFalse("Sensitive insurance-related data detected in logs!", matcher.find());
}

Regularly Review and Manage Your Logs

Consistently reviewing and updating your logs is essential to prevent unintended sensitive data exposure and to maintain compliance with security standards. Implement a robust log management policy and enforce retention and audit practices to safeguard sensitive information.

Retention Policies Define clear retention policies to ensure sensitive data in logs is not stored longer than necessary. Make sure your retention policies align with your organization’s standards and procedures.

Example Policy: Retain logs for 90 days unless explicitly required for compliance or operational needs.

Periodic Audits Perform regular audits to identify and remediate instances of accidental sensitive data recording. Automated tools can assist in scanning logs for patterns of sensitive information.

// Example: Using automated tools to detect sensitive patterns
// Pattern for Social Security Numbers
Pattern ssnPattern = Pattern.compile("\\d{3}-\\d{2}-\\d{4}")

Matcher matcher = ssnPattern.matcher(logEntry)
if (matcher.find()) {
    logger.warn("Sensitive data detected in logs: " + matcher.group())
}

By maintaining a structured review and management process, you can ensure logs remain compliant with your organization’s standards. Applying these strategies also maintains observability and troubleshooting capabilities while safeguarding sensitive data.

Additional Resources

To further strengthen your understanding and implementation, these resources provide additional guidance on secure coding practices.

• 8 Best Logging Practices to Keep Sensitive Data Out

• OWASP Cheat Sheet Series:

  • Logging Cheat Sheet
  • Error Handling

• Guidewire Cloud Standards

  • IS-IMP-1017: Logging
  • IS-SEC-1007: Payment Card Handling
  • IS-SEC-1008: Personally Identifiable Information
  • IS-SEC-1332: Hard-Coding of Security Credentials

• Guidewire Documentation

  • Application Logging
  • Intentional logging

These resources provide detailed guidance on secure coding practices specific to Guidewire environments.

---

By incorporating these tailored strategies and examples, you'll enhance the security of logging within Guidewire applications.