data protection & logging

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

Tenant context inclusion in log entries

Tenant context should be included in all log entries. This is essential for distinguishing between activities of different users or organizations in multi-tenant environments and is critical for audit trails and incident investigation.

Events that must always be logged

The following security events must always be logged: input validation failures (including discrete list validation), output validation failures, authentication successes and failures, authorization (access control) failures, session management failures (cookie modification, suspicious JWT validation failures), application errors and system events, application startups and shutdowns, use of higher-risk functionality (user administration, administrative privileges, default or shared accounts, access to sensitive data, encryption activities, system-level object creation/deletion, data import/export, file uploads, deserialization failures, network connections and TLS failures, unexpected HTTP verbs), legal opt-ins, and suspicious business logic activities (out-of-order actions, actions not making business sense, attempts to exceed limitations).

Log entry when, where, who, what attributes

Each log entry must record when, where, who, and what. When includes log date/time in international format, event date/time, and interaction identifier. Where includes application identifier (name and version), application address (hostname, IPv4/IPv6 and port), service name and protocol, geolocation, window/form/page (URL and HTTP method for web), and code location (script name, module name). Who includes source address (device identifier, user IP address, cell/RF tower ID, mobile telephone number) and user identity if authenticated (database primary key-value, username, license number). What includes event type, severity level (0=emergency through 7=debug, or fatal/error/warning/info/debug/trace), security relevant event flag, and description.

Log sanitization to prevent log injection attacks

Perform sanitization on all event data to prevent log injection attacks by removing or encoding carriage return (CR), line feed (LF), and delimiter characters. Additionally sanitize to remove sensitive data. Ensure input validation is performed on event data from other trust zones to ensure it is in the correct format, and consider alerting and not logging if there is an input validation failure.

Data that must be excluded or masked from logs

The following should not be recorded directly in logs but instead removed, masked, sanitized, hashed, or encrypted: application source code, session identification values (replace with hashed value if tracking is needed), access tokens, sensitive personal data and PII (health, government identifiers, vulnerable people), authentication passwords, database connection strings, encryption keys and other primary secrets, bank account or payment card holder data, data of higher security classification than the logging system is allowed to store, commercially-sensitive information, information illegal to collect in relevant jurisdictions, and information users have opted out of or not consented to.

Log storage on separate file system partition

When using the file system for logs, it is preferable to use a separate partition than those used by the operating system, other application files, and user-generated content. Apply strict permissions concerning which users can access the directories and the permissions of files within the directories. In web applications, logs should not be exposed in web-accessible locations, and if exposed, should have restricted access and be configured with a plain text MIME type (not HTML).

Database logging with separate restricted account

When using a database for logs, utilize a separate database account that is only used for writing log data and has very restrictive database, table, function, and command permissions.

Standard formats for log transmission

Use standard formats over secure protocols to record and send event data or log files to other systems, such as Common Log File System (CLFS) or Common Event Format (CEF) over syslog. Standard formats facilitate integration with centralized logging services.

Log handler implementation as standard module

Implement an application-wide log handler which can be called from other modules or components. If possible, create this log handler as a standard module that can be thoroughly tested, deployed in multiple applications, and added to a list of approved and recommended modules. Document the interface referencing organization-specific event classification and description syntax requirements.

Interaction identifier for linking related events

The interaction identifier is a method of linking all relevant events for a single user interaction (e.g., desktop application form submission, web page request, mobile app button click, web service call). The application should record the interaction identifier instead of losing the information and forcing subsequent correlation techniques to reconstruct separate events. This is particularly useful when a single request may have multiple input validation failures or when an output validation failure occurs much later than the input submission.

Customizable logging default requirements

If logging level customization is implemented, the default level must provide sufficient detail for business needs. It should not be possible to completely deactivate application logging or logging of events necessary for compliance requirements. Alterations to logging level/extent must be intrinsic to the application (undertaken automatically based on an approved algorithm) or follow change management processes (changes to configuration data or source code modification). The logging level must be verified periodically.

Input validation on event data from other trust zones

Perform input validation on event data from other trust zones to ensure it is in the correct format. Consider alerting and not logging if there is an input validation failure on event data.

Logging system failure handling

Ensure failures in the logging processes or systems do not prevent the application from otherwise running or allow information leakage. The application must continue functioning even if logging fails.

Time synchronization across servers and devices

Synchronize time across all servers and devices. This is not always possible where the application is running on a device under another party's control (e.g., individual's mobile phone, remote customer's workstation on another corporate network). In these cases, attempt to measure the time offset or record a confidence level in the event timestamp.

Log protection from tampering at rest

At rest, logs must be protected from tampering and unauthorized access by: building in tamper detection to know if a record has been modified or deleted, storing or copying log data to read-only media as soon as possible, recording and monitoring all access to logs (which may need prior approval), and restricting privileges to read log data with periodic review.

Log protection in transit with secure transmission

If log data is sent over untrusted networks (for collection, dispatch elsewhere, analysis, or reporting), use a secure transmission protocol. Consider whether the origin of the event data needs to be verified and perform due diligence checks (regulatory and security) before sending event data to third parties.

Logging verification in code review and testing

Logging functionality must be included in code review, application testing, and security verification processes: ensure logging works correctly as specified, check that events are classified consistently with correct field names/types/lengths to agreed standard, ensure logging is enabled during security/fuzz/penetration/performance testing, test mechanisms are not susceptible to injection attacks, check for no unwanted side-effects when logging occurs, test effect when external network connectivity is lost, ensure logging cannot deplete system resources (disk space, database transaction log space) leading to DoS, test effect of logging failures (simulated database connectivity loss, lack of file space, missing write permissions, runtime errors), verify access controls on log data, and if logs are used in action against users (blocking access, account lock-out), ensure this cannot cause DoS of other users.

Log retention period requirements

Log data, temporary debug logs, and backups/copies/extractions must not be destroyed before the duration of the required data retention period and must not be kept beyond this time. Legal, regulatory, and contractual obligations may impact retention periods.

High-risk functionality requiring logging

Use of higher-risk functionality must always be logged, including: user administration actions (addition or deletion of users, changes to privileges, assigning users to tokens, adding or deleting tokens), use of systems administrative privileges or access by application administrators including all actions by those users, use of default or shared accounts or break-glass accounts, access to sensitive data such as payment cardholder data, encryption activities (use or rotation of cryptographic keys), creation and deletion of system-level objects, data import and export including screen-based reports, submission and processing of user-generated content especially file uploads, deserialization failures, network connections and associated failures (backend TLS failures including certificate validation failures), and requests with unexpected HTTP verbs.

Suspicious business logic activities to log

Log suspicious business logic activities such as: attempts to perform a set of actions out of order or bypass flow control, actions which do not make sense in the business context, and attempts to exceed limitations for particular actions.

Give your agent this brain