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 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.
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 <[email protected]> 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.
