Charles broke the cardinal rule in security ( never say never ). Viruses rely
on dynalloc. This vulnerability was used against Target where they were
recently fined $18 million and lost millions in revenues for their data breach.
In MVS, many of the dynalloc exposures don't exist but there are e
Subject: Dynalloc (was Macro processor)
Charles broke the cardinal rule in security ( never say never ). Viruses rely
on dynalloc. This vulnerability was used against Target where they were
recently fined $18 million and lost millions in revenues for their data breach.
In MVS, many of the dynalloc
On 2017-12-22, at 14:26:07, Jon Perryman wrote:
> Charles broke the cardinal rule in security ( never say never ). Viruses rely
> on dynalloc. This vulnerability was used against Target where they were
> recently fined $18 million and lost millions in revenues for their data
> breach.
> In MVS
Again with the motivated reasoning. Give me any fact that it's unrelated. Give
me any fact that I'm wrong. Of course it's based on dynamic allocation. In a
permanent allocation situation (like JCL, CICS or possibly IMS), you are
defining datasets that can be used at that time. From a security st
How can RACF stop someone when they have a legitimate need to update something
like clists? Or do we keep making the processes so complicated that more people
jump to Unix where they have complete freedom and control. Security is a
balancing act of risk versus cost.
Jon.
On Friday, Decembe
Apologies, I accidentally sent this reply so Jon directly instead of to the
list.
Peter
-Original Message-
From: Farley, Peter x23353
Sent: Friday, December 22, 2017 7:34 PM
To: 'Jon Perryman'
Subject: RE: Dynalloc (was Macro processor)
Jon,
I think our confusion (or a
On 2017-12-22, at 17:37:52, Jon Perryman wrote:
> How can RACF stop someone when they have a legitimate need to update
> something like clists? Or do we keep making the processes so complicated that
> more people jump to Unix where they have complete freedom and control.
> Security is a balanci
>>How can RACF stop someone when they have a legitimate need
It can't of course. That's why the Target attack (like most others) essentially
revolved around a bit of social engineering and getting access to a privileged
account. Along with poor malware detection, lack of network segregation and
This started as me being surprised that Cobol and PL/I now support Dynalloc
because of the security risks. I satisfied that it exists and for whatever
reason, it is no longer considered a security exposure. My apologies for
allowing this to drag into a discussion about security theory in this gr
On 12/23/2017 8:18 AM, Jon Perryman wrote:
People are clever and will find ways to abuse things if they are motivated.
Dynalloc can easily be exploited. It's not exploited because no one has been
motivated to exploit it.
Security risks are big news in this century and there have been some
*o
On Fri, 22 Dec 2017 21:26:07 +, Jon Perryman wrote:
>Charles broke the cardinal rule in security ( never say never ). Viruses rely
>on dynalloc. This vulnerability was used against Target where they >were
>recently fined $18 million and lost millions in revenues for their data
>breach.
C
] Im
Auftrag von Walt Farrell
Gesendet: Samstag, 23. Dezember 2017 18:10
An: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Betreff: Re: Dynalloc (was Macro processor)
On Fri, 22 Dec 2017 21:26:07 +, Jon Perryman wrote:
>Charles broke the cardinal rule in security ( never say never ). Viruses rely
On Sat, 23 Dec 2017, at 16:18, Jon Perryman wrote:
> Most security breaches need multiple exploits on MVS. Often, eliminating
> a single exploit is enough to to stop that particular breach.
> SAF (RACF) secures resources but there will be always be exposures (e.g.
> A security admin can't possib
On 2017-12-23, at 10:09:47, Walt Farrell wrote:
> On Fri, 22 Dec 2017 21:26:07 +, Jon Perryman wrote:
>
>> Charles broke the cardinal rule in security ( never say never ). Viruses
>> rely on dynalloc. This vulnerability was used against Target where they
>> >were recently fined $18 million
I only wanted to know why dynalloc is no longer considered an exposure. When
these people did the risk analysis for dynalloc on MVS, what made them decide
why it's not an exposure and does not need to be a controlled resource?
Thanks, Jon.
On Saturday, December 23, 2017 8:40 AM, Ed Jaffe
I was going from a court ruling but David Stokes noted a whitepaper that
confirms my suspicions in the court ruling.
Target does not have z/OS nor dynalloc (by name). However Unix is by design
dynalloc all the time.
Jon
On Saturday, December 23, 2017 9:09 AM, Walt Farrell
wrote:
On Fri
On Sat, 23 Dec 2017, at 18:40, Jon Perryman wrote:
> I only wanted to know why dynalloc is no longer considered an exposure.
> When these people did the risk analysis for dynalloc on MVS, what made
> them decide why it's not an exposure and does not need to be a
> controlled resource?
Maybe it'
Naming conventions only go so far in securing departmental data because of
exceptions. For instance, there is departmental overlap such as payroll and
general ledger.
As for "Production being executed by a user", forgive me if I implied that. I
was specifically saying production being executed b
On Sat, 23 Dec 2017, at 19:42, Jon Perryman wrote:
> Naming conventions only go so far in securing departmental data because
> of exceptions. For instance, there is departmental overlap such as
> payroll and general ledger.
But if there's proper separation between production ids (which run the
p
Am I missing something or are the arguments for disabling dynamic allocation
nearly a clone of the old arguments for restricting AMASPZAP?
Proper separation from user departments is usually not a problem from the IT
perspective. User departments generally run in CICS or IMS which is very
controlled (unless in VSE I think). Instead, this would most likely be an IT
person where they maintain programs.
You sound very confident and it'
Jon,It seems to me that what you’re saying is that if one works
in a badly run z/OS shop with unprotected UserIDs and unscrupulous employees
who share their user credentials then that might result in a security exposure.
In tha
Keven, As I said before, I wanted to know why it's not considered an exposure
now. I'm not interested in convincing anyone it's an exposure because it won't
help to answer my question.
Jon.
On Saturday, December 23, 2017 8:48 PM, Keven Hall
wrote:Jon,It seems to me that what you’re s
your question?
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Jon Perryman
Sent: Sunday, December 24, 2017 12:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
EXTERNAL: This email origi
] On
Behalf Of Jon Perryman
Sent: Sunday, December 24, 2017 12:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
EXTERNAL: This email originated from outside of Broadridge. Do not click any
links or open any attachments unless you trust the sender and know
Jon Perryman
Sent: Sunday, December 24, 2017 12:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
EXTERNAL: This email originated from outside of Broadridge. Do not click any
links or open any attachments unless you trust the sender and know the content
is safe.
K
The argument that dynalloc is the problem strikes me as somewhat dubious.
It was suggested that you need to restrict dynalloc because an allocated
data set is a way to capture data that the user is already authorized to
access.
That is not the "problem" statement; a data set might contribute to
On 2017-12-24, at 00:10:58, Farley, Peter x23353 wrote:
>
> ... Without necessary access rights, allocation is a useless tool for
> malfeasance of any kind.
>
Ummm... Denial of Service?
-- gil
.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Sunday, December 24, 2017 9:33 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
On 2017-12-24, at 00:10:58, Farley, Peter
Farley, Peter x23353
Gesendet: Sonntag, 24. Dezember 2017 19:02
An: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Betreff: Re: Dynalloc (was Macro processor)
OK, possibly for 5 minutes or so. Mainframe operations personnel are trained,
in my experience, to prioritize such issues in order to keep the batch stream
On 2017-12-24, at 11:01:38, Farley, Peter x23353 wrote:
>
> If truly a DOS attempt, then this would be followed the next day by promotion
> to the street for the responsible programmer and reprimands for the code
> reviewer(s) for missing such a trick.
>
But the DoS could be inadvertent, by a
: Sunday, December 24, 2017 9:33 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
On 2017-12-24, at 00:10:58, Farley, Peter x23353 wrote:
>
> ... Without necessary access rights, allocation is a useless tool for
malfeasance of any kind.
>
Ummm...
On Sun, 24 Dec 2017 12:17:22 -0700, Paul Gilmartin wrote:
>On 2017-12-24, at 11:01:38, Farley, Peter x23353 wrote:
>>
>> If truly a DOS attempt, then this would be followed the next day by
>> promotion to the street for the responsible programmer and reprimands for
>> the code reviewer(s) for
On Sun, 24 Dec 2017 05:38:48 +, Jon Perryman wrote:
>Keven, As I said before, I wanted to know why it's not considered an exposure
>now.
Why do you assume it was ever considered an exposure?
--
Walt
Think like a security admin instead of programmer. You are right that dynalloc
is not a problem but to a security admin, it is an exposure. Exposures combine
to become a problem. Here are some examples (UNRELATED to dynalloc) that may
help to clarify.
1. Don't you have customers that refuse to
Walt, you wrote, "Therefore, RACF is not allowing an ENQ on a DSN, because RACF
has no idea that an ENQ is being done." and it occurs to me to point out that,
likewise, ENQ is not preventing access to a DSN because ENQ has no idea that a
dsn is being accessed (which, of course, is different from
IST@LISTSERV.UGA.EDU] Im
Auftrag von Farley, Peter x23353
Gesendet: Sonntag, 24. Dezember 2017 19:02
An: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Betreff: Re: Dynalloc (was Macro processor)
OK, possibly for 5 minutes or so. Mainframe operations personnel are trained,
in my experience, to prioritize suc
24, 2017 2:17 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
EXTERNAL: This email originated from outside of Broadridge. Do not click any
links or open any attachments unless you trust the sender and know the content
is safe.
On 2017-12-24, at 11:01:38, Far
On Sun, 24 Dec 2017 15:58:10 -0500, Walt Farrell wrote:
>RACF is not allowing an ENQ on a DSN, because RACF has no idea
>that an ENQ is being done. If anyone were to control that, it would
>be data set allocation, who would have to invoke RACF to ask if
>the user would have authority to eventua
On Wed, 27 Dec 2017 08:22:33 -0500, Tom Marchant
wrote:
>It is even more difficult for RACF to answer the question if the data
>set may only be accessed by certain programs.
Excellent point, Tom, and an even better example than mine. Thanks.
--
Walt
I'm not saying that it comes down to dynalloc. Security never comes down to a
single exploitation. Think about alcatraz which despite all the extreme
security measures still had an escape. I'm sayiing that dynalloc is not
controlled by security admins and there are simple scenario's to exploit i
41 matches
Mail list logo
