Are your security parameters strong enough to ward off an attacker looking for vulnerability in your system? Are you compliant? What other issues can affect your security parameters? Two experts, Richard Castle of Ernst and Young, and Selva Kumar, of Softsquare LLC, have some advice.

Richard Castle says that configuration parameters play a significant role in maintaining security controls in SAP installations. At the spring SAPinsider GRC 2011 conference, he discussed user provisioning, restricting access to Basis objects and transactions, functional transactions, assigning adequate segregation of duties to users, and limiting access to customized tables, programs, and transactions. In his talk, “An External Auditor’s Guide to Preparing Your Landscape for a Security Audit,” he provided some common security parameters, shown in Table 1.

Richard advises you to ask the following questions regarding security parameters:

1. Do your security parameters align with your policy?
2. Are your security parameters consistent between SAP instances
3. Are your security parameters reasonable in terms of minimizing risk, yet not overly restrictive (e.g., too many caveats on passwords)?
4. Are your security parameters documented in your risk and control matrices?
5. How do your security parameter settings match up with your external auditor expectations?

Let’s assume that you’ve gone through those five checkpoints with regard to parameters. What other issues should concern you?

I recently spoke with Selva Kumar, the vice president of Softsquare LLC (https://www.softsquare.biz), which offers services related to cloud computing and SAP integration to third-party systems. Selva responded to my questions about security parameters and challenges that his clients face.

Q: Your training video for using SAP transactions for SAP system parameters explains how to maintain a profile parameter and display profile parameter attributes. The video seems straightforward, but are there any steps involved in maintaining or displaying parameters that security administrators sometimes forget? Is there a common mistake that they make?

A: The common mistake is the user entering the wrong value and also not knowing the implications of the parameter change. Most of the security parameters are straightforward. But some of the memory-related parameters in Basis can have very negative consequences if not properly tested.

Q: What’s the toughest challenge related to aligning security parameters with a company’s policies?

A: The time-out policy for systems. The automatic logoff is only 10 minutes. Factory workers at a job site have complained about stepping away from the computer while working and then having to log on again. This setting cannot be adjusted, or we would be noncompliant.

Q: How do you ensure that security parameters are consistent between SAP instances?

A: When there’s a system refresh, we manually make sure that parameters match the SAP security policy. The parameter file can be downloaded from one system and uploaded into a newly created system.

Q: How would you gauge if your security parameters are too restrictive? Would you ask the users of systems for feedback?

A: We hear comments from workers about the auto logoff or a password change policy frequently. Some users will complain that they have to change their password frequently. But these security measures are required to protect the system as the security risks from internal users are much greater in companies. Most of the security risk in a company is from an insider attack. If the person next to you can see your unlocked computer with the SAP screen open, he can access the information or act on the data.

Q: How would you determine if your security parameter settings match an auditor’s expectations?

A: I usually work closely with the internal audit group of the company to follow the best practices on all the parameters. The internal audit group is closely involved right from the development of the SAP security policy document. They are one of the major stakeholders in determining the security policy. We also document any deviations from the best practices in the security policy document.

Q: Which of the five checkpoints for security parameter settings would you consider the most important? Why?

A: Point 3. The 60- to 90-day password change policy, locking of a system after three failed attempts, a 10-minute logoff policy, and complex password and password length are all very important security parameters.

Q: What difficulties have your clients encountered regarding balancing risks versus being overly cautious?

A: There is a constant pushback from the end-user community for changing the policy so it is less restrictive. When you have multiple systems, they have to change their passwords and remember them, so some of the clients have implemented single sign-on to alleviate the problem. With regard to a logoff policy, they do work with end users and see if the time can be increased. But a logoff policy is a risky one; if you are working on a factory floor, people could use your terminal when you have walked away. If you do not log them off, the access could be abused. With respect to length of the passwords, some clients have provided the user with password generation and storing tools that can help them create a password and also safely store it, so they do not write them down on a notebook or some other place where other people can see them.

Q: Do you have an example of when a client changed a policy in response to feedback from users while still being able to remain compliant?

A: I have seen clients change the auto logoff policy to accommodate the people on the factory floor as they have to check things and they get logged out before they can complete the transaction. When they make the policy change, the change will be reviewed and recommended by the internal auditors. This recommendation will be based on a valid business case. When the companies decide to change the policy, they will also document the change in the company policy document to reflect a new auto logoff policy. Generally, the external auditors will not recommend a value or specific threshold for any policy. They will make sure the policy confirms with the generally accepted industry practices. If they see a policy change that does not conform with industry practice, they will ask for business justification. If the company has documented the business case for deviation, it will not be a violation of company policy.

Q: What issues related to security parameters would a company that acquires another company have?

A: Make sure that you have a security policy that matches up throughout the company. A company located in a third-world country might not have the same policy as a Fortune 500 company, so the audit compliant security policy should be enforced in all the systems in the company. The new company that is being acquired should be required to comply with the security policy.

Q: What features of SAP BusinessObjects Access Control 10.0 have your clients been the most interested in?

A: The ABAP version of the GRC tool is tightly integrated with SAP, and it will resolve a lot of the performance issues. Now all the GRC tools are going to be on the same ABAP system, giving them unified access to the systems. The reports can be customized, and also user-defined reports can be created. Firefighter logs can be routed through workflow, and more detailed transaction details are available in the Firefighter reports. You can customize the user request form in the user provisioning screen. The customizing helps companies take away some of the fields and include some others that are required.  Let us say they want to have company code as a selection criterion. Then it could also be included in the form.

Q: If a company chooses to outsource some of its business processes, what challenge does that pose to security administrators?

A: The sharing of passwords with somebody else, not following the procedure for changing passwords or giving excess access to users, not following the process when making role changes, not documenting the changes, not getting proper approval, skipping the testing, transporting unnecessary roles, and overlaying the roles with old roles are the common problems with outsourcing.

Q: What issue related to security parameters and compliance are your clients most concerned about?

A: One of the big concerns is not complying with a security policy. When new systems are created, the security parameters need to be checked to make sure they comply with the company’s security policy.

Q: So then your clients are saying their biggest challenge is getting users to comply with security policies when a new SAP system is deployed? Do you have an example of when one of your clients felt frustrated by this issue?

A: One of the clients wanted to implement a 45-day password change policy. The users were not happy with the policy as they have to change their passwords every 45 days. The client had four production systems and multiple production support systems. So the users felt that they had to constantly change their passwords, and also there were a lot of help desk tickets for resetting passwords. Finally, the client working with internal auditors was able to implement single sign-on to help the users.

Q: Do your clients ever feel stuck between keeping workers content and maintaining a level of security controls that is strong enough for the company to remain compliant? Could you cite an example of when a client had this feeling with regard to a specific system?

A: More and more clients are going for a thin layer front-end interface. SAP NetWeaver Portal is the front-end tool they use to access the SAP system. The portal is an outward-facing front-end tool that can be attacked by hackers. Some percentage of users are in the field, and they run reports from the SAP system. The system is accessed over the Internet from remote locations. The password strength, change frequency, and auto logoff policy cannot be changed for that reason.

Q: We recently published an article in entitled “10 Tips to Ensure Compliance Doesn’t Slip After a GRC 10.0 Go-Live.” Have you advised a client on how to maintain compliance after a system goes live? Can you describe this experience? That is, what were the challenges? Did you receive support for your recommendations regarding compliance issues, or were they challenged by the business implementing the system?

A: SAP GRC’s policy lifecycle management capabilities help security administrators to manage the policy life cycle of creating, reviewing, and approving policies, and linking policies to risks and control. (Note: The SAP BusinessObjects GRC 10.0 applications were released for general availability on August 10, 2011, so a lot of these life cycle management features are available now.)

Q: We published another article titled “How to Migrate Your Current SAP Business Objects Access Control Deployment to Version 10.0.” Do any of your clients plan to upgrade their systems to SAP BusinessObjects Access Control 10.0? If so, what concerns have they voiced about maintaining security during this upgrade?

A: My client will be upgrading shortly. One of the main concerns is the migration since we are moving from a Java-based system to a completely ABAP-based platform. All the configuration done in the Java-based system has to be done in the new ABAP-based system. All the workflow settings, approvers, sensitive roles, and stages in the SAP GRC tool have to migrate to new software. Since it is an entirely new platform, it will be considered as a new install. Additionally, the hardware requirement needs to be reviewed as there will be a performance impact on the existing ABAP system. One of the major impacts is going to be training and documentation. Now all the training has to updated, and help documentation has to be rewritten.

Gary Byrne

Gary is the managing editor of Financials Expert and SCM Expert. Before joining WIS in March 2011, Gary was an editor at Elsevier. In this role he managed the development of manuscripts for Elsevier’s imprint responsible for books on computer security. Gary also has held positions as a copy editor at Aberdeen Group, a Boston-based IT market research company, and as an editor at Internet.com, a publisher of content for the IT community. He also gleaned experience working as a copy editor for International Data Corp., a Framingham, MA-based IT market research company. He earned a bachelor of science degree in journalism from Suffolk University in Boston. He enjoys traveling, sailing as a passenger onboard schooners, and helping his wife, Valerie, with gardening during summer weekends. He’s a fan of all the Boston sports teams and once stood behind Robert Parish in a line at BayBank. He felt small and didn’t ask for an autograph. You can follow him on Twitter at @FI_SCM_Expert. His online footsteps can also be found in the SAP Experts group on LinkedIn.

You may contact the author at gary.byrne@wispubs.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.