Application Security Logging
Last modified by Sebastian Klipper on 2024/09/12 18:36
This draft page describes the configuration of the relevant loggers to meet various security requirements.
Just as important as what you choose to log is what you intentionally avoid logging. Sensitive data such as private information, secret keys, source code, certificates, and similar items should never be included in logs. For a detailed list of what should be excluded from logging, refer to the OWASP Logging Cheat Sheet.
This draft page does not take into account the implications for privacy requirements, such as GDPR. The logging requirements and data protection requirements may need to be balanced in accordance with national and international laws and regulations. Like the privacy requirement of "data minimization". This principle requires that only the personal data necessary for the specific purpose is collected and processed.
Compliance with OWASP Application Logging Vocabulary Cheat Sheet
XWiki records all changes to wiki pages (that includes configuration when set in wiki pages) in the wiki in the event stream, which can be queried.
| Category | Event Type | Description | Level | ISO/IEC 27002 8.15 Logging | OWASP Application Security Verification Standard (ASVS) | Logger Configuration in | Example |
|---|---|---|---|---|---|---|---|
| Authentication [AUTHN] | authn_login_success[:userid] | All login events should be recorded including success. | INFO | successful system access attempts | Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations. (7.2.1) | <logger name="com.xpn.xwiki.user.impl.xwiki.XWikiAuthServiceImpl" level="info"/>What will be logged:
What will be logged:
| "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_login_success:joebob1",
"level": "INFO",
"description": "User joebob1 login successfully",
... |
| authn_login_successafterfail[:userid,retries] | The user successfully logged in after previously failing. | INFO | successful system access attempts | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_login_successafterfail:joebob1,2",
"level": "INFO",
"description": "User joebob1 login successfully",
... | ||
| authn_login_fail[:userid] | All login events should be recorded including failure. | WARN | rejected system access attempts alarms raised by the access control system | <logger name="?org.xwiki.security.authentication.internal.AuthenticationFailureLoggerListener?" level="xxx"/><logger name="com.xpn.xwiki.user.impl.xwiki.MyFormAuthenticator" level="info"/>What will be logged:
| "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_login_fail:joebob1",
"level": "WARN",
"description": "User joebob1 login failed",
... | ||
| authn_login_fail_max[:userid,maxlimit(int)] | All login events should be recorded including failure. | WARN | rejected system access attempts alarms raised by the access control system | <logger name="?org.xwiki.security.authentication.internal.AuthenticationFailureLoggerListener?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_login_fail_max:joebob1,3",
"level": "WARN",
"description": "User joebob1 reached the login fail limit of 3",
... | ||
| authn_login_lock[:userid,reason] | When the feature exists to lock an account after x retries or other condition, the lock should be logged with relevant data. | WARN | alarms raised by the access control system | <logger name="?org.xwiki.security.authentication.internal.CaptchaAuthenticationFailureStrategy?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_login_lock:joebob1,maxretries",
"level": "WARN",
"description": "User joebob1 login locked because maxretries exceeded",
... | ||
| authn_password_change[:userid] | Every password change should be logged, including the userid that it was for. | INFO | changes to system configuration | <logger name="?org.xwiki.security.authentication.internal.DefaultResetPasswordManager?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_password_change:joebob1",
"level": "INFO",
"description": "User joebob1 has successfully changed their password",
... | ||
| authn_password_change_fail[:userid] | An attempt to change a password that failed. May also trigger other events such as authn_login_lock. | INFO | changes to system configuration | <logger name="?org.xwiki.security.authentication.internal.DefaultResetPasswordManager?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_password_change_fail:joebob1",
"level": "INFO",
"description": "User joebob1 failed to changing their password",
... | ||
| authn_impossible_travel[:userid,region1,region2] | When a user is logged in from one city and suddenly appears in another, too far away to have traveled in a reasonable timeframe, this often indicates a potential account takeover. | CRITICAL | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_impossible_travel:joebob1,US-OR,CN-SH",
"level": "CRITICAL",
"description": "User joebob1 has accessed the application in two distant cities at the same time",
... | ||
| authn_token_created[:userid, entitlement(s)] | When a token is created for service access it should be recorded | INFO | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "aws.foobar.com",
"event": "authn_token_created:app.foobarapi.prod,create,read,update",
"level": "INFO",
"description": "A token has been created for app.foobarapi.prod with create,read,update",
... | |||
| authn_token_revoked[:userid,tokenid] | A token has been revoked for the given account. | INFO | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "aws.foobar.com",
"event": "authn_token_revoked:app.foobarapi.prod,xyz-abc-123-gfk",
"level": "INFO",
"description": "Token ID: xyz-abc-123-gfk was revoked for user app.foobarapi.prod",
... | |||
| authn_token_reuse[:userid,tokenid] | A previously revoked token was attempted to be reused. | CRITICAL | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "aws.foobar.com",
"event": "authn_token_reuse:app.foobarapi.prod,xyz-abc-123-gfk",
"level": "CRITICAL",
"description": "User app.foobarapi.prod attempted to use token ID: xyz-abc-123-gfk which was previously revoked",
... | ||
| authn_token_delete[:appid] | When a token is deleted it should be recorded | WARN | alarms raised by the access control system deletion of important data files | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authn_token_delete:foobarapi",
"level": "WARN",
"description": "The token for foobarapi has been deleted",
... | ||
| Authorization [AUTHZ] | authz_fail[:userid,resource] | An attempt was made to access a resource which was unauthorized | CRITICAL | rejected data access attempts rejected resource access attempts alarms raised by the access control system | Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations. (7.2.2) | <logger name="com.xpn.xwiki.user.impl.xwiki.XWikiRightServiceImpl" level="info"/>What will be logged:
Note: XWikiRightServiceImpl is deprecated, replaced by the config just below. What will be logged:
| "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authz_fail:joebob1,resource",
"level": "CRITICAL",
"description": "User joebob1 attempted to access a resource without entitlement",
... |
| authz_change[:userid,from,to] | The user or entity entitlements was changed | WARN | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authz_change:joebob1,user,admin",
"level": "WARN",
"description": "User joebob1 access was changed from user to admin",
... | |||
| authz_admin[:userid,event] | All activity by privileged users such as admin should be recorded. | WARN | use of privileges | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "authz_admin:joebob1,user_privilege_change",
"level": "WARN",
"description": "Administrator joebob1 has updated privileges of user foobarapi from user to admin",
... | ||
| Excessive Use [EXCESS] | excess_rate_limit_exceeded[userid,max] | Expected service limit ceilings should be established and alerted when exceeded, even if simply for managing costs and scaling. | WARN | rejected resource access attempts alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "excess_rate_limit_exceeded:app.foobarapi.prod,100000",
"level": "WARN",
"description": "User app.foobarapi.prod has exceeded max:100000 requests",
... | |
| File Upload [UPLOAD] | upload_complete[userid,filename,type] | On successful file upload the first step in the validation process is that the upload has completed. | INFO | <logger name="?com.xpn.xwiki.internal.fileupload?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "upload_complete:joebob1,user_generated_content.png,PNG",
"level": "INFO",
"description": "User joebob1 has uploaded user_generated_content.png",
... | ||
| upload_stored[filename,from,to] | One step in good file upload validation is to move/rename the file and when providing the content back to end users, never reference the original filename in the download. This is true both when storing in a filesystem as well as in block storage. | INFO | <logger name="?com.xpn.xwiki.internal.fileupload?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "upload_stored:user_generated_content.png,kjsdhkrjhwijhsiuhdf000010202002",
"level": "INFO",
"description": "File user_generated_content.png was stored in the database with key abcdefghijk101010101",
... | |||
upload_validation[filename,(virusscan|imagemagick|...) FAILED|incomplete|passed)] | All file uploads should have some validation performed, both for correctness (is in fact of file type x), and for safety (does not contain a virus). | INFO|CRITICAL | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "upload_validation:filename,virusscan:FAILED",
"level": "CRITICAL",
"description": "File user_generated_content.png FAILED virus scan and was purged",
... | ||
| upload_delete[userid,fileid] | When a file is deleted for normal reasons it should be recorded. | INFO | deletion of important data files | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "upload_delete:joebob1,",
"level": "INFO",
"description": "User joebob1 has marked file abcdefghijk101010101 for deletion.",
... | ||
| Input Validation [INPUT] | input_validation_fail[:field,userid] | When input validation fails on the server-side it must either be because a) sufficient validation was not provided on the client, or b) client-side validation was bypassed. In either case it's an opportunity for attack and should be mitigated quickly. | WARN | rejected resource access attempts | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "input_validation_fail:date_of_birth,joebob1",
"level": "WARN",
"description": "User joebob1 submitted data that failed validation.",
... | |
| Malicious Behavior [MALICIOUS] | malicious_excess_404:[userid|IP,useragent] | When a user makes numerous requests for files that don't exist it often is an indicator of attempts to "force-browse" for files that could exist and is often behavior indicating malicious intent. | WARN | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "malicious_excess404:123.456.789.101,M@l1c10us-Hax0rB0t0-v1",
"level": "WARN",
"description": "A user at 123.456.789.101 has generated a large number of 404 requests.",
... | |
| malicious_extraneous:[userid|IP,inputname,useragent] | When a user submits data to a backend handler that was not expected it can indicate probing for input validation errors. If your backend service receives data it does not handle or have an input for this is an indication of likely malicious abuse. | CRITICAL | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "malicious_extraneous:[email protected],creditcardnum,Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0",
"level": "WARN",
"description": "User [email protected] included field creditcardnum in the request which is not handled by this service.",
... | ||
| malicious_attack_tool:[userid|IP,toolname,useragent] | When obvious attack tools are identified either by signature or by user agent they should be logged. | CRITICAL | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "malicious_attack_tool:127.0.0.1,nikto,Mozilla/5.00 (Nikto/2.1.6) (Evasions:None) (Test:Port Check)",
"level": "WARN",
"description": "Attack traffic indicating use of Nikto coming from 127.0.0.1",
... | ||
| malicious_cors:[userid|IP,useragent,referer] | When attempts are made from unauthorized origins they should of course be blocked, but also logged whenever possible. Even if we block an illegal cross-origin request the fact that the request is being made could be an indication of attack. | CRITICAL | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "malicious_cors:127.0.0.1,Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0,attack.evil.com",
"level": "WARN",
"description": "An illegal cross-origin request from 127.0.0.1 was referred from attack.evil.com",
... } | ||
| malicious_direct_reference:[userid|IP, useragent] | A common attack against authentication and authorization is to directly access an object without credentials or appropriate access authority. Failing to prevent this flaw used to be one of the OWASP Top Ten called Insecure Direct Object Reference. Assuming you've correctly prevented this attack, logging the attempt is valuable to identify malicious users. | CRITICAL | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "malicious_direct:joebob1, Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0",
"level": "WARN",
"description": "User joebob1 attempted to access an object to which they are not authorized",
... | ||
Privilege Changes [PRIVILEGE] This section focuses on object privilege changes such as read/write/execute permissions or objects in a database having authorization meta-information changed. Changes to user/account are covered in the User Management section. | privilege_permissions_changed:[userid,file|object,fromlevel,tolevel] | Tracking changes to objects to which there are access control restrictions can uncover attempt to escalate privilege on those files by unauthorized users. | WARN | use of privileges | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "malicious_direct:joebob1, /users/admin/some/important/path,0511,0777",
"level": "WARN",
"description": "User joebob1 changed permissions on /users/admin/some/important/path",
... | |
Sensitive Data Changes [DATA] It's not necessary to log or alert on changes to all files, but in the case of highly sensitive files or data it is important that we monitor and alert on changes. | sensitive_create:[userid,file|object] | When a new piece of data is created and marked as sensitive or placed into a directory/table/repository where sensitive data is stored, that creation should be logged and reviewed periodically. | WARN | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sensitive_create:joebob1, /users/admin/some/important/path",
"level": "WARN",
"description": "User joebob1 created a new file in /users/admin/some/important/path",
... | ||
| sensitive_read:[userid,file|object] | All data marked as sensitive or placed into a directory/table/repository where sensitive data is stored should be have access logged and reviewed periodically. | WARN | successful data access attempts files accessed and the type of access | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sensitive_read:joebob1, /users/admin/some/important/path",
"level": "WARN",
"description": "User joebob1 read file /users/admin/some/important/path",
... | ||
| sensitive_update:[userid,file|object] | All data marked as sensitive or placed into a directory/table/repository where sensitive data is stored should be have updates to the data logged and reviewed periodically. | WARN | changes to system configuration | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sensitive_update:joebob1, /users/admin/some/important/path",
"level": "WARN",
"description": "User joebob1 modified file /users/admin/some/important/path",
... | ||
| sensitive_delete:[userid,file|object] | All data marked as sensitive or placed into a directory/table/repository where sensitive data is stored should have deletions of the data logged and reviewed periodically. The file should not be immediately deleted but marked for deletion and an archive of the file should be maintained according to legal/privacy requirements. | WARN | deletion of important data files | <logger name="?org.xwiki.component.internal.DocumentDeletedListener?" level="xxx"/><logger name="?org.xwiki.component.internal.WikiDeletedListener?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sensitive_delete:joebob1, /users/admin/some/important/path",
"level": "WARN",
"description": "User joebob1 marked file /users/admin/some/important/path for deletion",
... | ||
Sequence Errors [SEQUENCE] Also called a business logic attack, if a specific path is expected through a system and an attempt is made to skip or change the order of that path it could indicate malicious intent. | sequence_fail:[userid] | When a user reaches a part of the application out of sequence it may indicate intentional abuse of the business logic and should be tracked. | WARN | alarms raised by the access control system | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sequence_fail:joebob1",
"level": "WARN",
"description": "User joebob1 has reached a part of the application out of the normal application flow.",
... | |
| Session Management [SESSION] | session_created:[userid] | When a new authenticated session is created that session may be logged and activity monitored. | INFO | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "session_created:joebob1",
"level": "INFO",
"description": "User joebob1 has started a new session",
... | ||
| session_renewed:[userid] | When a user is warned of session to be expired/revoked and chooses to extend their session that activity should be logged. Also, if the system in question contains highly confidential data then extending a session may require additional verification. | INFO | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "session_renewed:joebob1",
"level": "WARN",
"description": "User joebob1 was warned of expiring session and extended.",
... | |||
| session_expired:[userid,reason] | When a session expires, especially in the case of an authenticated session or with sensitive data, then that session expiry may be logged and clarifying data included. The reason code may be any such as: logout, timeout, revoked, etc. Sessions should never be deleted but rather expired in the case of revocation requirement. | INFO | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "session_expired:joebob1,revoked",
"level": "WARN",
"description": "User joebob1 session expired due to administrator revocation.",
... | |||
| session_use_after_expire:[userid] | In the case a user attempts to access systems with an expire session it may be helpful to log, especially if combined with subsequent login failure. This could identify a case where a malicious user is attempting a session hijack or directly accessing another person's machine/browser. | WARN | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "session_use_after_expire:joebob1",
"level": "WARN",
"description": "User joebob1 attempted access after session expired.",
... | |||
| System Events [SYS] | sys_startup:[userid] | When a system is first started it can be valuable to log the startup, even if the system is serverless or a container, especially if possible to log the user that initiated the system. | WARN | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sys_startup:joebob1",
"level": "WARN",
"description": "User joebob1 spawned a new instance",
... | ||
| sys_shutdown:[userid] | When a system is shut down it can be valuable to log the event, even if the system is serverless or a container, especially if possible to log the user that initiated the system. | WARN | <logger name="org.xwiki.shutdown" level="info"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sys_shutdown:joebob1",
"level": "WARN",
"description": "User joebob1 stopped this instance",
... | |||
| sys_restart:[userid] | When a system is restarted it can be valuable to log the event, even if the system is serverless or a container, especially if possible to log the user that initiated the system. | WARN | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sys_restart:joebob1",
"level": "WARN",
"description": "User joebob1 initiated a restart",
... | |||
| sys_crash[:reason] | If possible to catch an unstable condition resulting in the crash of a system, logging that event could be helpful, especially if the event is triggered by an attack. | WARN | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sys_crash:outofmemory, "level": "WARN",
"description": "The system crashed due to Out of Memory error.",
... | |||
| sys_monitor_disabled:[userid,monitor] | If your systems contain agents responsible for file integrity, resources, logging, virus, etc. it is especially valuable to know if they are halted and by whom. | WARN | de-activation of security systems (such as anti-virus systems and intrusion detection systems) | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sys_monitor_disabled:joebob1,crowdstrike",
"level": "WARN",
"description": "User joebob1 has disabled CrowdStrike",
... | ||
| sys_monitor_enabled:[userid,monitor] | If your systems contain agents responsible for file integrity, resources, logging, virus, etc. it is especially valuable to know if they are started again after being stopped, and by whom. | WARN | activation of security systems (such as anti-virus systems and intrusion detection systems) | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "sys_monitor_enabled:joebob1,crowdstrike",
"level": "WARN",
"description": "User joebob1 has enabled CrowdStrike",
... | ||
| User Management [USER] | user_created:[userid,newuserid,attributes[one,two,three]] | When creating new users, logging the specifics of the user creation event is helpful, especially if new users can be created with administration privileges. | WARN | creation of identities | <logger name="?org.xwiki.notifications.filters.internal.UserAddedEventListener?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "user_created:joebob1,user1,admin:create,update,delete",
"level": "WARN",
"description": "User joebob1 created user1 with admin:create,update,delete privilege attributes",
... | |
| user_updated:[userid,onuserid,attributes[one,two,three]] | When updating users, logging the specifics of the user update event is helpful, especially if users can be updated with administration privileges. | WARN | modification of identities | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "user_updated:joebob1,user1,admin:create,update,delete",
"level": "WARN",
"description": "User joebob1 updated user1 with attributes admin:create,update,delete privilege attributes",
... | ||
| user_archived:[userid,onuserid] | It is always best to archive users rather than deleting, except where required. When archiving users, logging the specifics of the user archive event is helpful. A malicious user could use this feature to deny service to legitimate users. | WARN | <logger name="xxx" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "user_archived:joebob1,user1",
"level": "WARN",
"description": "User joebob1 archived user1",
... | |||
| user_deleted:[userid,onuserid] | It is always best to archive users rather than deleting, except where required. When deleting users, logging the specifics of the user delete event is helpful. A malicious user could use this feature to deny service to legitimate users. | WARN | deletion of identities | <logger name="?org.xwiki.notifications.filters.internal.listener.DeleteUserEventListener?" level="xxx"/> | "datetime": "2019-01-01 00:00:00,000",
"appid": "foobar.netportal_auth",
"event": "user_deleted:joebob1,user1",
"level": "WARN",
"description": "User joebob1 has deleted user1",
... |
Compliance with other requirements
This section outlines the configuration of the relevant loggers to address remaining security requirements not covered in the table above.
| Event | ISO/IEC 27002 8.15 Logging | OWASP Application Security Verification Standard (ASVS) | Logger Configuration in |
|---|---|---|---|
| Successful Data Access | successful data access attempts | <logger name="xxx" level="xxx"/> | |
| Successful Resource Access | successful resource access attempts | <logger name="xxx" level="xxx"/> | |
| Successful System Configuration Changes | changes to system configuration | <logger name="xxx" level="xxx"/> | |
| Successful Use of Utility Programs and Applications | use of utility programs and applications | <logger name="xxx" level="xxx"/> | |
| Successful Transactions | transactions executed by users in applications (In some cases, the applications are a service or product provided or run by a third party) | <logger name="xxx" level="xxx"/> | |
| Rejected Time-based Multi-factor OTP Token | Verify that if a time-based multi-factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device. (2.8.5) | <logger name="xxx" level="xxx"/> | |
| TLS Connection Failures | Verify that backend TLS connection failures are logged. (9.2.5) | <logger name="xxx" level="xxx"/> |
