Audit/Logging Repudiation Laurie Williams williams@csc.ncsu.edu Security Testing: Testing for What It s NOT supposed to do Thompson, Herbert, *, IEEE Security and Privacy, July/Aug 2003, pp. 83-86. 1
Audit Many industries are required by legal and regulatory requirements to be: Auditable all activities that affect user state or balances are formally tracked Traceable it s possible to determine where an activity occurs in all tiers of the application High integrity logs cannot be overwritten or tampered with by local or remote users http://www.owasp.org/index.php/error_handling,_auditing_and_logging CWE 778: Insufficient logging When security-critical events are not logged properly, such as a failed login attempt, this can make malicious behavior more difficult to detect and may hinder forensic analysis after an attack succeeds. Sufficient data should be logged to enable system administrators to detect attacks, diagnose errors, and recover from attacks. http://cwe.mitre.org/data/definitions/778.html 2
What to log Reading of data file access and what kind of data is read. This not only allows to see if data was read but also by whom and when. Writing of data logs also where and with what mode (append, replace) data was written. This can be used to see if data was overwritten or if a program is writing at all. Modification of any data characteristics, including access control permissions or labels, location in database or file system, or data ownership. Administrators can detect if their configurations were changed. Administrative functions and changes in configuration regardless of overlap (account management actions, viewing any user's data, enabling or disabling logging, etc.) http://www.owasp.org/index.php/error_handling,_auditing_and_logging#logging What to log All authorization attempts (include time) like success/failure, resource or function being authorized, and the user requesting authorization. We can detect password guessing with these logs. These kinds of logs can be fed into an Intrusion Detection system that will detect anomalies. Deletion of any data (object). Sometimes applications are required to have some sort of versioning in which the deletion process can be cancelled. Network communications (bind, connect, accept, etc.). With this information an Intrusion Detection system can detect port scanning and brute force attacks. All authentication events (logging in, logging out, failed logins, etc.) that allow to detect brute force and guessing attacks too. http://www.owasp.org/index.php/error_handling,_auditing_and_logging#logging 3
What to log Reading of data file access and what kind of data is read. This not only allows to see if data was read but also by whom and when. Writing of data logs also where and with what mode (append, replace) data was written. This can be used to see if data was overwritten or if a program is writing at all. Modification of any data characteristics, including access control permissions or labels, location in database or file system, or data ownership. Administrators can detect if their configurations were changed. Administrative functions and changes in configuration regardless of overlap (account management actions, viewing any user's data, enabling or disabling logging, etc.) http://www.owasp.org/index.php/error_handling,_auditing_and_logging#logging CWE 779: Logging Excessive Data While logging is a good practice in general, and very high levels of logging are appropriate for debugging stages of development, too much logging in a production environment might hinder a system administrator's ability to detect anomalous conditions. This can provide cover for an attacker while attempting to penetrate a system, clutter the audit trail for forensic analysis, or make it more difficult to debug problems in a production environment. Log files can become so large that they consume excessive resources, such as disk and CPU, which can hinder the performance of the system/ cause a denial of service. http://cwe.mitre.org/data/definitions/778.html 4
Log Files Logs should be written so that the log file attributes are such that only new information can be written (older records cannot be rewritten or deleted). Logs should also be written to a write once / read many device such as a CD-R. Copies of log files should be made at regular intervals. Log files should be copied and moved to permanent storage and incorporated into the organization's overall backup http://cwe.mitre.org/data/definitions/285.html CWE 532: Information Leak through Log Files While logging all information may be helpful during development stages, it is important that logging levels be set appropriately before a product ships so that sensitive user data and system information are not accidentally exposed to potential attackers. Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files. From: http://cwe.mitre.org/data/definitions/532.html 5
Repudiation Attack Nonrepudiation is the assurance that someone cannot deny something. Typically, nonrepudiation refers to the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated. This attack can be used to change the authoring information of actions executed by a malicious user in order to log wrong data to log files. Defs from http://searchsecurity.techtarget.com/sdefinition/0,,sid14_gci761640,00.htmls 6
View Access Log by Patient 7