Modern enterprises are facing a perfect storm of increasingly sophisticated technology, changing regulations, and cybersecurity attacks that are rapidly growing in their scale, scope, and speed. In today’s technology landscape, cloud and mobile connectivity to SAP systems demand more than just network firewalls and perimeters to effectively protect your applications, and auditors and compliance managers are looking for more than just segregation of duties to effectively mitigate risk.

GRC 2016 speaker Julie Ford of Customer Advisory Group, an expert with more than 13 years of experience as an architect in SAP security, recently took questions during a live Q&A on how best to stay ahead of hackers and protect critical SAP data. She answered questions on how to manage SAP landscape security and work with auditors, such as:

• What is cybersecurity and how does it apply to SAP?

• What is the current SAP Threat Matrix? How can I best evaluate my systems to determine whether they are vulnerable to hackers?

• What types of data do hackers look for in SAP systems and what would they do with it?

• What are some best practices for protecting my SAP systems?

• What questions are auditors asking about SAP and cybersecurity?

Transcript:

Natalie Miller, SAPinsider: Hello and welcome to today’s live Q&A on protecting your SAP data from cybersecurity threats. I’m Natalie Miller, features editor of SAPinsider and insiderPROFILES, and I’m excited to introduce today’s panelist, Julie Ford, Global Cybersecurity Lead and Senior GRC Customer Advisor at Customer Advisory Group. Julie will also be a speaker at our GRC 2016 event in Vienna this June.

Julie has more than 13 years of experience as an architect in SAP security, cybersecurity, governance, risk, compliance, and information assurance, and she has worked with multiple GRC implementations, security redesigns, and audit remediation. 

Hi, Julie, thank you so much for being here today!

Julie Ford, Customer Advisory Group: Hello, everyone.

Natalie Miller: There are some great questions from readers already waiting for you, but to kick things off, can you explain what cybersecurity means at the SAP information security level?

Julie Ford: Cybersecurity at the SAP information security level is a separate entity from network security or intrusion detection. The SAP security team needs to be in a defensive position, working with the BASIS, server, and database teams to ensure they are able to prevent intrusion rather than detect it.

Comment from Ashish: Does SAP have or plan to have an SAP firewall that overrides all the third-party firewall policies? If this is possible, will SAP have its own sets of updates on security threats that can be applied to its firewall, hence protecting all the SAP applications from cybersecurity threats?

Julie Ford: There is no plan to do this to my knowledge. The SAP Enterprise Threat Detection tool on SAP HANA is the closest currently in place, and it is not offering any third party policy or patching.

Comment from Sam: On the topic of vulnerability assessment / configuration (i.e. security settings) management, we are currently considering Onapsis against a custom solution made of SAP Solution Manager, EqSmart, and in-house tools. Am I correct in thinking that Onapsis has a vulnerabilities DB, whereas Solution Manager just assesses patch levels for various SAP components? Does SAP view the Onapsis solution as superior when compared to consistent patching based on gaps identified by Solution Manager? What is the edge or added value with Onapsis versus consistent patching?

Julie Ford: I don’t know how SAP views the Onapsis tool. I have used their solution myself and the older version I had opportunity to use was good. The decision that needs to be made is if the cost of the solution is worthwhile in light of the long note development cycle when using the existing SNOTE processes accomplish the same thing. Onapsis will perform the test and alert you to new vulnerabilities, including those that SAP hasn’t released yet. But if the vulnerability is new, the solution is still a year out, and Onapsis won’t be able to propose a solution. The last time I looked at the Onapsis solution, it still required manual application of security notes and system configuration change recommendations made by the system. 

Comment from Sam: On the topic of the implementation of corrective actions, we know from PwC cyber-risk practice that SAP vulnerabilities remain open an average of 12-18 months before either a patch is provided or before a patch can be applied. The main reason for slow patching is assurance through change management procedures (for example, regression testing). Do you have any suggestions to speed up this cycle? Should we decide to perform timely patching, does SAP provide impact assessments together with patches? And how can we gain additional assurance that functionality is unaffected?

Julie Ford: To my knowledge, SAP does not provide any assurance or assessment of patch/security notes against the current system. It also would not be possible to offer assurances against patch-related issues within specific configurations or in light of customizations different companies may have done. The best defense in this situation is an educated SAP Security and BASIS team along with a solid process for note review, implementation, and testing or aging them in a QA system.

Comment from Sam: In general, can SAP share customer success stories in this area or provide a list of reference customers who have successfully addressed the vulnerability / remediation cycle?

Julie Ford: I can’t address if SAP has customer success stories. I can only speak to what I have done over the years, and I don’t work for SAP.

Comment from Guest: If we integrate some other application with SAP R/3 for any document or file uploading, what would the security threat be for our system? When connecting with another application, what can be the threat for our data or system?

Julie Ford: Yes, each connection from SAP out to another application opens a door via the communications channel. This is a threat, and that communications channel and the security around the user IDs touching that channel need to be carefully created and monitored.

Comment from Andrzej: How can we recover after an attack?

Julie Ford: This would follow standard disaster recovery procedures. If the system is compromised and modified during an attack, a restore from backup would be necessary. If the attack is data theft, forensic investigation at the SAP, database, server, and network layers will have to happen. Then you’ll need an analysis of your security and closure of the holes used to perform the attack. The corporate lawyers have to get involved to manage prosecution.

Comment from Andrzej: How can we recognize a slow attack, like the insertion of fake transactions distributed over time, and how can we recover after that kind of attack?

Julie Ford: The new SAP Enterprise Threat Detection tool can help in this. This would also be done through transaction usage data found in STAD or in GRC. Otherwise, you would need to use log traces in the network routers and intrusion detection systems.

Comment from Masood: What are the tools available to scan/monitor and recommend SAP vulnerabilities that need to be implemented in SAP systems?

Julie Ford: There are a number of tools available:

• ERP Scan – erpscan.com
• ESNC Security Suite for SAP Applications – esnc.de
• Onapsis – onapsis.com
• SAPYTO – cybsec.com

Comment from Aman Dhillon: Ashish, there are SAP applications gateways that you can use to augment network firewalls for controlling access to SAP servers. Look into ACLS within the SAProuter and Web Dispatcher.

Julie Ford: Yes, this is true. The SAProuter and Web Dispatcher are critical for security and patching. There are no policies for network routers or intrusion systems from SAP.

The biggest thing to recognize is that cybersecurity is not a single tool, and when applying the term to SAP, it is a collaboration of server security, database security, and SAP security with all its related patch and hot fix maintenance.

Cybersecurity is a collaboration of these elements: policy, governance and risk management, application security, information security, and network security.

Comment from Guest: What’s the current SAP Threat Matrix? How can I best evaluate my systems to determine whether they are vulnerable to hackers?

Julie Ford: The current SAP Threat Matrix is published on the SAP Security News Page. Managing the security notes through SNOTE and being educated on the types of threats and how your system uses the tools utilizing those technologies allows you to build a threat matrix relevant to your implementation. Click here for more information.

Comment from Masood: It is very difficult to review SAP Notes each month and make decisions whether to implement them. I think SAP should encourage customers to implement all the vulnerabilities patches; otherwise, a lot of customers won’t take it seriously.

Julie Ford: I agree that managing the security notes is not a small task, and companies need to understand the risk in order to add security note evaluation and application to the project plans each month. Raising awareness at the CISO level for all application security is critical to moving this forward.

Comment from Aman Dhillon: Sam, Solution Manager does a lot more than just monitor patch levels. It can discover vulnerabilities in your system configuration. All you have to do is import a strong ruleset into configuration validation.

Julie Ford: Agreed, but many clients do not use Solution Manager to this level due to the complexity of implementation. If it is implemented, there are ways to connect SAP Process Control to monitor and report out through audit to create accountability in the application of the vulnerabilities noted.

Comment from Jeffrey Miller: Have you been involved in an SAP S/4HANA cloud edition install yet, and if so, are there any security concerns you can foresee?

Julie Ford: I have not as of yet been involved in a HANA cloud implementation or been able to do a security evaluation of one.

Comment from Rob: What are best practices for managing security notes?

Julie Ford: Best practice for security notes is to first understand the vulnerabilities being discussed. Review the notes and discuss specific ones that may impact business with the development teams. After that, I recommend a monthly application, leaving them in QA to age for a month and be tested via the other user acceptance testing in process. Then, move them to production. This applies to non-urgent notes. Urgent notes should be applied immediately.

Comment from Masood: Are these tools delivered by SAP?

Julie Ford: There are some items delivered by SAP, like SNOTE and the alerts from Solution Manager. Other tools are by third-party vendors.

Comment from Len: What are the best ways to work with auditors on their questions related to system, network, and communications security?

Julie Ford: Auditors are becoming savvier with their questions. The best way to manage this is to have a patching program in place with documentation on what was applied and when to SAP, the database, and the server level. Also, document the process for managing RFC connections and RFC security. This is a good start and keys into the standard SAP Security Auditor work.

Comment from Kee: Are there any best practices or recommendations provided on security for an SAP landscape from a cyber threat perspective? I understand there is not one tool that does it all, but some guidelines or some sort of checklist will help.

Julie Ford: There is a security review offered by SAP, but beyond that it’s a matter of working with the business to decide how critical the data in SAP is and what they are willing to invest in its defense. The first step is at the SAP Security level — make sure you have least privilege, that RFC access is fully defined in roles, that you use S_TABU_DIS and S_TABU_NAM fully, and that no one, including batch IDs, has SAP_ALL.

After that, you should have a security notes application process, a review of external connections, and the security audits from external vendors. Those things can all be done internally for a zero dollar investment. If the company wants to go deeper, then there will be a tool investment from a third party required.

Comment from Masood: Is there a document that we can follow to engage Solution Manager to perform a scan of vulnerabilities in participating systems?

Julie Ford: You can work with your BASIS team for their development plan for Solution Manager. They will be able to help set up the monitoring of vulnerabilities.

Comment from Aman Dhillon: For applying security patches, the most common practice in my experience is Hot News within 30 days and High within 90. There’s usually a quarterly patching cycle. Mediums and lows get implemented through SPs. ‘Immediate’ is not possible in most cases.

Julie Ford: Aman, quarterly is not necessarily a workable process any longer. The volume of notes is too high for most companies to manage and it would require a full project kickoff in order to deal with the amount of time required away from other work. By implementing on a rolling monthly basis, the workload is leveled and overall awareness is raised.

Comment from Kee: Have you done any Pen testing at the SAP landscape level to identify back doors and loop holes in the enterprise security architecture? Do you recommend companies performing that to get their security posture around SAP applications (n/w and communications)? I don’t see them done often.

Julie Ford: I have worked with Onapsis to do penetration testing, both black and white box testing into SAP. There are not a lot of companies doing this yet, but I have worked with them. There are others out there:

• ERP Scan – erpscan.com
• ESNC Security Suite for SAP Applications – esnc.de
• Onapsis – onapsis.com
• SAPYTO – cybsec.com

Comment from Aman Dhillon: I agree that monthly is ideal, but most customers can’t perform regression tests on a monthly basis.

Julie Ford: Not all notes require full regression testing. Working with the applications developers/configuration people will help flag those that do.

Comment from Christine: What are the different considerations we need to keep in mind for application, information, and network security? Are auditors becoming savvier at all levels of the security structure?

Julie Ford: Excellent question! At all layers, it’s a matter of figuring out what is critical information and what is public information. Once that is decided upon, information security is the decision about who can see what data across all applications. HR data, for example, is always secured in SAP, while other aapplications, the data can be secured at the network directory/file share level. The network security piece would address what applications can reach through the network firewalls and touch HR data.

At the SAP layer, managing the application security includes the well-publicized GRC portions to manage SOD and fraud, but that should be expanded into a process of giving only what the users need to do their jobs and reducing access as much as possible.

Comment from Kee: Is there a community or forum that is actively discussing / posting on SAP cybersecurity topics? It will be nice to exchange ideas, as that is one of the goals for most security SMEs in this forum.

Julie Ford: There are a lot of groups on LinkedIn discussing SAP Security, but I haven’t seen ASUG get deeply involved in the cybersecurity aspects yet. It would be excellent if the security and GRC advisory group in ASUG would become more involved. There are some very active groups on ISACA talking about application security and enterprise security, and they are expanding the COBIT processes down into ERP Security with special addendums addressing SAP Security. Their forums are quite good.

Comment from Matt: What are some key sensitive functions are that need to be restricted in SAP?

Julie Ford: At the authorization object level, you need to restrict the classic finance and HR ones, but the biggest threats are around S_RFC, S_TABU_DIS, S_TABU_NAM, S_PROGRAM, etc. More care needs to be given in areas involving intellectual property stored inside of SAP — BOMs, recipes, etc. — that are given out for display access by rote. This is a problem, and loss of intellectual property rights has been reported through this avenue.

Comment from Christine: How do you think moving to SAP HANA will impact information security? If data is residing in the SAP HANA system, is it more susceptible to risk?

Julie Ford: The problem with HANA isn’t in the change of security — it adds another layer of security. The problem is in the volume of data that will be available at a single source. The risk in moving to HANA is that data segregation will be reduced, archiving will not be quite as needed, and larger volumes of information will be at a hacker’s fingertips.

For example, if you have different modules segregated across landscapes, the data is not available for a single mass copy and more system traversal is necessary. It’s a security process called ‘defense in depth.’ HANA flattens that depth.

Natalie Miller: As we come to the end of today’s Q&A, I’d like to thank you all for joining us and for all these great questions! And a big thanks to Julie for these insightful answers!

Julie Ford: My latest blog article on the subject is also available on our site. I will be publishing more soon.

For information about our cybersecurity services, please go to our cyber services page on the Customer Advisory Group's website.

Julie Ford, Global Cybersecurity Lead and Senior GRC Customer Advisor, Customer Advisory Group
Julie Ford is a senior member of the Customer Advisory Group with a Master’s degree in cybersecurity from the University of Maryland and more than 13 years of experience as an architect in SAP security, cybersecurity, governance, risk, compliance, and information assurance. Julie is accustomed to working in global fast paced, high volume environments working with local and offshore resources, complex landscapes, and integration issues. Leveraging a wide-range of talents in computer technology, staff leadership, federal audit, and regulatory compliance, Julie provides a solid foundation to address all aspects of information systems across all platform types, project requirements, and business needs. Julie has worked with multiple GRC implementations, security redesigns, and audit remediation. She is an SAP TechEd and dCode speaker and an expert in the area of cybersecurity for SAP.

Modern enterprises are facing a perfect storm of increasingly sophisticated technology, changing regulations, and cybersecurity attacks that are rapidly growing in their scale, scope, and speed. In today’s technology landscape, cloud and mobile connectivity to SAP systems demand more than just network firewalls and perimeters to effectively protect your applications, and auditors and compliance managers are looking for more than just segregation of duties to effectively mitigate risk.

GRC 2016 speaker Julie Ford of Customer Advisory Group, an expert with more than 13 years of experience as an architect in SAP security, recently took questions during a live Q&A on how best to stay ahead of hackers and protect critical SAP data. She answered questions on how to manage SAP landscape security and work with auditors, such as:

• What is cybersecurity and how does it apply to SAP?

• What is the current SAP Threat Matrix? How can I best evaluate my systems to determine whether they are vulnerable to hackers?

• What types of data do hackers look for in SAP systems and what would they do with it?

• What are some best practices for protecting my SAP systems?

• What questions are auditors asking about SAP and cybersecurity?

Transcript:

Natalie Miller, SAPinsider: Hello and welcome to today’s live Q&A on protecting your SAP data from cybersecurity threats. I’m Natalie Miller, features editor of SAPinsider and insiderPROFILES, and I’m excited to introduce today’s panelist, Julie Ford, Global Cybersecurity Lead and Senior GRC Customer Advisor at Customer Advisory Group. Julie will also be a speaker at our GRC 2016 event in Vienna this June.

Julie has more than 13 years of experience as an architect in SAP security, cybersecurity, governance, risk, compliance, and information assurance, and she has worked with multiple GRC implementations, security redesigns, and audit remediation. 

Hi, Julie, thank you so much for being here today!

Julie Ford, Customer Advisory Group: Hello, everyone.

Natalie Miller: There are some great questions from readers already waiting for you, but to kick things off, can you explain what cybersecurity means at the SAP information security level?

Julie Ford: Cybersecurity at the SAP information security level is a separate entity from network security or intrusion detection. The SAP security team needs to be in a defensive position, working with the BASIS, server, and database teams to ensure they are able to prevent intrusion rather than detect it.

Comment from Ashish: Does SAP have or plan to have an SAP firewall that overrides all the third-party firewall policies? If this is possible, will SAP have its own sets of updates on security threats that can be applied to its firewall, hence protecting all the SAP applications from cybersecurity threats?

Julie Ford: There is no plan to do this to my knowledge. The SAP Enterprise Threat Detection tool on SAP HANA is the closest currently in place, and it is not offering any third party policy or patching.

Comment from Sam: On the topic of vulnerability assessment / configuration (i.e. security settings) management, we are currently considering Onapsis against a custom solution made of SAP Solution Manager, EqSmart, and in-house tools. Am I correct in thinking that Onapsis has a vulnerabilities DB, whereas Solution Manager just assesses patch levels for various SAP components? Does SAP view the Onapsis solution as superior when compared to consistent patching based on gaps identified by Solution Manager? What is the edge or added value with Onapsis versus consistent patching?

Julie Ford: I don’t know how SAP views the Onapsis tool. I have used their solution myself and the older version I had opportunity to use was good. The decision that needs to be made is if the cost of the solution is worthwhile in light of the long note development cycle when using the existing SNOTE processes accomplish the same thing. Onapsis will perform the test and alert you to new vulnerabilities, including those that SAP hasn’t released yet. But if the vulnerability is new, the solution is still a year out, and Onapsis won’t be able to propose a solution. The last time I looked at the Onapsis solution, it still required manual application of security notes and system configuration change recommendations made by the system. 

Comment from Sam: On the topic of the implementation of corrective actions, we know from PwC cyber-risk practice that SAP vulnerabilities remain open an average of 12-18 months before either a patch is provided or before a patch can be applied. The main reason for slow patching is assurance through change management procedures (for example, regression testing). Do you have any suggestions to speed up this cycle? Should we decide to perform timely patching, does SAP provide impact assessments together with patches? And how can we gain additional assurance that functionality is unaffected?

Julie Ford: To my knowledge, SAP does not provide any assurance or assessment of patch/security notes against the current system. It also would not be possible to offer assurances against patch-related issues within specific configurations or in light of customizations different companies may have done. The best defense in this situation is an educated SAP Security and BASIS team along with a solid process for note review, implementation, and testing or aging them in a QA system.

Comment from Sam: In general, can SAP share customer success stories in this area or provide a list of reference customers who have successfully addressed the vulnerability / remediation cycle?

Julie Ford: I can’t address if SAP has customer success stories. I can only speak to what I have done over the years, and I don’t work for SAP.

Comment from Guest: If we integrate some other application with SAP R/3 for any document or file uploading, what would the security threat be for our system? When connecting with another application, what can be the threat for our data or system?

Julie Ford: Yes, each connection from SAP out to another application opens a door via the communications channel. This is a threat, and that communications channel and the security around the user IDs touching that channel need to be carefully created and monitored.

Comment from Andrzej: How can we recover after an attack?

Julie Ford: This would follow standard disaster recovery procedures. If the system is compromised and modified during an attack, a restore from backup would be necessary. If the attack is data theft, forensic investigation at the SAP, database, server, and network layers will have to happen. Then you’ll need an analysis of your security and closure of the holes used to perform the attack. The corporate lawyers have to get involved to manage prosecution.

Comment from Andrzej: How can we recognize a slow attack, like the insertion of fake transactions distributed over time, and how can we recover after that kind of attack?

Julie Ford: The new SAP Enterprise Threat Detection tool can help in this. This would also be done through transaction usage data found in STAD or in GRC. Otherwise, you would need to use log traces in the network routers and intrusion detection systems.

Comment from Masood: What are the tools available to scan/monitor and recommend SAP vulnerabilities that need to be implemented in SAP systems?

Julie Ford: There are a number of tools available:

• ERP Scan – erpscan.com
• ESNC Security Suite for SAP Applications – esnc.de
• Onapsis – onapsis.com
• SAPYTO – cybsec.com

Comment from Aman Dhillon: Ashish, there are SAP applications gateways that you can use to augment network firewalls for controlling access to SAP servers. Look into ACLS within the SAProuter and Web Dispatcher.

Julie Ford: Yes, this is true. The SAProuter and Web Dispatcher are critical for security and patching. There are no policies for network routers or intrusion systems from SAP.

The biggest thing to recognize is that cybersecurity is not a single tool, and when applying the term to SAP, it is a collaboration of server security, database security, and SAP security with all its related patch and hot fix maintenance.

Cybersecurity is a collaboration of these elements: policy, governance and risk management, application security, information security, and network security.

Comment from Guest: What’s the current SAP Threat Matrix? How can I best evaluate my systems to determine whether they are vulnerable to hackers?

Julie Ford: The current SAP Threat Matrix is published on the SAP Security News Page. Managing the security notes through SNOTE and being educated on the types of threats and how your system uses the tools utilizing those technologies allows you to build a threat matrix relevant to your implementation. Click here for more information.

Comment from Masood: It is very difficult to review SAP Notes each month and make decisions whether to implement them. I think SAP should encourage customers to implement all the vulnerabilities patches; otherwise, a lot of customers won’t take it seriously.

Julie Ford: I agree that managing the security notes is not a small task, and companies need to understand the risk in order to add security note evaluation and application to the project plans each month. Raising awareness at the CISO level for all application security is critical to moving this forward.

Comment from Aman Dhillon: Sam, Solution Manager does a lot more than just monitor patch levels. It can discover vulnerabilities in your system configuration. All you have to do is import a strong ruleset into configuration validation.

Julie Ford: Agreed, but many clients do not use Solution Manager to this level due to the complexity of implementation. If it is implemented, there are ways to connect SAP Process Control to monitor and report out through audit to create accountability in the application of the vulnerabilities noted.

Comment from Jeffrey Miller: Have you been involved in an SAP S/4HANA cloud edition install yet, and if so, are there any security concerns you can foresee?

Julie Ford: I have not as of yet been involved in a HANA cloud implementation or been able to do a security evaluation of one.

Comment from Rob: What are best practices for managing security notes?

Julie Ford: Best practice for security notes is to first understand the vulnerabilities being discussed. Review the notes and discuss specific ones that may impact business with the development teams. After that, I recommend a monthly application, leaving them in QA to age for a month and be tested via the other user acceptance testing in process. Then, move them to production. This applies to non-urgent notes. Urgent notes should be applied immediately.

Comment from Masood: Are these tools delivered by SAP?

Julie Ford: There are some items delivered by SAP, like SNOTE and the alerts from Solution Manager. Other tools are by third-party vendors.

Comment from Len: What are the best ways to work with auditors on their questions related to system, network, and communications security?

Julie Ford: Auditors are becoming savvier with their questions. The best way to manage this is to have a patching program in place with documentation on what was applied and when to SAP, the database, and the server level. Also, document the process for managing RFC connections and RFC security. This is a good start and keys into the standard SAP Security Auditor work.

Comment from Kee: Are there any best practices or recommendations provided on security for an SAP landscape from a cyber threat perspective? I understand there is not one tool that does it all, but some guidelines or some sort of checklist will help.

Julie Ford: There is a security review offered by SAP, but beyond that it’s a matter of working with the business to decide how critical the data in SAP is and what they are willing to invest in its defense. The first step is at the SAP Security level — make sure you have least privilege, that RFC access is fully defined in roles, that you use S_TABU_DIS and S_TABU_NAM fully, and that no one, including batch IDs, has SAP_ALL.

After that, you should have a security notes application process, a review of external connections, and the security audits from external vendors. Those things can all be done internally for a zero dollar investment. If the company wants to go deeper, then there will be a tool investment from a third party required.

Comment from Masood: Is there a document that we can follow to engage Solution Manager to perform a scan of vulnerabilities in participating systems?

Julie Ford: You can work with your BASIS team for their development plan for Solution Manager. They will be able to help set up the monitoring of vulnerabilities.

Comment from Aman Dhillon: For applying security patches, the most common practice in my experience is Hot News within 30 days and High within 90. There’s usually a quarterly patching cycle. Mediums and lows get implemented through SPs. ‘Immediate’ is not possible in most cases.

Julie Ford: Aman, quarterly is not necessarily a workable process any longer. The volume of notes is too high for most companies to manage and it would require a full project kickoff in order to deal with the amount of time required away from other work. By implementing on a rolling monthly basis, the workload is leveled and overall awareness is raised.

Comment from Kee: Have you done any Pen testing at the SAP landscape level to identify back doors and loop holes in the enterprise security architecture? Do you recommend companies performing that to get their security posture around SAP applications (n/w and communications)? I don’t see them done often.

Julie Ford: I have worked with Onapsis to do penetration testing, both black and white box testing into SAP. There are not a lot of companies doing this yet, but I have worked with them. There are others out there:

• ERP Scan – erpscan.com
• ESNC Security Suite for SAP Applications – esnc.de
• Onapsis – onapsis.com
• SAPYTO – cybsec.com

Comment from Aman Dhillon: I agree that monthly is ideal, but most customers can’t perform regression tests on a monthly basis.

Julie Ford: Not all notes require full regression testing. Working with the applications developers/configuration people will help flag those that do.

Comment from Christine: What are the different considerations we need to keep in mind for application, information, and network security? Are auditors becoming savvier at all levels of the security structure?

Julie Ford: Excellent question! At all layers, it’s a matter of figuring out what is critical information and what is public information. Once that is decided upon, information security is the decision about who can see what data across all applications. HR data, for example, is always secured in SAP, while other aapplications, the data can be secured at the network directory/file share level. The network security piece would address what applications can reach through the network firewalls and touch HR data.

At the SAP layer, managing the application security includes the well-publicized GRC portions to manage SOD and fraud, but that should be expanded into a process of giving only what the users need to do their jobs and reducing access as much as possible.

Comment from Kee: Is there a community or forum that is actively discussing / posting on SAP cybersecurity topics? It will be nice to exchange ideas, as that is one of the goals for most security SMEs in this forum.

Julie Ford: There are a lot of groups on LinkedIn discussing SAP Security, but I haven’t seen ASUG get deeply involved in the cybersecurity aspects yet. It would be excellent if the security and GRC advisory group in ASUG would become more involved. There are some very active groups on ISACA talking about application security and enterprise security, and they are expanding the COBIT processes down into ERP Security with special addendums addressing SAP Security. Their forums are quite good.

Comment from Matt: What are some key sensitive functions are that need to be restricted in SAP?

Julie Ford: At the authorization object level, you need to restrict the classic finance and HR ones, but the biggest threats are around S_RFC, S_TABU_DIS, S_TABU_NAM, S_PROGRAM, etc. More care needs to be given in areas involving intellectual property stored inside of SAP — BOMs, recipes, etc. — that are given out for display access by rote. This is a problem, and loss of intellectual property rights has been reported through this avenue.

Comment from Christine: How do you think moving to SAP HANA will impact information security? If data is residing in the SAP HANA system, is it more susceptible to risk?

Julie Ford: The problem with HANA isn’t in the change of security — it adds another layer of security. The problem is in the volume of data that will be available at a single source. The risk in moving to HANA is that data segregation will be reduced, archiving will not be quite as needed, and larger volumes of information will be at a hacker’s fingertips.

For example, if you have different modules segregated across landscapes, the data is not available for a single mass copy and more system traversal is necessary. It’s a security process called ‘defense in depth.’ HANA flattens that depth.

Natalie Miller: As we come to the end of today’s Q&A, I’d like to thank you all for joining us and for all these great questions! And a big thanks to Julie for these insightful answers!

Julie Ford: My latest blog article on the subject is also available on our site. I will be publishing more soon.

For information about our cybersecurity services, please go to our cyber services page on the Customer Advisory Group's website.

Julie Ford, Global Cybersecurity Lead and Senior GRC Customer Advisor, Customer Advisory Group
Julie Ford is a senior member of the Customer Advisory Group with a Master’s degree in cybersecurity from the University of Maryland and more than 13 years of experience as an architect in SAP security, cybersecurity, governance, risk, compliance, and information assurance. Julie is accustomed to working in global fast paced, high volume environments working with local and offshore resources, complex landscapes, and integration issues. Leveraging a wide-range of talents in computer technology, staff leadership, federal audit, and regulatory compliance, Julie provides a solid foundation to address all aspects of information systems across all platform types, project requirements, and business needs. Julie has worked with multiple GRC implementations, security redesigns, and audit remediation. She is an SAP TechEd and dCode speaker and an expert in the area of cybersecurity for SAP.