Friday, 1 February 2008

Auditing Data Conversion

Data conversions are an essential part of testing the primary Controls that are necessary to ensure that the task is performed completely and accurately, and that no unauthorised changes to the input take place. Experience has demonstrated that the most likely point of error and fraud in computer systems is during the input phase. This is where data may be: -

  • lost or incomplete;
  • duplicated;
  • unauthorised or fictitious;
  • manipulated during the input process;
  • inserted without authority (either accidentally or fraudulently).

One of the issues that is often missed is that a system change and the associated testing needs to cover aspects as banal as:

  • starting up, shutting down and operating computers (other than PCs) and networks;
  • software, hardware and network problem investigation and resolution;
  • producing and distributing centrally produced computer outputs;
  • operating “batch” (or “background”) jobs;
  • backing up the system and management of off-line files (tapes, CDs, DVDs, etc);
  • installing new and amended software;
  • providing a help desk service for recording and allocating problems (hardware, software, communications) for resolution, and expediting outstanding problems;

When moving to a new finacial system always validate that the process is documented, there are adequate procedures for handling input forms, and that the data input to the system for processing is first tested for errors and omissions. Statistical tests can be carried out against the appropriate application system (e.g. duplication, gap analysis, transactions unmatched with accounts).

The basic stategs in a data conversion may include test of controls for the following areas:

  1. Strategy, Planning, Identify Dependencies
  2. Data Cleansing of Predecessor Systems
  3. Data Reconciliation and Validation Procedures
  4. Parallel Maintenance of Master Files
  5. Ownership and Sign-Off of Converted Files
  6. Internal Staff have Primary Responsibility - and Contract Staff should work subject to additional validation
  7. Special Controls for Automated and Manual Conversions

With legistlation to protect the integrity of data and finacial reports, it is still amazing that data conversion testing is rare and oft overlooked.

Thursday, 31 January 2008

The postal acceptance rule

The postal acceptance rule states that where an acceptance is to be sent by post, the contract associated with that acceptance is considered as concluded at the moment of posting the letter, not when the letter is received (or in fact if the letter is received). If the offeror does not wish to conclude, the contract through acceptance via the post, s/he may stipulate the form of acceptance. (The “postal acceptance rule” was introduced to present assurance to the “new” British penny post. It dates back to Adams v. Lindsell, 1 Barnewall and Alderson 681, In the King's Bench (1818); See also Household Fire Insurance Co v Grant [1879] 4 Ex D 216).

Lim (2004) points out that there have been at least "twelve theories or explanations offered for the postal acceptance rule". He further notes that two of these theories apply particularly well to Internet-based contractual transactions. The first theory hypothesises that the postal acceptance rule is applicable to Internet transactions as the communication proceeds through a third party. Next, an argument exists for the theory that the postal acceptance rule applies to e-mail, as it is a non-instantaneous means of communicating.

Contractual acceptance through e-mail remains unsettled by judicial review or decision. As such, there is still a high degree of uncertainty surrounding the issues of offer and acceptance related to the formation of contracts through e-mail based communication. In the US, this issue has been determined through statutory intervention (Uniform Electronic Transactions Act, 1999; USA). In the UK, the issue remains unclear even following the ECA.

In cases concerning international transactions, the Sale of Goods (United Nations Convention) Act 1994 may be applied. This act overrides the concept of “postal acceptance” is and as an alternative presents the approach that acceptance “will become effective at the moment the indication of consent reaches the offeror”. In practice, the acceptance transpires at the instant that the communication arrives at the offeror’s computer. While no decided cases on this point are available as guidance, the courts have traditionally been disinclined to extend the application of the postal acceptance rule.

Although telex, faxes and e-mail are separate technologies, they share many features. In both Entores v. Miles Far East Corp ([1955] 2 QB 327) and Brinkibon Ltd v Stahag Stahl (1983), the courts declined to extend the application of the postal acceptance rules.

Lord Wilberforce (Brinkibon Ltd v Stahag Stahl [1983]) stated at 42, "where the condition of simultaneity is met, and where it appears to be within the mutual intention of the parties that contractual exchanges should take place in this way, I think it a sound rule, but not necessarily a universal rule”. The issue of “read receipts” for e-mail could be an important factor in a future decision. Lord Fraser of Tullybelton (at 43) differs somewhat in his judgement from Lord Wilberforce, stating that:
A party (the acceptor) who tries to send a message by telex can generally tell if his message has not been received on the other party’s (the offeror's) machine, whereas the offeror, of course, will not know if an unsuccessful attempt has been made to send an acceptance to him. It is therefore convenient that the acceptor, being in the better position, should have the responsibility of ensuring that his message is received.”

From the above cases, we can see that technological differences such as the inclusion of read and sent receipts. Further, the arguable position of e-mail as to whether it is or is not “instantaneous” has created a level of uncertainty in contracting as “the question of the applicability of the postal acceptance rule to e-mail acceptances has not been judicially settled.” (Lim, 2002, p66).

The postal acceptance rule as a generally consideration does not to apply to Web-based communications. This is because most Web-based systems employee mechanisms such as check-sums to maintain constant communication between the client and server systems. The constant verification this communication channel provides for the implication that communications take place though an immediate send process. Thus, both parties receive communications instantaneously.

The UK Government has not adopted the Model Law (As contained in the Electronic Commerce (EC Directive) Regulations 2002, SI 2002/2013), which would have put to rest the postal rule argument concerning email. The regulations do however unmistakably declare the point at which an order is legally supposed to be communicated. Regulation 11(2)(a) states that where businesses contract, “the order and the acknowledgement of receipt will be deemed to be received when the parties to whom they are addressed are able to access them”. Where contracts complete by email are concerned, the instant of completion would be the time when the email is presented to the person to whom it is addressed and not when the message is actually received by their email server.

Wednesday, 30 January 2008

Trusting electronically signed documents.

Both electronic and paper documents are subject to tampering. The discovery of collisions has demonstrated that the process of signing a hash signature is not without its own vulnerabilities. In fact, the collision allows two versions of the document to be created with the same hash and thus same electronic signature.

It was stated in a response to an earlier post that “Electronic contracts do not have to be re-read when they are returned because there's generally no mechanism (unless it's built into the electronic process) to alter the contract terms, scratch out a line, insert text, etc. What you send is what is being signed.

Unfortunately this is not true.

An attacker could generate two documents. One states:
Sell at $500,000.00 (Order 1)

The second document states:
Sell at $1,000,000.00 (Order 2)

Our attacker wants to have the second document as the one that is signed. By doing this they have increased the sale contract by $500,000.

Confoo is a tool that has been used to demonstrate two web pages that look different, but have the same MD5 hash (and there are also issues with other hash algorithms as well).

Digital signatures typically work using public key crypto. The document is signed using the private key of the signer. The public key is used for verification of the signature. The issue is that public key crypto is slow. So rather then signing the entire document, a hash of the document is signed. As long as the hash is trusted, the document is trusted. The concern is that collisions exist.

So back to the issue. Our attacker takes order 1 and order 2 and uses the Confoo techniques (also have a look at Stripwire).

The client is sent a document that reads as “order 1” and they agree to buy a product for $500,000. As such they sign the order using an MD5 hash that is encrypted with the buyers private key. Our attacker (using Confoo style techniques) has set up a document with a collision. Order 1 and Order 2 both have the same hash.

Our attacker can substitute the orders and the signed document (that is a verified hash) will still verify as being signed.

The ability of Microsoft Word to run macros and code makes it a relatively simple attack to create a collision in this manner.

So, electronic documents do need to be re-read – but it is simpler in that there are tools to verify these. Ensure that the Hash used is trusted and even use multiple hashes together.

Further Reading:
http://www.doxpara.com/slides/Black%20Ops%20of%20TCP2005_Japan.ppt


Tech aside.

This attack works due to the nature of hashing algorithms. If you have 2 documents, x and y that have the same hash (i.e. a collision) then by appending an additional block of information – q to the documents will also result in a collision. This is (x+q) will have the same hash as (y+q).

Tuesday, 29 January 2008

E-mail and electronic contracts

There are a number of contractual issues associated with e-mail. There are for example, numerous debates over the applicability of the postal rule. When sending an e-mail, there are several potential moments of acceptance. These are:

  1. The first moment occurs when the e-mail departs the sender’s outbox controlled by the sender. In Internet-based e-mail transactions, the e-mail cannot be recall once it has left the sender's outbox. This is a situation analogous to the postal rule.

  2. The next is the instant of recept of the e-mail into the recipient’s inbox. At this point, the e-mail is accessible to the recipient.

  3. The next possible instant that could potentially be the moment of acceptance is when the recipient collects the e-mail from the mail server into the mail client's inbox. At this point, the recipient has received the e-mail.

  4. Finally, there is an argument for defining the moment of acceptance as the point when the recipient has opened or read the e-mail.

The additional inclusion of features such as e-mail recall (in products such as Microsoft Outlook), read receipts and send receipts (in most e-mail servers and client) further obfuscate the moment that could be considered the time when acceptance was made.

E-mail is the digital equivalent of a letter sent through the post. All normal functions of postal mail transpire through e-mail. This includes not only the ability to send advertisements or invitations to treat (Partridge v Crittenden [1968]), but also equally offers and acceptances.

It must be remembered that the “question of whether the mailbox rule applies to e-mail is one that the courts have not yet answered. Its applicability seems to depend on whether e-mail is deemed to be more like instantaneous communication than like traditional mail services. Unlike real time chat e-mail, however, it is probably not instantaneous in the sense of this rule.” (Cavazos & Morin, 1994).

E-mail, maybe fast, but it is not instantaneous. Failed delivery, rerouting, damage in delivery or simply delayed all arise with E-mail. For this reason, e-mail, may be argued to most closely mirror a postal letter delivery.

What is an “Electronic Contract”

When contrasting contractual principles, it is clear that where a contract is not required to be in writing (Columbia Law Review, Apr., 1929 Pp. 497-504; Columbia Law Review, Jun., 1907, pp. 446-449; McKendrick, E, 2005, p 184), that little additional uncertainty could be created where the contract is completed electronically. In fact, it is clear that electronic evidence must hold greater weight than verbal evidence (Lord Justice Auld, Sept 2001, Cpt 11). What is not clear is the extent of the weight attached to the various forms of electronic evidence. The strength of a digital signature algorithm and the security surrounding the mechanisms used to sign an electronic document will respectively influence the weight associated with any piece of electronic evidence.

It has been argued that the digital contract may appear on the computer screen to consist of words in a written form but merely consist of a virtual representation (Allison et al, 2003). The ECA has removed the uncertainty and doubt surrounding the question as to the nature of electronic form used in the construction of a contract. In this, the ECA specifies that the electronic form of a contract is to be accepted as equivalent to a contract in writing.

An electronic contract has a twofold structure. Thought of electronically, the contract is a sequence of numbers and code saved to some electronic or magnetic medium. Alternatively, the contract becomes perceptible through a transformation of the numeric code when broadcast to a computer output device such as a printer or screen(Bainbridge, 2000; Reed, 2004; Brownsword, 2000). Prior to the passing of the ECA, this dichotomy exasperated the uncertainty contiguous with whether an electronic contract can be regarded as being a contract in writing.

The English legal doctrines of offer, acceptance and consideration when coupled with an intention to create legally binding relations define the necessary conditions for the creation of a contract. There is no necessity for the most part [Excluding contracts such as for the transfer of real property, which are covered by a variety of specific acts] that any contract be concluded in writing.

The question as to whether contracts performed electronically are legalistically equivalent to writing comes more to a question of evidential weight and the application of the parole evidence rule (Durtschi, 2002; Lim, 2002). By stating that electronic contracts are equivalent to writing, the ECA has in effect, forbid the introduction of extrinsic evidence which could change the terms of the electronic contract.

The question would remain as to a determination of whether the electronic communications contain the final agreement between the parties. Where some, though not all, of the terms are agreed in the electronic communication, a partial integration will result in the allowing of extrinsic evidence (Treitel, 2003).
The ECA did little to suppress the disputes surrounding the evidential weight attached to an electronic signature due to the receipt of a number of objections [Eg., London Borough of Newham for the National Smart Card Project (2003)] prior to the passing off the bill. Accordingly, when the Act was passed on 25 May 2000 its provisions as to the weight of electronic signatures did not meet the objectives of the EC Directive on Electronic Signatures and where less detailed. Section 7(1) provides:

'In any legal proceedings-
(a) an electronic signature [176] incorporated into or logically associated with a particular electronic communication or particular electronic data, and
(b) the certification [177] by any person of such a signature, shall each be admissible in evidence in relation to any question as to the authenticity of the communication or data or as to the integrity of the communication or data.'

Monday, 28 January 2008

Oracle Programing and security

Encryption is a fascinating issue within database design and for this post we are looking principally at Oracle.
Oracle provides some inbuilt encryption and hashing packages as standard modules. There are also a number of both free solutions and commercial alternatives that provide this capability. The familiar issues of compliance, performance and protecting keys also needs to be addressed.

One of the biggest issues has come as a result of the PCI-DSS (the standards that are designed to protect payment card information). In particular to the database issue, we need to look at section 3.4 of the PCI-DSS (Version 1.1). It states that the followign task must be completed:

Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital
media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:

  • Strong one-way hash functions (hashed indexes)
  • Truncation
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key management processes and procedures.
The MINIMUM account information that must be rendered unreadable is the PAN.
If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.”

3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control Payment Card Industry (PCI) Data Security Standard 6 mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.



The MD5 routines in DBMS_OBFUSCATION_TOOLKIT are available from version 8iR3, and the DBMS_METADATA package is available from version 9iR1 of Oracle.

The DBMS_OBFUSCATION_TOOLKIT package provies an Oracle developer with the ability to encrypt data in the database. At present it only implements the DES and 3DES encryption algorithms. The package doesn’t allow double encryption and doesn’t support CBC modes. DBMS_CRYPTO is a newer package that is designed as a replacement for the DBMS_OBFUSCATION_TOOLKIT package available in Oracle 8i and 9i, it addresses many of the shortcomings in the previous package. It is is easier to use and contains more cryptographic algorithms:
  • Cryptographic algorithms - DES, 3DES, AES, RC4, 3DES_2KEY
  • Padding forms - PKCS5, zeroes
  • Block cipher chaining modes - CBC, CFB, ECB, OFB
  • Cryptographic hash algorithms - MD5, SHA-1, MD4
  • Keyed hash (MAC) algorithms - HMAC_MD5, HMAC_SH1
  • Cryptographic pseudo-random number generator - RAW, NUMBER, BINARY_INTEGER
  • Database types - RAW, CLOB, BLOB
The hashing checksum routines provide functions to allow checksums to be created for both raw and text data. These functions are used to both obscure data and to ensure the integrity of the data. An example would be for the developer to write a checksum value for each object in a schema. It is also important to add error checking and input validation.

It is essential to monitor and log which users have access to the packages DBMS_METADATA, DBMS_OBFUSCATION_TOOLKIT, and DBMS_CRYPTO. The who_can_access.sql script may be used to provide this level of auditing or a a simple control. The access of any users who do not need to run these packages needs to be REVOKEd to ensure that you only grant privileges to those that need them. MD5 checksums can be used to make it more difficult for an attacker to cover their tracks.

The DBMS_OBFUSCATION_TOOLKIT has a limitation with the MD5 routines. This package only sums the first 32K of data. This is also a limitation inherent to PL/SQL. An attacker could use this flaw to alter any code after the 32K boundary. By splitting PL/SQL code into blocks of 32K that are processed separately for the purpose of creating a checksum, this flaw is avoided. It does increase the processor utilisation however.

A simple example of using the encryption packages is:

SET SERVEROUTPUT ON
DECLARE
l_visa_card_num VARCHAR2(19) := '0123 4567 8901 2345';
l_ccn_raw RAW(128) := UTL_RAW.cast_to_raw(l_visa_card_num);
l_key RAW(128) := UTL_RAW.cast_to_raw('abcdefgh');

l_encrypted_raw RAW(2048);
l_decrypted_raw RAW(2048);
BEGIN
DBMS_OUTPUT.put_line('Original : ' || l_visa_card_num);

l_encrypted_raw := DBMS_CRYPTO.encrypt(src => l_ccn_raw,
typ => DBMS_CRYPTO.aes_cbc_pkcs5,
key => l_key);

DBMS_OUTPUT.put_line('Encrypted : ' || RAWTOHEX(UTL_RAW.cast_to_raw(l_encrypted_raw)));

l_decrypted_raw := DBMS_CRYPTO.decrypt(src => l_encrypted_raw,
typ => DBMS_CRYPTO.aes_cbc_pkcs5,
key => l_key);

DBMS_OUTPUT.put_line('Decrypted : ' || UTL_RAW.cast_to_varchar2(l_decrypted_raw));
END;
/
Original : 0123 4567 8901 2345
Encrypted : 3223041423134363443444777412353453453633251435345435335444343373632333135424533543314545
Decrypted : 0123 4567 8901 2345

PL/SQL procedure successfully completed.
Using these functions it is possible to verify the integrity of an Oracle database and also meet the PCI requirements.

Sunday, 27 January 2008

Spare Time

A little lanscaping.

Well the outside area is coming along and the herbs are growing nicely (at least those that the wallabies do not like).
We have summer savory, oregano, majoram, thyme (common), spearmint, catnip, peppermint and common mint all waiting to be used in salads and for that flavoured stew. At the front is a paw paw (papya), there are a coupl,e coffee trees and some comfry and dog's bane.
More gardens, rocks to collect and lanscaping await. I have to go tend the salad and kitchen garden later today, but all in the morning prior to the SUMMER SUN beating down.
But not till my next vactations.
Right now, with a chapter of a book to complete, questions for SANS 509 (Oracle security) and a few other tasks to complete - I am trying to ignore the mowing...

The adventures of Kermit the great

Little to do with Security as this is a Sunday.
The full adventures of Kermit the Great (KtG) will be posted on my wife's blog later today. My pictures, her text and the adventures of KtG.
See KtG overcome the insurmountable obstacles that lie in his path as he emerges from his frog lair to finally survey his demise.

More on Kermit the Great shall be made available at http://lynn-downunder.blogspot.com/ later today...

Same frog channel...