Why do you need to protect your connections?
Most probably you have heard many times how important is to secure IT systems nowadays. IT security technologies are very familiar today in our day-to-day life. Who of you have not used a smart card? Or have you typed in on your browser’s address bar a URL starting by https when buying an item on Internet? Or even simpler, authenticate yourself on Hotmail?
SAP systems are not different in this respect and are of course subjected to security constraints. Indeed I have to say this is one of the keystones companies need to carefully pay attention on investing on assets of different nature (human capital, software, etc.) in order to get a reasonable level of security. I would even dare to say SAP systems are one of the most important ones to be secured since they are normally handling very critical data for the business of many companies.
If we look SAP systems as isolated entities, companies need to protect their systems in the following general terms:
- Authentication: users must be registered on SAP systems somehow (e.g. creating a user master record in ABAP stacks) and then identify themselves when trying to log in.
- Authorization: apart from needing to know who you are and let you come on in, systems must manage somehow who is allowed to do what. SAP uses authorization mechanisms like roles and profiles in ABAP or J2EE security roles and UME actions in Java.
- Password policies: the NetWeaver platform allows you to set some system parameters so that you can force your user community to enter stronger passwords and make life more difficult to hackers.
- Risk management: unfortunately risks are unavoidable and need to be managed and mitigated. In here techniques make sure critical authorizations are under control, backup and recovery strategies, high availability, disaster recovery plans can help you out to mitigate risks.
- Process governance: governance of your business processes is also a way to mitigate risks at a business level. Keep a tight control over concept like Segregation of Duties might allow companies to protect themselves again frauds and even be at a the safe side from a legal point of view.
- Legal regulations: this world is ruled by laws and this is not avoidable either (lucky us!). IT world is even getting more and more regulated over the time and force companies to implement policies to be aligned with current regulations. Clear examples are data retention policies, data privacy laws, Sarbanes-Oxley Act, Basel I, II and III for banking industry.
Just as a quick for your information, SAP Governance, Risk and Compliance (GRC) Suite helps you out on keep a better control over these bullets.
However, can you tell a SAP system that runs by its own without exchanging information with any other? Or even let’s put it simpler. SAP installations follow typical client-server architecture where a client program running on users’ PC connects to the backend system, i.e. the SAP system itself. There is an exchange of information between the users’ PC and the SAP system. Going even further most of today business processes expands across multiple systems and even outside company boundaries (e.g. B2B, mobility applications) making data being transmitted over miles of wires and even public and unsecure networks without final users even realize what is happening behind the scene.
We can then conclude SAP systems do not run isolated. You can normally find many security issues when auditing how systems interoperate. Let’s take a very common and simple example again. It is very common to see how company’s employees connect to SAP systems insecurely via SAPGUI. This may allow attackers to steal employees’ identities and make use of them in a harmful way.
Therefore an additional effort on securing the data paths is required so that data confidentiality and integrity (which are the two fundamental pillars when referring to secured data transfers) are preserved while data is being transferred.
I will introduce some technologies that you can take into consideration when securing data exchange scenarios on your SAP landscapes.
Your network security
In a very simple way, the term network topology means how your network will look like if you draw it on a piece of paper. In other words, it is a map that shows you of the different network devices interrelates each other so that one computer attached to the network on one side can connect to another one attached at other side.
Companies implement their private network (intranets) as TCP/IP networks (most usually) which is from a technical standpoint exactly the same technology used publicly by the Internet. TCP/IP allows you to segment networks into chunks based on IP addresses, network masks and routing data. We will call those segments as network zones which will be interconnected forming eventually the whole private network. Therefore, in a very simplistic manner, a TCP/IP network topology will show how these zones interrelates each other.
From a security point of view, you should then place your SAP backed systems in a separated network zone which will bring you following advantages:
- You can clearly distinguish between the user community and the backend system networks.
- You can apply a more restricted security level on your backend system network.
- You can have a better access control to your backend system network by filtering out network traffic coming in and going out.
- Network traffic can be better optimized.
The key piece on implementing a good access control to a given zone is firewalls. A firewall is either a hardware or software component that defines which connections can be established between communication partners. There are basically two types of firewalls depending on the information they used to filter network traffic:
- Packet filters: they are able to filter traffic based on the information contained in the TCP and/or IP headers (e.g. IP address, TCP ports, etc.).
- Application gateways: they are able to filter traffic based on information at application level which means they have the ability to extract information contained further down in the application frame within the TCP/IP whole network packet.
SAP does not provide any packet filter firewall. However you have several possibilities when talking about application gateways:
- SAProuter which is able to route and filter traffic at the SAP NI layer, the SAP proprietary network layer used by SAP protocols like RFC and DIAG.
- SAP Web Dispatcher which is able to filter and balance HTTP(S) requests addressed to SAP NetWeaver Application Servers.
Note as well that each type of firewall is not mutually exclusive. In fact in the real world they normally co-live together for the sake of your overall system security as shown on following typical network topology:
Note in previous picture how access control to your backend systems is achieved:
- External business partners do not connect to your backend system directly. Instead, their requests are filtered and routed by the SAProuter or the SAP Web Dispatcher running at your company DMZ (depending on the application protocol being used).
- The firewall protecting your backend network zone allows only the traffic originated from your application gateways at DMZ to pass through.
- The backend network zone is also protected by a second internal firewall from your internal user community network.
Outer and inner DMZ
You can add an extra security bonus by splitting the DMZ out onto two DMZ zones:
- The outer DMZ
- The inner DMZ
The outer DMZ will be the entry point from the Internet (rest of the world) to you company. The inner DMZ will be the entry point to your backend network from either outer DMZ or internal user community network placing in here inner SAProuters, inner SAP Web Dispatchers, portal systems (e.g. SAP Enterprise Portal) or any other system which allows you to access content from backend systems.
SAP supports one more additional security technique known as Reverse Invoke. It enables network connections to be established from the backend network. It increases network security since firewalls do not allow any connection originated outside backend network to pass through into the backend network. Both SAProuter and SAP Web Dispatcher can be set up to use reverse invoke.
Let’s take an example. Imagine a web application is being served by a SAP system in the backend network. When a user wants to use that web application he or she starts a web browser and connects to a SAP Web Dispatcher in the DMZ. The SAP Web Dispatcher is used as the access point to the web application. However, when reverse invoke is set up, the connection is initiated by the Internet Communication Manager (ICM) in the SAP system and not by the SAP Web Dispatcher. Therefore the inner firewall (the one protecting the backend network) can be set up so that no incoming connections are allowed.
SAProuter can be set up as well to work in a similar way.
Transport layer security
Securing your network is feasible as long as you have full control over the network resources. Once you lose that control, you need to rely on third parties security policies or even worse you cannot guarantee your data will be safe at all. This is when you need to go for cryptographic technologies like the ones we will described in this section as a mean to preserve your data confidentiality and integrity.
Note as well that securing your network does not mean you should skip data encryption. Nothing is further from the truth. Very critical data (e.g. HR data, medical trials, etc.) usually need to be transferred over encrypted data paths even when they don’t cross out company boundaries and network is firewalled everywhere. Therefore, following technologies can then be also implemented within companies’ private networks upon specific scenarios.
Secure Network Communications
Secure Network Communications (SNC) is a software layer developed by SAP that protects end-to-end the data communication paths between components of a SAP system that use SAP protocols like RFC or DIAG. It adds a security layer on communications between:
- SAPGUI and SAP systems
- Two SAP system servers (both ABAP and Java)
- External RFC servers and SAP systems servers
- SAP systems and SAP printing servers
SNC does not implement the security mechanism by itself but it provides an interface to an external security product by means of the GSS-API V2 (Generic Security Services Application Programming Interface Version 2). This allows you to implement external security techniques that are not directly provided by SAP (e.g. smart cards, Kerberos, etc.).
These are the three levels of security protection you can apply with SNC:
- Authentication: this is the minimum level of protection where only the identities of communication partners are verified. Data are sent unencrypted.
- Integrity: this is an intermediate level protection where any unwished data change during transfer can be detected. Data are still sent unencrypted.
- Privacy: this is the maximum level of protection where data are sent encrypted over the wire between the two partners.
SAP provides free of charge the SAP Cryptographic Library as a default SNC security product, unless the German export regulations prevent SAP to deliver this product on your country. If you are an authorized SAP customer, you can download the product on the SAP Service Marketplace at https://service.sap.com/swdc. However, SAP Cryptographic Library can only be used for implementing SNC between server components, i.e. to protect RFC based communications. If you require protecting client communications as well (e.g. connections between SAPGUI and your SAP systems) you need to purchase an extra product either by SAP (SAP NetWeaver Single Sign-On) or by a certified SAP partner.
You should also keep in mind that only one SNC product can be used per application server. There is no possibility to alternate between different SNC products depending on your needs within a SAP instance scope.
Secure Sockets Layer
The Secure Sockets Layer (SSL) is a widely used transport protocol created by Netscape back in the 90s for securing messages transmitted over unsecured media on the Internet and then a way to prevent eavesdropping and tampering. Today the term SSL is generally used to also refer to its successor the Transport Layer Security (TLS). SSL is almost everywhere on the Internet nowadays. If you did not know yet, every single time you type in “https://…” on your browser’s address bar, data are travelling back and forth through a SSL connection. In fact SSL is a must on any kind of e-commerce business: online banking, ebay, paypal, etc. So for sure you have ever dealt with it before.
SSL is located between the TCP layer and the application layer (e.g. HTTP) on the TCP/IP stack. It uses a range of cryptographic technologies to provide same protection levels as SNC:
- Authenticate the client, the server or both by using an asymmetric cryptography system. Digital certificates take an important role in the SSL authentication mechanism.
- Keep data confidential by using a symmetric cryptographic system.
- And keep data integrity by using message authentication codes (i.e. MAC).
TLS and SSL are an integral part of most used web browsers nowadays (Internet Explorer, Firefox, Chrome, Opera, etc.) and also supported by almost any web server among them of course SAP systems.
On new systems based on SAP NetWeaver 7.3x, you can implement SSL on SAP by setting up the ICM properly for both ABAP and Java stacks. However this is slightly different on Java systems based on earlier versions of SAP NetWeaver. On those older versions you need to set up the SSL Service Provider instead.
No matter what version, you need to meet following requirements so that your SAP systems become ready to transmit over SSL:
- SAP Cryptographic Library must be installed on the SAP server.
- You must have access to a PKI subsystem so that the SSL server digital certificate can be generated and signed up by CA entities.
- A container for all certificates involved in SSL connections. Again, as of SAP NetWeaver 7.3x, this container is implemented in the form of a file called SSL Server Personal Security Environment (SSL Server PSE) no matter your stack is ABAP, Java or both. In ABAP world this has not changed in older versions. However this is not the case of Java where versions older than NW 7.3x used a specific service called Key Storage to keep SSL certificates safe.
In regards to the usage of SSL within the SAP world, there are many scenarios that protect data transmissions over SSL tunnels. Right now I can think of:
- SAP mobility products like Afaria and Sybase Unwired Platform
- Web Dynpros
- ICF services
- SAPGUI for HTML
- Web Services
- SAP Message Server
- SAP NetWeaver Portal
- SAP NetWeaver PI
- SAP NetWeaver Gateway
Virtual Private Networks
A Virtual Private Network (VPN) is the general term used to define several technologies to connect private networks across public networks like the Internet in such a way a host computer physically located at one of this private networks can transmit data to the others as if they were just one logical private network.
You can imagine a VPN as long pipe between two ends where you can’t see anything that is being throw out inside. In the real world, the pipe effect is achieved by means of tunneling protocols and the opacity by means of encryption techniques.
Likewise SNC and SSL, VPN security model provides:
- Confidentiality since data are sent out encrypted.
- Sender authentication to prevent unauthorized users from accessing the VPN.
- Message integrity to detect whether transmitted messages having been tampered.
One of the controversial features of the VPN technologies is the amount of different tunneling protocols (e.g. IPSec, TLS/SSL, PPTP) used by the vendors who provide VPN solutions. Normally each of these protocols will require specific VPN client software bringing up incompatibilities between those VPN solutions. Nonetheless, VPN is widely used today to connect remote sites and allow employees to work from home.
The most clear example where VPN technologies is used within SAP world is to connect customer’s SAP systems to SAP’s facilities that allows SAP to deliver all remote services available (e.g. remote support, OS/DB migration verification sessions, etc.). However, same technique can be used for connecting private SAP systems to other private remote systems which is typically required in a B2B scenario for instance.
Other security techniques
I don’t want to finish up this article without quickly mentioning Trusted RFCs and Secure Store & Forward Mechanisms (SSF).
On one side, if you are familiar with SAP terminology, you may know already SAP systems can connect each other at application level by means of Remote Function Calls (RFC). If a calling SAP system is registered on the called system as a trusted system, no password must be supplied. This is indeed the main advantage of trusted RFCs from a security standpoint. However you should keep in mind:
- Data transmitted through the RFC itself are not encrypted unless SNC is implemented as well.
- Trusted relationship is unidirectional.
- Authorization object S_RFCACL must be maintained in the trusting system (the called system) so that trusted RFC becomes fully operational.
- Only possible between ABAP systems.
On the other side, you have Secure Store & Forward Mechanisms (SSF) in the ABAP world as well for protecting your data by means of digital signatures and digital envelopes. SSF is oriented to protect data at application level more than the communication paths itself. Or saying in other words, instead of creating a protected communication tunnel you send data through, SSF allows you to encrypt and sign data and then send them out preserving confidentiality (the digital envelope) and integrity (the digital signature) up to the right recipients who will be able to decrypt and verify them (and the other way around). SSF relies on a PKI implementation for an effective usage and as evidence the standard used for this secure data format is PKCS#7.
You may use SSF for example in following scenarios:
- Store confidential documents encrypted into SAP database.
- Store confidential documents encrypted into an external file systems or storage media (e.g. for being processed by 3rd party interfacing software).
- Send and receive signed data to and from business partners and process them directly in SAP (as long as it sticks to PKCS#7).
- SAP ArchiveLink.
At the application layer, the usage of SSF might require (depending on the scenario) some custom ABAP development. SAP provides the SSF functionality by means of a set of ABAP function modules. At low level, SSF requires a security provider as well. SAP delivers to you either the Security Library (SAPSECULIB) limited to digital signature only or the SAP Cryptographic Library for both using digital signatures and envelopes. You can also go for external security products among the list of SAP-certified partners.
Nobody can question today the need companies have their systems interoperate in a secure way. Indeed this interoperability has become global and even expands company’s boundaries which mean for instance a system of company ACME physically located in Spain need to connect technically to another system of company EMCA located in U.S. Therefore the use of the Internet as a transport medium becomes essential. However we all know the Internet is a huge jungle governed by nobody and then security in terms of authentication, confidentiality and integrity are crucial to make business over this medium.
I presented here some techniques oriented to SAP world companies can implement to get a reasonable level of security according to today security standards while making business over unsecure data paths. However the security area of knowledge is evolving pretty quick and new standards, new requirements and new weaknesses will for sure show up in the future.
Therefore my advice is to keep on top of security topics as much as your time allows you to be up-to-date on new issues and fixes related to SAP products. In fact SAP provides you with some tools for this purpose:
- You can search security notes at https://service.sap.com/securitynotes
- Upon customer’s request, SAP launched the so-called SAP Security Patch Day, scheduled for the second Tuesday of every month, to ensure that security fixes for all SAP products under support are available to be downloaded at SAP Marketplace
- You can start browsing and reading blogs published in the SCN security workspace at http://scn.sap.com/community/security
Please keep this advice seriously!
- SAP NetWeaver Security Guide
- Note 66687 – Use of network security products
- Secure Network Communications
- Using the SAP Cryptographic Library for SNC
- RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”
- RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”
- SAP Software Partner Program
- Note 486688 – Schedule VPN connection to SAP network
- Digital Signatures and Encryption