
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. |
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. |
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. |
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) |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.