About the
(ISC)² Blog

  • (ISC)² believes in the importance of open dialogue and collaboration, between both (ISC)², its certified members and members of business and society.

    (ISC)² established this blog to provide a voice to its certified members, who have significant knowledge and valuable insights to share that can benefit the information security industry, the people in it and the public at large.

    The postings on this site are the author's own and don't necessarily represent
    (ISC)²'s positions, strategies or opinions. (ISC)² does not control, monitor, or endorse any links provided in this blog and makes no warranty or statement regarding the content on any linked website.

    Those who post comments to blogs should ensure their comments are focused on the topic at hand. (ISC)² reserves the right to remove any post or comment from this site.

    Should you find objectionable content in this blog, please notify us as soon as possible at blog@isc2.org.

    Please click here for FAQs.

    Please click here for the Blog guidelines.

« Security in process automation systems | Main | Computer: 0, Toaster: 1 »

07 December 2007

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54f109b67883400e54f9a6f708833

Listed below are links to weblogs that reference Playing “Hide and Seek” with Obsolete Data :

Comments

Hi Harry.

Working as an IT auditor reviewing software development projects, I've often been through the arguments about using (hopefully a copy of) real live data for testing. The developers typically argue that real data is the ultimate testbed. I usually argue that real data is too valuable and often too sensitive, and normally lacks all the test cases that are needed. I believe that, to obfuscate real data or create realistic test cases, the architects and developers need to truly understand the data structures, and getting to that level of knowledge is in itself a valuable part of the process, but usually the project managers veto such ideas saying it's too expensive :-(

I've upped the ante a few times by insisting that if the developers/testers are going to use real data, then the entire development and testing environment must be secured to the same degree as the primary database system, complete with tight access control and personal accountability through individual accounts and traceability/auditability, which obviously goes against the grain for most development teams.

I'd be interested, though, to find examples of situations where development or test environments containing real data have been hacked. That would lend weight to my cause in persuading management.

Kind regards,
Gary

The comments to this entry are closed.

Recent Contributors

Past Contributors