Question:
In relation with the parameter: rdisp/gui_auto_logout
For one SAP PRD system with 5000 users (at pharma and biotech industry),
Is there any current recommendation to set this parameter at 1800s, or 3600s, or 2700s?
Thanks.
All your comments are welcomed.
Answer:
SAP recommends not using this parameter (due to the potential loss of data if time-outs occur); audit will argue it should be - I don't know - 15 minutes, or 900 seconds, and that if someone steps away in the middle of data-entry, so be it, they should start over; that the risk of having to reenter data is secondary to the risk to user accountability if someone hijacks an SAP session when a user goes to lunch.
Good luck with this one.
Let the auditor bashing begin.
Answer:
if someone hijacks an SAP session when a user goes to lunch.
If you know that much, then let the developer-bashing begin...
Answer:
Homer, the best thing that we've done here is set via Microsoft's SMS, a policy that enforces a lock of the user's system after 15 minutes (windows settings for screensaver). This allows us to place that parameter at around 4 hours, without having to worry about audit slamming us with risky open sessions on a machine.
Although, you need to work with your basis folks on this in case you get hangups by accident, and the system will not remove them for a long time. Locking up dialog processes makes the basis folks give me nasty looks at the watercooler..
_________________
"SOX.. hmm .. Aren't they the baseball teams in Boston and Chicago?"
Kind Regards,
IamEvilHomer
(Wayne)
Answer:
Is it possible to programatically take another users session? I mean standard program / feature?
Tarr
Answer:
Is it possible to programatically take another users session? I mean standard program / feature?
Tarr
Well, there was a similar sort of feature in earlier versions but is disabled now(I guess SAP's now understood the risk involved)
With that, you could actually take up a user session, means you could see what the user is doing exactly in his session, but you could not do anything in it.
But I dont know of any such feature or programming technique in the latest versions since 4.6C.
If someone knows, do tell me
_________________
Suril
A conclusion is simply the place where you got tired of thinking.
Answer:
I know this was a feature with the earlier versions of 3.1, but haven't seen it since. You could access it (If I remember correctly) via the SM04 display, but like suril said, you could only view their screens (it didn't refresh, and you could not see typed text until they made a change in the screen - i.e. enter, or an execute button)
I'm sure they took it out due to an audit risk.
_________________
"SOX.. hmm .. Aren't they the baseball teams in Boston and Chicago?"
Kind Regards,
IamEvilHomer
(Wayne)
Answer:
I heard a rumour about S_ADMI_FCD PADM controlling such a thing and some new activities and checks for S_DEVELOP.
Tarr
Answer:
I wasn't referring to anything as sinister as taking over a session over the network, but that audit would prefer that this parameter be turned on to prevent someone from walking up to the desk of another user after they've walked away for lunch.
Not saying this is the only rational viewpoint, but audit will generally be the advocate of the strongest restriction available until it's concluded either that management accepts the risk and/or there's a mitigating control.
Answer:
They did that to you?
Do you only design and implement and remain up-to-date based on your audit and compliance requirements??
Get a life!!
Tarr
Answer:
Substituting the security ignorance of the user applies to several "standard" applications.... Outlook... Explorer... Cookies... Excel... during the lunch break.
Auto-time-out the screen saver to "achieve" what you want and train the user to be aware and manually lock.
On the SAP side you can also train and monitor.
If someone gains physical access to a PC which can access your network, you are potentially going to get hosed on and will probably not notice it, unless you monitor.
Tarr
Answer:
I wasn't referring to anything as sinister as taking over a session over the network, but that audit would prefer that this parameter be turned on to prevent someone from walking up to the desk of another user after they've walked away for lunch.
Not saying this is the only rational viewpoint, but audit will generally be the advocate of the strongest restriction available until it's concluded either that management accepts the risk and/or there's a mitigating control.
Audit are trying to see that there is control over unattended workstations/terminals. As other have said, there are a few controls around this but imo the simplest is to include mandatory password screensavers in the pc build. This extends the security to all of your applications - not just SAP. It also enables people in functions where they may need SAP open but away from the workstation (e.g. factory floor, some finance jobs) to keep the session alive but still be protected.
Using the param is a recommendation but if the risk is mitigated the audiots will have to accept that. It is unlikely that they will qualify your accounts based on that param missing.