C:\ian\Security\q305\report-template-include1.shtm

Security Forum Meeting with ABA Cyberlaw Committee

Objective of Meeting

This was a joint open meeting with representatives from the ABA Cyberlaw Committee - examining how legal/regulatory requirements for demonstrating control of electronic chattel paper (UCC 9-105) can be met by information technology and processes, sufficient to satisfy a court of law. The specific objectives set for this meeting were:

  • Level-set for attendees on project objectives and achievements to date, including presentation of our existing draft document: "Framework for Control of Electronic Chattel Paper"
  • Continue work on compiling a sufficient set of questions and answers that we expect a court of law would accept as satisfactory to demonstrate the effectiveness of an information system in exercising control over electronic chattel paper

Summary

Mike Jerbic gave a short presentation that he provided in earlier work - and delivered to the ABA Cyberlaw meeting in Nashville in March 2005 - to illustrate the essential technology requirements for exercising "control". In particular slide 7 was used as a continual reference through the meeting.

Issues that we need to ensure the Framework document covers in the light of initial discussion of general requirements include:

  • Rendering of the ECP as a tangible document - how it is brought together (template and diverse database sources - all within an acceptable controlled environment)
  • Generally speaking there is not a higher - more stringent - standard for ECP than there is for tangible paper-based chattel paper .... but risk of loss/theft is inherently higher for ECP - risk of aggregation - so we need to evaluate how high the security level (authentication, authorization, access control) must be
  • The meaning and implications of what is involved in "perfection" and priority of claim of ownership and indemnity in law

What mechanism determines the single authoritative original of an electronic document? What is the control environment that will assure this to the required level? The key issue is being able to trust that you know what is the single authoritative copy.

DealerTrack is a 3rd party handling a contract between the dealer and the purchaser. Through their financing arrangement they show who is the financier - this being the party who wishes to assert "ownership". The system shows all registered finance owners up to the current one. DealerTrack acts as the custodian of the record.

Much of the review in this meeting focused on the Statutory Analysis section of the Framework draft (starting on page 9).

There are two key components in the technology:

  • The run-time of the system
  • The administration of the system ... this being the entity that controls the environment

We need to secure both the information and the container for it.

If I am the authorized custodian, then this places a requirement on me to be able to demonstrate to an acceptable level that I am competent to make the assertion that I have the means to know that I hold the single authoritative original - that it is unique.

It is the role of the custodian to operate a reliable control system that includes processes, technology, and people such that the custodian can demonstrate to the satisfaction of its customers (both purchaser and financier), and in the event of dispute also to a court of law, that it is exercising control of the single authoritative original in ways which comply with the requirements of UCC9-105.

Moving on to the difficult issue of "Unalterable" (page 11 of the Framework draft), discussion raised the question: "can the document or control system know that it has been intruded and the ECP document altered?" and it concluded: "yes, but it cannot necessarily identify what was tampered with".

If an intruder manages to get inside a controlled environment by masquerading as an authorized user, and then tampers with the data in an ECP document, then the only mechanism that will detect this is checking the run-time environment and auditing whether the change that was made is outside permitted limits.

This is a layered approach to encompass the control system within a tamper-detection system - a guard whose role is to guard the lower-level guard. In this model there is a presumption that within the control environment all change is authorized.

In comparison, the DealerTrack system states that all changes are unauthorized and that all changes create a new contract which supersedes the previously applicable ECP contract. It was agreed that this is one way to implement the "unalterable" requirement in UCC9-105. We need to set out a roadmap for how we readily identify processes that we believe meet the "unalterable" requirement.

If w assume that rogue administrators, and criminal acts of intrusion by masquerading as an authorized user, are out of scope, then within the control environment a single authoritative copy can within the same contexts as apply to tangible (paper) chattel paper be considered unalterable. Note that:

  • Control environment design should implement administrator permissions such that no administrator is permitted to access specific ECP documents (read, write, or delete) or assume the machine identity of any authorized user of any ECP. This would go far to mitigate vulnerability from insider fraud.
  • While UCC9-105 seems to put "unalterable" in absolute terms, it cannot reasonably be considered as an absolute requirement in the context of requirements on ECP not being more stringent than those placed on paper-based systems.

Burden of proof is therefore best shifted from proving a control system is unalterable to detecting that a change has happened and moving it to determining whether the alteration was authorized or unauthorized. This moves the burden away from the somewhat absolute "must be unalterable" UCC9-105 requirement to a check on what are authorized changes.

Note for interested parties: DealerTrack use software developed by an organization named e-original.

Outputs

Agreement that we have addressed key outstanding issues sufficiently to enable the document editor to produce a significantly advanced new draft.

Next Steps

The document editor will prepare a new draft of the Framework document.

The ABA has its next meeting starting August 8th, so we will aim to have the basic Framework document draft in sufficient state for presentation to that meeting. To achieve this, we will hold a teleconference on Thursday July 28th, with provision for another on Thursday Aug 4th.

Links

See Above.


   
   |   Legal Notices & Terms of Use   |   Privacy Statement   |   Top of Page   Return to Top of Page