There are breach stories associated with print-outs thrown in the garbage,
where the print-outs contain sensitive information.
We do not live in a paperless office. Everyone needs a printer ...
everyone does screen prints, everyone gets reports, some people get their
output in the form of some file extracted from the 400 data, going into say
an XL or other format. There would need to be a programming standard that
any report, any screen, that is showing sensitive data, that has been
converted from encrypted form for the benefit of the user, states in a
standard location that it contains that sensitive data, like on page
headers we now put date time who name of report page # etc. well also add
some phrase like "top secret" or "shred when done with" and combine this
with inter-company personnel rules for the handling and storage of any such
report containing such sensitive data.
Whatever standard the company comes up with, there needs to be vigorous
auditing to make sure the new policies are being adhered to, and exceptions
authorized by top managers are appropriately documented.
You might start with the payroll system as a model.
Does the HR clerk have access to a paper shredder?
What goes into his or her waste paper basket unshredded?
How can he/she tell difference between confidential and non-confidential data?
Are file cabinets, that contain confidential material, properly marked so
that when that office gets closed, the contents do not end up in dumpster,
without first going through a shredder?
Company personnel habitually send to contacts in other companies a myriad
of copies of our internal reports, because they contain info we want to
give to the other companies. This practice needs a review, since now some
of that data is sensitive and should not be shared without some kind of
contract in place for the new reciipent of the data to protect it as
carefully as the original possessor supposed to.
>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
midrange.com
