Why do you need security logging for products?

Every developer understands the critical role of comprehensive error logging. Having detailed logs is invaluable during an operational incident, enabling you to swiftly identify and address the source of issues. This principle holds true for security as well. Effective security logging is essential to answer key questions about an application’s security posture, such as:

  • What are the signs of potential security breaches?
  • How can we detect unauthorized access or activities?
  • What actions were taken during a security incident?
  • Are there any patterns or anomalies in the logs that indicate malicious behavior?

To put it in a more formal manner, developers and security professionals need the capability to investigate events through logs in order to:

  • Identify security events
  • Investigate security incidents
  • Monitor policy violations
  • Ensure compliance with laws and regulations
  • Audit the sequence of activities, events, or transactions within the application

This logging approach is essential for maintaining a secure and compliant application environment.

Setting ground rules

Security logging is an integral part of application logging and must not be treated separately. It should adhere to established best practices, such as:

  • Use ISO 8061 Format for Timestamps: Adopting the ISO 8061 format (e.g., 2024-08-02T17:06:54Z) for timestamps captures sufficient timing details in the log. This is crucial if logs are centralized on another platform.
  • Log in JSON (or XML) Format: Logging in JSON or XML format enables universal consumption of application logs. Using key-value pairs makes logs more search-friendly and accessible.
  • Use Standard Log Levels: Apply regular log levels, such as WARN, DEBUG, INFO, and ERROR, to security events, just as with other logs.

If some security logs are generated by other platforms, do not reinvent the wheel. For example, if you use AWS and CloudTrail provides a sufficient audit log, while AWS Config tracks all configuration changes for your workloads in production, there’s no need to duplicate these logs. Instead, leverage existing logging to build a complete logging solution.

Lastly, ensure that a data lifecycle management plan is in place, and that it includes security logs. This plan should define how long logs are retained, how they are archived, and how they are securely disposed of when no longer needed.

Here is an example of a structured security log:

{
  "timestamp": "2024-08-02T16:10:00Z",
  "event": "authorization",
  "status": "failure",
 "http_response" : "403 access denied",
  "user": {
    "username": "janedoe",
    "user_id": "67890"
  },
  "source_ip": "203.0.113.1",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15",
  "resource": {
    "type": "REST API",
    "domain" : "api.vizrt.com"
    "uri": "/delete-db",
  },
  "http_method": "POST",
  "failure_reason": "insufficient_permissions",
 }

What to log?

Authentication

Authentication logs can capture malicious attempts to access the application using stolen credentials, for example through password spraying. Authentication logs are valuable for incident investigations and provide insights into who accessed the application, when was the application accessed and from where (IP)

Successful authentication

Log successful authentication events to be able to answer the following questions:

  • who accessed the application
  • Which IP address did they access the application from?
  • When did the successful authentication occur?

Unsuccessful authentication

Failed authentication attempts provide valuable information to identify ongoing attempts to access the application using stolen or potentially expired credentials. Logging these attempts helps in detecting patterns of malicious activity and can serve as an early warning system for possible security breaches. By monitoring and analyzing these logs, you can take proactive measures to secure your application and protect user accounts.

MFA events

Successful and unsuccessful MFA (Multi-Factor Authentication) events should also be logged. This logging helps identify whether a user accessed the application, the type of MFA used, and other relevant details. Logging MFA events provides insight into authentication patterns and can help detect potential security issues, such as unauthorized access attempts or MFA bypass attempts.

Authorization logging

Logging authorization failures is important to detect attempts to access data that the user is not allowed to access. Authorization logs should contain the following information:

  • Source IP address
  • User indentifier
  • Timestamp
  • Endpoint being accessed (url, domain name)
  • IP address and hostname of the resource being accessed
  • Error messages, HTTP code responses

Authorization failures

Failed attempts to access protected resources, such as REST APIs, administrative interfaces, and protected database tables, could indicate a potential compromise. These events should be logged with relevant details.

Application security logs

Application security logs can help investigations to detect attepts to thwart the application logic and discover software vulnerabilities. The following examples of application security logs are good to have.

Parser exceptions

Parsing exceptions, such as XML and JSON parsing errors, can be valuable for detecting security-related events. These errors may indicate denial of service attempts or malicious efforts to interact with the application through deserialization or XML injection attacks.

Validation failures

Validation errors provide valuable information about ongoing attacks against applications. For instance, logging regex validation errors for input parameters in REST requests or web application fields can reveal attempts to exploit the application.

Database queries

Errors occurring during database queries can indicate SQL injection attacks or potentially lead to denial of service. Logging these issues aids development and operations teams in investigating ongoing attacks or operational problems.

Sensitive functionality and sensitive data access

Logging for access to sensitive functionality, such as admin interfaces, and sensitive data access like financial information serves as an important audit log valuable both for compliance and security purposes.

Access level modifications

Changes to a user’s privilege level must be logged. For example, altering user access from a standard user to an administrator is a critical event that needs to be recorded. Logging these changes is essential because attackers may create new users to achieve persistence within the application or elevate a user’s privileges to gain access to administrative interfaces. By tracking privilege changes, you can detect and respond to unauthorized attempts to modify user roles, ensuring the security and integrity of your application.

Sensitive data access

Access to areas of an application containing sensitive information, such as billing and invoice data, or personally identifiable information (PII), should be logged for audit purposes. Logging access to these areas is crucial for detecting insider threats and abuse of access privileges.