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, many of the dynalloc exposures don't exist but there are exceptions. 
> The most obvious and least complicated is by employee's. Put your dataset in 
> production JCL and it will be caught when added to the job scheduler. Put 
> your dataset into production program and it will usually go unnoticed. How 
> about Clist libraries that
> 
RACF.

> are often common and rarely protected. I'm sure I could come up with more. 
> In a virus attack, dynalloc is extremely important. The Target incident took 
> a few days before the virus propagated to a critical environment. Without 
> dynalloc, it would have taken many years (or centuries) before it  propagated 
> to the desired location.
> Apparently cobol dynalloc is not well known and will probably not be fixed 
> until it becomes a problem. The real solution in MVS would be a SAF call in 
> SVC 99 that allows security admins to restrict access of Dynalloc. The 
> alternative is for a code review when programs are moved into production.  
> 
There are exits which could issue such SAF calls.  Or just protect with RACF.

> In Unix, we solve the dynalloc vulnerability by segregating sensitive 
> applications onto a different machine and limit resource access to / from 
> this machine. The courts went batsh*t crazy and ordered extreme measures be 
> taken by Target (including extra audits and who knows what else). I think the 
> courts went batsh*t crazy to send a message to all companies (clean up your 
> act) because very few companies take the proper precautions. This is not a 
> problem specific to Target. They were just the first to be caught. I wonder 
> how many companies got the message?
> Jon. 
> 
> On Thursday, December 21, 2017 12:13 PM, Charles Mills wrote:
> 
> DYNALLOC or not has nothing to do with data protection. A user has access to 
> exactly the same datasets via DYNALLOC that he would have via JCL DD.

-- gil

Reply via email to