Re: "Breach" (fka Would encryption have prevented known major breaches?)

[Paul Gilmartin]

On Mon, 18 Sep 2017 16:48:29 -0700, Phil Smith wrote:
>
>If we assume that "encrypted" means "using accepted strong encryption", not 
>"Bob's toy encryption system that any moron could break", then I'm perfectly 
>comfortable with the several billion years of effort required to decrypt the 
>data-I'll be dead by then. You don't find that to be long enough?
> 
Live long and prosper.

Beware the march of technology:
https://en.wikipedia.org/wiki/The_Magic_Words_are_Squeamish_Ossifrage

The decryption of the 1977 ciphertext involved the factoring of a 129-digit 
number, RSA-129, in order to recover the plaintext.

Ron Rivest estimated in 1977 that factoring a 125-digit semiprime would require 
40 quadrillion years, using the best algorithm known and the fastest computers 
of the day.
...
It was solved in 1993–94 by a large joint computer project co-ordinated by 
Derek Atkins, Michael Graff, Arjen Lenstra and Paul Leyland. More than 600 
volunteers contributed CPU time from about 1,600 machines (two of which were 
fax machines) over six months. The coordination was done via the Internet and 
was one of the first such projects.
...
In 2015, the same RSA-129 number was factored in about one day, with the 
CADO-NFS open source implementation of number field sieve, using a commercial 
cloud computing service for about $30.

-- gil

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

Re: "Breach" (fka Would encryption have prevented known major breaches?)

[Phil Smith]

Beverly Caldwell wrote:
>"Would encryption have prevented known major breaches?" Actually, no, I
>think it would have made the effects worse. If Equifax had encrypted their
>data, right now those clowns would be slapping each other on the back and
>telling themselves, nothing to worry about, no need to report this to
>anyone, eh boys? So the effects would have not been apparent for however
>long it took the people who got the data to decrypt it.

If we assume that "encrypted" means "using accepted strong encryption", not 
"Bob's toy encryption system that any moron could break", then I'm perfectly 
comfortable with the several billion years of effort required to decrypt the 
data-I'll be dead by then. You don't find that to be long enough?

...phsiii

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

Re: "Breach" (fka Would encryption have prevented known major breaches?)

[Beverly Caldwell]

"Would encryption have prevented known major breaches?" Actually, no, I
think it would have made the effects worse. If Equifax had encrypted their
data, right now those clowns would be slapping each other on the back and
telling themselves, nothing to worry about, no need to report this to
anyone, eh boys? So the effects would have not been apparent for however
long it took the people who got the data to decrypt it.

On Fri, Sep 15, 2017 at 7:05 AM, Peter Relson <rel...@us.ibm.com> wrote:

> 
> In my view, your definition is not what most people mean with the word
> "breach."
> 
>
> And in my view my definition is exactly what is meant by breach. A breach
> is unintended entrance. And that is exactly what the dictionary reference
> says.
>
> The consequences of that unintended entrance are not relevant to whether
> or not there was a breach.
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Would encryption have prevented known major breaches?

[Beverly Caldwell]

I encrypt my SSN by making up a new one every time some ahole asks for it.

On Sun, Sep 17, 2017 at 5:38 PM, Phil Smith  wrote:

> Jack J. Woehr wrote:
> >Okay, I have the answer to the Equifax question.
> >I obtained the answer by the simple act of freezing my records on all
> three services:
> >Experian and Transunion: Had to jump through many verification hoops,
> answer trick questions.
> >Equifax: One simple basic info screen and I'm the owner of my account
> freeze.
> >Reveals everything we need to know about the breach, don't you think?
>
> Ouch. True, but you missed Innovis-the fourth, soon (I expect) to be one
> of the Big Three.
>
> A kinder interpretation is that EFX decided that they'd pissed people off
> enough already, and should make it easy to freeze-they also stopped
> charging for it even in states like mine where they're allowed to do so.
> Innovis also doesn't charge, but I expect that's because they're relatively
> small, can't afford to irritate people. Not saying that EFX deserves this
> interpretation, just sayin' that it's possible.
>
> ...phsiii
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Would encryption have prevented known major breaches?

[Phil Smith]

Jack J. Woehr wrote:
>Okay, I have the answer to the Equifax question.
>I obtained the answer by the simple act of freezing my records on all three 
>services:
>Experian and Transunion: Had to jump through many verification hoops, answer 
>trick questions.
>Equifax: One simple basic info screen and I'm the owner of my account freeze.
>Reveals everything we need to know about the breach, don't you think?

Ouch. True, but you missed Innovis-the fourth, soon (I expect) to be one of the 
Big Three.

A kinder interpretation is that EFX decided that they'd pissed people off 
enough already, and should make it easy to freeze-they also stopped charging 
for it even in states like mine where they're allowed to do so. Innovis also 
doesn't charge, but I expect that's because they're relatively small, can't 
afford to irritate people. Not saying that EFX deserves this interpretation, 
just sayin' that it's possible.

...phsiii

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

Re: Would encryption have prevented known major breaches?

[Jack J. Woehr]

Okay, I have the answer to the Equifax question.

I obtained the answer by the simple act of freezing my records on all three 
services:

Experian and Transunion: Had to jump through many verification hoops, answer 
trick questions.

Equifax: One simple basic info screen and I'm the owner of my account freeze.

Reveals everything we need to know about the breach, don't you think?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Would encryption have prevented known major breaches?

[Bill Wilkie]

John:


I worked in a shop where we did the same thing. The biggest problem we had was 
that we put labels on the disk in the center, and after a while the labels 
would fly off and they stuck between platters and screwed up the mechanism. But 
they were secure.  Even WE couldn't read them. At that same shop we used 3420 
POTTER tape drives with small tapes and large block sizes that SUCKED the tapes 
off the reels because you couldn't find an UNWRINKLED piece of tape to write a 
large block.


When I started out in operations, the Payroll guy would come into the computer 
room with his payroll tapes, guard them with his life while creating the 
payroll, then take all of the tapes and stand by the printer while the reports 
and checks were being cut. Nobody was allowed near him.  Then, as soon as he 
was done, he would take the old payroll master files, remove the external 
labels and put the tapes on the scratch pile and leave. Needles to say the 
operators and DEBE were busy for the rest of the day.


And speaking of DEBE, I worked at one place where we actually had to log the 
start and end computer meter time for each shift.  If you didn't log about 6 
hours, they thought you were goofing off and you got called in. Most of the 
time on third shift when you started at midnight, you were done by 1:00 AM 
because everything bombed, but when you didn't move the meter by about 6 hours, 
you got in trouble.  So... most of the operators would start DEBE which as 
you know just looped till you cancelled it. Those guys were told they did a 
GREAT job. I refused to do it and got called on the carpet because I only 
logged about 2 hours.  These companies had to spend MILLIONS and produced 
nothing. Ah ,,,the good old days.


I figured I could write jobs that abended just as well so I went into 
programming. I couldn't even SPELL programmer but now I are one! LOL!


Bill


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Friday, September 15, 2017 7:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would encryption have prevented known major breaches?


On Fri, Sep 15, 2017 at 2:36 PM, Bill Wilkie <billwil...@hotmail.com> wrote:

> What if your data was encrypted, you read it into a sort, put the sort
> output to a data set where it was NOT encrypted, and someone copied it? Or,
> they got it from sort work areas that were left on disk and not erased?
> Does that count?
>

I was told of a company, back in the 3330 days, where the accounting dept
had their own set of 3330 disk packs. All their data & their temporary data
sets were on these packs. When the "secure" accounting cycle was running,
a person from the department brought those pack down. The operators removed
the normal temporary storage disks, then mounted the accounting data & work
disks. When the cycle ended, the department person took the packs back to
the accounting dept and locked them up in a safe. Now that was fairly
secure. Oh, and the output was actually taken off the printer by the
accounting person. This was in OS/MVT days, and there was no TSO on that
system.



>
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Jesse 1 Robinson <jesse1.robin...@sce.com>
> Sent: Friday, September 15, 2017 7:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would encryption have prevented known major breaches?
>
> I have to keep harping on this. The looming EU regulation on hacking is a
> potentially huge legal liability. You cannot defend yourself in court by
> arguing that you hire the best people. You can defend yourself only by
> showing that the hacked data was encrypted.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of zMan
> Sent: Friday, September 15, 2017 12:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Would encryption have prevented known major
> breaches?
>
> Hiring competent people. That's so 20th-century. Get with the program, man!
>
> On Fri, Sep 15, 2017 at 8:51 AM, John McKown <john.archie.mck...@gmail.com
> >
> wrote:
>
> > On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
> > <t...@tombrennansoftware.com>
> > wrote:
> >
> > > John McKown wrote:
> > >
> > >> IMO, encrypting data is a very good defense. Another good defense
> > >> is hiring competent people rather than inexpensive people and
> > >> giving them
> >

Re: Would encryption have prevented known major breaches?

[Anne & Lynn Wheeler]

we were somewhat involved in (original) cal. data breach notification
act ... having been brought in to help wordsmith the electronic
signature act and several of the players were heavily involved in
privacy ... and had done in depth public surveys and #1 was fraudulent
financial transactions somewhat as the result of various kinds of
breaches (before notification each member of public thot it was isolated
incident affecting only them).  Problem was that little or nothing was
being done about the breaches and it was hoped that publicity from the
notifications might prompt corrective action. The issue is that entities
normally take security measures in self interest/protection. In the case
of breaches, it wasn't the institutions that are risk, but the
public. Since then there has been a dozen or so federal bills proposed
about evenly divided between those similar to the cal. state act and
those that effectively negate need for notification (in some cases,
specifying a combination of information compromised that would
essentially never occur).

We had aksi been brought in as consultants into small client/server
startup that wanted to do payment transactions on their server, they had
also invented this technology called "SSL" they wanted to use, the
result is now frequently called "electronic commerce". Somewhat for
having done "electronic commerce", we get brought in to the X9A10
financial standard working group that had been given the requirement to
preserve the integrity of finanical infrastructure for *ALL* retail
payments. We did detailed end-to-end vulnerability and exploit studies
of various kinds of payments and eventually wrote a standard that
slightly changes the current paradigm ... and eliminates the ability of
crooks to use information from previous transactions, records and/or
account numbers to perform fraudulent transaction. As a result it is no
longer necessary to hide/encrypt such information ... either in transit
and/or at rest (somewhat negating the earlier work with SSL for
electronic commerce).

dual-use metaphor; transaction account number is used for business
processes and must be readily available for scores of business processes
and millions of locations around the planet. at the same time it is used
for authentication and therefor must *NEVER* be
divulged. The conflicting requirements has resulted in us observing that
even if the planet was buried under miles of information hiding
encryption, it still wouldn't stop information leakage

security proportional to risk metaphor; value of transaction information
to merchant is profit from the transaction ... possibly a couple of
dollars (and value to infrastructure operators a few cents) while the
value of the information to the crooks is the account balance and/or
credit limit. As a result, the crooks may be able to outspend attacking
the system by a factor of 100 times what the defenders can afford to
spend.

Part of the issue now is there are lot of stakeholders with vested
interest in the unchanged paradigm.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Would encryption have prevented known major breaches?

[Phil Smith]

Jesse Robinson wrote:
>I have to keep harping on this. The looming EU regulation on hacking is a 
>potentially huge legal liability. You cannot defend yourself in court by 
>arguing that you hire the best people. You can defend yourself only by showing 
>that the hacked data was encrypted.

Sure, and that IS worth repeating. GDPR is going to be a bus that hits a few 
folks before the even know it exists, I suspect.

I assume the point of "hire competent people" was "because they'll be smart 
enough not to use admin/admin for the management system logon". While 
"competent" doesn't necessarily imply doing the right thing all the time, using 
admin/admin definitely precludes the use of the term "competent", I submit!

...phsiii

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

Re: Would encryption have prevented known major breaches?

[Tony Harminc]

On 15 September 2017 at 15:37, John McKown  wrote:

> I think that more than encryption would need to be shown. I'm thinking
> that the algorithm must be "robust" (or whatever word the crypto people
> use). If not, then let's just use ROT13.

It's always best to use double ROT13 for defence in depth.

Tony H.

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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Fri, Sep 15, 2017 at 2:36 PM, Bill Wilkie <billwil...@hotmail.com> wrote:

> What if your data was encrypted, you read it into a sort, put the sort
> output to a data set where it was NOT encrypted, and someone copied it? Or,
> they got it from sort work areas that were left on disk and not erased?
> Does that count?
>

​I was told of a company, back in the 3330 days, where the accounting dept
had their own set of 3330 disk packs. All their data & their temporary data
sets were on these packs. When the "secure" accounting cycle was running​,
a person from the department brought those pack down. The operators removed
the normal temporary storage disks, then mounted the accounting data & work
disks. When the cycle ended, the department person took the packs back to
the accounting dept and locked them up in a safe. Now that was fairly
secure. Oh, and the output was actually taken off the printer by the
accounting person. This was in OS/MVT days, and there was no TSO on that
system.



>
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
> of Jesse 1 Robinson <jesse1.robin...@sce.com>
> Sent: Friday, September 15, 2017 7:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would encryption have prevented known major breaches?
>
> I have to keep harping on this. The looming EU regulation on hacking is a
> potentially huge legal liability. You cannot defend yourself in court by
> arguing that you hire the best people. You can defend yourself only by
> showing that the hacked data was encrypted.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of zMan
> Sent: Friday, September 15, 2017 12:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Would encryption have prevented known major
> breaches?
>
> Hiring competent people. That's so 20th-century. Get with the program, man!
>
> On Fri, Sep 15, 2017 at 8:51 AM, John McKown <john.archie.mck...@gmail.com
> >
> wrote:
>
> > On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
> > <t...@tombrennansoftware.com>
> > wrote:
> >
> > > John McKown wrote:
> > >
> > >> IMO, encrypting data is a very good defense. Another good defense
> > >> is hiring competent people rather than inexpensive people and
> > >> giving them
> > the
> > >> time to design, code, and test their solutions. I don't have
> > >> statistics, but many attacks are based on coding errors such as the
> > >> infamous "SQL Injection" attacks. On the almost hilarious attacks
> > >> which succeed
> > because
> > >> "whomever" didn't bother to configure the security on some piece of
> > >> equipment, and left the administrator credentials as "admin/admin".
> > >> Of course, the people & time requirements that I mentioned "cost too
> much"
> > >> and
> > >> "delay time to market". Today's world is based on think up
> > >> something in the morning, design over lunch, create before dinner,
> > >> ship the next morning.
> > >>
> > >
> > > Did you mention admin/admin because of this news report, or just
> > > coincidence?
> > >
> > > https://nam04.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.bbc.com%2Fnews%2Ftechnology-41257576&
> data=02%7C01%7Cbillwilkie%40hotmail.com%7C119fcd6b7a8a4006ca7d08d4fc6f
> 0771%7C84df9e7fe9f640afb435%7C1%7C0%
> 7C636411001169882688=NoMB%2BXNEHgLO6qX0aYduhy5TP4x0ANW4Q
> ugDNJVVHCc%3D=0
> >
> >
> > That was the reason. I just couldn't remember if it was Equifax or
> > something else in the news recently; and I was too lazy to double check.
> >
> > --
> > UNIX was not designed to stop you from doing stupid things, because
> > that would also stop you from doing clever things. -- Doug Gwyn
> >
> > Maranatha! <><
> > John McKown
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Fri, Sep 15, 2017 at 2:21 PM, Jesse 1 Robinson 
wrote:

> I have to keep harping on this. The looming EU regulation on hacking is a
> potentially huge legal liability. You cannot defend yourself in court by
> arguing that you hire the best people. You can defend yourself only by
> showing that the hacked data was encrypted.
>

​I think that more than encryption would need to be shown​. I'm thinking
that the algorithm must be "robust" (or whatever word the crypto people
use). If not, then let's just use ROT13. Oh, and you'd best be sure that
the passphrase, digital cert, etc is properly secured. It doesn't do any
good to encrypt a file and have the decryption key be easily found.


> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>

-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

Re: Would encryption have prevented known major breaches?

[Bill Wilkie]

What if your data was encrypted, you read it into a sort, put the sort output 
to a data set where it was NOT encrypted, and someone copied it? Or, they got 
it from sort work areas that were left on disk and not erased? Does that count?


Bill



From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
Sent: Friday, September 15, 2017 7:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would encryption have prevented known major breaches?

I have to keep harping on this. The looming EU regulation on hacking is a 
potentially huge legal liability. You cannot defend yourself in court by 
arguing that you hire the best people. You can defend yourself only by showing 
that the hacked data was encrypted.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Friday, September 15, 2017 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

Hiring competent people. That's so 20th-century. Get with the program, man!

On Fri, Sep 15, 2017 at 8:51 AM, John McKown <john.archie.mck...@gmail.com>
wrote:

> On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
> <t...@tombrennansoftware.com>
> wrote:
>
> > John McKown wrote:
> >
> >> IMO, encrypting data is a very good defense. Another good defense
> >> is hiring competent people rather than inexpensive people and
> >> giving them
> the
> >> time to design, code, and test their solutions. I don't have
> >> statistics, but many attacks are based on coding errors such as the
> >> infamous "SQL Injection" attacks. On the almost hilarious attacks
> >> which succeed
> because
> >> "whomever" didn't bother to configure the security on some piece of
> >> equipment, and left the administrator credentials as "admin/admin".
> >> Of course, the people & time requirements that I mentioned "cost too much"
> >> and
> >> "delay time to market". Today's world is based on think up
> >> something in the morning, design over lunch, create before dinner,
> >> ship the next morning.
> >>
> >
> > Did you mention admin/admin because of this news report, or just
> > coincidence?
> >
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.com%2Fnews%2Ftechnology-41257576=02%7C01%7Cbillwilkie%40hotmail.com%7C119fcd6b7a8a4006ca7d08d4fc6f0771%7C84df9e7fe9f640afb435%7C1%7C0%7C636411001169882688=NoMB%2BXNEHgLO6qX0aYduhy5TP4x0ANW4QugDNJVVHCc%3D=0
>
>
> That was the reason. I just couldn't remember if it was Equifax or
> something else in the news recently; and I was too lazy to double check.
>
> --
> UNIX was not designed to stop you from doing stupid things, because
> that would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown


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

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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Fri, Sep 15, 2017 at 2:15 PM, zMan  wrote:

> Hiring competent people. That's so 20th-century. Get with the program, man!
>
>
​Amusingly, from some of what I've read, one of the reasons for the COBOL
language was so that "lower trained" enlisted men (& women) could produce
quality code just using the English language ( versus Fortran et al). We
are _still_ coming up with languages for "the average person"
(inexperienced & inexpensive) to be able to write quality code which​ "just
works". Too bad the hardware people haven't come up with the DWIM opcode
yet.


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

Re: Would encryption have prevented known major breaches?

[Jesse 1 Robinson]

I have to keep harping on this. The looming EU regulation on hacking is a 
potentially huge legal liability. You cannot defend yourself in court by 
arguing that you hire the best people. You can defend yourself only by showing 
that the hacked data was encrypted. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Friday, September 15, 2017 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

Hiring competent people. That's so 20th-century. Get with the program, man!

On Fri, Sep 15, 2017 at 8:51 AM, John McKown <john.archie.mck...@gmail.com>
wrote:

> On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan 
> <t...@tombrennansoftware.com>
> wrote:
>
> > John McKown wrote:
> >
> >> ​IMO, encrypting data is a very good defense. Another good defense 
> >> is hiring competent people rather than inexpensive people and 
> >> giving them
> the
> >> time to design, code, and test their solutions. I don't have 
> >> statistics, but many attacks are based on coding errors such as the 
> >> infamous "SQL Injection" attacks. ​On the almost hilarious attacks 
> >> which succeed
> because
> >> "whomever" didn't bother to configure the security on some piece of 
> >> equipment, and left the administrator credentials as "admin/admin". 
> >> Of course, the people & time requirements that I mentioned "cost too much"
> >> and
> >> "delay time to market". Today's world is based on think up 
> >> something in the morning, design over lunch, create before dinner, 
> >> ship the next morning.
> >>
> >
> > Did you mention admin/admin because of this news report, or just 
> > coincidence?
> >
> > http://www.bbc.com/news/technology-41257576
>
>
> ​That was the reason. I just couldn't remember if it was Equifax or 
> something else in the news recently; and I was too lazy to double check.
>
> --
> UNIX was not designed to stop you from doing stupid things, because 
> that would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown


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

Re: Would encryption have prevented known major breaches?

[zMan]

Hiring competent people. That's so 20th-century. Get with the program, man!

On Fri, Sep 15, 2017 at 8:51 AM, John McKown 
wrote:

> On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan 
> wrote:
>
> > John McKown wrote:
> >
> >> ​IMO, encrypting data is a very good defense. Another good defense is
> >> hiring competent people rather than inexpensive people and giving them
> the
> >> time to design, code, and test their solutions. I don't have statistics,
> >> but many attacks are based on coding errors such as the infamous "SQL
> >> Injection" attacks. ​On the almost hilarious attacks which succeed
> because
> >> "whomever" didn't bother to configure the security on some piece of
> >> equipment, and left the administrator credentials as "admin/admin". Of
> >> course, the people & time requirements that I mentioned "cost too much"
> >> and
> >> "delay time to market". Today's world is based on think up something in
> >> the
> >> morning, design over lunch, create before dinner, ship the next morning.
> >>
> >
> > Did you mention admin/admin because of this news report, or just
> > coincidence?
> >
> > http://www.bbc.com/news/technology-41257576
>
>
> ​That was the reason. I just couldn't remember if it was Equifax or
> something else in the news recently; and I was too lazy to double check.
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: "Breach" (fka Would encryption have prevented known major breaches?)

[Peter Relson]

In my view, your definition is not what most people mean with the word
"breach."


And in my view my definition is exactly what is meant by breach. A breach 
is unintended entrance. And that is exactly what the dictionary reference 
says. 

The consequences of that unintended entrance are not relevant to whether 
or not there was a breach.

Peter Relson
z/OS Core Technology Design


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

Re: Would encryption have prevented known major breaches?

[Tom Brennan]

Phil Smith wrote:

All good questions, and obviously you pushed some of my favorite buttons! I'll 
stop now :)


Great notes Phil.  Thanks!

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

Re: Would encryption have prevented known major breaches?

[Tom Brennan]

John McKown wrote:

​IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them the
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed because
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.


Did you mention admin/admin because of this news report, or just 
coincidence?


http://www.bbc.com/news/technology-41257576

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

Re: Would encryption have prevented known major breaches?

[Phil Smith]

Curtis G. Pew wrote:
>When I gave a presentation about encryption to our programmers a few years 
>back, one thing I said was "Encryption never solves your problem. Instead, it 
>transforms your problem into a different problem, which may be easier to 
>solve." (I was thinking specifically about key management, but even that's not 
>the whole story.) The important point here is that just throwing encryption at 
>a security issue doesn't resolve it. Encryption is a valuable tool that 
>properly used can be a significant part of a security solution, but by itself 
>doesn't magically solve anything.

That's great-sums it up very nicely!

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

Re: Would encryption have prevented known major breaches?

[Pew, Curtis G]

On Sep 14, 2017, at 10:43 AM, John McKown  wrote:
> 
> IMO, encrypting data is a very good defense. Another good defense is
> hiring competent people rather than inexpensive people and giving them the
> time to design, code, and test their solutions. I don't have statistics,
> but many attacks are based on coding errors such as the infamous "SQL
> Injection" attacks. ​On the almost hilarious attacks which succeed because
> "whomever" didn't bother to configure the security on some piece of
> equipment, and left the administrator credentials as "admin/admin". Of
> course, the people & time requirements that I mentioned "cost too much" and
> "delay time to market". Today's world is based on think up something in the
> morning, design over lunch, create before dinner, ship the next morning.
> 

When I gave a presentation about encryption to our programmers a few years 
back, one thing I said was “Encryption never solves your problem. Instead, it 
transforms your problem into a different problem, which may be easier to 
solve.” (I was thinking specifically about key management, but even that’s not 
the whole story.) The important point here is that just throwing encryption at 
a security issue doesn’t resolve it. Encryption is a valuable tool that 
properly used can be a significant part of a security solution, but by itself 
doesn’t magically solve anything.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: Would encryption have prevented known major breaches?

[Mark Regan]

Just FYI...
Equifax hack preventable with patch
http://thehill.com/policy/cybersecurity/350616-equifax-hack-due-to-patchable-security-flaw

On Thu, Sep 14, 2017 at 11:44 AM John McKown 
wrote:

> On Thu, Sep 14, 2017 at 10:31 AM, Jesse 1 Robinson <
> jesse1.robin...@sce.com>
> wrote:
>
> > Thanks for the Draco education. ;-)
> >
> > One point I failed to mention is the question of why US companies should
> > be overwrought by an EU regulation. This is still in the 'opinion' stage,
> > but it was pointed out at SHARE that the data breach penalty is intended
> to
> > protect EU citizens--wherever they might reside. Surely Equifax holds
> data
> > on an untold number of EU citizens. That could make the company hugely
> > liable even though it's a US company. How this might shake out in court
> is
> > anybody's guess, but properly encrypting data is surely the best defense.
> >
>
> ​IMO, encrypting data is a very good defense. Another good defense is
> hiring competent people rather than inexpensive people and giving them the
> time to design, code, and test their solutions. I don't have statistics,
> but many attacks are based on coding errors such as the infamous "SQL
> Injection" attacks. ​On the almost hilarious attacks which succeed because
> "whomever" didn't bother to configure the security on some piece of
> equipment, and left the administrator credentials as "admin/admin". Of
> course, the people & time requirements that I mentioned "cost too much" and
> "delay time to market". Today's world is based on think up something in the
> morning, design over lunch, create before dinner, ship the next morning.
>
>
>
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 <(323)%20715-0595> Mobile
> > 626-543-6132 <(626)%20543-6132> Office ⇐=== NEW
> > robin...@sce.com
> >
> >
>
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Regards,

Mark T. Regan

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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Thu, Sep 14, 2017 at 10:31 AM, Jesse 1 Robinson 
wrote:

> Thanks for the Draco education. ;-)
>
> One point I failed to mention is the question of why US companies should
> be overwrought by an EU regulation. This is still in the 'opinion' stage,
> but it was pointed out at SHARE that the data breach penalty is intended to
> protect EU citizens--wherever they might reside. Surely Equifax holds data
> on an untold number of EU citizens. That could make the company hugely
> liable even though it's a US company. How this might shake out in court is
> anybody's guess, but properly encrypting data is surely the best defense.
>

​IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them the
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed because
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.



>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

Re: Would encryption have prevented known major breaches?

[Jesse 1 Robinson]

Thanks for the Draco education. ;-)

One point I failed to mention is the question of why US companies should be 
overwrought by an EU regulation. This is still in the 'opinion' stage, but it 
was pointed out at SHARE that the data breach penalty is intended to protect EU 
citizens--wherever they might reside. Surely Equifax holds data on an untold 
number of EU citizens. That could make the company hugely liable even though 
it's a US company. How this might shake out in court is anybody's guess, but 
properly encrypting data is surely the best defense.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Wednesday, September 13, 2017 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

Draco is the formal name of a constellation.
https://en.wikipedia.org/wiki/Draco_(constellation)
The laws Draco instituted included the death penalty for many crime.
And if a fire breathing dragon breaths on you, you are toast.

On Wed, Sep 13, 2017 at 12:43 PM, John McKown <john.archie.mck...@gmail.com> 
wrote:
> On Wed, Sep 13, 2017 at 12:39 PM, Mike Schwab 
> <mike.a.sch...@gmail.com>
> wrote:
>
>> https://en.wikipedia.org/wiki/Draconian
>>
>> https://en.wikipedia.org/wiki/Draco_(lawgiver)
>> Draco, law scribe who replaced informal oral laws with harsh written 
>> laws and a court system 650-600 BC, Athens, Greece
>>
>>
> Interesting, I was misinformed about Draco (being a dragon per a 
> different post in this thread).
>
>
> --
> UNIX was not designed to stop you from doing stupid things, because 
> that would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown


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

Re: Would encryption have prevented known major breaches?

[Phil Smith]

Clark Morris wrote:
>In looking at the news, I'm wondering if encryption would have
>prevented any of the known data breaches.  I'm thinking of Equifax,
>Anthem, Target and Yahoo for starters.

The Anthem breach was the result of a phishing attack, and an internal machine 
was compromised. At that point, the bad guys are so far inside the tent that 
it's not clear what would have helped. See 
https://www.bankinfosecurity.com/new-in-depth-analysis-anthem-breach-a-9627

Target was more interesting: the POS terminal software was compromised, and so 
it was stealing data that was being passed through the payments path in the 
clear. Encryption *in the terminal* would have stopped that. See 
http://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/
 and lots of others (since this is an older one, there's lots out there if you 
search "target breach analysis").

Finally, Yahoo has been breached repeatedly. A bit of Googling finds focus on 
why the most recent breach was fruitful: the bad guys stole unsalted MD5-hashed 
passwords, thus allowing a rainbow table to be used against the data. This is 
so basic and obvious in the security business that I think most people at that 
point said "It doesn't matter how exactly the data was exfiltrated-Yahoo was 
just asking for it". But I'm sure there are more detailed discussions out there.

The key to making encryption be as effective as possible is to only decrypt the 
data occasionally. That means that transparent encryption, such as whole-file 
encryption in z/OS, isn't that effective. It's not useless, but it's not as 
effective as application-level encryption, simply because it means that things 
"below" the application in the stack can be breached and allow data theft (as 
opposed to what I might call "byte theft", i.e., stealing encrypted data, which 
is of no value).

Of course if the application is truly breached, all is lost-if the application 
has rights to cleartext data.


Using format-preserving data protection means that many applications can 
operate on the data in its protected state, without changes. Simplest example: 
a credit card number (PAN). However many applications you have that touch PANs, 
the only ones that ever need the cleartext are the ones that ingest them from 
the outside world (web pages, customer service applications, et al.) and the 
one that passes it to the processor for authorization/settlement. And *maybe* 
some folks in fraud prevention. Otherwise, it's just a magic 15- or 16-digit 
number (soon to be more digits, o boy): all you care about is that it's 
consistent and unique, and that it looks like a PAN. So if you protect the 
middle six digits (all that PCI DSS requires) *as soon as you acquire it*, then 
several good things are true:


1) All of the other applications are safer (note that "r"!) because they 
will never touch cleartext

2) All of the other applications are out of PCI scope

3) All of the other applications need no changes

4) Data is interoperable with other systems, including ASCII systems, 
without requiring decryption before transmission

5) The attack surface for PANs (assuming proper control of key access, 
etc., of course) is limited to the acquiring applications and the application 
that does authorization/settlement

So with relatively little effort, you've protected a lot of the system.

Again, as others have noted, defense-in-depth means you also want DASD 
encryption, you also want encrypted backups, you also may use whole-file 
encryption in cases where data has to be stored as cleartext.


>If one steals a database, they
>need to be able to steal the means to read it which would mean they
>have a computer compatible with the target company and the
>corresponding software.  While dumps of tape files can give probable
>hits, if the record descriptions aren't available, there is at least
>some difficultly in guessing which fields are what.  How did the
>thefts work and to what extent did the thieves appear to the system as
>valid users?

True, but any protection you're imputing there is "security by obscurity". If I 
had managed to get into Equifax and acquired a raw dump of a 10TB database, I 
think I could find a z/OS system somewhere (or build one) and figure out how to 
read it so I could monetize that dump. Or maybe I'd just do analysis and make 
some guesses.

>Are test systems, even with data masking applied to production data,
>of use to thieves?

If they have improper access to real data, sure; and if they provide a way to 
understand data flows and connections to enable attacks on production, also 
yes. That is, if a test system isn't secure "because it's just a test system", 
and that lets bad guys bang on it unnoticed until they find a hole that they 
can then use on the production system, then definitely.

>What are the risks of encryption?  Loss of password or keys seems a
>noticeable risk as does compromise of same.

Re: "Breach" (fka Would encryption have prevented known major breaches?)

[Steve Smith]

"Breach" comes doen from middle English, and it didn't originally mean
"hack into a computer system and steal data".  Peter's take is that an
unauthorized part broke through at least one layer of defense, and
that is certainly something to be concerned about.  And I'd call that
at least a "partial" breach.  Clearly there's a difference between
that and routine exposure through normal processing.  Also clear is
that if the malefactor is prevented from their ultimate goal, then
that is *not* a "complete" breach...

Say a bank robber breaches the front door of a bank in the middle of
the night, but can't open the safe.  Certainly much better than if he
had, but the bank doesn't just ignore the incident.

One of the tenets of "defense in depth" is that you react to partial
failures (breaches) to help prevent a total failure (breach) later.

Anyway for legal purposes, one would need to see and abide by the
definition used by the authorities involved.  I think this is why
scientists and lawyers like to use Latin.  English is for poetry.

sas

On Thu, Sep 14, 2017 at 1:39 AM, Timothy Sipples  wrote:
> Peter Relson wrote:
>>Isn't the answer really: no, it would not have prevented the breach but it
>>would have prevented the breach from having the undesirable effects (e.g.,
>>exposing sensitive data)?
>
...
>
> In my view, your definition is not what most people mean with the word
> "breach." I agree with most people. I don't think a hyper technical
> definition is too useful here, and it could easily be misleading and take
> precious focus off what the planet really needs. If your definition of
> "breach" holds, then you have to clarify why sending sensitive data over a
> properly encrypted VPN connection, or discarding/recycling a properly
> encrypted and physically intact disk or tape, is not a "breach."

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

Re: Would encryption have prevented known major breaches?

[Timothy Sipples]

Peter Relson wrote:
>Isn't the answer really: no, it would not have prevented the breach but it
>would have prevented the breach from having the undesirable effects (e.g.,
>exposing sensitive data)?

First of all, a strong, multi-layered defense can indeed prevent (inner)
breaches even as you've (re)defined them. A successful breach often
involves "leapfrogging." That is, the attacker penetrates the first (only?)
line of defense, obtains unencrypted or too weakly encrypted credentials,
then uses those credentials to penetrate the next layer. Indeed, this is
precisely the reason why KDFAES support was added to RACF some time ago.
(Please turn KDFAES, passphrases, and, preferably, multi-factor
authentication on if you haven't already! And try to make sure that RACF or
your other security manager is put back in charge of at least
authorization. If RACF only knows about server-level IDs because
authorization has been fully delegated elsewhere, that's probably bad.)

In my view, your definition is not what most people mean with the word
"breach." I agree with most people. I don't think a hyper technical
definition is too useful here, and it could easily be misleading and take
precious focus off what the planet really needs. If your definition of
"breach" holds, then you have to clarify why sending sensitive data over a
properly encrypted VPN connection, or discarding/recycling a properly
encrypted and physically intact disk or tape, is not a "breach." Those
patterns also involve someone potentially or actually able to intercept,
record, and do whatever they wish with the encrypted data. The data, in
encrypted form, is made public. But properly encrypted data, without access
to the private key, is useless. Properly encrypted data could be burned
onto CDs and mailed to every household -- AOL style -- and there'd be no
breach in any sensible meaning of the word.

Dictionaries appear to agree with me (and others):

http://www.dictionary.com/browse/breach?s=t

As an analogy, a police or military force will often, quite deliberately,
allow an attacker entry into a particular zone. Even facilitate and
encourage that entry. Is that a "breach"? No, it's not. The reason they do
this is because it makes it easier to catch the attacker and to gather
evidence, as in police sting operations. It is *then* possible for
operational security to be breached if the attacker is more clever than
expected, but that's rare.

So I disagree with your definition of "breach." I would use words like
"unauthorized copying of encrypted data with no security impact" to
describe what you're describing.

Elardus Engelbrecht wrote:
>If breachers are insiders themselves, you're basically out
>of luck and goodbye to your [sensitive and unencrypted] data.

No, I disagree again. In my view we shouldn't perpetuate the myth that the
"god administrator" is necessary. It's just not true. We know how to
design, deliver, and operate systems that do not require operators and
administrators to be deities, at least not solo deities. We know how to
prevent insider attacks. The whole concept of "inside" versus "outside" is
outmoded at best. It's "Maginot Line" thinking, and it demonstrably doesn't
work.

Many organizations have already adopted a non-god IT approach, quite
successfully. z/OS Data Set Encryption, properly implemented, is one of the
unique capabilities that can help.


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

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

Re: Would encryption have prevented known major breaches?

[Tom Brennan]

Of course I think encryption helps security, but it can't stop someone 
from hacking a different way, such as using the methods already setup to 
decrypt data (like I think Steve was referring to).  For example, if I 
could get on a system and eventually get APF dataset authority, I could 
hack into RACF or even IOS/ICSF and watch the bits fly by, hopefully 
without much notice.  At that level, encryption is meaningless.  I'd 
even bet the Equifax data was encrypted internally.


Better for all of us would be to have people stop relying on things like 
my name and SSN for identification, making the Equifax dump relatively 
useless.  Yes, I want a chip embedded under my skin!  I'll even take 
chip number 666 if nobody else wants it :)


Jesse 1 Robinson wrote:
There was a lot of discussion at SHARE this summer about the impact of the new EU regulation that imposes Draconian penalties on a company that fails to report data breaches *very* quickly. (Who was Dracon anyway, and why such a hard *ss?) The EU rule stipulates that if breached data is encrypted, then there is no obligation to report and no penalty. The difference in cost to a large company ought to pay for several z14s.  


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager

323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, September 13, 2017 6:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

The bottom line is this: stolen encrypted data is much harder to use, or it 
takes time and effort to crack it.  But no encryption seals all the attack 
vectors, many of which would bypass encryption.

E.G.  z/OS Data Set Encryption is so transparent, many users won't even know 
the data *is* encrypted.  (in my experiments with it, it's actually more 
difficult to get a glimpse at the encrypted data than to see it in the clear).  
So a bad guy who breaches the system in a way that impersonates an authorized 
user won't be bothered by the encryption at all.

Crypto-wizards know exactly how hard it is to crack particular forms of 
encryption.  It's nothing to IBM's shame if someone builds a powerful enough 
machine to do it; or far less likely a mathematical genius finds a better 
algorithm.  Now, if their implementation has some fatal back-door that gets 
exploited, then they'd deserve much more than embarrassment.

sas

On Wed, Sep 13, 2017 at 8:54 AM, Elardus Engelbrecht 
<elardus.engelbre...@sita.co.za> wrote:


Peter Relson wrote:



Isn't the answer really: no, it would not have prevented the breach but it 
would have prevented the breach from having the undesirable effects (e.g., 
exposing sensitive data)?


Actually in my humble opinion, there are TWO answers - Yes and No.

It depends on how the breach took place in the first place.

If breachers are insiders themselves, you're basically out of luck and goodbye 
to your [sensitive and unencrypted] data.

If breachers can install nefarious software on your z/OS users workstation, 
they can mis-use those workstations to steal [and perhaps decrypt] whatever 
they want.

If you are leaving a hole somewhere where (non-SSL) application, FTP and TELNET 
for example, are open to the outside world, then you deserves to be punished.

... etc ...




If breached data is encrypted, I believe that there is not a regulatory 
requirement to report the breach.


I don't know about rules and regulations, but I believe ALL breaches should be 
reported somehow. Of course, red faces will follow despite the encrypted data.

Perhaps if someone can really decrypt it, then big blue has a red face...

Groete / Greetings
Elardus Engelbrecht




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


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

Re: Would encryption have prevented known major breaches?

[Mike Schwab]

Draco is the formal name of a constellation.
https://en.wikipedia.org/wiki/Draco_(constellation)
The laws Draco instituted included the death penalty for many crime.
And if a fire breathing dragon breaths on you, you are toast.

On Wed, Sep 13, 2017 at 12:43 PM, John McKown
 wrote:
> On Wed, Sep 13, 2017 at 12:39 PM, Mike Schwab 
> wrote:
>
>> https://en.wikipedia.org/wiki/Draconian
>>
>> https://en.wikipedia.org/wiki/Draco_(lawgiver)
>> Draco, law scribe who replaced informal oral laws with harsh written
>> laws and a court system 650-600 BC, Athens, Greece
>>
>>
> Interesting, I was misinformed about Draco (being a dragon per a different
> post in this thread).
>
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Wed, Sep 13, 2017 at 12:39 PM, Mike Schwab 
wrote:

> https://en.wikipedia.org/wiki/Draconian
>
> https://en.wikipedia.org/wiki/Draco_(lawgiver)
> Draco, law scribe who replaced informal oral laws with harsh written
> laws and a court system 650-600 BC, Athens, Greece
>
>
​Interesting, I was misinformed about Draco (being a dragon per a different
post in this thread).​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Wed, Sep 13, 2017 at 12:28 PM, Jesse 1 Robinson 
wrote:

> There was a lot of discussion at SHARE this summer about the impact of the
> new EU regulation that imposes Draconian penalties on a company that fails
> to report data breaches *very* quickly. (Who was Dracon anyway, and why
> such a hard *ss?)


​If the question about "Draconian" is actual, it comes from "draco" or
"dragon". And most dragons are hard *sses.​



> The EU rule stipulates that if breached data is encrypted, then there is
> no obligation to report and no penalty. The difference in cost to a large
> company ought to pay for several z14s.


> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

Re: Would encryption have prevented known major breaches?

[Mike Schwab]

https://en.wikipedia.org/wiki/Draconian

https://en.wikipedia.org/wiki/Draco_(lawgiver)
Draco, law scribe who replaced informal oral laws with harsh written
laws and a court system 650-600 BC, Athens, Greece

On Wed, Sep 13, 2017 at 12:28 PM, Jesse 1 Robinson
<jesse1.robin...@sce.com> wrote:
> There was a lot of discussion at SHARE this summer about the impact of the 
> new EU regulation that imposes Draconian penalties on a company that fails to 
> report data breaches *very* quickly. (Who was Dracon anyway, and why such a 
> hard *ss?) The EU rule stipulates that if breached data is encrypted, then 
> there is no obligation to report and no penalty. The difference in cost to a 
> large company ought to pay for several z14s.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Steve Smith
> Sent: Wednesday, September 13, 2017 6:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Would encryption have prevented known major breaches?
>
> The bottom line is this: stolen encrypted data is much harder to use, or it 
> takes time and effort to crack it.  But no encryption seals all the attack 
> vectors, many of which would bypass encryption.
>
> E.G.  z/OS Data Set Encryption is so transparent, many users won't even know 
> the data *is* encrypted.  (in my experiments with it, it's actually more 
> difficult to get a glimpse at the encrypted data than to see it in the 
> clear).  So a bad guy who breaches the system in a way that impersonates an 
> authorized user won't be bothered by the encryption at all.
>
> Crypto-wizards know exactly how hard it is to crack particular forms of 
> encryption.  It's nothing to IBM's shame if someone builds a powerful enough 
> machine to do it; or far less likely a mathematical genius finds a better 
> algorithm.  Now, if their implementation has some fatal back-door that gets 
> exploited, then they'd deserve much more than embarrassment.
>
> sas
>
> On Wed, Sep 13, 2017 at 8:54 AM, Elardus Engelbrecht 
> <elardus.engelbre...@sita.co.za> wrote:
>> Peter Relson wrote:
>>
>>>Isn't the answer really: no, it would not have prevented the breach but it 
>>>would have prevented the breach from having the undesirable effects (e.g., 
>>>exposing sensitive data)?
>>
>> Actually in my humble opinion, there are TWO answers - Yes and No.
>>
>> It depends on how the breach took place in the first place.
>>
>> If breachers are insiders themselves, you're basically out of luck and 
>> goodbye to your [sensitive and unencrypted] data.
>>
>> If breachers can install nefarious software on your z/OS users workstation, 
>> they can mis-use those workstations to steal [and perhaps decrypt] whatever 
>> they want.
>>
>> If you are leaving a hole somewhere where (non-SSL) application, FTP and 
>> TELNET for example, are open to the outside world, then you deserves to be 
>> punished.
>>
>> ... etc ...
>>
>>
>>>If breached data is encrypted, I believe that there is not a regulatory 
>>>requirement to report the breach.
>>
>> I don't know about rules and regulations, but I believe ALL breaches should 
>> be reported somehow. Of course, red faces will follow despite the encrypted 
>> data.
>>
>> Perhaps if someone can really decrypt it, then big blue has a red face...
>>
>> Groete / Greetings
>> Elardus Engelbrecht
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Would encryption have prevented known major breaches?

[Jesse 1 Robinson]

There was a lot of discussion at SHARE this summer about the impact of the new 
EU regulation that imposes Draconian penalties on a company that fails to 
report data breaches *very* quickly. (Who was Dracon anyway, and why such a 
hard *ss?) The EU rule stipulates that if breached data is encrypted, then 
there is no obligation to report and no penalty. The difference in cost to a 
large company ought to pay for several z14s.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Wednesday, September 13, 2017 6:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

The bottom line is this: stolen encrypted data is much harder to use, or it 
takes time and effort to crack it.  But no encryption seals all the attack 
vectors, many of which would bypass encryption.

E.G.  z/OS Data Set Encryption is so transparent, many users won't even know 
the data *is* encrypted.  (in my experiments with it, it's actually more 
difficult to get a glimpse at the encrypted data than to see it in the clear).  
So a bad guy who breaches the system in a way that impersonates an authorized 
user won't be bothered by the encryption at all.

Crypto-wizards know exactly how hard it is to crack particular forms of 
encryption.  It's nothing to IBM's shame if someone builds a powerful enough 
machine to do it; or far less likely a mathematical genius finds a better 
algorithm.  Now, if their implementation has some fatal back-door that gets 
exploited, then they'd deserve much more than embarrassment.

sas

On Wed, Sep 13, 2017 at 8:54 AM, Elardus Engelbrecht 
<elardus.engelbre...@sita.co.za> wrote:
> Peter Relson wrote:
>
>>Isn't the answer really: no, it would not have prevented the breach but it 
>>would have prevented the breach from having the undesirable effects (e.g., 
>>exposing sensitive data)?
>
> Actually in my humble opinion, there are TWO answers - Yes and No.
>
> It depends on how the breach took place in the first place.
>
> If breachers are insiders themselves, you're basically out of luck and 
> goodbye to your [sensitive and unencrypted] data.
>
> If breachers can install nefarious software on your z/OS users workstation, 
> they can mis-use those workstations to steal [and perhaps decrypt] whatever 
> they want.
>
> If you are leaving a hole somewhere where (non-SSL) application, FTP and 
> TELNET for example, are open to the outside world, then you deserves to be 
> punished.
>
> ... etc ...
>
>
>>If breached data is encrypted, I believe that there is not a regulatory 
>>requirement to report the breach.
>
> I don't know about rules and regulations, but I believe ALL breaches should 
> be reported somehow. Of course, red faces will follow despite the encrypted 
> data.
>
> Perhaps if someone can really decrypt it, then big blue has a red face...
>
> Groete / Greetings
> Elardus Engelbrecht


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

Re: Would encryption have prevented known major breaches?

[Elardus Engelbrecht]

Peter Relson wrote:

>Isn't the answer really: no, it would not have prevented the breach but it 
>would have prevented the breach from having the undesirable effects (e.g., 
>exposing sensitive data)?

Actually in my humble opinion, there are TWO answers - Yes and No.

It depends on how the breach took place in the first place. 

If breachers are insiders themselves, you're basically out of luck and goodbye 
to your [sensitive and unencrypted] data.

If breachers can install nefarious software on your z/OS users workstation, 
they can mis-use those workstations to steal [and perhaps decrypt] whatever 
they want.

If you are leaving a hole somewhere where (non-SSL) application, FTP and TELNET 
for example, are open to the outside world, then you deserves to be punished.

... etc ...


>If breached data is encrypted, I believe that there is not a regulatory 
>requirement to report the breach.

I don't know about rules and regulations, but I believe ALL breaches should be 
reported somehow. Of course, red faces will follow despite the encrypted data.

Perhaps if someone can really decrypt it, then big blue has a red face...

Groete / Greetings
Elardus Engelbrecht

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

Re: Would encryption have prevented known major breaches?

[Peter Relson]

Isn't the answer really: no, it would not have prevented the breach but it 
would have prevented the breach from having the undesirable effects (e.g., 
exposing sensitive data)?
If breached data is encrypted, I believe that there is not a regulatory 
requirement to report the breach.

Peter Relson
z/OS Core Technology Design


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

Re: Would encryption have prevented known major breaches?

[scott Ford]

Guys,

I am curious has anyone published how these places were hacked, i.e.;
method ...
This way one maybe prevent it.

Scott

On Tue, Sep 12, 2017 at 10:30 AM, Timothy Sipples 
wrote:

> Clark Morris wrote:
> >In looking at the news, I'm wondering if encryption would have
> >prevented any of the known data breaches.
>
> The short answer: "Yes."
>
> The implementation details matter a lot and influence the success rates.
>
> 
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: Would encryption have prevented known major breaches?

[Timothy Sipples]

Clark Morris wrote:
>In looking at the news, I'm wondering if encryption would have
>prevented any of the known data breaches.

The short answer: "Yes."

The implementation details matter a lot and influence the success rates.


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

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

Would encryption have prevented known major breaches?

[Clark Morris]

In looking at the news, I'm wondering if encryption would have
prevented any of the known data breaches.  I'm thinking of Equifax,
Anthem, Target and Yahoo for starters.  If one steals a database, they
need to be able to steal the means to read it which would mean they
have a computer compatible with the target company and the
corresponding software.  While dumps of tape files can give probable
hits, if the record descriptions aren't available, there is at least
some difficultly in guessing which fields are what.  How did the
thefts work and to what extent did the thieves appear to the system as
valid users?

Are test systems, even with data masking applied to production data,
of use to thieves?

What are the risks of encryption?  Loss of password or keys seems a
noticeable risk as does compromise of same.

Clark Morris

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