Adaptive authentication monitoring requirements
Implement monitoring and alerting in adaptive authentication systems for potentially suspicious activity, including how the user is notified.
OWASP Cheat Sheets · all subjects
logging and monitoring
32 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Authentication logging and monitoring requirements
Enable logging and monitoring of authentication functions to detect attacks and failures on a real-time basis. Ensure that all failures are logged and reviewed, all password failures are logged and reviewed, and all account lockouts are logged and reviewed.
Sensitive data event: sensitive_update
Log updates to sensitive data with event name 'sensitive_update:[userid,file|object]' at WARN level. All updates to sensitive data should be logged and reviewed periodically. Example: event 'sensitive_update:joebob1,/users/admin/some/important/path' logs modification to sensitive file.
Mean time to identify breach is approximately 200 days
According to the IBM Cost of a Data Breach Report 2025, the mean time to identify a breach continues to hover around 200 days. Consistent security event logging vocabulary enables organizations to monitor applications and alert on anomalous behavior to improve time to identify and mitigate attacks.
Logging format with ISO 8601 timestamp and UTC offset
All security events should be logged in JSON format with a datetime field in ISO 8601 format WITH UTC offset (e.g., '2021-01-01T01:01:01-0700'). The logging format includes: datetime, appid, event, level, description, useragent, source_ip, host_ip, hostname, protocol, port, request_uri, request_method, region, and geo.
Encryption event: crypt_encrypt_fail
Log encryption failures with event name 'crypt_encrypt_fail[:userid]' at WARN level. Example: event 'crypt_encrypt_fail:joebob1' logs that user joebob1 was unable to perform encryption.
Excessive use event: excess_rate_limit_exceeded
Log rate limit violations with event name 'excess_rate_limit_exceeded[:userid,max]' at WARN level. Example: event 'excess_rate_limit_exceeded:app.foobarapi.prod,100000' logs that user app.foobarapi.prod exceeded max of 100,000 requests.
Malicious behavior event: malicious_excess_404
Log excessive 404 requests (force-browsing attempts) with event name 'malicious_excess404:[userid|IP,useragent]' at WARN level. Example: event 'malicious_excess404:123.456.789.101,M@l1c10us-Hax0rB0t0-v1' logs force-browsing behavior from IP address.
Malicious behavior event: malicious_extraneous
Log unexpected/unsupported input fields with event name 'malicious_extraneous:[userid|IP,inputname,useragent]' at CRITICAL level. Unsupported fields indicate input validation probing. Example: event 'malicious_extraneous:dr@evil.com,creditcardnum,Mozilla/5.0...' logs submission of unexpected creditcardnum field.
Malicious behavior event: malicious_attack_tool
Log detected attack tool usage with event name 'malicious_attack_tool:[userid|IP,toolname,useragent]' at CRITICAL level. Tools identified by signature or user agent string. Example: event 'malicious_attack_tool:127.0.0.1,nikto,Mozilla/5.00 (Nikto/2.1.6)...' logs Nikto tool detection.
Privilege event: privilege_permissions_changed
Log object permission changes with event name 'privilege_permissions_changed:[userid,file|object,fromlevel,tolevel]' at WARN level. Track changes to files/objects with access restrictions to uncover privilege escalation attempts. Example: event 'permissions_changed:joebob1,/users/admin/some/important/path,0511,0777' logs permission change from 0511 to 0777.
Sensitive data event: sensitive_create
Log creation of sensitive data with event name 'sensitive_create:[userid,file|object]' at WARN level. Log when new sensitive data is created or placed in sensitive directories/tables. Example: event 'sensitive_create:joebob1,/users/admin/some/important/path' logs creation in sensitive location.
Sensitive data event: sensitive_delete
Log deletion/archival of sensitive data with event name 'sensitive_delete:[userid,file|object]' at WARN level. All sensitive data deletions should be logged and reviewed. File should be marked for deletion (not immediately deleted) and archive maintained per legal/privacy requirements. Example: event 'sensitive_delete:joebob1,/users/admin/some/important/path' logs file marked for deletion.
Sequence error event: sequence_fail
Log business logic attacks (sequence errors) with event name 'sequence_fail:[userid]' at CRITICAL level. When a user reaches application parts out of expected sequence, log as indication of intentional abuse. Example: event 'sequence_fail:joebob1' logs user bypassing normal application flow.
System event: sys_startup
Log system startup with event name 'sys_startup:[userid]' at WARN level. Log user that initiated startup, even for serverless/container systems. Example: event 'sys_startup:joebob1' logs that user joebob1 spawned new instance.
System event: sys_restart
Log system restart with event name 'sys_restart:[userid]' at WARN level. Log user that initiated restart, even for serverless/container systems. Example: event 'sys_restart:joebob1' logs that user joebob1 initiated restart.
System event: sys_crash
Log system crashes with event name 'sys_crash[:reason]' at WARN level. Log unstable conditions causing crashes, especially if triggered by attack. Example: event 'sys_crash:outofmemory' logs crash due to out of memory error.
System event: sys_monitor_disabled
Log monitoring agent disablement with event name 'sys_monitor_disabled:[userid,monitor]' at WARN level. Systems may contain file integrity, resource, logging, or virus monitoring agents; log when disabled and by whom. Example: event 'sys_monitor_disabled:joebob1,crowdstrike' logs CrowdStrike disabled by user.
System event: sys_monitor_enabled
Log monitoring agent enablement with event name 'sys_monitor_enabled:[userid,monitor]' at WARN level. Log when monitoring agents are re-enabled after being stopped and by whom. Example: event 'sys_monitor_enabled:joebob1,crowdstrike' logs CrowdStrike re-enabled by user.
User management event: user_created
Log user creation with event name 'user_created:[userid,newuserid,attributes]' at WARN level. Log specifics of creation, especially if new users can be created with administration privileges. Example: event 'user_created:joebob1,user1,admin:create,update,delete' logs creation with specified privilege attributes.
User management event: user_updated
Log user updates with event name 'user_updated:[userid,onuserid,attributes]' at WARN level. Log specifics of user updates, especially if users can be updated with administration privileges. Example: event 'user_updated:joebob1,user1,admin:create,update,delete' logs update with specified attributes.
User management event: user_archived
Log user archival with event name 'user_archived:[userid,onuserid]' at WARN level. Always archive rather than delete users except where required. Log specifics of archive event. Malicious users could exploit to deny service. Example: event 'user_archived:joebob1,user1' logs user1 archived by joebob1.
User management event: user_deleted
Log user deletion with event name 'user_deleted:[userid,onuserid]' at WARN level. Always archive rather than delete except where required. Log specifics of deletion. Malicious users could exploit to deny service. Example: event 'user_deleted:joebob1,user1' logs user1 deleted by joebob1.
Data privacy consideration for logging
All fields logged after event type should be considered optional. Organizations implementing this logging method should weigh value of fields being logged against responsibility as data steward. For example, logging user IP address may be useful for detection and response but may be considered personally identifiable information subject to regulation or deletion requests.
Never log private or secret information
Private or secret information, source code, keys, certificates, and other sensitive data should never be logged. Refer to OWASP Logging Cheat Sheet for comprehensive list of items that should be excluded from logging.
Logging libraries for implementing OWASP vocabulary
Several libraries support implementing OWASP logging vocabulary: Python (lucabello/owasp-logger), C#/.NET (byteguard-hq/byteguard-security-logger), and multi-language (Python/Java/Go/Node.js: thatsjet/security_event_logger).
Threat modeling for identifying security events
Use simple threat modeling approach to identify security events: (1) What could go wrong? (e.g., Orders: unauthorized ordering; Authentication: login as someone else; Authorization: viewing someone else's account), (2) What would happen if it did?, (3) Who might intend to do this? (intentional attacks, employee testing, incorrectly coded API).
First step to logging security events is good error handling
The goal of logging is to alert on specific security events. The first step is good error handling; if events are not trapped/caught in code, there is no event to log.
System event: sys_shutdown
Log system shutdown with event name 'sys_shutdown:[userid]' at WARN level. Log user that initiated shutdown, even for serverless/container systems. Example: event 'sys_shutdown:joebob1' logs that user joebob1 stopped instance.
Sensitive data event: sensitive_read
Log access to sensitive data with event name 'sensitive_read:[userid,file|object]' at WARN level. All data marked sensitive or in sensitive repositories should have access logged and reviewed periodically. Example: event 'sensitive_read:joebob1,/users/admin/some/important/path' logs read access to sensitive file.
Defense metrics and monitoring for credential stuffing
Each defense should generate volume metrics for use as a detective mechanism, including both detected and mitigated attack volume with filtering on fields such as IP address. Monitoring and reporting these metrics may identify defense failures or unidentified attacks and show impact of new or improved defenses. When multiple teams administer different defenses, coordination is needed during maintenance, deployment or modification.
Logging and monitoring in SSC
All SSC systems including VCS, build tools, delivery mechanisms, artifact repositories, and runtime systems must be configured to log authentication attempts, configuration changes, and other anomalous events. Logs must be monitored using centralized SIEM, log aggregator, or similar tool to ensure log data is actionable.