|
More and more in my consulting travels, I come across "AS/400-iSeries-i5-System i" (covering all my bases per a previous thread... ;-) shops that have i5/OS data-at-rest encryption requirements. This is not an area of expertise for me or our company, so I typically tell them to look at the cryptographic capabilities that are native to the OS or, if they don't have in-house development support, tell them that they can check out the various iSeries vendors for solutions.
My question to all of you bona fide programmers is: How much of an issue is it (or would it be) for your shop to have to modify an existing DB2 table due to column expansion required by an encryption enhancement?
IBM says "Depending on the encryption algorithm used to encrypt the data, the length of an existing column might not have to be increased." You would probably limit the number of encrypted DB columns to only the most sensitive fields (think PCI-DSS) and, by doing so, also minimize the hit taken due to performance and sorting restrictions when using encryption.
Would you seek out and try to incorporate the IBM algorithm that does not increase column size to save work and reduce the "pain" of reaching compliance? Or is it not that big of a deal when dealing with so few fields? Would column expansion matter when buying off-the-shelf?
Best regards,
Steven W. Martinson, CISSP, CISM
Sheshunoff Management Services, LP.
Senior Consultant - Technology & Risk Management
2801 Via Fortuna, Suite 600 | Austin, TX 78746
Direct: 281.758.2429 | Mobile: 512.779.2630
e.Mail: smartinson@xxxxxxxxx
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.