Planning for security

The security of data, exchanges, and system integrity is a vital part of achieving your business objectives.

You must identify your business issues and translate them into business objectives. After you identify your objectives, you can begin planning for all the facets of implementing AS4 Microservice, including security.

A successful implementation depends on a comprehensive, multifaceted plan that you formulate before you configure the building blocks that tell AS4 Microservice the work you want it to do. The best practice is to use multiple layers of security to circumvent unauthorized interception of data if one layer is bypassed or compromised. For example, use digital signatures to sign your message and also encrypt the message.

You need to consider the following types of questions and recommended best practices when you identify your AS4 Microservice security objectives. The best practices outline the high-level steps necessary to implement security for AS4 Microservice. It describes planning that needs to be done for each task and the documentation references you can access for more information.

Planning to secure hardware

Where is your software installed and running? Who has physical access to those machines?

Planning to limit the data that users can view and manage

Which users need to access which areas of the application, and what permissions do they need? Consider all aspects of user and role management. As part of the planning process, determine the user access to AS4 Microservice and the data it collects and exchanges. Consider the following when you determine user access:

The types of users (roles) who can access AS4 Microservice. When you create users, u give them credentials, or permissions, to access the system by assigning the users to a group with specified permissions and access rights.
The permissions those roles have to configure and maintain data and system infrastructure. In general, give each user the least amount of access control necessary.
Whether you plan to limit what events (data) that specific users can monitor. When you assign visibility permissions, data visibility groups can be used to segregate the data that is collected and exchanged. Data visibility groups facilitate the segmentation of data and add another layer of security to your system.
Whether you implement a password policy that governs password creation and expiration limits. To ensure software security, it is important to implement and enforce a password policy. Ideally, the password policy that you implement for AS4 Microservice users also conforms to your company's password policy. This password policy applies first and foremost to the default system access credentials, the MACCOUNTADMIN and SYSADMIN users. You must change the password for both of those users immediately after you install the application. The default password for both users is password. Your password policy can include specifications for minimum and maximum password length, requiring lowercase, uppercase, and special (non-alphanumeric) characters in the password, and excluding lowercase, uppercase, and special characters in the password (for example, the admonition to not repeat a user name in the password).

Planning to manage digital certificates

A digital certificate is a set of electronic data that uniquely identifies an organization. The certificate contains a public key for the organization, and is digitally signed by a trusted party to bind the public key to the organization. Other information in the certificate specifies how the key is used and the time period for which it is valid. In this application, you can use certificate authority certificates, private/public key certificates, and trading partner certificates.

Do you need notifications when your partner's digital certificates that are used in exchanges are going to expire or are revoked? Do you trust received public certificates by authentication with a configured CA store and Certificate Revocation Lists (CRLs)? A Certificate Revocation List (CRL) is a time-stamped list of certificates that are revoked (or are no longer trusted) by a certificate authority (CA). A CA is an independent and trusted third party that issues digital certificates to provide assurance that the public key of an entity truly belongs to that entity. On the CRL, the CA maintains a list of serial numbers of certificates that are revoked. The CRL also contains a statement that indicates why each certificate was revoked and the date that the revocation occurred. The list usually contains all certificates that were revoked within the lifetime of the CA.

Do you use digital certificates for identity authentication, and select the certificate that is based on alias name and function usage (such as sign, verify, encrypt, decrypt, SSL client)? Do you allow the signing of outbound exchanges with an X.509 certificate to ensure message integrity and prevent data modification in transit? Do you specify that inbound messages must be signed, and specify the signature hash to be used?

Planning for secure communications

Consider these functions to ensure the security of your communications with your partners include these commonly accepted aspects of security:

Identification and authentication

Identification is the ability to identify uniquely a user of a system or an application that is running in the system. Authentication is the ability to prove that a user or application is genuinely who that person or what that application claims to be. You can also specify that inbound messages must be signed, and specify the signature hash to be used. For NIST compliance, you must specify a higher key strength algorithm (for example, SHA256) in the conformance policy.

Determine whether you want to create conformance policies (for AS4 exchanges) that specify security aspects and settings to secure communication with your partners. Security policies can include whether:

HTTP or HTTPS basic authentication is required
Signed messages are required
Signed Message Disposition Notifications (MDNs) are required for AS4 exchanges
Messages are required to be encrypted

Authentication uses a security token to validate a user and determine whether their access is valid in a particular context. A client can be a user, computer, or application. To provide authentication, you can insert a security token in the request message. Depending on the type of security token that you use, the security token can also be inserted in the response message.

Authorization

Authorization protects critical resources in a system by limiting access only to authorized users and their applications. It prevents the unauthorized use of a resource or the use of a resource in an unauthorized manner.

Confidentiality

You can use a Java Cryptography Encryption file to strengthen cryptographic operations. This application programming interface that supports and enhances the security features of the application. The JCE policy file helps to ensure data privacy, maintains data integrity, authenticates on partner to another, and prevents repudiation of messages.

The confidentiality mechanisms protect sensitive information from unauthorized disclosure. For example, you can ensure message confidentiality by converting the contents to ciphertext with XML encryption. This encryption ensures that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers.

You can use the secure HTTPS protocol to transmit messages when they are transmitted to and from your partners. HTTPS, a combination of Hypertext Transfer Protocol (HTTP) and Secure Sockets Layer (SSL), is the industry standard for securing information that is transmitted between partners.

Canonicalization is a process for converting data that has more than one physical representation into a standard format that is known as Canonical XML. XML canonicalization (c14n) of an XML document defines the physical changes that can be made to the document without changing the logical representation of the document. Canonicalization is recommended when you use an XML digital signature.

Data integrity and nonrepudiation

The data integrity and nonrepudiation mechanisms detect whether unauthorized modification of data occurred. You can ensure message integrity and authentication by signing a message with a digital signature. This signature confirms the source of the message and detect whether the contents were altered in transit. You can also set the maximum size of message payloads to prevent denial of service because a large payload is exhausting system resources. And, you can set the maximum size of a message request. This message validation measures the message size against the criteria you specify and any request that is larger than the specified size limit is rejected.

In the application, support for message-level security is provided though the WS-Security standards found in ebMS, including a combination of XML digital signatures and XML encryption. Signing and encryption are primarily accomplished with X.509 security tokens for authenticating messages, securing privacy, and ensuring the tamper-proof data transmission. These integrity and confidentiality security mechanisms also prevent message alteration and eavesdropping. Additionally, you can prevent replay attacks by using message time stamps.

XML digital signatures and XML encryption provide the ability to do the following:

Selectively encrypt and protect the integrity of parts of a message without needing to encrypt the entire message. You can also secure different parts of a message with different methods. For example, you can use integrity (by applying a digital signature to the entire message) on the security token and confidentiality (specifying which message parts within the generated message must be encrypted) on the message body.

Protect data without encrypting it.

Construct overlapping digital signatures that use different keys.

Digitally sign and encrypt data in the sequence that your application dictates.

When you use public key cryptography, XML encryption ensures message confidentiality but it does not ensure message integrity because the receiver key is public. The following are best practices when you use XML encryption.

Use XML encryption with digital signatures to ensure the identity of the sender.
Within a message, you can keep data elements confidential by encrypting the elements by using a strong encryption cipher with an adequate key length to deter brute forcing.
Encrypt messages that contain sensitive data with a strong encryption cipher (either with transport encryption or message encryption, or both).
Encrypt messages that contain sensitive data (and must remain encrypted at rest after the message is received) with strong data encryption (not transport encryption).
Super-encrypting is the process of encrypting an EncryptedData element. An XML document can contain zero or more EncryptedData elements. An EncryptedData element cannot be the parent or child of another EncryptedData element. However, the actual data encrypted in the element can be anything, including EncryptedData and EncryptedKey elements. During super-encryption of an EncryptedData or EncryptedKey element, you must encrypt the entire element.
Encrypted keys or data can identify a key that is required for decryption by identifying the corresponding key that is used for encryption with a security token. You do not need to specify a trust path or the specific contents of the certificate to identify the decryption key.

Nonrepudiation is a security mechanism that is used in business-to-business transactions to establish the sender, the receiver, and the contents of the file that is transmitted. Nonrepudiation provides proof that a transaction occurred, or that you sent or received a message. Nonrepudiation is supported by the use of digital certificates and public key cryptography to sign messages.