Designing SAP Fiori and SAP HANA Applications with Security in Mind

Panelist: Frederik Weidemann, Virtual Forge

Date: Tuesday, September 25

Sponsor: Cybersecurity for SAP Customers

Virtual Forge’s Frederik Weidemann, a speaker at the upcoming SAPinsider Cybersecurity for SAP Customers conference, answered user questions on building secure SAP Fiori and SAP HANA applications. SAPUI5 applications are responsive across browsers and devices and the UI controls automatically adapt themselves to the capabilities of each device. The improvements in look and feel improves the user experience and adds flexibility to allow users to connect seamlessly on multiple devices, but there are corresponding cybersecurity considerations. Read the transcript below to dive in with your most pressing questions.

Matthew Shea (SAPinsider): Hello, and thanks for coming to today’s live Q&A on designing secure SAP Fiori and SAP HANA applications. We’re joined by Virtual Forge’s Frederik Weidemann, who will be presenting on this topic, as well as a few others, at the upcoming SAPinsider Cybersecurity for SAP Customers conference. This conference will be held November 28-30, 2018, in Orlando. For more information or to register for the conference, click here.

I have a couple of general questions to start the conversation. First, what are the most common security and compliance findings?

Frederik Weidemann (Virtual Forge): To answer that question, we need to distinguish between the different development environments. You can develop your back-end logic in various languages depending on the scenario. Some  examples are ABAP, SAP HANA extended application services Javascript (XSJS), SAP HANA SQLscript, and even other languages using SAP HANA extended application services, advanced model and SAP HANA.

For all languages, general program paradigms apply, and these must always be taken into account. Examples are trust no input, defense in depth, and least privileges. On the other hand, all these languages do allow injection and other attacks. The most critical vulnerabilities are typically command injections or SQL injections. If you are developing on SAP HANA, then the things can change a little bit, as everything will be strictly limited by authorizations. Thus, a SQL injection would normally allow you to select data from different tables. If the user does not have extensive authorizations, an attacker will be limited to the given authorizations. This approach helps build secure applications from the bottom up. On the other hand, it also puts more responsibility on the developer as he or she will be in charge of designing the right authorizations for the application. I will give practical examples in my session titled “Develop secure SAP Fiori and SAP HANA applications” at the Cybersecurity for SAP Customers conference in Orlando.

Matthew Shea (SAPinsider): What’s the typical development environment for SAP Fiori applications these days?

Frederik Weidemann (Virtual Forge): The challenge of this question is to cover all relevant technologies. SAP Web IDE in the SAP Cloud Platform is the preferred way to develop SAP Fiori applications. An example scenario would be to connect an SAP Fiori launchpad in the cloud to your on-premise environment using the Cloud Connector, or you could connect an SAP S/4HANA cloud instance directly. The code itself would then be stored either in an SAP Cloud Platform Git repository or in an SAPUI5 ABAP repository. Alternatively, you could use the launchpad on an SAP NetWeaver Gateway system.

Comment From Sachin Tiwari: Could you clarify the differences between cloud and on-premise with regard to security?

Frederik Weidemann (Virtual Forge): That’s a tough question to answer in just a few sentences. Let me try a short version: The cloud’s benefit is that security patches are handled by SAP, and the cloud does scale easily. On the other hand, there is no sort of “testing” for new versions. SAP will constantly patch its cloud, and you need to take care that your applications will still work. Often people will connect their on-premise environments using the Cloud Connector. In that case the cloud will become a kind of demilitarized zone (DMZ), and it might be possible that your back end needs to handle a different amount of traffic. For on premise it’s easy — That’s the world you already now. As the customer, you need to manage everything on your own, but you are also in charge of any changes.

Comment From Sandeep: We have almost 3,000 tiles in our production system (PRD), and the roles and security /catalogs for SAP Fiori were created based on the higher subset of group. In hindsight we are realizing this is a problem for us because the initial load time is huge for users. For example, an SAP Extended Warehouse Management (SAP EWM) clerk manager has 80 tiles in PRD, and he uses only five functions. If another five roles are added, you have almost 200 tiles.

Frederik Weidemann (Virtual Forge): There is no quick-and-dirty answer to your question. But a simple one is that you can customize your SAP Fiori launchpad, and users can also rearrange it on their own according to their needs. Therefore, users could see only what they really need or want to see.

Comment From Colin Bezant: How do I make sure that my SAP Fiori app doesn’t give me access to data that I would otherwise not be able to see or change in SAP S/4HANA?

Frederik Weidemann (Virtual Forge): The most important point is to understand your architecture and your related authorizations. Are you using a standard SAP Fiori app, or do you build you own custom app? In SAP HANA everything can be limited easily with authorizations, and the same thing can be done in SAP S/4HANA using ABAP. However, many customers struggle with the vast amount of possibilities and details that the SAP authorization frameworks allow. Also, a typical setup using the SAP Fiori launchpad will utilize trusted Remote Function Call (RFC) connections. Therefore, the user needs to be in the back end as well. For custom applications take code security seriously into account. As a penetration tester, I always try to do things developers don’t have on their radar when they develop applications. I do non-functional testing and try to break things. Thinking like an attacker typically helps also a lot in securing your applications.

Comment From Kosh: Could you help with insight on SAP Fiori design for credit card authorizations and settlements? How can we make these processes efficient and secure?

Frederik Weidemann (Virtual Forge): Any processing of credit cards must be compliant with the Payment Card Industry Data Security Standard (PCI DSS). That’s something you might already now, but this compliance is also the starting point on what you are allowed to do and what you shouldn’t do. I don’t see a big difference between a normal application and an SAP Fiori application. The same compliance requirements need to be fulfilled, and you need to analyze your process from end to end. However, from an architecture point of view, cloud developments are interesting. Often web application firewalls (WAF) are required by PCI DSS, and you cannot just easily put you own WAF in front of a cloud application.

Comment From Guest: Could you recommend any guidelines for what a developer should do or look for with this “attacker” mindset?

Frederik Weidemann (Virtual Forge): Threat modeling is a good starting point. I also suggest that someone within your organization make himself familiar with offensive security. It helps a lot if someone understands how applications can be attacked. On the other hand, it’s sufficient to understand how exploits work; you don’t need to be able to attack software on your own. It’s just that you should be able to understand the root cause of a software vulnerability. If you gain this knowledge, you can estimate the impact and likelihood of an attack and help define a risk. Once you have a risk you can estimate an appropriate mitigation. For example, an OS command injection in an admin interface where the admin already has the authorization to execute OS commands is not so critical as an OS command injection that everyone can abuse.

Comment From Ali Uppal: How can we secure and hide our customized SAPUI5 code from our client? Because we have to deploy code on the client’s server, the client may change our product to sell it to other clients.

Frederik Weidemann (Virtual Forge): A good starting point is the SAPUI5 security guide. Take into account that SAPUI5 is a client framework and that you also should always focus on the back-end logic. An attacker can always just ignore all client-side validation and talk to your back end right away.

You cannot hide your SAPUI5 application code. Any user with access to your application will always see the code. Make sure that your intellectual properties are within your back-end logic. The more you make your application dependent on back-end logic, the harder it will be for a competitor to copy your application as he or she will need to reverse engineer your back-end logic.

Comment From Peter: From a security point of view, is SAP Fiori more vulnerable than SAP Solution Manager?

Frederik Weidemann (Virtual Forge): There is no simple answer to that question, and I think they shouldn’t be compared. In both cases make sure that all requirements from security guides are met and that you start with a secure environment. For SAP Solution Manager review SAP Note 2253549 (the SAP Security Baseline Template).

Comment From Pugazhenthi Ponnusamy: Could you offer advice regarding role mapping between the SAP Fiori front-end server and  SAP S/4HANA back-end server?

Frederik Weidemann (Virtual Forge): The difference really depends on your business processes and your local scenario — that is, how many systems, which components, on-premise, or cloud, etc. A good starting point is the SAP Fiori for SAP S/4HANA wiki.

Comment From Brahmanandam: What are the key security points to consider while designing the SAP Fiori security?

Frederik Weidemann (Virtual Forge): A good start is to always use SAP’s own guides. Every product has a security guide (for example, the Security Guide for SAP S/4HANA 1709 FPS01 (PDF), which provides you with a good overview about the different areas and will cover the different layers from the network layer up to the application layer. SAP security patch management is typically one of the issues that most SAP system users struggle with. Therefore, besides focusing on secure development, configuration, and authorizations, try to set up an SAP security lifecycle management approach that covers all your layers (for example, configuration and authorization checks, static code analysis, and security information and event management [SIEM]). Automate as many security checks as you can because an SAP system always will be one of the most complex systems in your landscape, especially as your system matures. I really like to highlight that a meaningful and high degree of security automation is typically a good indicator for operational excellence of the operations group. You can build on your own, use SAP tools, or explore the open market where there are many tailored SAP security solutions. Select whatever approach best fits your needs.

Comment From Guest: Is it good practice to separate SAP Fiori role and back-end business roles even though we have an embedded environment? Are there any benefits from this approach? Is it a good practice to separate SAP Fiori role (catalog, group) and back-end business roles (Open Data Protocol [OData] service) even though we have an embedded environment? Are there any benefits from this approach?

Frederik Weidemann (Virtual Forge): We do have some questions related to migrating authorizations. A good starting point is the SAP S/4HANA wiki. However, there is no black-and-white answer. Review also the SAP document titled “SAP S/4HANA-How to Create and Generate Backend Security Authorizations for SAP Fiori 2.0” and Jocelyn Dart’s blog titled “Leading S/4HANA UX – Adapting the Launchpad to the Business Role.”

Matthew Shea (SAPinsider): That just about wraps up our time for today. Thanks to everyone who participated for a great discussion and thanks to Frederik for taking the time to answer our questions today. To hear more from Frederik, be sure to register for Cybersecurity for SAP Customers, which will be held November 28-30, 2018, in Orlando. To learn more, click here.