Event attributes: when (timestamp and interaction identifier)
Each log entry must include the following timestamp attributes: log date and time in international format; event date and time (which may differ from logging time, for example when the client is periodically or intermittently online); and interaction identifier to link all relevant events for a single user interaction such as a desktop application form submission, web page request, mobile app button click, or web service call. The interaction identifier allows the application to record that multiple events relate to the same interaction rather than forcing subsequent correlation techniques to reconstruct the separate events.
Event attributes: where (location and context)
Each log entry must include the following location attributes: application identifier (name and version); application address (cluster/hostname or server IPv4 or IPv6 address and port number, workstation identity, or local device identifier); service (name and protocol); geolocation; window/form/page (entry point URL and HTTP method for a web application, dialogue box name); code location (script name, module name).
Event attributes: what (event type, severity, description)
Each log entry must include the following descriptive attributes: type of event; severity of event with examples including {0=emergency, 1=alert, ..., 7=debug} or {fatal, error, warning, info, debug, trace}; security relevant event flag if the logs contain non-security event data too; description.
Optional event attributes to consider recording
Additionally consider recording: secondary time source (e.g. GPS) event date and time; action (original intended purpose of the request such as Log in, Refresh session ID, Log out, Update profile); object (affected component or other object such as user account, data resource, or file); result status (whether the action aimed at the object was successful, such as Success, Fail, Defer); reason (why the status occurred); HTTP Status Code (web applications only, such as 200 or 301); request HTTP headers or HTTP User Agent (web applications only); user type classification (public, authenticated user, CMS user, search engine, authorized penetration tester, uptime monitor); analytical confidence in the event detection (low, medium, high or numeric value); responses seen by the user and/or taken by the application (status code, custom text messages, session termination, administrator alerts); extended details (stack trace, system error messages, debug information, HTTP request body, HTTP response headers and body); internal classifications (responsibility, compliance references); external classifications (NIST SCAP, Mitre CAPEC).
Never log without legal sanction
Never log data unless it is legally sanctioned. Intercepting some communications, monitoring employees, and collecting some data without consent may all be illegal.
Data to exclude from logs: credentials and secrets
The following should never be recorded directly in logs but instead should be removed, masked, sanitized, hashed, or encrypted: application source code, session identification values (consider replacing with a hashed value if needed to track session specific events), access tokens, authentication passwords, database connection strings, encryption keys and other primary secrets.
Data to exclude from logs: sensitive personal and business data
The following should never be recorded directly in logs but instead should be removed, masked, sanitized, hashed, or encrypted: sensitive personal data and some forms of personally identifiable information (PII) such as health information, government identifiers, vulnerable people information; bank account or payment cardholder data; data of a higher security classification than the logging system is allowed to store; commercially-sensitive information; information it is illegal to collect in the relevant jurisdictions; information a user has opted out of collection, or not consented to such as use of do not track, or where consent to collect has expired.
Do not exclude events from known internal systems and trusted parties
Never exclude any events from known internal systems such as other internal systems, trusted third parties, search engine robots, uptime/process and other remote monitoring systems, penetration testers, or auditors. However, you may want to include a classification flag for each of these types in the recorded data to differentiate them.
Data to conditionally exclude or special handling: PII and connection details
The following data can exist and while useful for subsequent investigation, it may also need to be treated in a special manner before the event is recorded: file paths, database connection strings, internal network names and addresses, non-sensitive personal data (personal names, telephone numbers, email addresses). Consider using personal data de-identification techniques such as deletion, scrambling or pseudonymization of direct and indirect identifiers where the individual's identity is not required, or the risk is considered too great.
Customizable logging level default and restrictions
If it is desirable to alter the level of logging (type of events based on severity or threat level, amount of detail recorded), ensure that: the default level must provide sufficient detail for business needs; it should not be possible to completely deactivate application logging or logging of events that are necessary for compliance requirements; alterations to the level/extent of logging must be intrinsic to the application (undertaken automatically based on an approved algorithm) or follow change management processes (changes to configuration data, modification of source code); the logging level must be verified periodically.
Perform input validation on event data from other trust zones
When collecting event data, 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.
Log injection attack mitigation
Logs are a target of attacks and may be vulnerable to log injection. See OWASP Log Injection and CWE-117. Attacks on logs can affect confidentiality (unauthorized access to sensitive information), integrity (modification or deletion of records), availability (denial of service through disk exhaustion or log destruction), and accountability (preventing writes to cover tracks or causing wrong identity to be logged).
Include logging in security verification processes
Logging functionality and systems must be included in code review, application testing and security verification processes. This includes ensuring logging is implemented and enabled during application security, fuzz, penetration, and performance testing.
Test logging mechanisms for injection vulnerabilities
Test logging mechanisms to ensure they are not susceptible to injection attacks.
Test logging impact on system resources
Ensure logging cannot be used to deplete system resources, for example by filling up disk space or exceeding database transaction log space, leading to denial of service.
Test logging failure scenarios
Test the effect on the application of logging failures such as simulated database connectivity loss, lack of file system space, missing write permissions to the file system, and runtime errors in the logging module itself.
Test external connectivity loss impact on logging
Check the effect on the logging mechanisms when external network connectivity is lost, if external connectivity is usually required for logging.
Prevent denial of service through log-based user blocking
If log data is utilized in any action against users (such as blocking access or account lock-out based on log entries), ensure this cannot be used to cause denial of service of other users.
Centralized log collection network architecture
Create a centralized system for collecting logs from all business services. Applications are located in network segments for FRONTEND (UI), MIDDLEWARE (business application), and BACKEND (database). A separate logging service is located in different segments: BACKEND (log storage), MIDDLEWARE with log loader application and log collector application, FRONTEND (UI for viewing logs), and optional FRONTEND applications that receive cloud logs. Saving and downloading logs require opening different network accesses with processes performed by different applications.
Verify logging field definitions match standards
Ensure logging is working correctly and as specified by checking that events are being classified consistently and that field names, types and lengths are correctly defined to an agreed standard.
Check for unwanted side-effects when logging occurs
Ensure there are no unwanted side-effects when logging occurs.
Verify access controls on log data
Verify that access controls on the event log data are properly implemented and enforced.
Centralized security controls verification in microservices
To verify implementation of centralized, simple, vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls, analyze data collected on infrastructure services. This maps to OWASP ASVS V1 #1.1.6.
Application components business/security functions verification
To verify the definition and documentation of all application components in terms of the business or security functions they provide, analyze the short description parameter from: application-functionality services; infrastructure services. This maps to OWASP ASVS V1 #1.11.1.
Application-functionality service information to collect
For each application-functionality service that implements one or several business processes or functionality, collect: Service name (ID) - unique service identifier; Short description - describes the business process or functionality; Link to source code repository; Development Team - team responsible for development; API definition - link to interface description (e.g., OpenAPI specification) including security scheme definition (scopes, API keys needed per endpoint); The microservice architecture description - link to architecture diagram or description; Link to runbook.
Infrastructure service information to collect
For each infrastructure service (authentication, authorization, service registration and discovery, security monitoring, logging, API gateway), collect: Service name (ID) - unique service identifier; Short description - describes the functionality implemented; Link to source code repository (if applicable); Link to the service documentation - includes service API definition, operational guidance, and runbook.
Data storage information to collect
For each data storage in the microservices system, collect: Storage name (ID) - unique storage identifier; Software type - the software implementing the data storage (e.g., PostgreSQL, Redis, Apache Cassandra).
Message queue information to collect
For each message queue used for asynchronous microservices communication, collect: Message queue (ID) - unique message queue identifier; Software type - the software implementing the message queue (e.g., RabbitMQ, Apache Kafka).
Data asset information to collect
For each valuable data asset processed by system microservices, collect: Asset name (ID) - unique asset identifier; Protection level - classification such as PII or confidential; Additional info - clarifying information about the asset.
Service-to-storage relation information to collect
For each relation between a microservice and data storage, collect: Service name (ID) - the service identifier; Storage name (ID) - the storage identifier; Access type - specify if the access is "Read" or "Read/Write".
Sensitive data identification and classification
To verify that all sensitive data is identified and classified into protection levels, analyze data collected on: data assets and their description; asset-to-storage relations. This maps to OWASP ASVS V1 #1.8.1.
Service-to-service synchronous communication information to collect
For each synchronous communication between microservices, collect: Caller service name (ID); Called service name (ID); Protocol/framework used - e.g. HTTP (REST, SOAP), Apache Thrift, gRPC; Short description - describes the purpose of communication (query of information or state-changing business function) and data passed between services in terms of assets.
Service-to-service asynchronous communication information to collect
For each asynchronous communication between microservices, collect: Publisher service name (ID); Subscriber service name (ID); Message queue (ID) - the queue used for communication; Short description - describes the purpose of communication (receiving of information or commands for state-changing business function) and data passed between services in terms of assets.
Asset-to-storage relation information to collect
For each relation between a data asset and storage, collect: Asset name (ID); Storage name (ID); Storage type - specify the storage type for the asset, e.g. "golden source" or "cache".
API security scheme definition in OpenAPI specification
When defining the API definition for an application-functionality service, include security scheme definition in the OpenAPI specification to document scopes or API keys needed to invoke dedicated endpoints. Reference: https://swagger.io/docs/specification/authentication/
Graphical presentation of microservices architecture
Create a graphical presentation of application architecture showing building blocks and relations in the form of a services call graph or data flow diagram. Tools that can be used include Enterprise Architect or DOT language for graph description.
Data leakage analysis using collected architecture data
To analyze possible data leakage, analyze data collected on: data assets and their identification; service-to-storage relations; service-to-service synchronous communications; service-to-service asynchronous communications; asset-to-storage relations. This maps to OWASP ASVS V1 #1.1.2 and OWASP Top 10-2017 A3-Sensitive Data Exposure.
Trust boundaries, components, and data flows documentation
To verify documentation and justification of all application trust boundaries, components, and significant data flows, analyze data collected on: application-functionality services; infrastructure services; data storages; message queues; service-to-storage relations; service-to-service synchronous communications; service-to-service asynchronous communications. This maps to OWASP ASVS V1 #1.1.4.
Principle of least privilege enforcement in microservices
To define minimally needed microservice permissions and API key scopes, analyze data collected on: API definition from application-functionality services; service-to-storage relations; service-to-service synchronous communications; service-to-service asynchronous communications. This maps to OWASP ASVS V1 #1.4.3.
High-level architecture security analysis
To verify definition and security analysis of application high-level architecture and all connected remote services, analyze data collected on: application-functionality services; infrastructure services; data storages; message queues. This maps to OWASP ASVS V1 #1.1.5.
Limit container resource allocation
Limit container resource allocation to prevent resource exhaustion DoS attacks.
Use the --memory flag to limit the maximum memory available to a container. Use the --cpus flag to limit CPU resources available to a container. These constraints should be applied based on expected workload requirements.
Reference: Docker resource constraints documentation (memory and CPU).