Audit/Logging Repudiation. Security Testing: Testing for What It s NOT supposed to do

Loading....

Loading....

Loading....

Loading....

Loading....

Full text

(1)

Audit/Logging

Repudiation

Laurie Williams

williams@csc.ncsu.edu

Security Testing: Testing for What

It’s NOT supposed to do

(2)

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.

(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

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.

(4)

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.

(5)

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.

(6)

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.

(7)

Figure

Updating...

References

Updating...

Related subjects : What s New in Security