Authors
Roland Mittermeir, Markus Clermont, & Karin Hodnigg
Abstract
Previous research on spreadsheet risks has predominantly focussed on errors inadvertently introduced by spreadsheet writers i.e. it focussed on the "end-user aspects" of spreadsheet development.
When analyzing a faulty spreadsheet, one might not be able to determine whether a particular error (fault) has been made by mistake or with fraudulent intentions. However, the fences protecting against fraudulent errors have to be different from those shielding against inadvertent mistakes.
Faults resulting from errors committed inadvertently can be prevented ab initio by tools that notify the spreadsheet writer about potential problems whereas faults that are introduced on purpose have to be discovered by auditors without the cooperation of their originators. Even worse, some spreadsheet writers will do their best to conceal fraudulent parts of their spreadsheets from auditors.
In this paper we survey the available means for fraud protection by contrasting approaches suitable for spreadsheets with those known from fraud protection for conventional software.
Sample
The following mechanisms can be used to protect spreadsheets against the incorporation of fraud-permissive code or against fraudulent modifications:
- Reviews and inspections. There are several forms of reviews, distinguished by their purpose, position in the development cycle and the particular techniques applied. The techniques range from walkthroughs to inspections.
- Testing. Testing can only show the presence of faults, but never their absence. While testing can only raise the level of confidence one can have in the correctness of a program, its fault detection characteristics are sufficiently different from those of reviews or proofs so that any solid quality management strategy would employ a mix of these quality assurance strategies.
- Assertions. Assertions are a strategy for relating program code to its specification and, if the assertions are to be executed during operation, for checking whether the state defined by the operation of the program on a particular stream of input data conforms to the specification.
- Authentification. The idea is basically that the content of the program portion of the sheet is subjected to some cryptographic encoding such that any modification in the program would lead to a different cipher. Consequently, the program is sealed against unauthorised changes and users of this program can be sure that they used the program they intended to use and not some slightly modified clone of it.
Publication
2005, EuSpRIG
