Panelists: Frederik Weidemann and Stephen Lamy
Sponsor: Virtual Forge Your SAP systems and the data within are an integral part of your business. You need to ensure your SAP applications are secure and stable, but there are a wide array of cybersecurity threats to worry about. Find out how to secure your SAP landscape from cyber threats and learn how to secure new technology like SAP HANA. Read the Q&A discussion transcript below expert advice from cybersecurity experts.
If you haven't already, subscribe to SAPinsider Online for free today! Matthew Shea: Hello, and welcome to today’s chat on cybersecurity. I am excited to be joined by Cybersecurity for SAP Customers 2017 speakers Frederik Weidemann and Stephen Lamy. Frederik and Stephen will answer questions on how to secure your SAP landscape from cyber threats and how to secure new technology such as SAP HANA. Stephen Lamy is the CEO and Managing Director of Virtual Forge, Inc., which offers products and services for the prevention, detection, and management of cybersecurity and stability issues in SAP systems and applications. His SAP career began in 1990 as a developer in the SAP Walldorf office, where he spent 16 years leading development teams for SAP HCM, as well as benefits, migration, and integration tools for R/2, R/3, SAP ERP Central Component (ECC), and SAP Business by Design. At Virtual Forge, Stephen continues to build on his reputation for producing innovative software that helps companies reduce risk, increase efficiency, and improve the quality of their SAP systems. Frederik Weidemann is Head of Consulting at Virtual Forge GmbH with a focus on SAP security for 11 years. He is a coauthor of the first book on ABAP Security,
Sichere-ABAP Programmierung, published by SAP PRESS, and he has spoken at several SAP- and security-related conferences such as RSA, Troopers, OWASP, and DSAG. Frederik frequently teaches on secure ABAP programming (course WDESA3) at SAP University in Walldorf and on SAP security for Virtual Forge's customers. He also writes articles on SAP security on a regular basis and has found numerous zero-day defects in business software. Frederik holds a German diploma in computer science and scored first or second place in several Capture-The-Flag hacking contests during his time in university.
Comment From Jeison: We have very tight IT security in place for our infrastructure. Do we still need to secure SAP systems separately?
Frederik Weidemann: The short answer is yes, of course. The long answer is in a way, SAP represents an entire IT infrastructure in itself, including authorizations, configuration, custom applications, and many others. That also means that a configuration error in an externally facing SAP-based application can circumvent the entire IT security concept. An example – although I hope a very unlikely one – is a vulnerability at Equifax that resulted from using the admin/admin combination of username and password. A standard SAP system installation creates not only one but also several standard usernames and passwords. If passwords for those are not changed, anyone can access the system with extensive authorizations by simply logging on to the respective logon page – even if this faces toward the public Internet.
Comment From vera.oneal: Do you have any suggestions for patch management survival for SAP servers?
Stephen Lamy: Unfortunately, there is no easy fix here. We do recommend that you apply these patches. However, we know this is sometimes difficult, as some patches require extensive manual effort or require the system to be restarted – a task that is difficult to do in a productive environment. A good tip to follow in this case is to first match the security patches with your system landscape (i.e., which patch applies to which systems). Also, you should establish a risk tolerance – can you live with a potential risk, and if so, for which systems?
Comment From Matchko: We have a lot of external users accessing our SAP system landscape – both SAP HANA and the regular SAP business suite. How can we ensure secure access for all users?
Stephen Lamy: There are several answers to this question and several points to consider. Here are just a few examples to consider. Client access needs to be secured. For SAP HANA, which is usually accessed using web browsers, this means encrypted communication, https. For other SAP systems, the SAP GUI will probably be used for access. And even the SAP GUI is not always secured – there was an example where an older version of the SAP GUI was vulnerable as it was exposing usernames and passwords in clear text. So, you want to make sure that anyone accessing the system is on the latest SAP GUI patch. Another example to consider is the handling of authorizations. If you stick to the rule that only those authorizations should be given to users who actually need to do their work, you would take a big step forward. And, of course, there are other things to consider, such as password complexity or, better yet, Single Sign-On (SSO) access, encrypted communication channels, and other factors.
Comment From Tony: Are there any special security requirements that we need to worry about for SAP HANA systems?
Frederik Weidemann: Most definitely. While on one hand SAP did a pretty good job in securing SAP HANA by design, SAP HANA is still a very complex system. By comparison, a standard SAP S/4HANA installation contains almost 300 million lines of code. There is bound to be a vulnerability in that code. And even not considering those requirements, with SAP HANA, SAP is going the route of using more standard web technology. This also means that common vulnerabilities of web technologies apply to SAP HANA – something that wasn’t the case with other SAP technologies. In addition, there are new attack vectors applying to SAP HANA – one potential example being random-access memory (RAM) scraping. With RAM scraping, malware is injected into the server’s memory. Since SAP HANA is an in-memory technique that stores all sensitive data in memory too, this is something that should be considered. Another thing I would like to add is that for SAP HANA to leverage its full performance, data in memory is not encrypted. Therefore, it is vital for all communication to and from SAP HANA, including client access, to be encrypted by default.
Comment From Alaa: Cloud is the future. Despite the solutions offered by SAP and other service providers, security is still a major concern. What is your point of view in this regard?
Frederik Weidemann: Whether the cloud is the future depends on your use cases and on the size of your organization. There is no black and white here. We have been involved in various hybrid architecture discussions, and one of the challenges is to understand your own security requirements. For example, one of the most mentioned security requirements is to avoid any downtime. Therefore, if you select a cloud provider, you should carefully review the service-level agreements (SLAs) and cross-check these with your business uptime requirements. In addition, you should take into account that your cloud vendor manages security for its infrastructure, but the responsibility in case of a breach will still rely on the customer. Therefore, a customer using the cloud still needs to take care overall. On one hand, cloud solutions are handy, but on the other hand, another complexity is added. Therefore, security monitoring is another security requirement in cloud scenarios that is often overlooked.
Comment From Alita: Our critical SAP applications are internal, and we have firewalls. Are attacks on an SAP system by outside hackers actually a problem?
Stephen Lamy: First, even though the SAP applications are internal, this does not necessarily mean that there is no outside access to an SAP system anyway. Most attacks (about 70 percent) are internal. But even if this is not the case, there are other vulnerabilities. For example, the solution manager defaults to a web user interface. And in older releases of SAP applications, several web services – which are even known to be vulnerable – were set as active by default. Second, if we talk about outside hackers, we are not necessarily talking about people using the Internet to try to access any given computer inside a corporate network. On the contrary, social engineering is among the most effective hacker techniques. And then we are all of a sudden talking about internal access to SAP systems, which is a far greater attack surface than outside attacks.
Comment From Lisa Borchers: What is the recommended schedule of how often patches should be installed? Should they be installed quarterly, biannually, or annually?
Frederik Weidemann: The official answer from SAP is as soon as possible. The reality is that customers typically patch between quarterly and biannual periods. However, SAP changed its security patch strategy. Besides the monthly patches, security notes are only released for Support Package levels that are not older than 18 months. Therefore, if you don’t patch regularly, you will have the weird situation that the amount of relevant security patches in SAP Solution Manager System Recommendation will go down because the systems thinks they’re not relevant. Also, it should be taken into account that there is a frequent release of Hot News notes. These notes are about risks that typically endanger your landscape severely. I will elaborate on this topic as well during my talks at the conference.
Comment From Robert: We’ve operated SAP applications for 20 years and never had a cybersecurity problem. Should I be concerned?
Frederik Weidemann: There is a saying among IT security professionals that there are no companies that haven’t been hacked – they’ve just not noticed it. In fact, a study recently showed that the time between an attack itself and the detection of that attack averages 146 days. But even if you have not been attacked in the past, the hacker community by now has discovered SAP as a potential and valuable target. After all, almost every company that uses SAP applications keeps its most sensitive data – the crown jewels if you will – inside an SAP system. So, we are seeing a steep increase of attacks targeting SAP systems.
Comment From Moore: Isn’t SAP responsible for SAP security?
Stephen Lamy: SAP is indeed responsible for securing its standard delivered product. However, correctly and securely configuring the system lies within your responsibility as a customer. Additionally, SAP systems are heavily configurable and also usually have lots of custom- developed applications with lots of custom code. You are responsible for these aspects alone. SAP cannot help you with them.
Comment From Blakely: Our company has an initiative for SAP security. Can you give us advice on getting this started and areas to focus on?
Stephen Lamy: That is a good question. Given the complexity of SAP systems, we recommend beginning with a vulnerability assessment to get an idea of the current state of your systems. You want to consider the threats to your system based on your business and how you are using the SAP systems. As needed, we suggest that you follow up with penetration testing (pentesting) to confirm the threats. We do not believe that a pentest alone - aka black box pentest - is enough. We recommend starting with white-box testing to get an overview of the vulnerabilities from the inside out. Based on the findings, you can then establish a roadmap and begin to both remediate the existing vulnerabilities in a prioritized approach and implement detection systems to monitor cybersecurity threats.
Comment From Mike: What's your experience with SAP HANA and Sybase database encryption? Do you see it leveraged often? What challenges do customers face? Any major impacts you can highlight would be appreciated.
Frederik Weidemann: Honestly, we don’t often see database encryption. For me, security is often related to encryption, patch management, and authorizations. A chain is only as strong as its weakest link. Thus, if you have a SQL injection error in your application, or if you miss an authority check in the right position, even more severe threats might arise. In the past 12 years of pentest experience, I have seen far more systems being vulnerable due to simple coding and configuration issues than due to missing system encryption. Also take into account that any coding vulnerability might render your database encryption useless.
Comment From Michael: How is an attack recognized? Put another way, how would one know your SAP system is being attacked?
Frederik Weidemann: There are two things to take into account to reduce the risk of being breached: proactive and reactive security. You are referring to reactive security. We typically see that many customers already cover security information and event management (SIEM) solutions. What they are missing in many cases, however, is the SIEM connection to an SAP system. But it’s not only about SIEM; it’s also about the fact that your organization needs to be able to react to incoming alerts. To make this further complicated, one of the central logs, the so-called security audit log, is not enabled by default in an SAP system. Even if it’s enabled, we see in our pentests and vulnerability assessments, that the log is not configured to collect all security-relevant events. Please keep in mind that there are more log files that need to be taken into account when setting up SIEM monitoring (e.g., HTTP log, BAL, STAD, Gateway Log, and so on).
Comment From Michael: Thanks, Frederik. And if all that is enabled (and correctly), would alerts need to be designed to identify an attack worthy of investigation versus false positives?
Frederik Weidemann: You should see any alert in a different manner – either it's an incident or you should optimize your pattern.
Comment From Richard Wilhite: What are the best practices for securing sensitive data transmitted to and from mobile devices? What risks due to mobile devices exceed the best practices and how do we mitigate them?
Frederik Weidemann: This depends on the used devices and on the data to be processed on the mobile clients. For example, some customers require client application data encryption for data classified as strictly confidential. If you think about all the caches that today’s web browsers have, this is a challenging task. Nevertheless, I like the question. Whenever mobile devices are used, a certain trade-off to security needs to be done, especially if these devices are not in control of your organization. Therefore, answering this question is quite more complex, as it really depends on the use case.
Matthew Shea: Thank you, everyone who joined today! Thank you, Frederik and Stephen, for your insightful answers! Stephen and Frederik will be presenting in these sessions at Cybersecurity for SAP Customers 2017:
