On 24 August 2017 at 04:41, R.S. <r.skoru...@bremultibank.com.pl> wrote:
> W dniu 2017-08-23 o 18:25, Karl S Huf pisze:
>
>> NTAC:3NS-20
>>
>> Good question. Reminds me of the age-old Auditor 101 question: "What do
>> you do to restrict AMASPZAP?"
>> Explaining that it's just a tool like any other and that the real issue
>> is properly securing the entities it might update is the real solution
>> always fell on deaf ears. They believed there was something magical
>> about Zap.
>>
>
> Well, yes and no.
> Yes, you are 100% right for nowadays (and several previous years).
>
> However, AFAIK many (20+) years ago things were different.
> AMASPZAP as authorized program can bypass security and perform operations
> restricted to the system (to simplify).
> However contemporary versions of AMASPZAP do its own security check before.
No - never. AMASPZAP (IMASPZAP before MVS, i.e. before 1972, and before the
notion of APF authorization) was always subject to dataset protection (via
passwords, long before RACF), and if it was asked to update the VTOC, it
would issue a message to the operator to ask permission to do so. Of course
asking the operator via WTOR doesn't fit today's ideas of security, but
nonetheless even the very earliest MVS version of AMASPZAP did not have any
magic ability to change the system.
Code from ~1970 IMASPZAP:
UPVTMSG WTOR 'IMA117D REPLY Y OR N TO UPDATE VTOC
X96503820
',CDBUF,1,WTOECB,ROUTCDE=1,DESC=2
96553820
WAIT ECB=WTOECB A38645
96603820
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
