Scrubbing sensitive data in dumps

[Holst, Jeffrey A]

A year or two ago I attended a webinar that was discussing (selling) a product that would scrub sensitive information (generally PII) from dumps (SVC dumps, SYSMDUMPs and the like) prior to sending these to a software vendor.

I told my management about it, and there was no interest, so I didn't retain any information on it.

Fast forward to today. My manager calls me up and asks if I know of any products that can scrub sensitive information from dumps. My response was that I had attended a webinar on one. I was asked what the product was and who the vendor might be, and I could not recall and I didn't have anything saved.

Does anyone know of such a product? I know there is one out there but I haven't figured out a search argument to locate it yet.

Jeffrey Holst
Infrastructure Configuration Consultant
Technology and Operations, Shared Services

PNC Bank
Columbus Whitehall Service Center 2
4653 E Main St
Columbus, OH 43213
(614) 856-5443
jeffre...@pnc.com




The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to read it. If you think you received it in error, please notify the sender. Do not forward or copy without permission of the sender. This message may be considered a commercial electronic message under Canadian law or this message may contain an advertisement of a product or service and thus may constitute a commercial electronic mail message under US law. You may unsubscribe at any time from receiving commercial electronic messages from PNC at http://pages.e.pnc.com/globalunsub/
PNC, 249 Fifth Avenue, Pittsburgh, PA 15222; pnc.com




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Skeldum, William]

There was a patent filed by IBM on Locating and altering sensitive information in core dumps.
http://www.google.com.pg/patents/US20080126301
Bill Skeldum

The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.

[Jim Mulder]

I found the patent filing to be an amusing read, at least with respect
to
the z/OS specific stuff. There is no SS type of dump record. And if you
wanted
to process a dump, you certainly wouldn't do it by reading the raw dump
records
(as that wouldn't work very well for data which crosses a 4k boundary (and
thus crosses a dump record boundary). You would do it by writing an IPCS
VERBEXIT program, or a Rexx exec, which uses IPCS services to access the
dump, and prepare the lists of storage ranges for modification and/or
modification
avoidance. The ranges would then be input to an IPCS function which would
use
the IPCS storage map to translate the address ranges into ranges within
dump
records. And then that would be the input into a program which does the
copying
with modifications.

We did have a meeting in z/OS development quite a few years ago to
discuss
someone's wish for this type of function for z/OS dumps. We concluded
that
in general, identifying the sensitive data to be modified would be so
problematic
that it was not worth pursuing.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> wrote on
08/11/2017 04:23:17 PM:

> From: "Skeldum, William" <William...@EFIRSTBANK.COM>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/11/2017 04:53 PM
> Subject: Re: Scrubbing sensitive data in dumps
> Sent by: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU>
>
> There was a patent filed by IBM on Locating and altering sensitive
> information in core dumps.
> http://www.google.com.pg/patents/US20080126301
> Bill Skeldum

[Thomas Loges]

Here is a link to the description of a product for log and dump
anonymization called SF-SafeDump:

http://www.fedtke.com/exchange/SF_SafeDump_for_zos.pdf

Thomas Loges
ITERGO Germany

[Jim Mulder]

To correct myself, there is a type SS record. I almost never see
them.
There are also type A, SC, SD, and SC records which could contain
sensitive data.

[Tony Harminc]

On 11 August 2017 at 16:23, Skeldum, William

<William...@efirstbank.com> wrote:
> There was a patent filed by IBM on Locating and altering sensitive information in core dumps.
> http://www.google.com.pg/patents/US20080126301

Whatever its technical merits, that IBM patent is remarkable in that
at least six of the seven inventors appear by their names to be women.
(The name Chunhui could be male, I'm told, but there is a female IBMer
Chunhui Yang who has contributed to some Redbooks, so all seven are a
good bet.) This is surely both rare and encouraging for a patent in an
area like this in these controversial times for women in the software
business.

Tony H.

[Rob Schramm]

Something like Xbridge data sniff?

Rob Schramm

--

Rob Schramm

[Paul Gilmartin]

On Fri, 11 Aug 2017 17:09:10 -0400, Jim Mulder wrote:
>
> We did have a meeting in z/OS development quite a few years ago to discuss
>someone's wish for this type of function for z/OS dumps. We concluded that
>in general, identifying the sensitive data to be modified would be so problematic
>that it was not worth pursuing.
>

This is reminiscent of a question posed (here?) (years?) ago concerning
detecting credit card numbers in data sets, with the objective of
obfuscating them.

OK. Any 16 numeric digits, or packed, or 64-bit binary in range, or ...
Validate check digit?

Same answer.

Or SSNs.

-- gil

[Charles Mills]

My understanding is that the XBridge product was successful at this technically. CA has a new product in this area that is successful technically. (By "technically" I mean that the technology is successful in recognizing credit card numbers, SSNs, and so forth. There is more pattern to a credit card number than just "16 numeric digits.")

These products address files and datasets, but the same pattern recognition would apply to dumps.

The problem as I see it -- after taking several sessions at SHARE on data privacy -- is that the definition of "personal information" is endlessly elastic. Read "What constitutes personal data?" on http://www.eugdpr.org/gdpr-faqs.html.

And by the way, if you are in the US and think that the GDPR is a Europe-only thing, read "Who does the GDPR affect?" and "What are the penalties for non-compliance?" on the same page. Also note the countdown clock on their home page!

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Friday, August 11, 2017 11:23 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Scrubbing sensitive data in dumps

On Fri, 11 Aug 2017 17:09:10 -0400, Jim Mulder wrote:
>
> We did have a meeting in z/OS development quite a few years ago to
>discuss someone's wish for this type of function for z/OS dumps. We
>concluded that in general, identifying the sensitive data to be
>modified would be so problematic that it was not worth pursuing.
>
This is reminiscent of a question posed (here?) (years?) ago concerning detecting credit card numbers in data sets, with the objective of obfuscating them.

OK. Any 16 numeric digits, or packed, or 64-bit binary in range, or ...
Validate check digit?

Same answer.

Or SSNs.

[ITschak Mugzach]

few years ago `i wrote a program to mask business data from dumps. it
masked Hebrew text, zone decimal numbers (if the are larger then 3 chars)
and some Luhn baed numbers by replacing them with dots on both sides of a
printed dump. I don't have access to the code now, but it is quit simple
and base on clients secrets (the way they generate key numbers like brunch
number, account, etc.).

Itschak

--
ITschak Mugzach
*|** IronSphere Platform* *|** Automatic ISCM** (Information Security
Contiguous Monitoring) **| *

[Tony Thigpen]

Charles,

Even if the regulation says:

"Non-Eu businesses processing the data of EU citizens will also have to
appoint a representative in the EU."

What legal recourse does the EU have to go after a US company that does
not "appoint a representative in the EU"?

I think the trick here is that should a company "appoint a
representative in the EU" thinking that it's something simple to appease
the EU, then they have a business presence in the UA. Once they have "a
representative in the EU", then the EU has a legal entity to go after
for non-compliance.

The company I work for has determined that under no circumstance will we
"appoint a representative in the EU". And, if the EU attempts legal
action, our defense is that EU do not apply to a US business that only
does work in the US. Just because a EU citizen chooses to use our
services while in the US, that does not constitute a EU business
presence. (No matter what the GDPR is trying to claim.)

Take a simple example. A EU person stays at a Florida based Bed &
Breakfast. And, the guest supplies his address and phone number. The
GDPR 'claims' that the GDPR now applies. But, such a claim violates the
the sovereignty of the USA. And, since the Bed & Breakfast does not have
a presence in the EU, that sovereignty protects it.

In other words, the GDPR can claim to reach into other countries, but
legally, it can not. It's just trying to scare people into compliance.

Tony Thigpen

[Charles Mills]

@Tony, thanks for starting a new thread. I was about to do so, realizing I had hijacked a perfectly good dump-scrubbing thread.

There was a lot of "how are they going to enforce it on us?" at the SHARE sessions. My reply was "if you have deep pockets, I'm sure there is a team of lawyers that would be happy to help you be a test case." I'm not a lawyer, but my daughter is (albeit not an international justice lawyer) and might have some experience in this area. I am with her next week and will ask her.

The borderline examples are myriad. Here was mine. You are a bank. A customer checks off US citizen on the account form and gives a US address. But she also is an EU National and has an EU residence. You would have no way of knowing that.

And pity the poor Brits! Brexit comes *after* the effective date of GDPR, so they have to make all the preparations for a law that will soon not affect them.

There was discussion about how you would erase every trace of someone's existence if you have DB2 volume backup tapes buried deep in Iron Mountain. And what if the lawyers were also telling you "you can't erase that -- we have an open discovery action going on that"?

I thought the most interesting observation came from two different companies that said "we have to implement this -- so we might just as well do it for all of our customers."

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen
Sent: Saturday, August 12, 2017 12:21 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

Charles,

Even if the regulation says:

"Non-Eu businesses processing the data of EU citizens will also have to appoint a representative in the EU."

What legal recourse does the EU have to go after a US company that does not "appoint a representative in the EU"?

I think the trick here is that should a company "appoint a representative in the EU" thinking that it's something simple to appease the EU, then they have a business presence in the UA. Once they have "a representative in the EU", then the EU has a legal entity to go after for non-compliance.

The company I work for has determined that under no circumstance will we "appoint a representative in the EU". And, if the EU attempts legal action, our defense is that EU do not apply to a US business that only does work in the US. Just because a EU citizen chooses to use our services while in the US, that does not constitute a EU business presence. (No matter what the GDPR is trying to claim.)

Take a simple example. A EU person stays at a Florida based Bed & Breakfast. And, the guest supplies his address and phone number. The GDPR 'claims' that the GDPR now applies. But, such a claim violates the the sovereignty of the USA. And, since the Bed & Breakfast does not have a presence in the EU, that sovereignty protects it.

In other words, the GDPR can claim to reach into other countries, but legally, it can not. It's just trying to scare people into compliance.

[Edward Gould]

> On Aug 12, 2017, at 4:05 PM, Charles Mills <char...@MCN.ORG> wrote:
>
> @Tony, thanks for starting a new thread. I was about to do so, realizing I had hijacked a perfectly good dump-scrubbing thread.
>
> There was a lot of "how are they going to enforce it on us?" at the SHARE sessions. My reply was "if you have deep pockets, I'm sure there is a team of lawyers that would be happy to help you be a test case." I'm not a lawyer, but my daughter is (albeit not an international justice lawyer) and might have some experience in this area. I am with her next week and will ask her.
>
> The borderline examples are myriad. Here was mine. You are a bank. A customer checks off US citizen on the account form and gives a US address. But she also is an EU National and has an EU residence. You would have no way of knowing that.
>
> And pity the poor Brits! Brexit comes *after* the effective date of GDPR, so they have to make all the preparations for a law that will soon not affect them.
>
> There was discussion about how you would erase every trace of someone's existence if you have DB2 volume backup tapes buried deep in Iron Mountain. And what if the lawyers were also telling you "you can't erase that -- we have an open discovery action going on that"?
>
> I thought the most interesting observation came from two different companies that said "we have to implement this -- so we might just as well do it for all of our customers."
>
> Charles

Charles:
This per se is not about dump scrubbing, but it does have to do with dumps.
In the 1980’s I had a job interview with an unnamed part of the government.
To say the least they handled a lot of Top Secret data.
I asked how they handled the dumps with IBM. Their answer was they didn’t. I asked, How do you send dumps to IBM. Their answer was that you didn’t.
All problem determination was done on the spot. I then asked what about IBM source? You can’t debug (very much) by looking at just instructions.
Their answer was (the best I can remember) was something like this, “the problem is not fixed”, I asked incredulously and you can work like this?
Their answer was “yes”.
Now, since then I have found out that at other secret installations, they have IBM people that have the right clearences that can talk on secure likes to other IBMers to resolve these types of issues.
Apparently this installation did not do this.
I turned down the job mainly because of that and I didn’t like living out in the desert.
Ed

[Charles Mills]

Mmm, a reverse hijack.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Edward Gould
Sent: Saturday, August 12, 2017 6:09 PM
To: IBM-...@LISTSERV.UA.EDU

[Timothy Sipples]

Tony Thigpen wrote:
>In other words, the GDPR can claim to reach into other countries, but
>legally, it can not.

*Legally*, of course they can. GDPR is a set of European Union regulations.
They say what they say.

It's a separate question whether, when, and how the European Union and its
member countries enforce GDPR. For your hypothetical bed and breakfast in
Florida there's probably not much the European Union can immediately do if
there's a GDPR violation. However, the B&B's proprietors might want to
avoid visiting the EU. :-)

Practically every country demands that other countries (and the entities
within them) treat its citizens according to certain minimum standards.
GDPR will soon become part of the minimum standards that EU countries
demand.

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sip...@sg.ibm.com

[Jim Mulder]

As someone who spends a considerable amount of time reading dumps,
I have some requirements for anyone who uses a product like this on a dump
and then sends the dump to IBM.

1. You must inform IBM that the dump you are sending has been modified.

2. You must supply a list of all of the modified or deleted storage
ranges.
This could be a report produced by the product. Or,
the product could append SC (COMPDATA) records to the dump,
which contain descriptions of the storage ranges which have been
omitted or modified. The 8 character component identifier for these

records would be something which starts with a 3 character prefix
that
IBM has assigned to the vendor.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

> From: Thomas Loges <Thoma...@ALICE-DSL.DE>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/13/2017 11:11 PM
> Subject: Re: Scrubbing sensitive data in dumps

> Sent by: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU>
>

> Here is a link to the description of a product for log and dump
> anonymization called SF-SafeDump:
>
> http://www.fedtke.com/exchange/SF_SafeDump_for_zos.pdf
>

[Charles Mills]

Having consulted with an attorney who will remain nameless, states cooperate
in enforcing each other's laws. If you murdered an EU citizen and returned
home, the US would assist the EU authorities in prosecuting you.

If you store anything resembling personal data and if there is any chance
that that data could be associated with an EU national then I think business
prudence demands that you assume GDPR applies to your company.

Don't shoot the messenger. I'm not defending the law. I'm just calling it as
I see it.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: Sunday, August 13, 2017 4:40 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

Tony Thigpen wrote:
>In other words, the GDPR can claim to reach into other countries, but
>legally, it can not.

*Legally*, of course they can. GDPR is a set of European Union regulations.
They say what they say.

It's a separate question whether, when, and how the European Union and its
member countries enforce GDPR. For your hypothetical bed and breakfast in
Florida there's probably not much the European Union can immediately do if
there's a GDPR violation. However, the B&B's proprietors might want to avoid
visiting the EU. :-)

Practically every country demands that other countries (and the entities
within them) treat its citizens according to certain minimum standards.
GDPR will soon become part of the minimum standards that EU countries
demand.

[Ron Hawkins]

Then tell me why my overseas banks contacting me to provide details under FBAR.

What's good for the goose...

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Saturday, August 12, 2017 2:06 PM
To: IBM-...@LISTSERV.UA.EDU

[Charles Mills]

For exactly the same reason. US law effectively applies to non-US banks, just like EU law effectively applies to US banks.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Ron Hawkins
Sent: Monday, August 14, 2017 12:30 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

Then tell me why my overseas banks contacting me to provide details under FBAR.

What's good for the goose...

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Saturday, August 12, 2017 2:06 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] GDPR for US companies (Was: Scrubbing sensitive data in dumps)

@Tony, thanks for starting a new thread. I was about to do so, realizing I had hijacked a perfectly good dump-scrubbing thread.

There was a lot of "how are they going to enforce it on us?" at the SHARE sessions. My reply was "if you have deep pockets, I'm sure there is a team of lawyers that would be happy to help you be a test case." I'm not a lawyer, but my daughter is (albeit not an international justice lawyer) and might have some experience in this area. I am with her next week and will ask her.

[R.S.]

W dniu 2017-08-14 o 18:29, Ron Hawkins pisze:

> Then tell me why my overseas banks contacting me to provide details under FBAR.
>
> What's good for the goose...

Yes, my bank also contacted me in regard of FBAR (or other US
regulation). Neither me nor the bank has businesses in US.

--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kon...@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.

[Joel C. Ewing]

Right! Just because a sequence of bytes "could" represent a legitimate
SSN doesn't mean it is a SSN. Murphy's law guarantees that scrubbing
anything that could be interpreted as a SSN will eventually also scrub
some combination of adjacent numeric values, character strings, address
pointers or pieces of instructions, possibly essential to understanding
the problem, that just coincidentally resembles a valid SSN but isn't.
May be a low probability, but it will surely happen. If you try to
recognize and sanitize additional types of values that are less
structured, like names and addresses, the odds of false findings of
sensitive data must increase. Color me "skeptical" that any automatic
process to sanitize all sensitive data won't leave collateral damage --
it will either fail to be complete or potentially sanitize things that
should be left alone.

Whoever is tasked with interpreting a modified dump is entitled to know
the extent to which it was altered, precisely because there will always
be room for doubt whether any dump sanitizer could function with 100%
accuracy.
JC Ewing

On 08/13/2017 10:28 PM, Jim Mulder wrote:
> As someone who spends a considerable amount of time reading dumps,
> I have some requirements for anyone who uses a product like this on a dump
> and then sends the dump to IBM.
>
> 1. You must inform IBM that the dump you are sending has been modified.
>
> 2. You must supply a list of all of the modified or deleted storage
> ranges.
> This could be a report produced by the product. Or,
> the product could append SC (COMPDATA) records to the dump,
> which contain descriptions of the storage ranges which have been
> omitted or modified. The 8 character component identifier for these
>
> records would be something which starts with a 3 character prefix
> that
> IBM has assigned to the vendor.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
> Poughkeepsie NY
>
>
>> From: Thomas Loges <Thoma...@ALICE-DSL.DE>
>> To: IBM-...@LISTSERV.UA.EDU
>> Date: 08/13/2017 11:11 PM
>> Subject: Re: Scrubbing sensitive data in dumps
>> Sent by: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU>
>>

>> Here is a link to the description of a product for log and dump
>> anonymization called SF-SafeDump:
>>
>> http://www.fedtke.com/exchange/SF_SafeDump_for_zos.pdf
>>

> ...


--
Joel C. Ewing, Bentonville, AR jce...@acm.org