Re: Dynalloc (was Macro processor)

If by “it” you mean MVS DynAlloc then the reason it’s not considered to be a potential security exposure now is pretty much the same reason for it never having been, namely that it cannot be used to circumvent system security.

Re: Dynalloc (was Macro processor)

Jon, Dynalloc is not an exposure in a properly configured z/OS SAF environment. Most large shops I have worked at don't allow application programmers (who are the ones most likely to have the skills to perpetrate a security breach and the necessary inside knowledge of process and procedure)

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

Am I missing something or are the arguments for disabling dynamic allocation nearly a clone of the old arguments for restricting AMASPZAP?

Re: Calling BPXWDYN to Return DSNAME for DDNAME

"I have tested both versions in 1.13 and 2.3 systems successfully." Good to know Willie! Could you post the essentials of your successful INFO call to return DSNAME for DDNAME? I'd like to see how it differs from mine, which failed.

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

AW: Dynalloc (was Macro processor)

How about this? https://www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412 And no, it had nothing to do with z/OS or Dynalloc. -Ursprüngliche Nachricht- Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]

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 dynalloc. This vulnerability was used against Target where they >were >recently fined $18 million and lost millions in revenues for

Re: AW: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

Re: Dynalloc (was Macro processor)

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

AW: Dynalloc (was Macro processor)

>>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