Re: Suggestions on best practices for idle timeouts

[Velislav K Pavlov <VelislavPavlov () FERRIS EDU>]

When considering a session termination and log off, one should keep in mind specific regulations like HIPAA.

HIPAA Technical safeguard:
164.312(a)(2)(iii)
Have you implemented procedures that terminate an electronic
session after a predetermined time of inactivity?





From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Eric 
Lukens
Sent: Thursday, October 29, 2015 10:47 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Suggestions on best practices for idle timeouts

Our auditors have forced the web apps to time out after a short amount of time since we don't force the desired 
screensaver timeouts on all our machines (classrooms for example) and do not prevent access from personally-owned 
devices for many of the apps. They've also applied this to most of the student-oriented systems as well--class 
registration and so forth, which are obviously going to be accessed with personal devices. The auditors see the timeout 
on their checklist and want to enforce it universally and without exceptions.

Another thing to consider is the action the timeout actually does. Typically from an audit standpoint, it needs to lock 
the session and require authentication again, it does not need to log you off and destroy the session on the 
server-side. However, more often than not the easy implementation in a web application is to destroy the session and 
log off the user. I've seen people lose hours worth of work because their session was destroyed in the background while 
they were still creating content, or because they entered data into a browser window that had been open for some time 
and had timed-out. If possible, it would be much nicer if the application accepted the submission into a sandbox for 
timed-out sessions, and upon a re-authentication imported the data. This re-auth could already show the username and 
only require the password--this concept is very common with ecommerce sites now. Obviously not every application can 
support this, and it requires more work, but it would be much nicer to the end-users and improve workflow. Obviously 
there should also be some sort of time-out for the server-side sessions, but those can be much, much longer. I suppose 
the same end result could be accomplished by maintaining several different sessions in the background.

On Thu, Oct 29, 2015 at 9:18 AM, Tim Doty <tdoty () mst edu<mailto:tdoty () mst edu>> wrote:
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



--

Eric C. Lukens

IT Security Policy and Risk Assessment Analyst

ITS-Network Services

Curris Business Building 15

University of Northern Iowa

Cedar Falls, IA 50614-0121

319-273-7434

http://www.uni.edu/elukens/

"Security is a process, not a product."  Bruce Schneier