Re: i5/OS Encryption

Probably not all fields need this protection, just social security #, bank account data ... depends on nature of business and what geography they doing business in ...and there's also the security angle of who all in the company should have access to those fields, and when you doing testing, you want to populate the fields in the test data with something consistent with those fields layouts but not real person data.

There is also access to the decryption algorithm, as used by whatever software.
My understanding is that in the TJX breach, the data was encrypted, but the hackers got access to the decryption algorithm, rendering the encryption protection worthless.

According to one of the IBM security manuals, when people connect by Client Access, if their PC remembers the password, when it is transmitted to 400/i whatever host, it is communicated encrypted, but if they key it in at sign on time, that transmission is not encrypted. My interest was in communication over non-IBM connections such as Cisco or Wireless, and general availability of co-worker PCs (like laptops in transit) to unauthorized persons. I may have misread the manual.

I have witnessed security where characters are altered in-place.
For example, any given character in Hexadecimal is represented by two standard characters like say E-7 and they in turn are represented by a string of binary values. One algorighm flips bits such that any E is replaced by an A, and other such combination replacements, so you end up with a string of characters that are intelligible but scrambled. That kind of approach will not alter the number of characters that is the size of the field.

I have also witnessed a system like that which had a bug in it. Fixing that was non-trivial.

Backup rotation policy may need rethinking. I have heard that if backup media ever gets corrupted, and encryption is involved, the data cannot be recovered.

I have also seen where some fields are labeled for a particular purpose, but people have keyed into them some other content. So there coult be data content that needs to be protected, but you would not know it from the field naming. There would need to be analysis of content according to patterns that would indicate that what's in there is not consistent with field labeling.

Steven

Just an uninformed set of thoughts here - heh!

There is the matter of which logical files are based on the files - recompile
There is the matter of which programs use the files - recompile
There is the matter of what those programs do with the columns in
question - change code and recompile

One thing I don't know - have not done much with encryption - is -
does the system automagically decrypt it for use in programs? I
suspect not, but I don't know.

HTH
Vern

you wrote:

>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