Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.databases.filemaker > #2242 > unrolled thread

How to prevent a developer from tampering with the log

Started byclkaufmann@gmx.ch (Christoph Kaufmann)
First post2015-04-30 09:49 +0200
Last post2015-04-30 09:07 -0700
Articles 12 — 6 participants

Back to article view | Back to comp.databases.filemaker


Contents

  How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 09:49 +0200
    Re: How to prevent a developer from tampering with the log Ursus <ursus.kirk@ziggo.nl> - 2015-04-30 10:04 +0200
      Re: How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 10:54 +0200
        Re: How to prevent a developer from tampering with the log Martin Τrautmann <t-usenet@gmx.net> - 2015-04-30 09:22 +0000
          Re: How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 19:59 +0200
          Re: How to prevent a developer from tampering with the log Helpful Harry <HelpfulHarry@BusyWorking.com> - 2015-05-01 09:12 +1200
        Re: How to prevent a developer from tampering with the log Ursus <ursus.kirk@ziggo.nl> - 2015-04-30 11:36 +0200
          Re: How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 19:59 +0200
            Re: How to prevent a developer from tampering with the log ursus <ursus.kirk@gmail.com> - 2015-04-30 21:16 +0200
            Re: How to prevent a developer from tampering with the log Martin Τrautmann <t-usenet@gmx.net> - 2015-04-30 20:19 +0000
            Re: How to prevent a developer from tampering with the log Helpful Harry <HelpfulHarry@BusyWorking.com> - 2015-05-01 09:17 +1200
    Re: How to prevent a developer from tampering with the log Howard Schlossberg <howard@nospam.fmprosolutions.com> - 2015-04-30 09:07 -0700

#2242 — How to prevent a developer from tampering with the log

Fromclkaufmann@gmx.ch (Christoph Kaufmann)
Date2015-04-30 09:49 +0200
SubjectHow to prevent a developer from tampering with the log
Message-ID<1m3oqe3.130zxj910odzpeN%clkaufmann@gmx.ch>
FMP 11/FMS 11 on Win 7: Users create entries in a list an write into
fields.

Problem: the solution and its output are only accepted if there is no
way for the company to alter entries without trace, i.e. change
creation/modification timestamps etc.

While there a tools like ultralog, auto-enter, prohibit entries by
users, they all depend on restricted access.

Here's the catch: The solution is created and maintained by an in house
developer.

Imagine this conversation:

Company: the log shows that we saw this/did that on...

Business partner: your admin could have changed the timestamps and the
text fields, in fact, he could have created this record 30 minutes ago.

Compnay: No he couldn't have because [insert solution to this problem
here]

I assume I could write logs into csv files or something, that'll give a
file on the hard drive with a creation date etc. But is this file info
safe?

-- 
Christoph Kaufmann
http://clk.ch

[toc] | [next] | [standalone]


#2243

FromUrsus <ursus.kirk@ziggo.nl>
Date2015-04-30 10:04 +0200
Message-ID<c1789$5541e206$52d9780b$48789@news.ziggo.nl>
In reply to#2242
Christoph Kaufmann schreef op 30-4-2015 om 09:49:
> FMP 11/FMS 11 on Win 7: Users create entries in a list an write into
> fields.
>
> Problem: the solution and its output are only accepted if there is no
> way for the company to alter entries without trace, i.e. change
> creation/modification timestamps etc.
>
> While there a tools like ultralog, auto-enter, prohibit entries by
> users, they all depend on restricted access.
>
> Here's the catch: The solution is created and maintained by an in house
> developer.
>
> Imagine this conversation:
>
> Company: the log shows that we saw this/did that on...
>
> Business partner: your admin could have changed the timestamps and the
> text fields, in fact, he could have created this record 30 minutes ago.
>
> Compnay: No he couldn't have because [insert solution to this problem
> here]
>
> I assume I could write logs into csv files or something, that'll give a
> file on the hard drive with a creation date etc. But is this file info
> safe?
>
If there is no trust between company and developer they shouldn't have 
hired him/her in the first place. Why would a developer change a records 
timestamp? Other then for fraudulent uses?

No log system, however carefully constructed is a 100% safe. If a 
log-file resides on a certain computer, you only need access to that 
computer. A developer might need that access. If this is really an issue 
then you could let the solution send an e-mail to the company after 
every change. Or buy an encryption-plug in that garbles the log. But I 
probably would doubt my position as a developer and look elsewhere for a 
job.

keep well, Ursus

[toc] | [prev] | [next] | [standalone]


#2244

Fromclkaufmann@gmx.ch (Christoph Kaufmann)
Date2015-04-30 10:54 +0200
Message-ID<1m3ot4f.vsa6rg1pb16gwN%clkaufmann@gmx.ch>
In reply to#2243
Ursus <ursus.kirk@ziggo.nl> wrote:

> If there is no trust between company and developer

The company and the developer are on the same side; the developer is an
employee. That's exactly the problem. The company is a hospital that
provides nursing. Insurances pay the nursing and check the
documentation.

> Why would a developer change a records 
> timestamp? Other then for fraudulent uses?

Because some insurance person made an appointment to check the
documentation. Chief nurse rushes to the developer and says: we did a
lot of nursing nobody documented because there was no time and a flu
epidemy, could we please put in the missing records with the date and
time of our work, not the ones of record creation? That's not lying
after all, but the insurance guy gets the wrong impression and the
hospital is about to lose a lot of money.

We don't need to discuss what kind of developer would be tempted or get
instructed to do this. As long as this is technically possible, the
insurance must and will not accept the documentation and all the work
will count as undocumented, i.e. not done.

A third party product makes sure the client can't change the timestamp.
I need a tool for the same feature in my in house Filemaker solution.

> If a 
> log-file resides on a certain computer, you only need access to that 
> computer. A developer might need that access.

That's interesting - we're using a data center, they could move the log
files to some sort of trust center.

> If this is really an issue 

It is. It's about money :-)

> Or buy an encryption-plug in that garbles the log.

Plugin is in place. How would a check look like?

-- 
Christoph Kaufmann
http://clk.ch

[toc] | [prev] | [next] | [standalone]


#2245

FromMartin Τrautmann <t-usenet@gmx.net>
Date2015-04-30 09:22 +0000
Message-ID<slrnmk3t21.1gs8.t-usenet@ID-685.user.individual.de>
In reply to#2244
On Thu, 30 Apr 2015 10:54:21 +0200, Christoph Kaufmann wrote:
>  A third party product makes sure the client can't change the timestamp.
>  I need a tool for the same feature in my in house Filemaker solution.

You can't do that in FMP.

Of course you might prevent data entry via layouts and record options. 
But all of this can be bypassed by someone with admin privileges.

You could use an external tool which does prevent manipulation via data
entry - such as simple text files with timestamp of data entry and
checksum calculation.

You can import those values to FMP and do the processing as required
within FMP.

- Martin

[toc] | [prev] | [next] | [standalone]


#2264

Fromclkaufmann@gmx.ch (Christoph Kaufmann)
Date2015-04-30 19:59 +0200
Message-ID<1m3pj3i.1hyo77c10392okN%clkaufmann@gmx.ch>
In reply to#2245
Martin ?rautmann <t-usenet@gmx.net> wrote:

> You could use an external tool which does prevent manipulation via data
> entry - such as simple text files with timestamp of data entry and
> checksum calculation.

We'd have to make sure the text wasn't created later in the process.

What about the Filemaker backup file? It's file info says when it was
created.

-- 
Christoph Kaufmann
http://clk.ch

[toc] | [prev] | [next] | [standalone]


#2268

FromHelpful Harry <HelpfulHarry@BusyWorking.com>
Date2015-05-01 09:12 +1200
Message-ID<010520150912058370%HelpfulHarry@BusyWorking.com>
In reply to#2245
In article <slrnmk3t21.1gs8.t-usenet@ID-685.user.individual.de>, Martin
?rautmann <t-usenet@gmx.net> wrote:

> On Thu, 30 Apr 2015 10:54:21 +0200, Christoph Kaufmann wrote:
> >  A third party product makes sure the client can't change the timestamp.
> >  I need a tool for the same feature in my in house Filemaker solution.
> 
> You can't do that in FMP.
[snip]

I doubt you can do it in anything. The developer is the one making the
system, so, by necessity, they always have access to everything.

Helpful Harry   :o)

[toc] | [prev] | [next] | [standalone]


#2246

FromUrsus <ursus.kirk@ziggo.nl>
Date2015-04-30 11:36 +0200
Message-ID<11259$5541f7a4$52d9780b$36548@news.ziggo.nl>
In reply to#2244
Christoph Kaufmann schreef op 30-4-2015 om 10:54:
> Ursus <ursus.kirk@ziggo.nl> wrote:
>
>> If there is no trust between company and developer
>
> The company and the developer are on the same side; the developer is an
> employee. That's exactly the problem. The company is a hospital that
> provides nursing. Insurances pay the nursing and check the
> documentation.
>
>> Why would a developer change a records
>> timestamp? Other then for fraudulent uses?
>
> Because some insurance person made an appointment to check the
> documentation. Chief nurse rushes to the developer and says: we did a
> lot of nursing nobody documented because there was no time and a flu
> epidemy, could we please put in the missing records with the date and
> time of our work, not the ones of record creation? That's not lying
> after all, but the insurance guy gets the wrong impression and the
> hospital is about to lose a lot of money.
>
> We don't need to discuss what kind of developer would be tempted or get
> instructed to do this. As long as this is technically possible, the
> insurance must and will not accept the documentation and all the work
> will count as undocumented, i.e. not done.
>
> A third party product makes sure the client can't change the timestamp.
> I need a tool for the same feature in my in house Filemaker solution.
>
>> If a
>> log-file resides on a certain computer, you only need access to that
>> computer. A developer might need that access.
>
> That's interesting - we're using a data center, they could move the log
> files to some sort of trust center.
>
>> If this is really an issue
>
> It is. It's about money :-)
>
>> Or buy an encryption-plug in that garbles the log.
>
> Plugin is in place. How would a check look like?
>
OK I see where you are going now. Ofcourse you need to save a log NOT in 
the same folder as the filemaker files. Even better not even on the same 
computer. Set up an encrypted partition on a different server. Create an 
email account on that, such that filemaker can send an email to the 
server where the logfile gets encryted and stored. Developer doesn't 
need access to that, so he doesn't need any password. His supervisor 
would be the one with access. AND create a double check on an offline 
account (Cloud-service) Evernote isn't too expensive and can be set up 
easily by the supervisor. Supervisor would be the only one accessing. 
Evernote creates an email address and it could very easily be done such 
that filemaker sends a copy to evernote. Using the hashtag system mails 
also get classified into groups if needed.

Then I would create one line of MD5 code for the whole record for every 
committed change within the filemaker file, based on timestamp and 
contents. Store the MD5 within the filemaker file AND within both logs. 
MD5 is harder to read, but also very hard to crack.

This would ofcourse create an enormous amount of data, even with one 
line for every change. And the supervisor would need to verify the 
filemaker data against the log files, which is an enormous amount of 
work. But could be done by a very simple filemaker application importing 
a newly created MD5 for the file and from the log, then comparing them. 
The generated MD5 from filemaker should equal the last stored within the 
log.


Also be aware that, if dedicated to the task, any system can be cracked.

Ursus

[toc] | [prev] | [next] | [standalone]


#2265

Fromclkaufmann@gmx.ch (Christoph Kaufmann)
Date2015-04-30 19:59 +0200
Message-ID<1m3pjb3.1xg9ghk1stto8wN%clkaufmann@gmx.ch>
In reply to#2246
Ursus <ursus.kirk@ziggo.nl> wrote:

> Of course you need to save a log NOT in 
> the same folder as the filemaker files. Even better not even on the same
> computer.

Thanks for the details, I understand the process now. We'd have to move
the log files out of our own company's reach.

Question: if I click on any file on a disk and press Cmd-I
(File/Properties on Windows), I get a created/modified info from the OS
- can this be manipulated, too?

-- 
Christoph Kaufmann
http://clk.ch

[toc] | [prev] | [next] | [standalone]


#2266

Fromursus <ursus.kirk@gmail.com>
Date2015-04-30 21:16 +0200
Message-ID<mhtuvr$4vr$1@dont-email.me>
In reply to#2265
Christoph Kaufmann schreef op 30-4-2015 om 19:59:
> Ursus <ursus.kirk@ziggo.nl> wrote:
>
>> Of course you need to save a log NOT in
>> the same folder as the filemaker files. Even better not even on the same
>> computer.
>
> Thanks for the details, I understand the process now. We'd have to move
> the log files out of our own company's reach.
>
> Question: if I click on any file on a disk and press Cmd-I
> (File/Properties on Windows), I get a created/modified info from the OS
> - can this be manipulated, too?
>
You could change it, if really set to it, if needed you could include 
MD5 of timestamp at closure of the file. But this would be difficult and 
the moment the file is opened this would be reset to current date and time.
Altering creation or modification stamps of a file would serve no 
purpose. The contents of a file governs its validity, not its timestamp. 
A false timestamp could also prove an error within system setup. Or a 
glitch in time-management. It wouldn't prove any wrong doing.

-- 
Keep well, Ursus

[toc] | [prev] | [next] | [standalone]


#2267

FromMartin Τrautmann <t-usenet@gmx.net>
Date2015-04-30 20:19 +0000
Message-ID<slrnmk53ig.1gs8.t-usenet@ID-685.user.individual.de>
In reply to#2265
On Thu, 30 Apr 2015 19:59:36 +0200, Christoph Kaufmann wrote:
>  Question: if I click on any file on a disk and press Cmd-I
>  (File/Properties on Windows), I get a created/modified info from the OS
>  - can this be manipulated, too?

yes

[toc] | [prev] | [next] | [standalone]


#2269

FromHelpful Harry <HelpfulHarry@BusyWorking.com>
Date2015-05-01 09:17 +1200
Message-ID<010520150917197253%HelpfulHarry@BusyWorking.com>
In reply to#2265
In article <1m3pjb3.1xg9ghk1stto8wN%clkaufmann@gmx.ch>, Christoph
Kaufmann <clkaufmann@gmx.ch> wrote:
> Ursus <ursus.kirk@ziggo.nl> wrote:
> > 
> > Of course you need to save a log NOT in 
> > the same folder as the filemaker files. Even better not even on the same
> > computer.
> 
> Thanks for the details, I understand the process now. We'd have to move
> the log files out of our own company's reach.
> 
> Question: if I click on any file on a disk and press Cmd-I
> (File/Properties on Windows), I get a created/modified info from the OS
> - can this be manipulated, too?

Easy. Change the computer's system date before the file is created /
modified.

If it is a log file, then it will have probably have dates in it, so
the dates would be in an incorrect order ... except someone can easily
modify the log file.

Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]


#2263

FromHoward Schlossberg <howard@nospam.fmprosolutions.com>
Date2015-04-30 09:07 -0700
Message-ID<mhtjuq$khu$2@news.motzarella.org>
In reply to#2242
On 4/30/2015 12:49 AM, Christoph Kaufmann wrote:
> FMP 11/FMS 11 on Win 7: Users create entries in a list an write into
> fields.
>
> Business partner: your admin could have changed the timestamps and the
> text fields, in fact, he could have created this record 30 minutes ago.


As others have said, nothing is going to be 100% defensible if you have 
people administering the system who might have some conflict of interest 
(real or imagined) with one of the parties.

My suggestion would be to say to those questioning it: you can set up 
your own SQL database with your own administrators on your own servers, 
give us privileges to INSERT but not UPDATE (i.e. add records but not 
edit existing records) and then we will set up FileMaker to write to 
your SQL log each time something is changed or added on our end.

Given that, even if your FM admin temporarily turns off the SQL logging 
component to "fake" some FM data, the other party still has a log of 
what the data originally was.

Howard

[toc] | [prev] | [standalone]


Back to top | Article view | comp.databases.filemaker


csiph-web