Re: i5/OS Encryption

[Al Mac <macwheel99@xxxxxxxxxxx>]

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