× 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.



Dave,

> We have considered keeping it disabled and then enabling
> when we need
> to, but how would that impact a disaster recovery
> situation? Would you
> be able to log on as QSECOFR if no one else was around
> that could enable
> it first?

I wouldn't disable it, I would just hide the password in an envelope in
a safe to be used only for emergencies.  If you create one or more
alternative security officers, you solve the problem of attribution
("Who was using QSECOFR when the program was deleted?"), but you still
have to solve the problems of notification ("Who had to become the
Security officer in the last 24 hours?") and tracking ("What did you do
while you were the security officer"). 

Disabling QSECOFR might be a little overkill, and you would want to make
sure you have solid plans that would always make the system console
available in case you needed to actually signon with it.

IMHO,

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 Dave Snyder
> Sent: Thursday, February 23, 2006 11:33 AM
> To: midrange-l@xxxxxxxxxxxx
> Subject: RE: QSECOFR usage
> 
> We have considered keeping it disabled and then enabling
> when we need
> to, but how would that impact a disaster recovery
> situation? Would you
> be able to log on as QSECOFR if no one else was around
> that could enable
> it first?
> 
> Dave
> 
> -----Original Message-----
> From: BLCDOM.GWIA.midrange-l@xxxxxxxxxxxx
> Sent: Thursday, February 23, 2006 2:22 PM
> To: midrange-l@xxxxxxxxxxxx; stenore@xxxxxxx
> Subject: Re: QSECOFR usage
> 
> We address it with a program that changed the password for
> QSECOFR daily
> with
> a new one, the same program is the retrieve program which
> requires a
> help desk
> ticket to retrieve it (all custom created). works well and
> shuts down
> auditors, especially with the log file that contains who,
> what, when,
> where
> 
> 
> 
> 
> 
> --
> 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.