SECURITY GUIDE | PUBLIC

Document Version: 15.2.3 – 2018-11-23

Security Guide PCo 15.2

© 2018 SAP SE or an SAP affiliate company. All rights reserved.

THE BEST RUN

Document History

 Caution

Before you start the implementation, make sure you have the latest version of this document. You can find
the latest version at the following location: https://help.sap.com/viewer/p/SAP_PLANT_CONNECTIVITY

Versions

Version Date Description

1.0 2018-03-02 Initial version for PCo 15.2 (SP00)

2.0 2018-11-23 Updated version for PCo 15.2 (SP03)

Security Guide PCo 15.2

2 PUBLIC Document History
SAP Plant Connectivity

Introduction

This document outlines the available options in the Microsoft Windows operating system that you use to
implement the security policy that controls the access to SAP Plant Connectivity (PCo).

 Caution

This guide does not replace the administration or operation guides that are available for productive
operations.

 Note

PCo does not provide built-in user management. It uses standard Microsoft Windows domain user
accounts. It does not provide additional roles for controlling the user or group accounts specific to PCo
functionality for on premise. If a user can launch PCo, there is no limit to the functionality, provided the user
has administrator privileges. For more information about user management and security audits, see http://
technet.microsoft.com/en-us/library/cc781549%28WS.10%29.aspx .

If you use PCo together with the SAP Digital Manufacturing Cloud you have to define the rights of the
users who can access the services provided by the CloudServicesHost. Predefined roles are assigned to
individual services. You can assign the roles to the individual users in the Management Console under
Tools Cloud Integration User Configuration

● For a complete list of SAP Security Notes, see https://support.sap.com/en/my-support/knowledge-

base/security-notes-news.html .

Security Required by Plant Connectivity

With the increasing use of distributed systems and the Internet for managing business data, the demands on
security are also on the rise. When using a distributed system, you need to be sure that your data and
processes support your business needs without allowing unauthorized access to critical information. User
errors, negligence, or attempted manipulation of your system should not result in loss of information or
processing time. These demands on security apply likewise to SAP Plant Connectivity (PCo).

The following prerequisites apply to the correct operation of SAP Plant Connectivity:

● PCo can only be installed by a user with administrator privileges.

● Agent instances cannot be created or deleted unless the user has administrator privileges.
● Microsoft Windows users which are assigned to an agent instance are granted the Log on as a service
privilege.

Security Guide PCo 15.2

SAP Plant Connectivity PUBLIC 3
● If the PCo Management Console is started by a user without administrator privileges it is shown in display
mode only. The display mode allows access to all configuration data and logs but does not allow
configuration changes or starting and stopping of agents.

Security Guide PCo 15.2

4 PUBLIC SAP Plant Connectivity
About this Document

The Security Guide provides an overview of the security-relevant information that applies to PCo.

Overview of the Main Sections

The Security Guide comprises the following main sections:

● Before You Start

This section contains information about why security is necessary, and how to use this document.
● Technical System Landscape
This section provides an overview of the technical components and communication paths that are used by
PCo.
● User Administration and Authentication
This section provides an overview of the following user administration and authentication aspects:
○ Recommended tools to use for user management
○ User types that are required by PCo
● Authorizations
This section provides information about the authorizations required to run PCo.
● Network and Communication Security
This section provides an overview of the communication paths used by PCo and the security mechanisms
that apply. It also includes our recommendations for the network topology to restrict access at network
level.
● Data Storage Security
This section provides an overview of any critical data that is used by PCo and the security mechanisms that
apply.
● Dispensable Functions with Impacts on Security
This section provides an overview of the functions that have an impact on security, but which can be
disabled or removed from the system if necessary.

Security Guide PCo 15.2

About this Document PUBLIC 5
Before You Start

Important SAP Notes

For a list of additional security-relevant SAP Hot News and SAP Notes, see https://support.sap.com/en/my-
support/knowledge-base/security-notes-news.html .

Additional Information

For more information about specific topics, see the Quick Links as shown in the table below.

Content Quick Links on SAP Support Portal or SDN

Security http://sdn.sap.com/irj/sdn/security

Related SAP Notes ● https://launchpad.support.sap.com/#/mynotes?tab=Search

● https://support.sap.com/en/my-support/knowledge-base/
security-notes-news.html

Product Availability Matrix https://support.sap.com/en/release-upgrade-mainte­

nance.html#section_1969201630

SAP NetWeaver http://sdn.sap.com/irj/sdn/netweaver

Security Guide PCo 15.2

6 PUBLIC Before You Start
Technical System Landscape

For an overview of the Plant Connectivity system landscape, refer to the corresponding Master Guide in the
SAP Service Marketplace.

Topic Guide / Tool Quick Link

Technical description of PCo Master Guide http://help.sap.com/pco#section2

https://help.sap.com/viewer/p/
SAP_PLANT_CONNECTIVITY

Technical Landscape Design See applicable technical documents http://sdn.sap.com/irj/sdn/landscapede­

sign

Security See applicable security documents http://sdn.sap.com/irj/sdn/security

Security Guide PCo 15.2

Technical System Landscape PUBLIC 7
User Administration and Authentication

PCo does not have its own user management, but instead uses the standard Microsoft Windows domain user
accounts.

Authentication for the Plant Connectivity Management Services is done using Basic Authentication, that is, the
given user is authenticated using Microsoft Windows authentication. The same applies when Web server(s) are
configured in the PCo agent instance(s) and Basic Authentication is set.

 Note

For more information about user management and security audits, see http://technet.microsoft.com/en-
us/library/cc781549%28WS.10%29.aspx .

Security Guide PCo 15.2

8 PUBLIC User Administration and Authentication
Authorizations

Authorization for Management Console

To launch the Plant Connectivity Management Console to perform configuration changes or to start and stop
agents, you must have the corresponding administrator privileges.

 Note

In Windows 7 and higher the User Account Control (UAC) automatically detects that administrator
privileges are required.

Users without administrator privileges can start the PCo Management Console in display mode only. They
have read-only access to configuration details and logs. They are also allowed to export the configuration.

Authorization for Agent Instance Services

Agent instances running as a service may be configured to use a specific user. The user account used for this
needs the log on as a service privilege. This privilege is granted automatically when you assign a user to an
agent instance. Alternatively, this can be configured in the Group Policy Editor. You can find more information
about this on the Microsoft Developer Network (MSDN) Web site under the following links:

● Log on as a service privilege: http://msdn.microsoft.com/en-us/library/ms813948.aspx

● Service Logon Accounts: http://msdn.microsoft.com/en-us/library/ms677948(VS.85).aspx

To control the general access to the Plant Connectivity Management Console, you can use the following
technologies for the PCo system folder (usually found under C:\Program Files (x86)\SAP\Plant Connectivity
\System):

Technology Quick Link

Group Policy Objects (GPO) http://technet.microsoft.com/en-us/library/cc754286.aspx

Access Control Lists (ACL) http://technet.microsoft.com/en-us/library/cc770749(WS.

10).aspx

Security Guide PCo 15.2

Authorizations PUBLIC 9
Authorization Management in SAP Plant Connectivity

You can use authorization management to define specifically which PCo services you want external callers to
be able to access.

Standard Settings

After installing PCo, only users that belong to the Administrators user group have access to the services
provided by the Management Service. The PCo Web server can be called by users that belong to the
PCoWebServer user group provided this user group existed at the time of installation. Otherwise, and for all
other services, the default setting is No Access for the topmost level and Access Inherited from
Superordinate Service for the lower levels. After installation, you can revert at any time to these standard
settings by choosing the relevant pushbutton.

Authorization Services

SAP Plant Connectivity provides a number of services that can be used by remote computers:

● Management Service
Using the Management Service, you can call PCo functions using Web services. You can configure, start, or
stop agent instances and query configurations, status information, or protocols.
● Remote Client
The remote client enables you to monitor PCo from a remote computer, to start or stop agent instances, to
export and import configurations, and to query protocols.
● PCo Web Server
The PCo Web server provides configurable methods in the form of Web service endpoints.

You should use https for the service and, in addition, basic authentication. When using basic authentication the
services require that the user can log on to the Windows computer on which PCo is installed. In addition you
have to use the authorization management in the PCo Management Console to control which PCo services can
be accessed by external callers.

Security Guide PCo 15.2

10 PUBLIC Authorizations
Communication and Network Security

Your network infrastructure is extremely important in protecting your system. Your network needs to support
the communication necessary for your business needs without allowing unauthorized access. A well-defined
network topology can eliminate many security threats based on software flaws (at both the operating system
level and the application level) or network attacks such as eavesdropping.

If users cannot log on to your application or database servers at the operating system or database layer, then
there is no way for intruders to compromise the machines and gain access to the back-end system’s database
or files. Additionally, if users are not able to connect to the server LAN (local area network), they cannot exploit
well-known bugs and security holes in network services on the server machines.

Communication Channel Security

The table below shows the communication channels used by PCo, the protocol used for the connection, and
the type of data transferred.

Communication Path Protocol Used Type of Data Transferred Data Requiring Special Pro­
tection

OPC (DA, HDA, and A&E) COM/DCOM Tag values, metadata, and hi­
data source to PCo (and vice erarchical structure of tags
versa)

OPC UA data source to PCo HTTP (deprecated)/ HTTPS Tag values, metadata, and hi­ Password for user session (if
(and vice versa) or OPC UA specific protocol erarchical structure of tags used), private key of certifi-
via TCP cates

OPC UA destination Inherited from OPC UA Method call Inherited from OPC UA
source system source system

Data source to PCo (and vice Vendor-specific proprietary Tag values, metadata, and hi­ Password for logon to data
versa) (this applies to the fol­ protocol erarchical structure of tags source
lowing agents: Citect, IP21, PI,
PI-AF, Proficy)

Modbus data source TCP/Serial Protocol Tag values, metadata, and hi­
erarchical structure of tags

PCo to MII (destination) HTTP/HTTPS Tag values, metadata, and hi­ Password for logon to MII
erarchical structure of tags

Security Guide PCo 15.2

Communication and Network Security PUBLIC 11
Communication Path Protocol Used Type of Data Transferred Data Requiring Special Pro­
tection

PCo to Web service destina­ SOAP Tag values, metadata, and hi­ Password for Web service
tion erarchical structure of tags

PCo to ABAP NetWeaver AS RFC Tag values, metadata, and hi­ Password for logon to Net­
(destination) erarchical structure of tags Weaver system

PCo to OData destination HTTP/HTTPS Tag values, metadata, and hi­ Password for OData service
erarchical structure of tags

PCo to Restful Web service HTTP/HTTPS Tag values, metadata, and hi­ Password for Restful Web
destination erarchical structure of tags service

PCo to Universal Web service HTTP/HTTPS Tag values, metadata, and hi­ Password for Web service
destination erarchical structure of tags

PCo to Sybase ESP destina­ HTTP/HTTPS Tag values, metadata, and hi­ Password for Sybase ESP
tion erarchical structure of tags

PCo to ODBC destination ODBC Tag values, metadata, and hi­ Password for ODBC data
erarchical structure of tags source

MII (TagQuery) to PCo LISA (MII specific binary pro­ Tag values, metadata, and hi­
tocol) erarchical structure of tags

MII (PCoQuery) and NetWea­ xMII data transfer protocol Tag values, metadata, and hi­
ver to PCo (new MII specific protocol) erarchical structure of tags

PCo Remote Client to PCo NET.TCP (and potentially Commands, status informa­ (Encrypted) passwords in
Management Host also WCF (Windows Commu­ tion, configurations, and logs configuration data
nication Foundation)

MII (PCoQuery) to PCo Man­ HTTP/HTTPS Commands, status informa­ (Encrypted) passwords in
agement Host tion, configurations, and logs configuration data

WebSocket WebSocket Protocol Commands, status informa­

tion, configurations
WebSocket Protocol over
TLS

Web client to PCo web server WebSocket Protocol Command, status informa­ Windows account credential
tion, configurations which is part of the windows
WebSocket Protocol over
group PCoWebServer
TLS

Security Guide PCo 15.2

12 PUBLIC Communication and Network Security
Communication Path Protocol Used Type of Data Transferred Data Requiring Special Pro­
tection

MQTT to PCo and vice versa TCP MQTT packets Password for MQTT Server,

TCP over TLS Private keys for the client

certificates.
WebSocket Protocol

WebSocket Protocol over

TLS

Note the following protection options:

● RFC connections can be protected using Secure Network Communications (SNC).

● HTTP connections can be protected using the Transport Layer Security (TLS) protocol.
● SOAP connections are protected with Web services security.
● Universal Web service destination allows the usage of tokens to prevent CSRF attacks. For more
information, see Application help for Universal Web service destination.

 Recommendation

We strongly recommend using secure protocols (TLS, SNC) whenever possible.

Related Information

DCOM Security [page 13]

OPC UA Security [page 14]
Application Certificate Management in Plant Connectivity OPC UA Components [page 16]
Application Certificate Management in Plant Connectivity MQTT Components [page 17]
TLS-Based Secure Communication in PCo [page 18]
Enabling TLS for the Management Host Service [page 20]
Enabling TLS for an Agent Instance [page 21]
Enabling TLS for the Web Server Hosted in an Agent Instance [page 21]

DCOM Security

The OPC standards DA, HDA, and A&E use DCOM security. To implement DCOM security, carry out the
following steps:

1. On the machine where the OPC server is running, use the command dcomcnfg.exe to carry out the
following steps:
○ Check the launch and the activation limits under My Computer Properties COM Security .
○ Check the access limits.

Security Guide PCo 15.2

Communication and Network Security PUBLIC 13
 ○ Verify the OPCEnum application's DCOM security settings for launch/activation and access.
○ Verify the respective OPC server application’s DCOM security settings for launch/activation and
access.
○ Then make the following settings for the agent instance:
○ Grant the Anonymous Logon account local and remote permissions.
○ Grant the Everyone group local and remote permissions.
For a simple setup of both, you can grant the Anonymous Logon account and the Everyone group local
and remote permissions.
○ Set a valid domain user account.
2. On the machine where PCo is installed and the agent instance is running, use the file dcomcnfg.exe to
verify or change the launch and activation limits.
○ OPC server credentials for the local system:
○ Grant the Anonymous Logon account local and remote permissions.
○ Grant the Everyone group local and remote permissions.
○ Valid domain user account
The Everyone group covers all authenticated user accounts. You can grant permission to a specific
user or group to achieve a higher level of security.

OPC UA Security

This section applies to both the OPC UA source system, the OPC UA server, new as of PCo 15.1 (SP03), and the
OPC UA destination system, which inherits its properties from an OPC UA source system.

 Note

Recommendations for security policies may change over time due to increasing computing power. You
should review your settings regularly.

OPC UA security is divided into the following categories:

● Channel Communication: The channel communication uses the standard X.509 v3 certificates.
● User Session: The user session may use Anonymous, User name and Password, or Credentials.

OPC UA security for channel communication is governed by the OPC UA specification, which has been made
open source in 2015. The current version of PCo supports version 1.03 of the OPC UA specification.

 Note

Version 1.04 has been released but is not yet supported.

It is based on the usage of X.509 v3 certificates for both client and server. It defines several security modes:

● None
● Sign
● SignAndEncrypt

The profile security category lists several policies:

● None

Security Guide PCo 15.2

14 PUBLIC Communication and Network Security
● Basic128Rsa15
● Basic256
● Basic256Sha256

The policies can be combined in certain, predefined ways.

The links above provide detailed information about the algorithms used for each policy and also
recommendations on usage.

● Security policy None only supports security mode None and should be used only for testing or for
connecting to devices that do not support other security modes.
● Security policy Basic128Rsa15 is rated unsecure and should no longer be used, unless legacy servers
cannot be connected to securely using other policies.
● Security policy Basic256 is a reasonable secure policy if certificates are signed with Sha256, even though
Sha1 is supported.
● Security policy Basic256SHA256 is considered to be a secure policy if certificates are signed with Sha256.

Sign which transfers data unencrypted but with digital signatures that allow verification of data integrity.

In PCo, the security policies Basic128Rsa15, SHA256 and Basic256SHA256 are supported for the security
modes Sign and SignAndEncrypt. If the computation power of a device to which you want to connect is low and
confidentiality not an issue, but data integrity is important, you may consider using the security mode Sign.
With security mode SignAndEncrypt the messages are both signed and encrypted.

The OPC UA specification details the process of certificate validation for the creation of secure channels
(Release 1.03, Part 4, section 6.1.3). This process description allows the creation of a secure channel even
though some checks may have failed.

The PCo UA source system and server rely on the (open source) .Net SDK of the OPC Foundation, which
currently does not fully support this part of the specification, meaning that the same holds for SAP Plant
Connectivity OPC UA applications. This means for the UA source system, in particular:

● Certificate revocation lists are only supported for file-based storage of certificates. They are taken into
account automatically if they are present in the crl subfolder of the folder that is configured as trusted store
or trusted issuer store.
● Missing certificate revocation lists do not lead to certificate validation failure.
● Certificate revocation list checks cannot be configured.

The PCo OPC UA server currently does not support validation failure exceptions at all which leads, in general,
to higher security but fewer configuration options. The PCo OPC UA server only supports certificate revocation
lists for file-based certificate storage. As for the OPC UA source system, missing certificate revocation lists do
not lead to certificate validation failures.

Providing the option to use session security is the task of the OPC UA server. The PCo OPC UA server
functionality currently does not support user-based or certificate authentication for sessions; only anonymous
access is supported.

The PCo OPC UA source system supports user/password and certificate-based authentication if the OPC UA
server it connects to does.

Security Guide PCo 15.2

Communication and Network Security PUBLIC 15
Application Certificate Management in Plant Connectivity
OPC UA Components

OPC UA source system and server need an X.509 v3 certificate as application certificate for setting up a
secure connection, and for this application certificate the private key must be accessible to the OPC UA
application. The PCo OPC UA applications will not start without a valid certificate. If an OPC UA application
provides an application certificate, it must be a formally valid certificate or empty (null), otherwise the
connection is refused by the other party. No secure connection can be established with an empty certificate, of
course.

 Note

SAP Plant Connectivity does not provide a means to create X.509 v3 certificates for OPC UA application
certificates.

You can use self-signed certificates, certificates created by a UA server certificate creation utility from
another vendor, or certificates from a certificate authority to create application certificates.

PCo UA applications support both certificate chains as well as self-signed certificates for the creation of secure
channels. Since some UA applications may not be able to receive (partial) certificates, PCo UA applications
allow you to configure whether a certificate chain is sent or whether only the application certificate is sent. This
is the default.

To send a certificate chain, you have to store the application certificate in the Microsoft Certificate store and the
other (intermediate and CA) certificates of the chain in the folders your application uses as store for trusted
issuers or the trust store. If you send only a partial chain, the missing parts have to be available to the other
party by other means (usually in the trusted store or trusted issuer store). Collecting the certificates of a chain
to send them to the other party relies on finding, recursively, the certificate that was used to sign those
certificates in the chain that were already found. This is only possible if there is no gap in the chain as it is
stored in the folders in which the application can search for them.

In Plant Connectivity the application certificate must be stored in the Microsoft certificate store to protect the
private key. The recommended way to provide it is to import it as a .pfx file into the personal folder of the
LocalMachine store in the Microsoft certificate store. Other folders can be used to provide backward
compatibility. If the Current user store is used, PCo agent instances, which run as a service, may not be able to
access the private key, unless the service is run with the identity of the same user.

File-based certificate stores can only be used as a trusted store for application certificates from other UA
applications (without their private key). This can be set up on the Security tab of UA source systems and UA
servers. If you choose to change the default settings, you should follow the instructions in the ‘Prerequisites’
section to protect that location appropriately.

 Note

The OPC UA specification requires that certain attributes and extensions of application certificates are set
to specific values. These requirements may differ from what you are used to from other certificate-based
secure connections. They are detailed in section 6.2.2, Part 6 of revision 1.03 of the OPC UA specification.

Security Guide PCo 15.2

16 PUBLIC Communication and Network Security
  Note

Some UA applications may refuse to establish a secure connection if a self-signed certificate does not
specify CertificateSigning as intended key usage. The specification only requests
digitalSignature, nonRepudiation, keyEncipherment, and dataEncipherment.

 Note

The validation functionality for CA-signed certificates or chains of the Microsoft certificate store is, in
general, different from the one used by OPC UA applications. If the Microsoft certificate store can validate a
certificate signed by a CA, this means that the CA certificate is stored in the Trusted Root Certification
Authorities folder of the Microsoft certificate store. This is not normally the place where an OPC UA
application searches for the CA certificate. These latter locations are configured on the Security tabs of the
PCo UA application.

Application Certificate Management in Plant Connectivity

MQTT Components

The PCo MQTT client can optionally use an X.509 certificate as application certificate for setting up a secure
connection, but a secure connection using TLS can also be established without such a certificate. If the PCo
MQTT client uses an application certificate, its private key must be accessible. The PCo MQTT clients will not
start if an invalid certificate is used.

If you use certificate chains for client authentication, all intermediate CA certificates must be installed in the
Intermediate Certification Authorities store . The root CA certificate must be installed in the Trusted Root
Certification Authorities store.

 Note

The Microsoft Certificate store is always used for the client certificates. The configurable certificate store
type is only used during the validation of the server certificates.

When the PCo MQTT clients are used on Windows OS, the following security settings are recommended:

Recommended Settings on the Connection Tab

Field Recommended Setting

Store Type Microsoft Certificate Store

 Note
Note that the certificates for the current user may be
not visible during runtime if you start the corresponding
agent instance with other credentials. This will prevent
the agent instance from starting.

Security Guide PCo 15.2

Communication and Network Security PUBLIC 17
Field Recommended Setting

Trusted Certificates/Issuer Certificates/Rejected Certificates For the certificates, you choose a certificate storage location
on the local computer or the current user.

Revocation Check Check Online Revocation Lists

Revocation Check Scope Check Entire Chain

Ignore Server Host Name Do not select the checkbox.

Ignore Validity Period Do not select the checkbox.

If you use the File System Certificate Store, we encourage you to discuss the settings with your system
administrators.

 Note

File System Certificate Store does NOT support Indirect Certificate Revocation Lists.

During the validation of the server certificate chain the following algorithm is used:

1. The certificate chain is built by PCo using the sent certificates, the trusted certificate folders, and the
issuer certificate folders. The rejected folder is used only for temporary storage of the certificates.
2. If the chain is incomplete, the certificate is not trusted.
3. If the chain is built and at least one of the certificates is taken from the trusted folder, the certificate is
trusted.
4. The revocation check is only performed if the certificate chain is complete and the certificate is trusted.
5. During every online revocation check, the crls folder under the trusted folder will be updated according to
the last CRLs.

The following asymmetric hash algorithms are supported (in the brackets is the algorithm Object ID):

● SHA1 DSA (1.2.840.10040.4.3)

● SHA1 RSA (1.2.840.113549.1.1.5)
● SHA256 RSA (1.2.840.113549.1.1.11)
● SHA384 RSA (1.2.840.113549.1.1.12)
● SHA512 RSA (1.2.840.113549.1.1.13)

The following asymmetric hash algorithms are considered insecure and are not supported (in the brackets is
the OID ):

● MD2 RSA (1.2.840.113549.1.1.2)

● MD5 RSA (1.2.840.113549.1.1.4)

TLS-Based Secure Communication in PCo

Transport Layer Security (TLS) is the successor technology for SSL. TLS should be used in version 1.2, earlier
versions are deprecated. In PCo 15.2 SP03, FP 1 TLS 1.2 is supported for all TLS -based connections. In earlier

Security Guide PCo 15.2

18 PUBLIC Communication and Network Security
versions of PCo, only the predecessor technologies may be available for certain connections. This will be fixed
by patches.

New functionality in PCo will only support version 1.2 of TLS. Existing functionality may support earlier versions
to ensure backwards compatibility. Not supporting earlier versions may break connectivity. In future versions of
PCo, support for TLS 1.0, 1.1, or SSL may be disabled by default, though. You should use TLS 1.2 wherever
possible.

PCo uses Transport Layer Security (TLS) to secure the communication between PCo and the following:

● SAP MII, if PCo acts as MII client

● SAP ME, if PCo acts as Web client
● OData server, if PCo acts as OData client
● Web server for Restful Web services, if PCo acts as Web client
● ESP server, if PCo acts as ESP client
● SAP MII, if PCo acts as socket server
● WebSocket clients, for example, SAP MII, if PCo acts as WebSocket server
● Web service client, when PCo acts as Web server
● PCo MQTT source/destination system and an MQTT server

In addition, TLS is used in PCo services offered by the Management Host Service.

TLS is based on the exchange of certificates between server and client. During the handshake between server
and client, the server identifies itself by a certificate that is sent to the client. The client checks whether the
given certificate is a trusted and a valid certificate. Optionally, the server could request a client certificate. In
this case, the client also must send the certificate to the server that is checking the validity and the
trustworthiness of the certificate. A secure communication channel is only created successfully, if all checks
are passed.

In principle, there are two types of certificates:

● Self-signed certificates
● Certificates issued by a trusted Certification Authority (CA)

The type of certificate determines how to set-up the certificate infrastructure to get the secure communication
working:

● If certificates issued by a trusted CA are used, it is not necessary that the client knows the server
certificate and vice versa. It is only necessary that the client knows the CA certificate that issued the server
certificate. Accordingly, the server has to know the CA certificate that issued the client certificate. This
means that the server keeps the server certificate and the CA certificate in its certificate store, while the
client stores the client certificate and the CA certificate.
● If self-signed certificates are used, the certificates have to be exchanged between server and client. This
means that the server has to import the client certificate without a private key , while the client has to
import the servert certificate without a private key. Finally, the server certificate store contains the server
certificate (with a private key) and the client certificate (without a private key). Accordingly, the client
certificate store contains the client certificate (with a private key) and the server certificate (without a
private key).
● A Web server in PCo agent instance is configured with only one server certificate which is imported by the
client during the initial ‘handshake’. This certificate contains information such as expiration date, issuing
authority and the service end point URI (Uniform Resource Identifier). During handshake, the client
compares the URI to the URI it had originally communicated to ensure the match and it also checks the

Security Guide PCo 15.2

Communication and Network Security PUBLIC 19
 issuing authority and expiration date. The encryption and decryption during this process occur as
explained below:
○ The client encrypts with the server’s public key and the server decrypts with its private key, thus only
the entity with the private key can decrypt the client’s encrypted data.
○ The server encrypts with its private key and the client decrypts it with the public key of the server, thus
providing the assurance to the client that the data must have come from the owner of the certificate

● After this initial handshake process, both the server and the client agree on a shared secret symmetric key,
which involves less computation overhead and is responsible for establishing the secure communication.

In order to grant a Secure Socket communication between MII and PCo, a server and a client authentication
have been implemented. For more information about Configuring the Use of TLS on the AS Java, see http://
help.sap.com/saphelp_nw73ehp1/helpdata/en/4a/015cc68d863132e10000000a421937/content.htm .
The steps in PCo are described in the section Enabling TLS for an Agent Instance [page 21].

If PCo acts as an MII client or ME Web client, only a server authentication with certificates takes place.
According to the description above, a server certificate has to be imported onto the MII server or the ME server.
On the PCo side, the appropriate certificate has to be imported into the trusted certificate store.

To enable TLS for the Management Host service, the steps described in the corresponding section have to be
considered.

 Note

Self-signed certificates for PCo can be created with certificate creation tools like OpenSSL . (See PCo
application help for Default Certificates).

The Microsoft tool makecert is deprecated. Microsoft offers functionality to create self-signed certificates
in a newer version of MS PowerShell. See: https://docs.microsoft.com/en-us/windows/desktop/
seccrypto/makecert

To create a certificate request that could be sent to a CA, Microsoft IIS or certificate creation tools as
described above could be used.

Enabling TLS for the Management Host Service

You can enable TLS for the Management Host service by editing the file ManagementHost.exe.config.
Since the Management Host service is based on the Windows Communication Framework (WCF), potentially
all options provided by the WCF apply. It cannot be guaranteed, however, that all possible and valid
configurations will work in your environment. In particular, it is known that message security with
wsHttpBinding for connections between WCF -based applications and Java applications is problematic or
difficult to set up.

One particular example setup which enables transport security with the basicHttpbinding is described
below:

To do this, carry out the following steps:

1. You can modify the corresponding endpoint in the Services section by replacing
address=”http://
with

Security Guide PCo 15.2

20 PUBLIC Communication and Network Security
 address=”https://
2. In the serviceBehaviors section, replace
<serviceMetadata httpGetEnabled="True" httpGetUrl="http://hostname:port "
with
<serviceMetadata httpsGetEnabled="True" httpsGetUrl=”https://hostname:port”
3. Assign a certificate to the TLS port for the host name with Windows Command Prompt.
4. Open the Windows Command Prompt as Administrator and execute the following command:
netsh http add sslcert ipport=[IP address of PCo Server]:[Port of the Management
host] certhash=[thumbprint of certificate] appid=[Guid for the owning
application]
5. Here you have to enter the following parameters:

Parameter Description

ippport IP address and port for the binding

certhash The hash of the certificate. The hash is the thumbprint of

the certificate in capital letters.

appid GUID to identify the owning application. The GUID =

[1A570ED4-80D1-4A98-A7AB-8B4C6D5A42A5] shall be
used as PCo application GUID.

Example
add sslcert ipport=1.1.1.1:443 certhash=0102030405060708090A0B0C0D0E0F1011121314
appid={1A570ED4-80D1-4A98-A7AB-8B4C6D5A42A5}

Enabling TLS for an Agent Instance

1. Create a server certificate that is either self-signed or issued by a CA.

2. Import the server certificate to the personal certificate store.
3. Create a client certificate that is either self-signed or issued by a CA.
4. Import the client certificate or import the CA certificate to the trusted root CA store.
5. On the PCo Management Console, select an agent instance.
6. On theServers tab, select the entry SAP MII Query Server.
7. Select Server Certificate as the authentication type.
8. Click Browse to select the appropriate certificate.

Enabling TLS for the Web Server Hosted in an Agent Instance

The Web server hosted within the agent instance can be secured by enabling TLS technology for a Web client
and Web server communication over an insecure network that is encoded with the HTTP protocol. This use of
TLS to encrypt the HTTP traffic constitutes the HTTPS protocol.

Security Guide PCo 15.2

Communication and Network Security PUBLIC 21
The Web server is a self-hosted Windows Communication Foundation (WCF) service with
BasicHttpBinding (in the case of a SOAP-based Web service) and WebHttpBinding (in the case of a REST-
and ODATA-based Web services) classes that employ transport security. In order to enable TLS, it is mandatory
to configure the Web server port with an X.509 certificate during PCo Web Server endpoint configuration. The
default URI scheme in this endpoint configuration is HTTPS and the user is required to attach the server
certificate with this URI scheme. This feature can be disabled by manually changing the endpoint URI scheme
from HTTPS to HTTP.

Additionally, the PCo Web Server also provides the basic authentication and authorization mechanism to verify
identity and check the privileges of the authenticated user on the Web server and its operations. The user
should be defined on the host machine where PCo is installed. The authorization permissions can be set either
on the Web server or its individual operations. The authentication and authorization in that order is the default
behavior during the configuration of the Web server endpoint. However, this behavior can be turned off by
turning off the authentication in the Web Server Endpoint Configuration dialogue. When authentication is
turned off, it also automatically hides the authorization check and all the Web server operations can be
accessed without entering any user credentials. Certificate-based authentication to the Web server has been
introduced in the Web server, but certificate-based authorization in this process has been turned off.

 Note

The Microsoft Certificate store is always used for the Web server certificate.

Network Security

If the business system and the data source that are to be connected by PCo are located in different network
segments and/or separated by a firewall, the following considerations should be taken into account:

● The basic recommendation is to run PCo (or the agent instances, to be precise) close to the data source.
● For the notification scenario, PCo has to be able to reach the business system. The details for this are
configured in the notification destination in the PCo Management Console.
● For the query scenario, the business system needs to be able to reach the agent instance. The port used
for this can be configured in the agent configuration in the PCo Management Console.
● To use the remote console, the MMC (Microsoft Management Console) has to be able to reach the PCo
Management Host. The port used for this can be configured in the PCo Management Console.
● To create a data source of type PCo Connector in MII, the system needs to be able to access the PCo
Management Console.

Ports

All ports that an agent instance opens for incoming connections can be configured in the PCo Management
Console. For this, navigate to the Query Ports tab in the agent instance configuration.

Using the PCo Management Console, you can also configure the port that is opened by the PCo Management
Host. For this, navigate to Tools Options Management Host Settings .

Security Guide PCo 15.2

22 PUBLIC Communication and Network Security
Storing Configuration Information and Data
Privacy Protection

PCo stores all configuration information for source systems, destination systems, and agent instances in
configuration files. The location of these files depends on the operation system, but usually you can find the
folder under:

C:/ProgramData/SAP/PCo

This folder also contains the configuration audit log with the change history. This change history includes the
user ID of the person who made the changes. The system administrator with the relevant authorization can
delete the file depending on how long the audit data needs to be retained.

From the PCo Management Console you can reach this log using the View Menu.

 Note

PCo does not store any runtime data and does not provide other security audit capabilities.

For the encryption of passwords in the configuration database files, PCo uses built-in Microsoft operating
system support.

Security Guide PCo 15.2

Storing Configuration Information and Data Privacy Protection PUBLIC 23
Dispensable Functions with Impacts on
Security

The following functions that are relevant to security aspects can be switched off if you are not using them:

● Management Host: The Windows service for the PCo Management Host can be deactivated. The
Management Host is required for the following scenarios:
○ Creation of a PCoConnector data server in MII
○ Use of the Remote Client
● Active Monitor: If you are not using the Active Monitor scenario, you can deactivate the corresponding
Windows service or you deselect the corresponding component already during installation .

Security Guide PCo 15.2

24 PUBLIC Dispensable Functions with Impacts on Security
Important Disclaimers and Legal Information

Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:

● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:

● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.

Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by
SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use
the experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your
feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.

Security Guide PCo 15.2

Important Disclaimers and Legal Information PUBLIC 25
www.sap.com/contactsap

© 2018 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.

Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.

SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.

Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.

THE BEST RUN