[Date Prev][Date Next] [Chronological] [Thread] [Top]

# RE: alteration of Audit Log in Access

- To: <support@gesn.com>
- Subject: RE: alteration of Audit Log in Access
- From: "Nel Finberg" <nfglobal@earthlink.net>
- Date: Wed, 17 Oct 2001 14:48:16 -0700
- Importance: Normal
- In-reply-to: <PPECJKNKLDJLKJPKPPIOEELKDCAA.ken@gesn.com>

Thanks for the response, Ken. For now Metamor accepts the requirement to restrict the server password to authorized staff in the jurisdiction, and that it should be the responsibility of the jurisdiction to restrict knowledge of this password. So no action is necessary in this matter, at this time.
Nel

> -----Original Message-----
> From: owner-support@gesn.com [mailto:owner-support@gesn.com]On Behalf Of Ken Clark
> Sent: Thursday, October 18, 2001 9:55 AM
> To: support@gesn.com
> Subject: RE: alteration of Audit Log in Access
> Its a tough question, and it has a lot to do with perception. Of course everyone knows perception is reality.
> Right now you can open GEMS' .mdb file with MS-Access, and alter its contents. That includes the audit log. This isn't anything new. In VTS, you can open the database with progress and do the same. The same would go for anyone else's system using whatever database they are using. Hard drives are read-write entities. You can change their contents.
> Now, where the perception comes in is that its right now very *easy* to change the contents. Double click the .mdb file. Even technical wizards at Metamor (or Ciber, or whatever) can figure that one out.
> It is possible to put a secret password on the .mdb file to prevent Metamor from opening it with Access. I've threatened to put a password on the .mdb before when dealers/customers/support have done stupid things with the GEMS database structure using Access. Being able to end-run the database has admittedly got people out of a bind though. Jane (I think it was Jane) did some fancy footwork on the .mdb file in Gaston recently. I know our dealers do it. King County is famous for it. That's why we've never put a password on the file before.
> Note however that even if we put a password on the file, it doesn't really prove much. Someone has to know the password, else how would GEMS open it. So this technically brings us back to square one: the audit log is modifiable by that person at least (read, me). Back to perception though, if you don't bring this up you might skate through Metamor.
> There might be some clever crypto techniques to make it even harder to change the log (for me, they guy with the password that is). We're talking big changes here though, and at the moment largely theoretical ones. I'd doubt that any of our competitors are that clever.
> By the way, all of this is why Texas gets its sh*t in a knot over the log printer. Log printers are not read-write, so you don't have the problem. Of course if I were Texas I would be more worried about modifications to our electronic ballots than to our electron logs, but that is another story I guess.
> Bottom line on Metamor is to find out what it is going to take to make them happy. You can try the old standard of the NT password gains access to the operating system, and that after that point all bets are off. You have to trust the person with the NT password at least. This is all about Florida, and we have had VTS certified in Florida under the status quo for nearly ten years.
> I sense a loosing battle here though. The changes to put a password on the .mdb file are not trivial and probably not even backward compatible, but we'll do it if that is what it is going to take.
> Ken

> > From: owner-support@gesn.com [mailto:owner-support@gesn.com]On Behalf Of Nel Finberg
> > Sent: Tuesday, October 16, 2001 11:32 PM
> > To: support
> > Subject: alteration of Audit Log in Access
> > Jennifer Price at Metamor (about to be Ciber) has indicated that she can access the GEMS Access database and alter the Audit log without entering a password. What is the position of our development staff on this issue? Can we justify this? Or should this be anathema?
> > Nel

- References:
  - RE: alteration of Audit Log in Access
    - From: "Ken Clark" <ken@gesn.com>

- Prev by Date: RE: TSText-1-18-5-2
- Next by Date: Correct Term - Flash Memory
- Index(es):
  - Chronological
  - Thread