Yes, that's the way I did it too when it was my baby. It's generally accepted
that the abc manager is right person to decide who gets access to the abc
datasets (because how would ~I~ know?). But I also let him designate someone
in his area whom I scoped and trained to change the access rules
One of the Nordic banks had decentralised security admin. The main person
for giving access to the abc data, was a manager in the abc group. For
annual userid/access validation the abc manager had to review the access
lists, and report back. That way every manager suffered a little, rather
than
Volvo Data has (or had when I worked for them) a policy world-wide: Any
department with more than employees must have a someone there scoped to
change a password for her group. That way there was no problem with identity
authentication. Instead of calling the help desk and having them prove
List on behalf of
Wayne Bickerdike
Sent: Saturday, August 5, 2023 11:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Separation of Duties RACF Security Admins/Systems Programmers -
Sarbanes-Oxley
At Australian Defence we heavily used GROUP SPECIAL. That relieved sysprogs
from daily BAU tasks
n behalf
> of Jack Zukt
> Sent: Saturday, August 5, 2023 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Separation of Duties RACF Security Admins/Systems Programmers
> - Sarbanes-Oxley
>
> Role based security is the only kind that is manageable. Any other kind and
> you are p
: IBM Mainframe Discussion List on behalf of
Jack Zukt
Sent: Saturday, August 5, 2023 6:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Separation of Duties RACF Security Admins/Systems Programmers -
Sarbanes-Oxley
Role based security is the only kind that is manageable. Any other kind and
you
At most installations, I think, they start out with the sysprogs doing
security, and in the first months or even a year or two that makes sense, while
things are getting set up and the kinks worked out. But at every installation
I've worked at, the security function has evolved sooner or later
Role based security is the only kind that is manageable. Any other kind and
you are playing at security, you are not managing it.
Sysprogs and Secadmins really should be different persons. It is a very
different role. It is a different mindset. I have worked both roles,
sometimes both at the same t
The goal is to assign application security to a group then add the group to
the user's definition. When a person transfers then you add and deleted
groups to the user while the user keeps access to personal datasets.
On Fri, Aug 4, 2023, 15:51 Steve Thompson wrote:
> Don't know if TSS implement
Sox 404 is the section that mandates segregation of duties. It applies to
non-IT systems as well as IT, so not z/OS or even security specific, rather
"good business practices".
On Fri, Aug 4, 2023 at 11:34 PM Michael Babcock
wrote:
> I ran across this in a CICS security admin book (which should
In TSS a "group" is just a place to hang a GID for use in OMVS ... although
some software vendors use it for other purposes too. But it doesn't get
resource permissions; in TSS, a "profile" is a collection of permissions, and
it's assigned to multiple users, so I think it's analogous to a group
Role-based security ("RBAC") is a ton of work to set up the first time, but I'm
sold on its worth. More companies I've worked for than not, in the past 20
years, have implemented it or are implementing it, despite the huge effort
required.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7
> On Friday, August 4, 2023 at 01:25:32 PM PDT, Wayne Bickerdike
> wrote:
> The idea that a systems programmer of any type would be able to
> perpetrate fraud is a stretch.
A sysprog who can't perpetrate fraud is not a good sysprog. There is a huge
difference between desire having the abilit
Don't know if TSS implements groups. But with groups, I can have
access to certain DSNs read only, others update|delete|create. I
can have access to console commands from TSO, but not have logon
access to CICS. Just as examples.
Having to change TSO IDs is problematic because one loses access
To implement this would require systems that implement application
security. The idea that a systems programmer of any type would be able to
perpetrate fraud is a stretch.
I had access to everything mainframe (RACF, CICS, z/OS) in a top secret
installation. I wouldn't be able to place a purchase o
I ran across this in a CICS security admin book (which should also apply
to z/OS sysprogs):
Roles and separation of duties
A key security principle is the separation of duties between
different users so that no one person has sufficient access privilege to
perpetrate damaging fraud. *This
16 matches
Mail list logo
