3/Nov/2016 blog updated for re-tagging due to SCN migration
The aim of this document is to focus on the system controls for password self service to enable you to consider how best to design and configure SAP GRC Password Self Service in your environment. This topic was raised as part of feedback in the document Password Self Service & End User Logon Configuration - AC10 by leos and requested as part of the GRC Collaboration Project. If you are interested in specific configuration steps, please refer to Leo’s document or search SCN space for your requirements.
The scope of the document is SAP standard configuration specific to the SAP GRC component. If anyone would like to add suggestions on how to add additional security layers (tokens, SSO, etc) please add your comments in the section below for discussion.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A PSS tool needs to go through the basic process which includes verifying the identity of the user before the password can be issued. A critical design requirement for PSS is the ability to prevent an intruder masquerading as a valid user to obtain access to their account. Within GRC, there is more than way one to achieve this.
The above diagram is a conceptual view of the complete steps if all Password Self Service configuration steps are activated. Below is a summary on the intention of each step and impact if they are not used.
Network Perimeter
This is not so much a step in GRC configuration but recognises that network security will determine if the HTTP service for End User Login is Internet Facing. Assuming GRC system access is only accessible via internal network access, you have limited potential intruders to those who have network access. It has been included to recognise network perimeter security has a part in the GRC solution but will not be discussed in this document.
End User Logon
The GRC End User Logon functionality utilises a SAP Service Account to authenticate access for the HTTP service. This means, a SU01 Service Username and password is stored against the SICF web services and the end users do not require a SAP GRC account. The positive of this functionality is that end users do not need to be set up in SAP GRC component (simplify maintenance as well as license cost).
GRC makes use of Data Sources for User Authentication, Search and Details for end user functionality. Data Sources are configured via the GRC IMG (transaction SPRO) based on the use of connectors defined in the Integration Framework. Synchronisation jobs are then executed to import the user details. The End User Log-in page can be configured to force authentication against a specific data source. This means, when the user accesses End User Logon functionality, they will required to enter their password for a system defined in the authentication configuration (such as Active Directory or SAP ERP/ECC) and a real-time call is performed to authenticate the user. It is possible to use SAP GRC as an authentication system as well – although this would defeat the purposes in End Users not requiring a SAP GRC account.
Screen Shot: Impacts for configuration setting for Data Sources Verification
Risk # | Summary | Mitigation |
1 | End User Verification set to NO Any user on the network can enter any valid User Id without need to know the password to access the password self service | Challenge Response requires the user to respond to questions with the correct answer. A registration process is necessary for the user to provide these details (refer further below) Ultimately, the initial password or URL to retrieve password is sent to the user’s email address. If the email account is secured this prevents the intruder from accessing the account. However, if intruder has access to the user’s network login then this line of defense is broken. |
2 | End User Verification Relies on System Password being requested for This creates a catch-22 situation where the user needs to know their password to request a password they cannot remember. For example, if the user cannot remember their ECC password and that is why they need to use PSS then your solution will not work if you require them to authenticate with their ECC password. | Data Sources configuration for Authentication would require more than one data source to provide back-up or Verification will need to be set to NO (refer back to Risk 1). If multiple data sources are used, you will need to consider user training impacts and update the login screen to provide some instructions. One possibility is to configure the Active Directory as a data source for authentication as users would need their network password to login to their computer. |
3 | Social Engineering/User Password as an authentication method has a risk of an intruder obtaining it through social engineering means or User writing their password down or disclosing it. | Training users in the risk and consequences of sharing passwords or disclosing them to others is necessary to mitigate this risk. |
4 | Network Sniffing A call to the plug-in system is performed to retrieve and validate password (synchronisation jobs do not store the other system passwords in GRC). | Implement strong system security controls. If using Active Directory connector, ensure a secure port is used for communication. Protect the system to system communication through secure network communication (SNC) to prevent eavesdropping as password will no be sent in clear text. The service user account should also be restricted for permissions in the plug-in system to limit S_RFC access. |
Challenge
Challenge Response provides another way for a user to prove their identity through providing answers to pre-configured questions. The system issues a challenge (secret question) to which the user must respond (provide their answer). These questions and answers are stored in GRC tables with the answers in hashed form.
Challenge Response requires a registration step in which the use must provide this information. System configuration can provide template/global questions and the user can also create their own.
Screen Shots: Impacts for configuration setting for Challenge Response in PSS Global Settings
Risk # | Summary | Mitigation |
1 | No Challenge Response The GRC configuration for PSS Global Configurations Values allows you to set ‘PSS Disable Verification’ for Password Self Service or ALL. If you do this, the user does not need to answer special questions | Removal of challenge-response means there is one less security layer for password self service. This risk is reduced if you have End User Verification set to YES and/or can rely on the protection of the email account. |
2 | Social Engineering Depending on the question, an intruder may be able to guess or obtain the answer. For example, if the challenge is the user’s pet name, date of birth, etc, an intruder may know this information already or be in a position to obtain it (social media, access to and misuses of HR information). | GRC configuration can be used to limited questions to pre-defined Administrator questions only. User will not have the option to create questions. They will be required to register and provide their answers. Users need to be educated to choose questions and answers that are not publicly available. System Administrators can preview the challenge questions (answers are hashed but table should also be protected from access in SE16) and also system configuration can limit question creation to administrators only. Administrators are then in a position to set appropriate questions. |
3 | Guessing An intruder may guess the answers to the questions without using social engineering tactics. For example, if the challenge includes questions such as ‘What is your date of birth?’; ‘Where were you born?’; ‘What is your pet’s name?’, an intruder may have access to that information via social networks, knowledge about the user or even information user keeps on their desk. | The GRC Configuration allows you to specify the number of questions as well as attempts. To reduce the risk of guess-work, minimise the number of attempts and maximise the number of questions. For example, only allow 3 attempts at an incorrect answer and require the user to answer 4 questions. The specific numbers needs to be weighted against usability – the actual user may struggle to remember that many questions (i.e. it is technically impossible to have up to 100 question but would that be feasible?). Alternatively, train users to disregard the actual question and answer something different. Therefore, if the intruder knew the answer the question, they would still be incorrect. I found this idea in a news article (unable to locate source). However, in practise, this might be confusing for the user and make the solution unworkable. |
4 | Table Access Questions and Answers by the user in the registration process are stored in table GRACQUESTION. Answers are stored in hash value. | GRC table GRACQUESTION must be restricted to prevent users from downloading and reverse-engineering the hash values. |
5 | Registration process If a user has not registered their questions for Password Self Service then an intruder could access the account, register questions and then use those answers to request a password reset. | End User Verification would require the intruder to know the password for authentication. Secondly, there is still reliance on email address access being restricted. If you cannot rely on email address, then Verification should be used in the initial step. |
Reset Password
Once a user has proven their identity (End User Logon or Challenge Response) they can now select the system they require a password reset for. Users will only see the systems for which PSS has been enabled (IMG configuration controls this) and the user has access to. In this document, the example of SAP ECC has bee chosen. Therefore, a BAPI is called via RFC connection to reset the user password.
Risk # | Summary | Mitigation |
1 | Network Sniffing A remote function call executes a BAPI in the plug-in system to reset the password and return the information back to the GRC component to communicate to the user. If | Protect the system to system communication through secure network communication (SNC) to prevent eavesdropping as password will no be sent in clear text. The service user account should also be restricted for permissions in the plug-in system to limit S_RFC access. |
2 | Password Strength Weak passwords can be guessed. | User RZ10 system parameters and PRGN_CUST table settings to control the length and complexity of the initial password as well as the validity before password expires. Use of security policy can be implemented to differentiate rules for difference user groups but this will not apply to the initial password set by GRC. |
| 3 | System/Service Accounts are reset System functionality stops working as users fail on authentication | If End User Verification is not used (no password) there is risk that users could request reset of password for System/Services accounts. The user is unlikely to receive an email with the password information, however, system functionality will fail. For example, if the user for PSS password (stored in SICF) is reset then no users will have access to PSS. To avoid this, use security authorisations to restrict access to the accounts. Ensure accounts that should not be reset via PSS are in a special User Group and exclude access on S_USER_GRP authorisation |
| 4 | Account is Locked User account is locked when attempting to request new password | Accounts with a lock status of 128 (refer source system table USR02 for UFLAG field) will be automatically unlocked as part of the password reset. All other lock statuses are deliberate actions by a system administrator. The GRC PSS functionality has an inherent system control to check lock status and prevent password reset/unlock. Users will receive an error message (refer to Can Password Self Service unlock User?) Accounts with a Administrator lock need to be handled via the ARQ workflows. |
Emailing User
SAP GRC component will generate an email and send the login details to the user. System configuration can control if the password is specified in the email or if a URL is embedded instead. The URL example has been shown in this diagram.
Risk # | Summary | Mitigation |
1 | Network/Email Directory Access System Administrators, etc may have access to the email directory and be in a position to access the users email | Do not include the password in the email but send the URL link instead (as depicted in this scenario). Refer to section below for URL link and Password Change. |
2 | External Email Accounts Non-company email addresses may not be adequately secure for company policies | Limit configuration in transaction SCOT to specific domains only. Therefore, users will need to have a company email address. This solution will not work if your users have external accounts. You will also need to ensure the data sources for the user details contain the correct email address as per these rules. |
3 | SAP GRC access to SOST/SCOT Transaction SOST allows you to see email communication sent by the GRC system as well as forward the message to another account. | Restrict access to this transaction or prevent the administrator from viewing the contents of the message (can only see header instead) |
URL Link and Password Change
The GRC configuration allows you to choose send a password URL link or the actual password. This is set within the configuration for User Provisioning. As part of sending URL link only, you will need to specify how long the link is valid for before it expires. If Yes is chosen,the initial password is sent to the user. If no is set, the user receives an email with the URL to launch to then obtain the password.
At the end of this process, the user is now able to login with the initial password and change it. The change password rules adhere to the plug-in system configuration (USR40 password dictionary, RZ10 configuration parameters and security policy). These rules are not specific to GRC but based on SAP login sequence.
Conclusion
When you design your PSS process you need to choose the appropriate combination of steps for your organisation. At a minimum, you must define at least one step where you have confidence that only the user will know the information. This may be the Initial Logon, Challenge Response or Email.
Feedback and suggestions are encouraged, Please add your comments below – especially if you can contribute any more risks that should be considered as part of the PSS design process.
Regards
m.lee and alessandr0
Review and input by gretchen.lindquist and leos
- SAP Managed Tags:
25 Comments
