HP3000-L Archives

August 1998, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Andreas Schmidt <[log in to unmask]>
Reply To:
Date:
Tue, 11 Aug 1998 11:43:51 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
Hi,

(1) it's not a problem not to have a logon on the console.
(2) Whoever has access to the physical console (and to the computer) may
shutdown/stop the box,
independently whether there is a logon or not. The only difference: having a logon
as well, the intruder may purge/damage a lot of more based on the OP caps.
(3) Don't worry about the logon/logoff of the ops for each shift. You have shift
plans so that you can easily identify who was in the data center.
We have the same situation - also our operators are "lazy" and do not logoff/logon
per shift. But we do not see a problem in this behaviour.

Best regards, Andreas Schmidt, CSC, Germany







[log in to unmask] on 08/10/98 05:10:56 PM

Please respond to [log in to unmask]

To:   [log in to unmask]
cc:    (bcc: Andreas Schmidt/HI/CSC)
Subject:  console operators and security




I don't know if this one is a mountain or a molehill, and hope someone
cares to offer an opinion. The 3000 we are on is in a data center in
another state. We use SECURITY / 3000, requiring unique session names,
and configured so that to change a password, you have to supply the
current password. But the operators don't seem scrupulous about signing
on to the console under their own session name, or signing off at the
end of their shifts. For instance, the current session was signed on
Saturday at 11:39 PM; I sincerely hope that operator is not still at
work now. Now, so far as I know, they are careful about their own
passwords, and don't share. And I'm not sure that I want the operators
to have to sign off the console at the end of their shifts, and don't
remember if this affect console messages in any meaningful way, but
don't think so. If we need this to happen, I would probably choose the
configure SEC / 3K to either lockout or disconnect the session after
some interval.
The only problem that comes to mind is that "just anyone" can walk up to
the unattended console, and, since this is a data center, I am not too
terribly worried about unauthorized access, or someone 'playing around'
on the console. The only benefit would be the ability to figure out
which operator's watch something happened on, and that information can
be had by other means. Should I be concerned, or is this really not a
problem?

ATOM RSS1 RSS2