Auditing Requirements are Tricky. Isn’t it?

[adsenseyu2]

Many a project I worked upon, did not have a clear stated set of requirements related to auditing. Interestingly, with some projects, the auditing related requirements were created only after a couple of releases and got prioritized as less important in that specific release. One of the common observation I made across these projects is lack of understanding of auditing requirements and its significance, to key stakeholders including product owners, business analysts, developers and testers. Most of them could not figure out a strong reasoning in relation with why do we need to take care of audit trail of one or more transactions, until they got addressed/questioned by a security expert/officer/architect during review of application requirements/code review etc.

Before we go on why and when do we need to implement auditing requirements, lets understand what looks like auditing requirements?

What looks like auditing requirements?

Auditing requirements primarily looks like recording the information related with transactions such as who performed the transaction, when was it done, what is its detail etc. The transactions can be of many types such as financial (order/cancel/pay etc), workflow approvals/rejections etc. As per wikipedia, following is how auditing is defined as:

Auditing is defined as a systematic and independent examination of data, statements, records, operations and performances (financial or otherwise) of an enterprise for a stated purpose. In any auditing the auditor perceives and recognizes the propositions before him for examination, collects evidence, evaluates the same and on this basis formulates his judgment which is communicated through his audit report

Why at all is auditing requirements needed to be implemented?

Auditing requirements need to be implemented primarily to handle/manage repudiation attacks. Repudiation attacks  happens as a result of data manipulation without any logs followed by the act of refusing and no longer accepting a transaction that one performed. The authenticity of the data/transactions when challenged is called the state of repudiation. And, for organization to prove  otherwise, they need to show the evidence that the transaction was performed. This is where auditing related data needs to be recorded for key transactions.

When & how does one figure out the auditing requirements?

The auditing requirements mostly remain implicit. Until the business analyst (BA) has the knowledge on threats related with Repudiation (refer STRIDE model), the auditing requirements go unnoticed. During business analysis process, BA needs to check with business users on what are sensitive data and key transactions which could have significant impacts such as financial loss if one refuses to accept that he/she was responsible for change or doing the transaction. Once these data and transactions are identified, the BA would like to put the auditing requirements around these such as recording information about any change of this sensitive data or, information (who, when, what, where, why etc). about the transactions.

Once business analysts (BA) documented the auditing requirement, developers need to put a design around audit including appropriate data model, and modules to manage the auditing data.

[adsenseyu1]