Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Make old Aloha data PCI compliant 2

Status
Not open for further replies.

hoagiemcgee

Technical User
Dec 7, 2006
9
US
Any tips on cleaning card data from older Aloha files? Regrinding data still leaves behind some plain text card numbers in translog.

I'm hoping for something more elegant than my plan of a search-and-replace with text editor.
 
We are currently developing some technology to help do just what you are asking. Our first version of this solution will be for Windows based applications and terminals (work stations). Where are you located? We may be able to help.

Steve Sommers
-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:
 
Aloha has a utility that was designed to do this. Your dealer should have this. It's called deltrack.exe.

Adam
 
I'm sorry, I misread the question. I thought you were asking if it was possible to make an older version compliant without upgrading or buying new. This is the technology we're working on.

In rereading the question, it appears you have upgraded to a compliant version and simply want to sanitize the prior data and log files. The upgrade process should have either done this for you or provided you with the documentation and/or utility to do the sanitation – this is a PABP requirement. As Adam stated, ask your dealer.

Sorry again, ignore my original post.


Steve Sommers
-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:
 
According to the vendor, Deltrack only works to sanitize .stl (settle) files. They ran it multiple times, but it left many .stl files unchanged. Finally, we just deleted them.

They also say that "regrinding the data" is what updates the trans.log files (which also contain card data). After regrinding, the version of the trans.log files are shown as upgraded. Most of the files are now encrypted, but some still have plain text card data. Regrinding again does nothing, since it reads as being the latest version and makes no further changes.

The vendor's solution is to "delete all but the last 6 mos data," but that is not an acceptable solution.
 
In order to read the trans.log information you would need a dealer only HASP key with the Log Utilities program. You cannot see what's in the trans.log with notepad. How are you seeing the card data?

Encrypting the STL files should be enough because that is the only place that the card numbers were vulnerable. The trans.log is already encrypted.

Adam
 
I can read my trans.log files (at least the ones created by aloha version5) with Textpad. Not the entire file, but I can see card numbers and expiration dates.

Translogs created with version 5.3.26 are completely encrypted and unreadable when I try the same Textpad method.

I was also told that stl files are not needed after running the day's batch and could be deleted. I hope that's true.
 
I personally wouldn't delete the stl files. They're handy just incase you need to look up some numbers in the future. Doesn't hurt anything to delete them.

I hadn't heard that older versions showed the card numbers in the trans.log. I wonder if a fixlog would work on this.

Adam
 
Is this fixlog tool something I can get my hands on? Or is it some sort of vendor-only program?
 
Honestly, I think your best bet is too burn the data on to a CD or DVD and purge it from the Aloha directory. That way, if you need it, you can always copy it over to see it at your leisure.

I cant comment on whether a fixlog would work for that, I thought it's only function was to remove errant data/corruption from the log files. I have my doubts as to whether this would work.

In this case, the path of least resistance might be the way to go.
 
Btw, the PCI rules go a lot deeper than just credit card numbers. It covers passwords conventions,physical and remote access to your file server, etc. It seems as though the banks goal is to make the specifications as broad as possible, so they can pass the buck where they see fit.
 
Yes. We found out about the PCI rules the hard way. Even our vendor isn't aware of all the rules.

 
I guess the moral of the story is to make sure you have strong passwords for your computer, strong firewall in place, lock the door to your office whenever you leave, and only give access to CC numbers to ppl that you would trust with your life.

I personally think that if someone really wants to screw you over and get CC numbers from your business and use them, there are things to stop them or make it very difficult. But if a thief is very motivated, there is only so much you can do.

If a thief knew how to look into a trans.log and get the numbers from them I would be very surprised!!
 
RE: If a thief knew how to look into a trans.log and get the numbers from them I would be very surprised!!

SURPRISE! Two things. First, the thieves you are talking about have some intelligence and most have no difficulties doing a Google search and finding info like this thread, so now they do know. Second, there are intelligent credit card scanners, very similar to virus scanners, available at various sources on the web that can find all files on your hard drive containing unencrypted card information. Even if they bypass the Google search, these programs will find the information in these files. Most PCI auditing companies will run this or a similar scan on your hard drives to validate compliance. Speak no evil, hear no evil, see no evil is not security and everyone should be concerned.

Basically, PABP compliance and the associated certification exist to "certify that the application conforms to, and will not prevent a merchant from being PCI compliant." The issue as described would prevent a merchant from being PCI compliant. Keep nagging your dealer or the vendor -- this issue requires resolution for any vendor to claim PABP compliance.


Steve Sommers
-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:
 
Wouldn't this take someone breaking into your office? Yes I know that they might be able to break into you system via the internet. If you have a strong firewall system and a strong password scheme, then it would be very difficult to "hack" in.

Yes, I agree that the upgrade should encrypt the old data in the trans.log. I haven't had a chance to verify this claim, but Aloha does have a very strong compliancy certification. So I'm not sure what to think about this other than if it's true then why did they certify Radiant and Aloha so strongly?

 
I'm not sure by the term "very strong compliancy certification", at present there is only one PABP certification, either certified or not certified.

As to why, marketing benefit and the writing on the wall is that eventually, VISA and MasterCard, through it's indirect lines via member banks, processors, gateways and eventually the merchants will require all applications to be PABP compliant. Right now it is more of a "strongly suggested" program and the degree of enforcement is, for the most part, up to the individual merchant bank.

As to how this got through a certification audit, auditing standards are still being ironed out. Right now, different auditors will catch or not catch different issues. I can tell you for a fact that either of the two auditing companies that we use would have caught this particular issue. We were just a participant in a security round table with VISA & MasterCard and standardizing the audits was a topic and it is being addressed. I can almost guarantee you that when a recertification takes place (they happen annually), this issue will be caught and at a minimum, vendors will need to provide detailed documentation and/or utilities to sanitize preexisting data.
 
Does anyone know where I am able to get a list of the PCI regulations? I called my credit card merchant company and the rep just seemed to be confused...

Thanks!
 
A simple text search can find unencrypted card numbers, if they exist. You don't have to know anything about aloha, file names/types, etc.

I will provide more details when I can.
 
This is such a grey area. I've given up. I'll let the PCI a-holes and the software companies figure out. When the merchant services people that I talk to don't even know what CISP or PCI is, I get a pain in my head from the frustration!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top