System iNetwork

Dan,

I couldn't agree with you more. I was a programmer for over 15 years and I can't tell you how much personal data I had access to. I never personally abused that privledge, but, now that I think about it, I probably threw several boxes of "test print outs" in the garbage can that had WAY too much personal data on it!

In the interest of full disclosure, I now work for SoftLanding Systems and we do sell a product that can help ease the test data retrieval and scrambling requirements.

I can also tell you that it has been our personal experience that the laws are increasing in number, as are the penalties for breaking them and the auditors who are aware of them.

Joe.

Hi, if you accept that a succesful test is one that reveals an as yet undiscovered fault (and not one that gets to eoj without crashing) then live data generally isn't good enough as it is too clean. Creating test files is not something you should do as an afterthought but as an integral part of the development, in parallel with the programme coding so you know what you are testing and how and why. Of course when the project starts slipping we all know what gets cut first....

Dan . . .
As a programmer/analyst w/over 20 years experience, I'd have to say that I agree with you 95%. The only part I would disagree on is the "I am not a fan of encrypting data in our on-line production data files". If there are sensitive data elements, then those data elements should have the data encrypted. & only decrypted by the application program that is going to display it. What happens if the backup tapes get lost by the carrier? If we encrypt that data at the "source", any copy we make of it would then be encrypted. I'd sleep a lot better at night knowing my SSN is encrypted everywhere it is stored.

Concur with Dan & Joe.

It is a rare thing when programmers are locked out of being able to see real data like SSNs, DOBs, full names, etc. Hopefully that is changing, for real, with HIPAA and SOX. I work for a privately-held company that has decided it is not subject to SOX requirements, but takes a very responsible position on personal data.

I tell family and friends that the data breaches they hear in the news lately are really only news because of the volume of identities involved. I tell them that I've been in the business for over 20 years, and there's hardly ever been an environment I've worked in where I would have been unable to extract sensitive information. Thank goodness every programmer I've ever worked with has the honesty and ethics of Mother Teresa.

Eh, that last comment was supposed to have been followed by (/sarcastic comment) using greater-than & less-than signs instead of parens shown here, but the blogger musta stripped them.

Regarding Ian's comments....

-live data generally isn't good enough as it is too clean.
I agree insomuch as you need "bad" data as well to drive all of your exception routines (which, after all, make up 80% of your code, right?). However, if you aren't going to pull the data from live, that means you have to build it from scratch, and that ain't fun.

-Creating test files is not something you should do as an afterthought but as an integral part of the development, in parallel with the programme coding so you know what you are testing and how and why.
Very true! But few, if any, programmer has either the time or the knowledge to successfully do this EACH and EVERY time. It really must be intelligently automated. The other down side of programmers building their own test data is that you spend an inordinate amount of time testing the data instead of testing your program, e.g. you create data scenarios that would never exist in real life and in messes up your program.

I agree with Jim Staub. Our system contains employee SSN's and customer credit card numbers. We now encrypt both of these, so anyone accessing the test or production or training (or ...) data base via any way other than the application programs can't see the real information.

hmm. five years ago when I was in Lincare, I was made to do all these things. I mean removing SSN as a customer key and replacing it with customer number etc. I even put a discussion thread on the RPG forum. JACHO compliance, CHAPS compliance, HIPPA compliances, privacy law compliance. Boy! those days were full of compliances.

I thought this issue was settled long ago but apparently people are still working on it.

The main characteristic of stud earrings is the appearance of floating on the ear or earlobe without a visible fashion point of connection. Studs are invariably constructed on the end of a post, jewelry which penetrates straight through the ear. NY jewelry The post is held in place by a removable friction back or clutch. Nata's Jewels! Occasionally, the stud earring is constructed so that the post is threaded, wedding jewelry allowing a screw back to securely hold the earring in place. This is useful in preventing the loss of expensive earrings jewelry ontaining precious stones or made of precious metals custom rings http://websearch.cnn.com/websearch/search?query=gold+custom+rings