application_security/logging

21 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Perform application activity logging with Winston, Bunyan, or Pino

Log application activities for debugging and security incident response. Use logging modules such as Winston, Bunyan, or Pino which support streaming, querying, and uncaught exception handling. Example configuration: configure transports for console and file output with different severity levels. Additional guidance available in OWASP Logging Cheat Sheet.

Audit logging for security events

Write audit logs before and after security related events. Consider logging token validation errors in order to detect attacks. Take care of log injection attacks by sanitizing log data beforehand.

HTTP logging requirements for security

Log all layer 7 HTTP calls with headers, caller metadata, and responses. Payloads may not be logged depending on where logging occurs (before TLS termination) and the sensitivity of data. Also log internal actions with actor and permission information, send trace IDs through the entire request lifecycle to track errors or malicious actions, and mask or remove sensitive data like SSNs, sensitive health information, and other PII from logs.

Monitoring & logging for serverless: use centralized logging, mask secrets and PII

Use centralized logging services such as CloudWatch, Azure Monitor, or GCP Logging for serverless functions. Mask secrets and personally identifiable information (PII) in logs.

Python logging redaction example for Lambda

Example Python code to redact sensitive fields in Lambda logging: iterate through event items and replace values with "***" for any key containing "password". This prevents secrets from appearing in logs.

Secret lifecycle logging for incident response

Incident response teams must have access to information about the lifecycle of a secret to aid in containment and remediation, including: who had access, when they used it, and when it was previously rotated.

Secret usage logging centralization

Logging for incident response should be to a single location accessible by incident response (IR) teams.

Standardized logging format for secrets

Use a standardized logging format and vocabulary such as the Logging Vocabulary Cheat Sheet to ensure that all necessary information about secret usage is logged.

Comprehensive auditing and monitoring across cloud providers

Implement comprehensive auditing and monitoring of secret access and usage across all cloud providers. Use centralized logging and monitoring solutions to aggregate and analyze logs from multiple providers.

SSC Logging and Monitoring requirements

All systems involved in the SSC, including VCS, build tools, delivery mechanisms, artifact repositories, and systems running applications should be configured to log authentication attempts, configuration changes, and other events that could identify anomalous behavior or support incident response. Logs must be sufficient in depth and breadth. A centralized SIEM, log aggregator, or similar tool is preferred for complexity. Log data must be actionable and monitored, not merely collected.

Payment processing logging and monitoring

Log all payment attempts including initiation, redirects, and callbacks with timestamps and IP addresses. Store raw request data for callbacks to aid investigation. Alert on unexpected order statuses without gateway confirmation, excessive callback attempts for the same order, and payment failures followed by repeated attempts with identical data.

Preparation Phase: HTTP Audit Logging Requirements

Standard Common Log Format (CLF) utilized by most web servers does not provide adequate data for proper incident response. The following HTTP data must be logged: Request URI (including QUERY_STRING); Full Request Headers (including Cookies); Full Request Body (POST payload); Full Response Headers; Full Response Body.

WebSocket logging events connection establishment termination

Log WebSocket events including connection establishment and termination with user identity, IP, and origin.

WebSocket logging authentication authorization handshake message processing

Log authentication and authorization events during handshake and message processing.

WebSocket logging security violations rate limiting validation failures

Log security violations including rate limiting triggers and message validation failures.

WebSocket logging do not log sensitive data tokens session IDs

Never log complete message contents, authentication tokens, session IDs, or personal information that could violate privacy regulations.

gRPC authorization failure logging

Log all authorization failures to detect potential attacks and compliance violations.

gRPC security event logging in Go

Implement structured security event logging with log.Printf("SECURITY_EVENT: %s | User: %s | IP: %s | Success: %t | Time: %s", event, userID, clientIP, success, time.Now().UTC().Format(time.RFC3339)). Log authentication attempts, authorization failures, and suspicious activities.

gRPC logging requirements

Include correlation IDs to track requests across distributed services. Ensure logs do not contain sensitive data like passwords or tokens.

Data protection: log all access

Record who accesses what data and when.

Legacy system challenge: limited logging

Older systems often do not provide the detailed security logs you need for modern threat detection and compliance requirements. You cannot manage what you cannot measure, and poor logging leaves blind spots in your security monitoring.

Give your agent this brain