Topic: 2011 NA
Subtopic: DB2 for z/OS
DATE: 2011-5-4 (09:45 AM - 10:45 AM)
SPEAKERS: Robert Andresen (CA )
In my years of visiting my DB2 clients I am astonished by how many build their test databases by merely copying production data over to the test system. While this will guarantee extremely good test data, it's a horrible practice in many instances. If your production data includes Social Security Numbers, Drivers License numbers or Credit Card Numbers you expose your customers to identity theft and fraud. Other categories of production data may raise Sarbanes-Oxley or HIPAA issues. Your companies spend a great deal of effort and expense to secure production data. Copying it to test is not only lazy, it can be dangerous. Companies have been sued, some have gone out of business because of these kinds of problems. You may be at risk of lawsuits, loss of employment and possibly prison time if you are deemed responsible for this kind security breech.My presentation will look at the problems of building test databases that are accurate enough to exercise all the program logic as if it were working in production, without the exposures of using actual production data. We'll cover:Identifying data that needs to be secureStrategies for extracting/scrambling/randomizing real dataWe'll look at decoding credit card numbers, drivers license numbers and Social security numbers to understand how much of each field can be scrambled and what needs to match other data fields. There are commercial software products available to help in this effort, we'll discuss some of the types available, e.g. data generators and database extractors, but the main thrust will be how to build a safe testing environment whether commercial software or home-grown utilities are used.
EXP. LEVEL: Beginner,Intermediate,Advanced
Understand why using production data in test is dangerous
Learn several strategies for creating valid test data that is not a security risk
Understand various coding schemes for credit cards, drivers licenses, social security numbers, etc.
Understand the need to plan for the necessary level of test data correlation based on the actions that testing will need to do. e.g. are credit card numbers merely treated as numeric fields, or do the numbers need to be valid Visa, Amex or other cards.
Understand your potential culpability in the even of unautherized access or use of production data
Click Here to Download
NOTE: These are only open to members of IDUG. If you are not a member, please CLICK HERE for more information.