Re: Suggestions on best practices for idle timeouts

[Tim Doty <tdoty () MST EDU>]

On 10/29/2015 09:27 AM, Brad Judy wrote:
> While I agree that endpoint security is important, keep in mind that
> we are talking about applications where the user base might be
> primarily students, prospective students or otherwise from endpoints
> under no control or influence of the organization.

And I do address that. However, the original request stipulated faculty.

> Personally, I think timeouts are perhaps more important these days
> than in the past.

We agree.

> -----Original Message----- From: The EDUCAUSE Security Constituent
> Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of
> Tim Doty Sent: Thursday, October 29, 2015 8:18 AM To:
> SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Suggestions on
> best practices for idle timeouts
>
> * PGP - S/MIME Signed by an unverified key: 10/29/2015 at 8:18:14 AM
>
> On 10/28/2015 12:43 PM, Emily Harris wrote:
> > We are in very lively discussions about best practices for idle
> > machine timeouts.  Most of the discussion is around timeouts for
> > faculty machines, as they could set up a computer with a video or
> > movie and not touch the machine again for 2 hours.  We are
> > specifically talking about timeouts for Single Sign On
> > applications.
>
> Since you say "Single Sign On application" I am assuming you are
> talking about timing out web sessions. If not, ignore this.
>
> Summary:
>
> Timing out web sessions is a workaround for not having local time
> outs. If possible, local timeouts should be used as they are more
> effective. If web session time outs prove necessary then the idle
> time can be shortened by using pop ups.
>
>
> Longer version:
>
> I don't know that it is popular, but my opinion is that timing out
> sessions is over-rated. As far as I can tell, the justification is
> that the user may walk away from their workstation, leaving it
> unattended, and some other individual will then abuse it for the
> logged in access.
>
> The problem in this scenario is not timing out web-based sessions,
> but the lack of end point security. Web sessions are far from the
> only access that is granted by an unsecured terminal. Consequently
> the best solutions will revolve around improving end point security.
>
> For example, mandating a screen locker with an appropriate idle
> time. This has the advantage that a user's sessions don't time out
> just because they are watching a training video.
>
> Another thing that can be done is to educate users about "Windows-L"
> and encourage them to hit those keys whenever stepping away from the
> machine. In shared office space encourage users to still secure
> their workstations, but accept group monitoring where at least one
> person is able to prevent unmonitored access by visitors (this is
> naturally not as good and works best when the users all have
> equivalent access -- still, it can be better than nothing).
>
> Pain associated with frequently typing in passwords may be alleviated
> by using proximity lock/unlock. My experience with this has not been
> good, but that was just kludge involving cell phones and blue tooth.
>
> But in the end, you are more likely to be able to negotiate a
> shorter idle time when using local timeouts (which can be cognizant
> of user activity, such as video watching) rather than timing out web
> sessions. And if the time out is shorter then that is addressing the
> need better, right?
>
> Another thing to keep in mind is that environments vary
> significantly. My idle timeout is only somewhere around five to
> fifteen minutes, but that's because 1) I have my own office, 2) I
> always lock the screen when I get up, 3) and I always close and lock
> my door. In contrast, we have a security conscious employee who works
> in an open, shared space who voluntarily set the local idle timeout
> to one minute (and still uses Windows-L when they get up). I'd be
> surprised if you were able to customize web session timeouts in such
> a fashion so a one-size-fits-all model is used which means
> insufficient timeouts, excessive aggravation, or both.
>
> When the concern is about end points over which there is no control
> (e.g., student-owned systems) then having an idle-timeout for web
> sessions can make sense. The biggest risk there is that there is no
> way to actually measure user idleness. Its very frustrating for a
> user to spend an hour typing into a form only to discover that the
> server idle-killed the session -- and some web applications are
> designed so that you can't go back to reclaim the text (or it just
> isn't that simple if there are a lot of fields). If feasible, a
> "prove your still there" pop up can be a reasonable work around and
> permits shortening the idle timeout.
>
> Tim Doty
>
>
> * Timothy Thomas Warren Doty <tdoty () mst edu> * Issuer: Internet2 -
> Unverified

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature