<html>
<body>
This is doable.<br><br>
There can also be the need to have more than one test environment for
different kinds of testing. During a conversion, I was recreating a
new test environment every 3-4 days so the Pilot Team could test which
problems had been fixed in the conversion process, and what new problems
to find.<br><br>
Since live data can be very volatile, it is often necessary to recopy
live to test to reflect latest conditions, or to rebuild to reflect
updated diversity of content. After doing that, run some software
to repopulate private and sensitive columns of the test data with
believable but untrue people. While getting this, impose extra
security blackout on access to the test environment, to avoid risk of a
breach before second step completed.<br><br>
For purposes of recovery from disruptions, some systems capture images of
changes, so that files can be recovered to some check pointed
condition. In some OS this is at the file table level irrespective
of how the files were accessed, imposed by business rules in the
files. You might check whether your clients have this capability,
if it can be turned on or off.<br><br>
In the test rebuild, you want to secure or destroy this record after
completing the fictionalization of the private and sensitive
data.<br><br>
In the live environment, this tool can be used to identify who all has
been accessing private and sensitive data to do what with it, such
as<br>
* <font color="#FF0000"><b>mass downloads</b></font> using telecommuting
or server to laptop<br>
* employees when vs. responsibilities of those employees ... are these
the people who should be accessing that data?<br>
* data accessed via front door or<font color="#FF0000"><b> back
door</b></font> (do I need to explain that concept that was mentioned in
the movie WARGAMES? Back doors are a lot more common than
non-developers might realize)<br><br>
In my computing reality, the technical name for this stuff is "audit
journals."<br>
In the business rules for a file or its contents, we can designate that
we want what changes to be tracked. There are also add on packages
to make it manager-friendly to navigate what gets accumulated.<br><br>
From what I have seen in the programmer technique discussion lists that
I am in, I would estimate 99.99% of my peers are using real private and
sensitive data in test environments.<br><br>
Pete wrote:<br>
<blockquote type=cite class=cite cite="">We discussed recently the matter
of real data in a test environment <br>
with a client. Frequently, when conducting an internal penetration <br>
test, we find copies of real data on development machines unprotected
<br>
by passwords or encryption. Rather than try to insist that developers
<br>
protect this real data properly, which is never going to happen, we <br>
suggested the following: (1) replace all name fields with alpha <br>
garbage (of the correct field lengths) so as to depersonalise the <br>
data (2) randomly swap fields such as city, zip code, credit card <br>
number etc. so that any given row of data is useless to a thief but <br>
still valid per range checks etc.<br><br>
Any views on this idea?<br><br>
Pete</blockquote></body>
</html>