× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Steven and Eric,

Thanks for your responses. I am the security officer, and query writer, as
well as having several other hats. That means that I would probably have
the keys needed to run the query.

Everything with a borrower address or SSN get shredded when it is no longer
needed as a matter of policy. Old tape saves as well. I don't think
printouts with SSNs are much of an issue at our company.

Our software package and database design were done by a sister company, and
we deal with Social Security numbers (SSN) and some bank information. The
design was done 20 to 25 years ago, for the most part (I was here then!),
and not much has changed.

I am trying to get a feel for what it would take to get those fields
encrypted, and it looks like a big rewrite of a lot of the system. The
student loan industry used SSNs for a very long time to identify student
borrowers. We are regulated by the department of Education, and they are a
Federal entity. The SSN still gets passed around a lot, but in password
protected files, and encrypted FTP and such. The entire database is mainly
keyed on the SSN. We are trying to get away from the SSN as much as
possible, but the Dept of Ed still requires it, as do the guarantee
agencies. We have instituted an account number, so mailings no longer
contain private information.

This is some good starter information for me, as I examine the possible
paths going forward.

Thanks again!

Jim

On 6/11/07, smorrison@xxxxxxxxxxxxxxxxxxx <smorrison@xxxxxxxxxxxxxxxxxxx>
wrote:

>The boss wants a simple list sorted by encrypted
>field with specific other requirements. This
>happens a lot at here in the office, and I was
>wondering how query or SQL access to those
>encrypted fields is impacted.

I'm starting to work with the encryption functions, and the first thing I
wonder about is if the data is sensitive enough to encrypt, do you really
want to print it on a bunch of reports? Will you be logging who runs the
reports, and ensure that all of those reports are properly destroyed?

While you can key a file on an encrypted field, there would be no way to
predict the order of keys in that file. For instance the encrypted value
of account 567 may place it before the encrypted value of account 123.


Steven Morrison
Fidelity Express
903-885-1283 ext. 479



"Jim Essinger" <dilbernator@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/11/2007 02:58 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: i5/OS Encryption






Just a question from one that has not looked into encryption at all,

What is the impact of queries run over files with encrypted data? If the
encrypted field is a part of the key to access the records in the file,
what's the impact there? The boss wants a simple list sorted by encrypted
field with specific other requirements. This happens a lot at here in the
office, and I was wondering how query or SQL access to those encrypted
fields is impacted.

Thanks!

Jim

On 6/10/07, R Bruce Hoffman <bruce.hoffman@xxxxxxxxxxxxxxxxx> wrote:
>
> As a practical matter, I can't think of a column, offhand, that would
> qualify for encryption, that would not need to be expanded. SSN, devoid
> of punctuation, under 3DES would require 32 characters for encryption.
> In traditional i5/OS, DDS described files, very few people (if any) ever
> defined a 9 digit SSN as a 32 character varying for bit data field. Even
> if they stored it as character with punctuation, it's 11 characters.
> Even with the original RC2 encryption, 11 becomes 19, and then becomes
> 24. (8 byte boundaries are used after the "additional" space is
> allocated.)
>
> So, I would consider the statement about not increasing the length of a
> field to be naive at best, and misleading.
>
> The first step in using in place encryption, would most likely be to
> isolate yourself from physical changes in the database. As long as you
> are tied to the physical layout, recompiles are inevitable. This could
> mean changing away from native I/O to SQL, or careful reconstruction of
> your database, oriented towards turning off level checks followed by
> appending the encrypted fields and then altering the programs that need
> to access the encrypted data.
>
> Encryption of the data in the database is not a quick add-on. It
> requires careful planning including, but not limited to, how to handle
> the encryption passwords.
>
>
> Steve Martinson 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
> >
> >
> >
> >
>

____________________________________________________________________________________
> > Looking for a deal? Find great prices on flights and hotels with
Yahoo!
> FareChase.
> > http://farechase.yahoo.com/
> >
>
> --
> "Suppose you were an idiot...
> And suppose you were a member of Congress...
> But I repeat myself."
> - Mark Twain
>
> ===========================================================
> R Bruce Hoffman



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.