× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Chris,

> You then
> give private
> authority of *exclude on the journal and receiver
> libraries for all of
> your security folks.

This is not going to be effective at keeping your *ALLOBJ users out of
the security audit journal.  The security checking algorithm is never
going to look at the user's private authority to the QAUDJRN because the
first thing it checks (on any authority lookup) is "Does the User have
*ALLOBJ?"  If the answer is yes, it does no further security checking.

When it comes to *ALLOBJ users, because you cannot prevent them from
violating your security policy and/or covering their tracks, I think the
best approach is to put just enough inhibitors in their way so that if
they commit a security violation it is clear that they did so willfully,
and not mistakenly.  And if they willfully violate security policy, you
have to take personnel action. (And thanks to Tom Liotta of our company
for first articulating that principle to me).  

jte

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Chris Bipes
> Sent: Thursday, November 17, 2005 3:01 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: QAUDJRN
> 
> Any one who has *allobj or *secadm or *secofr should have
> full auditing
> turned on.  There for any thing they do is captured in the
> QAUDJRN.  You
> should perform regular audits to make sure they do not
> disable auditing
> on their accounts.
> 
> Best is to create a user with full authority to audit
> journals, yet no
> other authority on the system.  This persons job is to
> audit your
> security officers, and the rest of the folks.  You then
> give private
> authority of *exclude on the journal and receiver
> libraries for all of
> your security folks.  All this is over and above the stuff
> Patrick
> mentioned.
> 
> Security is two parts, part 1 control access, part 2 audit
> access.
> Control and Audit should be two different people.
> 
> 
> Chris Bipes
> Information Services Director
> CrossCheck, Inc.
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> Patrick Botz
> Sent: Thursday, November 17, 2005 2:35 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: QAUDJRN
> 
> Dave,
> 
> You can also prevent  *ALLOBJ/security officers from being
> able to
> change
> security related system values.  In V5R2, as long as you
> control the
> service tools userIDs and the privileges that the other
> folks have, you
> can
> lock down security related system values using SST.  You
> would also want
> to
> prevent service tools userIDs with a default password from
> being
> changed/logged into (another option in the service tools
> security menu).
> Doing so will prevent any *ALLOBJ user profile from being
> able to change
> your security related system values.  It also prevents 3rd
> party
> applications from changing them "under the covers" during
> an
> install/upgrade.
> 
> By using this AND using the audit journal, you can prevent
> others from
> changing security related system values and also track who
> is changing
> other non-security related system values.
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.