File Trasnfer read only output

[Graham Moss]

We currently run the MANMAN MRP system and sue the above to generate an EFT BACS payment file in pain text. We need to be able to transfer the above file to a Windows PC in a read only format so that it cannot be changed from the time that is saved to the PC local hard drive

[Ian Miller.]

I think you will need some sort of checksum (e.g. md5) to ensure the file has not been changed. Any file format on the PC could be changed even if you set the protection.

[Robert Gezelter]

Graham,

If (and ONLY IF) the "Windows PC" is running Windows NT or a derivative (e.g., Windows 2000, Windows XP, Windows 2003, or Vista), then it is possible, but more care must be exercised than is common.

First, Ian's comment about running a cryptographic checksum (e.g., MD-5, SHA-1, or similar) is a good one. Maintaining a full copy of the file in a non-PC archive is also a requirement.

On the PC, the Administrator accounts must be secured and not used for non-Administrative access. The file must be downloaded using FTP from one account, and the protection attributes need to be set so that no one but the file owner can modify the file (or the directories leading to it).

Then the "normal" user must access the file from a different account, one that does not have the permissions to alter the file.

It is possible to "lock-down" a PC platform in this way, but many, if not most, environments do not bother.

I hope that the preceding is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

I might well be reading too much into this, but then most folks I've met that are running an EFT tend to be at least somewhat paranoid.

What or who are you protecting against?

How serious are the potential attacks?

What happens if the data gets changed; how is this (mis)information to be fed back into the system?

You can detect changes (using MD5), but viewable exporting data with security requirements -- with content protection -- is a difficult task, at best. This can include up to the level of difficulty that the ACS and AACS content protection systems are encountering.

I'd probably look to use a password-protected encrypted PDF here for the general case, but that's probably not going to operate all that well with whatever is planning to read this EFT BACS format.

I might well also look to transfer the file over using https transfer, possibly with an encrypted zip.

I'd probably reverse this, and determine the attacks, and what might be the appropriate storage on Windows, and see if I could figure out how to get there from OpenVMS. If it is straight ASCII text file with Windows file protections, for instance... Or if a read-only PDF or content-protection is required, etc...

And if you're looking for help securing a data file on a Windows system, you're probably not in the best available forum.

[Doug Phillips]

Rather than transfer the EFT file to a PC, we always place the file in a shared VMS directory (folder.) Using access restrictions, no PC user can change the file and the only user allowed access to the share (other than the administrator) is the responsible person who uploads or transmits the file.

Since the EFT file probably has a standard format requirement, adding any embedded checksum data might not be feasible (depending on the format, you might have a user-defined field available in a header or trailer record) and adding an embedded checksum or even a secondary checksum file won't help unless all of the programs use it.

[Phil.Howell]

Had the auditors in again?
About the only method that cannot be subverted is to burn to cd
Phil

[Willem Grooters]

Have you considered converting the file into a read-only format like recent PDF versions?
IIRC, we've done that on OpenVMS but I cannot recall the tooling. Otherwise, you could think of a program to receive the file and do teh conversion.

[Doug Phillips]

EFT files usually have a format specified by some standard; I'm familiar with ACH, but there are others. The format is dictated by whatever intermediary is receiving and processing the file. Because the file's subject is the transfer of money, and the intermediary is usually a bank, the format is understandably very strict. Most that I know of require ASCII text.

[Doug Phillips]

The format is dictated by whatever intermediary is receiving and processing the file, in this case BACS. I'm more familiar with ACH requirements but I suspect they're similar because they communicate with the same organizations.

Because the file's subject is the transfer of money, and the communication is usually routed to a bank, the format is understandably very strict. Most that I know of use ASCII text.

[Doug Phillips]

Darn ITRC. The first post hung and didn't show up so I tried again. Please ignore the first post.

[Ian Miller.]

formats like PDF are not read only if you use a binary file editor :-)

A sha1 checksum and/or write once media are needed.

[Doug Phillips]

Even a read-only file (or anything that can be displayed on a PC's screen) can be copied, changed and sent instead of the original.

It really comes down to making sure only trusted persons can access the file at all, and implementing procedures that insure that trust is maintained.

Religiously monitoring your bank-account balance, and/or using a special bank account for EFT's are common methods.

[Ian Miller.]

formats like PDF are not read only if you use the right editor :-)

A sha1 checksum and/or write once media are needed.