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 by a production user id. To
clarify, I was saying that since you don't have access, you must somehow get
another user to execute your program. The production user is only one method.
If you wanted access thru someone, a simpler method would be to ask a colleague
to run your program to see if they get the same results, error or any reason
they encounter occasionally.
As for "production required actions", these are processes. Processes are never
100%. An employee understands these processes and if motivated enough will find
where these processes fail.
>I said 6. Most employee's have full control for their datasets and
> allow anyone to allocate and write them.
Sorry, I said "allow" but meant "can allow" or better yet "can authorize".
Often, user's are allowed to change security rules on their own datasets. Most
don't use it and it's not publicized.
Jon.
On Saturday, December 23, 2017 9:41 AM, Jeremy Nicoll
<jn.ls.mfrm...@letterboxes.org> wrote:
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 possibly analyze every single resourse - more
> often it's a best estimate and experience).
This is what naming conventions are for. If the datasets belonging to
a particular part of your production system all have sensible HLQs
then protection is just a case of limiting who (from groups of users)
can read/write/allocate anything with that HLQ.
> I'll try to explain it again for those who are interested. Here are the
> attributes of the exposure again:1. You must be an employee because you
> need inside information. (They know many things processes and general
> security to avoid getting caught).2. The dataset is protected where they
> can't get read the file. Or they want information from a database that
> is protected. They cannot get to it from their userid.3. The first thing
> to exploit is run the program under a different userid that has
> authority. This is easily accomplished by moving it to production or
> having another employee run it (there are many easy methods to do this).
There are? If the program is 'in production' it has the access that any other
production program (in the same suite) would have. No ordinary user will
be able to run it - it would run only when triggered in the job-scheduler,
and then it would run under the production id.
And, where I worked, getting a new program, or a modified program into
production required actions from multiple people in multiple teams. I
agree collusion could have made it easier, but the audit trail (eg in SMF
data) would still be there.
> 4. The program has read access but how does the employee see that data?
> Writing to any of the permanent allocations are usually restricted and
> writing to these datasets will normally cause problems. The program is
> useless to the employee at this point.5. The program must use dynalloc
> to a dataset the employee can access.
But, where I worked, that static or dynamic allocation would not work.
The production id would not be able to do anything to files outwith its
own suite, let alone write to programmer HLQs.
Sometimes access was only granted to specific programs running
under specific ids.
> In cobol & pl/I, this is now easily accomplished by specifying a
> dataset in the program.
>6. Most employee's have full control for their datasets and
> allow anyone to allocate and write them.
If that's actually the case then the security hole isn't dynalloc, but
allowing ANYTHING to allocate/write to a programmer's datasets.
Where I worked... that certainly wasn't possible. The most you
could do was allocate & write to immediate colleagues' datasets,
people in the same team or subteam as yourself.
> Or the dataset could be another production dataset.
Which no normal user could read. On-call programming staff had
more access, but it was audited.
--
Jeremy Nicoll - my opinions are my own.
