Best Practices to create Highly Secure Applications in Mule 4

Dont want to compromise on Security

In this blog, I would like to share few Best Practices in creating Highly Secure Applications in Mule 4 (security at various levels — application, data, etc) for all deployment options.

Most of the configuration details (relevant to Security) shared here are taken from MuleSoft Documentation/Articles/Blogs.

Let me start with the concept of ‘Defence in Depth’, which is multi-layered security startegy recommended by all cloud service providers.

Defense in Depth is a cybersecurity strategy that involves implementing multiple layers of security measures to protect an organization’s information systems and data. The idea behind Defense in Depth is to create multiple barriers that an attacker must overcome, making it more challenging for them to breach the system.

Platform/Policies & Access Layer

1. Accessibility Control — Access Management

Use Anypoint Access Management to create your Anypoint Platform account or configure federated External Identity. In addition, you can configure access & permissions within your Organization &, based on your access level, manage the Users and Roles.

Secure or limit access to various Anypoint Platform features.

Grant permissions based on the Principle of Least Privilege (POLP) that limits users’ access rights to only what are strictly required to do their jobs.

User Management

a. Grant Minimum Required Permissions to Users

Org. Admin. manage user access using teams or roles (deprecated), or by granting permissions to users individually.

By default, in every new organization & business group, you can assign the following:

• API permissions: Select the name of the API you want to give access to, then pick a version and permission.
• Runtime Manager permissions: Select the name of the Runtime Manager environment to give access to, then pick a permission.
• Teams: Select the name of the team to give access to.

Steps to follow (using Teams feature)

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Users.
4. Click the name of the user to which you want to assign permissions.
5. Click the Permissions tab.
6. In the Permissions section, click Add permissions. The Add Permissions window appears.
7. In the Select Permissions section, select the permissions that you want to add and then click Next.
8. In the Select Business Groups section, select the business groups to which you want to apply the permissions. If you selected a permission that enables you to select environments, you can select which environments to apply to the permission. Click Next.
9. In the Review section, review the permissions and the business groups and environments to which they apply, and then click Add Permissions.

b. Disable or Delete any Unwanted User(s)

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Users.
4. Against each user, you want to disable/delete, click more actions menu (three dots (…) menu). Then select either Disable user or Delete user.
5. If Disable user is selected, a confirmation dialog pops-up. Click Confirm.
6. If Delete user is selected, a confirmation dialog pops-up. Enter the name of the user & then click Delete.

NOTE: The disable/delete actions can also be performed by clicking the name of each user in the Users listing screen (after Step #3) & then selecting desired action from more actions menu (… menu) present at the top right corner of the selected user screen.

c. Manage External Users who need access to Public APIs

When you make an API portal public, users from any other Anypoint Platform organization must register client applications to call your API. When these users log in to your public developer portal, they are considered external users because they are outside of your organization.

When a user logs into Anypoint Platform for the first time, they are automatically added to the External Users (Public portal access) tab. From this tab, you can view a list of all external users. You can also enable or disable each of these external users from this screen. When you disable an external user, they can no longer log in to your public portal.

You cannot search for external users because these users do not belong to your organization and do not have additional permissions. To grant users permission to perform tasks like deploying an application, you must invite the user to join your organization.

Business Group (BG) Management

Business Groups (BGs) are self-contained resource groups that contain Anypoint Platform resources such as applications & APIs.

BGs are not enabled by default in a new Anypoint Platform account. To activate BGs in your organization, contact your MuleSoft representative. There is a limit of 100 BGs per organization.

a. Manage Access to BG(s)

Steps to follow

1. In the Access Management navigation menu, click Business Groups.
2. Click the name of the business group you want to access.
   The Settings section appears, showing details about the root organization or business group.
3. Click the Access Overview tab.
   The Access Overview section appears, displaying a list of all users with any permissions in the current business group by default.
4. Use the drop-downs to specify:

— Users or Teams

— Permissions (sorted by product

— Business group

5. Select the user for which you want to change permissions/disable user/delete user.

b. Delete any Unwanted BG(s)

Steps to follow

1. In the Access Management navigation menu, click Business Groups.
2. Click the name of your root organization.
3. Click the …​ menu next to the business group to delete.
4. In the confirmation dialog, enter the name of the business group and then click Delete.

Organization (Root) Management

When you create an Anypoint Platform account, a Root Organization is created, & you are assigned as the owner of the organization — Organization Owner.

The level of access users have to various resources depends on their assigned roles and permissions.

a. Secure your Organization

As an Org. Admin., perform below tasks to secure the Organization:

Create required teams (Refer here for the info & steps on how to create Teams).

Assign users to relevant teams or roles that define their permissions (Refer here for the steps on how to assign users to Teams).

Remove users, if required (Refer above ‘Disable or Delete unwanted users’ subsection for the steps on how to delete users).

Create required business groups to delegate management of the resources and define the scopes of roles and permissions (Refer here for the steps on how to create BG).

Change owners of business groups.

Configure security-related organization settings.

b. Configure Session Timeout Properly

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Business Groups.
4. Click the name of your root organization.
5. Click the Settings tab.
6. Modify the session timeout: Set the right amount of time (in minutes) a user is inactive before they are automatically logged out of Anypoint Platform. The default is 60 minutes, the minimum is 15 minutes, and the maximum is 180 minutes.

Environment Management

Anypoint Platform enables you to create & manage separate deployment Environments for APIs & applications.

You cannot grant users access to an environment directly. To grant a user access to an environment, use role permissions.

a. Associate a Client Provider with the Environment

If you did not associate a client provider with the environment when you created it, the default client provider is the Anypoint Platform client provider.

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Business Groups.
4. Click the name of your root organization.
5. Click the Environments tab.
6. Click the name of the environment.
7. In the Client Provider field, select at least one client provider.
8. If you added more than one client provider, click Set as default to designate a default client provider.
9. Click Update.

b. Delete any Unwanted Environment(s)

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Business Groups.
4. Click the name of your root organization.
5. Click the Environments tab.
6. Click the name of the environment.
7. Click Delete to delete the environment.

Permission Management

Permissions are assigned using Teams or roles (deprecated), or by granting permissions to users individually.

The Teams feature enables you to create groups of users and then assign the members of those groups certain permissions across multiple business groups.

As an Organization Administrator, you can create and modify teams and assign cascading permissions according to organizational structure.

Each role (deprecated) contains a list of permissions that define what a user with that role can do with the specific resources it scopes.

Certain roles include a set of default permissions.

Depending on the product, you can grant permissions directly to a specific user, without the need for roles or teams — more fine-grained control.

NOTE: For the list of permissions that can be assigned to Teams, granted to individual users, or combined to create roles (deprecated), refer here.

Team Management

The Teams feature enables you to create groups of users and then assign the members of those groups certain permissions.

An Organization can have up to 1000 teams. Teams can be nested up to 10 levels, including the ‘Everyone at <Root Organization>’ team.

a. Grant Minimum Required Permissions within Team(s)

For the steps to follow, refer above ‘Grant Minimum Required Permissions to Users — using Teams feature’ subsection.

b. Assign User type — Team Member or Team Maintainer Properly

You must have the Organization Administrator permission or be a Team Maintainer yourself to modify Team Members and Team Maintainers.

You can designate a Team Maintainer to delegate team maintenance responsibilities to users without giving them full organization administrator permissions, or you can remove the Team Maintainer designation and convert users back to Team Members.

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission or is a Team Maintainer of the team you want to modify.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Teams.
4. In the Members section, navigate to the user you want to designate as a team maintainer.
5. In the Type drop-down, select either Maintainer or Member.

c. Delete any Unwanted Team(s)

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. Click …​ next to the team that you want to delete.
4. Click Delete…​.
5. Enter the name of the team that you want to delete.
6. Click Delete.

Role Management

A Role is a set of predefined permissions controlling access to each product or feature within Anypoint Platform. Depending on the product, you can use predefined roles with standard permissions, or you can specify your own permissions for each role.

Roles are set only for individual users.

Roles are now deprecated in favor of the Teams feature, but you can still manage roles using business groups. You grant most roles as permissions instead.

Multi-Factor Authentication (MFA) Management

Multi-Factor Authentication (MFA) provides an additional layer of verification for Anypoint Platform users. MuleSoft requires MFA when users access Anypoint Platform, either directly with their Anypoint credentials or via single sign-on (SSO).

MFA is enabled for direct logins and can’t be turned off at the organization level.

When a user logs in with their Anypoint credentials, they must enter their password and then verify their identity with one of these verification methods:

— Third-party TOTP authenticator apps

— Built-in authenticator

— Security key

— Salesforce Authenticator

a. Modify Verification Method

Steps to follow

1. Log in to Anypoint Platform.
2. In the Anypoint Platform navigation bar, click the circle icon that contains the initials associated with your Anypoint Platform account.
3. In the drop-down, click Profile.
4. Click Configure multi-factor authentication (MFA).
   The Manage Your Verification Methods interface appears.
5. If you want to register an additional verification method:

a. Next to the verification method you want to configure, click Add.

b. Follow the instructions to configure your preferred verification method.

c. Click Done.

6. If you want to remove a verification method:

a. Next to the verification method you want to remove, click the bin icon.

b. Click Yes.

c. Click Done.

7. Click Save.

b. Reset MFA

You can reset MFA for individual users if a device is compromised or lost.

If you are the only organization member with Organization Administrator permission and have lost access to your verification methods, contact customer support.

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Business Groups menu, select your root organization.
4. In the Access Management navigation menu, click Users.
5. Click the user whose multi-factor authentication configuration you want to reset.
6. Click Reset multi-factor authentication.
7. Click Confirm reset MFA.
   Next time the user logs in to Anypoint Platform, they are prompted to configure a new verification method.

Identity Management

As the Anypoint Platform organization administrator, you can configure Identity Management in Anypoint Platform to set up users for single sign-on (SSO).

An organization can have up to 25 external identity providers, or IdPs, configured for SSO

Configure identity management using one of the following SSO standards:

— OpenID Connect: End user identity verification by an authorization server including SSO

— SAML 2.0: Web-based authorization including cross-domain SSO

a. Add Identity Provider(s)

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Identity Providers.
4. Click Add Identity Provider, and then select the identity provider type you want to add. Choose one of the following:

OpenID Connect — For the steps on how to configure, refer here.

SAML 2.0 — For the steps on how to configure, refer here.

b. Delete any Unwanted IdP(s)

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Identity Providers.
4. Next to the identity provider you want to delete, click the …​ menu.
5. Click Delete…​
6. In the API Update window, click Continue.
7. Enter the name of your identity provider.
8. Click Delete.

Client Management

Anypoint Platform acts as a Client Provider by default, but you can also configure external client providers to authorize client applications. As an API owner, you can apply an OAuth 2.0 policy to authorize client applications that try to access your API. You need an OAuth 2.0 provider to use an OAuth 2.0 policy.

An organization can have up to 25 external client providers to authorize client applications.

a. Add Client Provider(s)

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Client Providers.
4. Click Add Client Provider, and then select the client provider type you want to add. Choose one of the following:

OpenAM — For the steps on how to configure, refer here.

PingFederate — For the steps on how to configure, refer here.

OpenID Connect — For the steps on how to configure, refer here.

Azure Active Directory — For the steps on how to configure, refer here.

b. Delete any Unwanted Client Provider(s)

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Business Groups menu, select your root organization.
4. In the Access Management navigation menu, click Client Providers.
5. Click the name of the client provider you want to delete.
6. In the client provider’s page, click Delete.
7. Enter the name of the client identity provider name.
8. Click Delete.

Before you delete a client provider, ensure that you do not have APIs, assets, or environments that depend on the client provider, or you will lose functionality.

Connected Apps Management

The Connected Apps feature provides a framework that enables an external application to integrate with the Anypoint Platform using APIs through OAuth 2.0 and OpenID Connect.

Connected Apps help user delegate their access without sharing sensitive credentials or giving full control of their applications to third parties.

OAuth can authorize access (via access token) to resources without revealing user credentials (client id & client secret) to apps.

OpenID Connect identifies the end user and obtains information to pass to OAuth 2.0 Connected Apps.

Connected Apps address use cases for the following types of users:

Org. Admin. — control how their organization’s data is used by allowlisting apps, revoking access, and disabling this feature for the entire organization.

Developer (having Org. Admin. permission) — register new (and manage existing) apps within their organization.

End User — authorize apps to access particular information, such as viewing assets in Anypoint Exchange.

Only root-level organization administrators can view and manage connected apps.

a. Create Connected App with Proper GRANT TYPE & SCOPE

Only developers who have the organization administrator permission can create apps and specify access scopes in Anypoint Platform.

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Connected Apps.
4. In the Owned Apps section, click Create App.
5. In the Create App page, configure Grant types & Scopes properly:

Grant types — The grant types to be used with this app. For more info., refer here.

Scopes — The level of permissions to provide to this app. Click Add Scopes to select the scopes. For more info., refer here.

6. Click Save.

b. Configure RESTRICTED Authorization Policy

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Connected Apps & then Authorizations section.
4. Click Configure button.
5. Choose Restricted — Only Connected Apps approved by an admin can be authorized by organization members to act on their behalf option. When you choose this option, the application allowlist is enabled, & all existing application authorizations are added automatically.

NOTE: For more info. on Application Allowlist, refer here.

By default, the Unrestricted authorization policy is enabled.

c. Remove Unwanted Connected Apps

Steps to follow

1. Log in to Anypoint Platform using an account that has the Organization Administrator permission.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. Click Connected Apps & then Authorizations section.
4. Click the …​ icon next to an application to remove the app from your organization. When you revoke an app’s access, the app’s OAuth 2.0 access tokens and refresh tokens are revoked, and the app can no longer access user data.

Audit Logging/Management

Changes made by users within Anypoint Platform organizations are logged through an Audit Logging service. You can access the data logs through the Audit Logging Query API or through the Audit Logging UI.

Key Points about Audit Logs

It provides a query-able history of actions performed within the Anypoint Platform.

It keeps track of all users who have interacted with objects in the system, and timestamps those actions.

It provides mechanisms for querying the set of users who have performed actions, the set of objects that had actions performed on them, and other endpoints that enable the querying of log entries.

Audit logs have a default retention period of one year.

Users who have the Organization Administrator and Audit Log Config Manager permission can customize the retention period.

a. Access Audit Logs

The audit log service is business-group aware, which means you see only logs that are relevant to your own business group.

Steps to follow

1. Log in to Anypoint Platform.
2. In the navigation bar or the main Anypoint Platform page, click Access Management.
3. In the Access Management navigation menu, click Audit Logs.
4. The Audit Logs page displays the logs. You can:

— Download audit logs.

— Set a time period for audit logs to display.

— Filter audit logs by product, type, and actions.

— Search audit logs by environment, object, and user.

NOTE: For more info. on the contents of Audit Logs, refer here.

External Access Management

The External Access feature enables separate organizations to collaborate in Anypoint Platform. For eg., organizations can share API specifications, connectors, and other assets in Anypoint Exchange with each other, without making them public.

Key Points about External Access

— Administrators control which organizations their users can collaborate with by maintaining a list of trusted organizations in Access Management.

— Both organizations must reside in the same control plane, and trust must be established between organizations before permissions can be granted.

— Permissions shared between organizations are granted at the organization level.

a. Add Trusted Organizations

To add an organization to your configuration, you must know its Anypoint domain.

Steps to follow

1. From the Access Management home page, click the External Access tab.
2. In the External Access page, click Add organization.
3. Enter the unique domain name of the organization you want to share permissions with.
4. Click Add.

b. Remove Unwanted Organizations

Steps to follow

1. From the Access Management home page, click the External Access tab.
2. In the External Access page, select … next to the name of the organization you want to remove.
3. Click Remove organization.
4. Click Yes, remove.

2. Policies Enforcement — API Manager

Policies enforcement using API Manager (using Mule Gateway)

Irrespective of Gateway runtime (Mule Gateway, Flex Gateway or Service Mesh) you choose, applying/configuring policies remain the same.

Security-related Policy Types

Client ID enforcement: Requires authorized client applications to use a client id and client secret.

Authentication/Authorization:

— OAuth 2.0 token enforcement API policies.

— Basic Authentication — LDAP/Simple.

— JWT.

— IP-based access control — Blacklisting/Whitelisting.

Tokenization: Tokenization/Detokenization of selected sensitive fields.

Payload threat protection: Guard against attacks sending over-sized JSON/XML request bodies.

Automated Policies

Use Automated Policies to enforce security requirements by applying the same policies to all APIs running in Mule. With policy automation, you can quickly design, build, and deploy secure and consistent APIs.

Users with Organization Admin, Environment Admin, or with a role to Manage Policies in the environment can create, edit and delete Automated Policies.

a. Apply Automated Policy

Prerequisite(s)

User with either:

— Org. Admin. permission

— Environment permission

— Manage Policies role

Steps to follow

1. In API Manager, select Automated Policies from the left navigation menu.
2. Click Add automated policy.
3. Select the provided security policy — Basic Auth Simple, Basic Auth LDAP, OAuth2.0, IP Allowlist, IP Blocklist, JSON Threat Protection, XML Threat Protection, JWT Validation, Schema Validation, Tokenization, Detokenization (last two applicable only for RTF deployment model) that you want to configure.
4. Click Next.
5. Configure the selected policy accordingly. For info. on how to configure policies, refer here for Mule Gateway or refer here for Flex Gateway.
6. Under Rule of Applications sub-section (after expanding Advanced options), choose the appropriate runtime among the listed & enabled runtime options:

— Flex gateways

— Mule gateways

7. Click Apply

API-level Policies

Unless otherwise configured, policies are by default applied to the entire API. Policies with this granularity are called API-level policies.

b. Apply API-level Policy

Prerequisite

User with either:

— Org. Admin. permission

— Environment permission

— Manage Policies role

Steps to follow

1. Go to API Manager.
2. In API Administration click the name of the API to which to apply a policy.
3. From the left navigation menu, click Policies.
4. Click + Add policy.
5. Select the Security policy to apply & click Next.
6. Configure the required configuration parameters. For info. on policy configuration parameters, refer here.
7. Click Apply.

Resource-level Policies

You can implement an additional level of policy granularity, one in which access is controlled based on a criterion. Policies with this granularity are called Resource-level policies. At the resource level of granularity, policies are applied to only those requests that match the criteria.

c. Apply Resource-level Policy

Prerequisite

User with either:

— Org. Admin. permission

— Environment permission

— Manage Policies role

Steps to follow

1. Go to API Manager.
2. In API Administration, click the name of the API to which to apply a policy.
3. From the left navigation menu, click Policies.
4. Click + Add policy.
5. Select the Security policy to apply & click Next.
6. Configure the required configuration parameters. For policy configuration parameters, refer here.
7. Expand Advanced options.
8. Under Method & resource conditions, select Apply configuration to specific API method & resources.
9. Select the method — GET, POST, PUT, etc. out of the list.
10. Configure URI template regex field. You can specify a regular expression (regex) to include multiple paths when you apply a policy to a subset of resources exposed by an API. For more info., refer here.

Custom Policies

If you want to apply a new policy to your API that isn’t included in the default set of policies, you can create and use a Custom policy. Custom Policies are policies that anyone can develop and apply to their APIs, with the intention of extending existing functionality or defining new ones.

Custom Policy Workflow

1. Develop the policy (Security-related).
2. Package the policy.
3. Upload the resulting policy assets to Exchange.
4. Apply the policy to any API through API Manager.

NOTE: For info. on how to create a Custom policy & other related configurations, refer here.

3. Persistent Queues Encryption

a. Encrypt Persistent VM Queues (applicable for CloudHub deployment option ONLY)

You can enable data-at-rest encryption for all your persistent queues. By enabling this feature, you ensure that any shared application data written to a persistent queue is encrypted, allowing you to meet your security and compliance needs.

Steps to follow

1. Login to Anypoint Platform using account which has entitlement to enable persistent queues encryption.
2. Go to Runtime Manager.
3. While deploying an application, which is using persistent VM queues, enable the option Encrypt persistent queues for Persistent queues, see below:

Enabling VM Persistent Queues encryption option

b. Encrypt Anypoint MQs

You can enable data-at-rest encryption for all your Anypoint MQs also.

Steps to follow

1. Log in to Anypoint Platform and click MQ in the navigation menu.
2. Click Destinations.
3. Click the Add icon to display the menu
4. Select Queue or FIFO Queue.
5. Complete the fields in Create Queue or Create FIFO Queue — Make sure to turn-on the Encryption field so that all messages in the queue are encrypted:

Enabling Anypoint MQ encryption option

Perimeter Layer

4. Advanced Security — Anypoint Security (applicable to RTF deployment option ONLY)

Anypoint Security provides advanced security for your APIs and integrations to protect sensitive data and stop threats at the edge. It provides:

Edge security: Construct layers of defense with rapidly configured, enterprise-grade Edge gateways. Prevent denial of service (DoS), content, and OWASP Top 10 attacks using policy-driven chokepoints that can be deployed in minutes.

Automatic hardening: Get seamless integration between Edge and API gateways, which automatically detect API attacks, escalates them to the perimeter, and updates protections to eliminate vulnerabilities.

Sensitive information detection: Get alerts when sensitive information — such as PII, PHI and credit card data — is in API payloads. Streamline auditing and governance with prebuilt monitoring dashboards.

Automatic tokenization: Meet compliance requirements faster with a simple, format-preserving tokenization service that protects sensitive data while supporting downstream dependencies.

Automated policies: Enforce standardized policies across environments, audit deployed policies for compliance, and bridge the gap between security and DevOps teams by empowering API owners to detect out-of-process changes and correct violations.

Standardize access: Establish standard API patterns for authentication and authorization and make patterns available as fragments to promote reuse instead of writing new, potentially insecure code.

Edge-level Security Policies

You can use the Anypoint Security’s Edge-level Security Policies to manage all traffic to your Runtime Fabric, and leverage API Manager policies to further enforce & apply specific behaviors to specific APIs, see below:

Anypoint Security’s Edge-level Security Policies

Edge-level Security Policies include:

Threat detection and prevention

— Content attack prevention (HTTP header and message limits checks)

— Denial of Service

— IP allowlists

Advanced TLS (certificate pinning, CRL)

Basic TLS (Mutual TLS, SSL Termination)

Prerequisites (common for all policy types)

— Have the Anypoint Security — Edge entitlement.

— Have Runtime Fabric on VMs/Bare Metal with inbound traffic configured.

— Enable inbound traffic on Runtime Fabric

a. Apply IP Allowlist Policy

Steps to follow

1. Navigate to Anypoint Security.
2. Click Create Policy, and select IP Allowlist.
3. Add a name for your policy in the Name field.
4. Under IP Allowlist, click Add IP.
5. Insert the range of IP addresses to the list. You must use the CIDR format for a range of IP addresses.
   To add more IP address ranges, click Add IP again.
6. Click Save Policy.

b. Apply Denial Of Service Policy

When you create a Denial Of Service (DoS) policy, you configure a time span and action to take when the error types you configure are encountered. If the policy encounters more errors than your configured threshold coming from the same IP address, the policy can either drop the connection silently (doesn’t attempt the TLS connection), or drop the connection immediately and return a 503 error.

The DoS policy determines the source of the request in the following three ways:

TCP Message — source IP address

Source IP address header field

Proxy Protocol IP address

Since the source of the request is based on the IP address, if an an attacker spoofs the source IP address, the DoS Policy cannot prevent the attack.

Steps to follow

1. Navigate to Anypoint Security, click Create Policy, and select Denial Of Service.
   The process of applying a DOS Policy has six different screens.
2. Click General on the left navigation bar:

a. Add a name for your policy in the Name field.

b. Set up a time interval, in seconds, in Rule A Time Period.
This time interval is the threshold at which your policy begins to block requests if it encounters the number of errors that you configure for each type of error.

c. Use the Max Sources To Monitor field to set up a maximum number of IP address to track.
The DoS policy can be configured to track up to 500000 IP addresses.

d. Use the Reject Message Action drop-down menu to select the type of response the policy returns when dropping a client connection. You have two options:

— Drop Silently: The policy drops the connection silently and avoids making the TLS handshake altogether. The policy avoids making the connection for the TCP packets with source IP address in AWS ELB Proxy Protocol headers, or for source IP address taken from the TCP packet. This is the most efficient way to terminate the client’s connection, as the policy avoids reading the attacker’s request.

— Send HTTP 503: The policy terminates the connection and returns a 503 (Service Unavailable) response to the client. This requires a TLS connection to be made, which is resource expensive.

3. Now you can configure your policy to take action for the different error types.

NOTE: For more info. on

— Rules, Thresholds, and Escalations, refer here.

— Mappings of policies violations & error escalations, refer here.

— Error Types, refer here.

c. Apply HTTP Limits Policy

HTTP Limits Policy prevents an attacker from sending large messages that can consume bandwidth and potentially cause performance degradation or denial of service. This policy limits the size of TCP protocol messages, paths, headers, and footers. This policy does not perform checks on the content of a message.

Steps to follow

1. Navigate to Anypoint Security, click the Create Policy icon, and select Content Attack Prevention.
2. Add a name for your policy in the Name field.
3. Configure the following parameters for your policy:

— Maximum Message Size: The default maximum message size allowed is 104857600 bytes. Modify this value based on the requirements of your application by setting the maximum size to a value based on a size your APIs can handle. To prevent attackers from abusing request body checking and exhausting resources, choose the smallest value that satisfies your requirements.

— Maximum Path Length: The default maximum path size allowed is 4096 bytes.

— Maximum Length Of a Single Header: The default maximum header length allowed for is 16384 bytes.

— Maximum Length Of a Single Trailer: The default maximum trailer length allowed is 16384 bytes.

— Maximum Number Of Headers and Trailers: The default maximum number of headers and trailers allowed is 32 kB.

4. To allow only specific HTTP methods, add them in the Allowed HTTP Request Methods field. Valid HTTP methods are: GET, POST, PATCH, HEAD, TRACE, OPTIONS, DELETE, and PUT.

5. Click Save Policy.

d. Apply Web Application Firewall (WAF) Policy

The Web Application Firewall (WAF) policy is available for request and response traffic to provide protection at the Web application level.

WAF policies are fully integrated with the existing Anypoint Security policy DoS (Denial of Service). When the WAF policy detects errors, it triggers the thresholds configured in the DoS, which can be optionally configured to take actions such as shaping or blocking traffic for an IP address from a malicious source.

Steps to follow

1. Sign into Anypoint Platform and navigate to Anypoint Security.
2. In the Security Policies page, click Create Policy and select Web Application Firewall (WAF).
3. Enter a Name for the policy and click Save Policy.
   The policy appears in the Security Policies list, where you can edit and delete policies.
4. Configure the rules to allow or block request traffic to your web application:

a. In the menu on the left, click Request Rulesets.
All the rules are disabled by default. For each rule, you can:

— Disable ruleset — (Default) Ruleset detection is turned off.

— Detect and allow violations — The violation is detected, and you will get information, per incident, in your log at the INFO level.

— Detect and reject violations — The request is rejected and returns a response status of HTTP/1.1 400 BAD REQUEST - web application firewall, and DoS is notified that a rule was triggered. If DoS has been configured for WAF Errors, DoS updates its WAF-related counters and takes action, if necessary. If DoS isn’t configured for WAF Errors, it ignores the notification it receives from WAF.
Information about the violation is also sent to the log, per incident, at INFO level. When you hover over the i to the right of each rule, the rule ID range for that ruleset is displayed. You can use this information for testing rulesets.

Configuring Request Rulesets as part of WAF Policy

b. In Advanced performance options, select one of the following options:

— Disable body scanner — By default, the request body is scanned unless the body is larger than 1 MB, in which case the scan is skipped.
Check this option if request body scanning isn’t needed, or to reduce CPU consumption.

— Detect sensitive information — If you select this option, the request body is scanned for sensitive information, and when you apply the WAF policy to Runtime Fabric, the log summary (rtfWafSecurityPolicySummary) records the count and number (rule ID) of the sensitive information pattern that is detected.

c. Click Save Policy.

5. Configure the rules to allow or block responses to your web application:

a. In the menu on the left, click Response Rulesets.
All the rulesets are disabled by default. For each rule, you can:

— Disable ruleset — (Default) Ruleset detection is turned off.

— Detect and allow violations — The violation is detected and you will get information, per incident, in your log at the INFO level.

— Detect and reject violations — The request is rejected and returns a response status of HTTP/1.1 400 BAD REQUEST - web application firewall and information about the violation is also sent to the log at INFO level per incident.

b. In Advanced Performance Options, select one of the following options:

— Disable body scanner — By default, the response body is scanned unless the body is larger than 1 MB, in which case the scan is skipped.
Check this option if response body scanning isn’t needed, or to reduce CPU consumption.

— Response messages must have one of the following MIME types in the content type header, or the WAF rules will not be evaluated:

— text/plain

— text/html

— text/xml

— application/json

— Detect sensitive information — If you select this option, the response body is scanned for sensitive information, and when you apply the WAF policy to Runtime Fabric, the log summary (rtfWafSecurityPolicySummary) records the count and number (rule ID) of the sensitive information pattern that is detected.

c. Click Save Policy.

6. Escalate the WAF Policy to DoS:

a. In Security Policies, select the DoS policy in the list and click Edit.

b. In the left menu, click WAF Errors.

c. Configure the WAF errors and click Save Policy.
All WAF errors will be handled by the thresholds you configure in the DoS policy.

Configuring WAF Errors as part of DoS Policy

NOTE: For more info. on WAF Rulesets, refer here.

Tokenization

Tokenization is a highly effective way to protect sensitive data. When you tokenize data, sensitive data elements are substituted with randomly generated non-sensitive data elements. It is commonly used for protecting payment card information, personally identifiable information, and other sensitive data.

Prerequisites

— Have the Anypoint Security — Edge entitlement.

— Have the correct permissions to manage tokenization.

— Have Runtime Fabric on VMs/Bare Metal with inbound traffic configured.

a. Create a Tokenization Service

Steps to follow

1. Go to the Runtime Manager­ > Tokenization Service page.
2. Click Create Tokenization Service.
3. Select the Runtime Fabric to which to deploy the tokenization service.
4. Select the tokenization format.
   You can assign one or more formats or all formats to one tokenization service.
5. Select the number of cores to use for the tokenization service replicas. The tokenization service runs on worker nodes in Runtime Fabric. You can select a minimum and maximum number of cores, defined as:

Reserved vCPU: The amount of vCPU guaranteed and reserved for the application’s use.

vCPU Limit: The maximum amount of vCPU the application can use (the level to which it can burst). This is shared CPU on the worker node.

6. Select the log level for the tokenization service or keep the default (ERROR).

7. Click Build and Deploy to create the tokenization table.

The tokenization mapping table build is a one-time action and takes some time to complete, depending on the size of the tokenization format.

b. Configure a created Tokenization Service

There are 2 ways to do:

Apply a Tokenization Policy to the API Gateway: You can apply a tokenization policy to configure the API gateway capability of Mule 4 to tokenize or detokenize request and response data sent between the Anypoint Runtime Fabric inbound load balancer and the Mule app.

Expose Tokenization as a Service to Mule Apps: When extra data processing is required, a Mule application can add business logic to send tokenization and detokenization requests directly to the tokenization service as part of its processing.

NOTE: For more info. on tokenization formats, refer here.

Secrets Manager

Anypoint Security’s Secrets Manager uses secure vault technology to store and control access to private keys, passwords, certificates, and other secrets.

Secrets Manager is not a general-purpose tool, it only supports usage with Anypoint Runtime Fabric and API Manager Proxy’s (for HTTPS certificate storage).

Secrets manager supports the management of TLS context for:

Runtime Fabric Ingress: You can store TLS artifacts in secrets manager and then configure Runtime Fabric Ingress with the secret reference. Secrets manager supports Runtime Fabric Ingress only for RTF on VMs /Bare Metal (Appliance) product.

API Manager: You can store the TLS artifacts in secrets manager and then configure API Manager with the secret reference.

Secrets manager can store and manage these secret types:

TLS Context: SSL Security Parameters (ciphers to use, TLS version, and so on).

Keystore: A repository of security certificates (either authorization certificates or public key certificates), along with their corresponding private keys.

Truststore: A repository of security certificates from either other parties with which you expect to communicate, or Certificate Authorities that you trust to identify other parties.

Certificates: Public X.509 certificates, which are electronic documents that bind a public key with an identity (hostname, organization, or individual).

Certificate Pin Set: A repository of security certificates from other parties that associate a client or host with their expected X.509 certificate or public key.

CRL Distributor: An entity that creates and maintains a list of CA certificates that are no longer trusted because their associated private keys, or a signing CA, were compromised.

NOTE: For more info. on Secret Types, refer here.

Secret Groups

A Secret Group is a logical grouping of secrets that enables you to manage a group of secrets as a unit.

Secrets Manager stores your secrets per secret group, per environment, and per business group.

a. Create a Secret Group

Steps to follow

1. In Anypoint Platform, go to Management Center then select Secrets Manager.
2. Click Create Secret Group.
3. Enter a name for the secret group and click Save. The name of your secret group must:

— Start with a letter

— Be at least three characters long and no longer than 35 characters

— Contain only letters, numbers, and dashes; however, the name cannot end with a dash.

After creating your secret group, it appears in the Secret Groups list view. Edit the secret group to add the necessary secret types, such as a truststore or a keystore.

b. Add a Truststore into a created secret group

For the steps to follow, refer here.

c. Add a Keystore into a created secret group

For the steps to follow, refer here.

d. Add a Certificate Pinset into a created secret group

For the steps to follow, refer here.

e. Add a Shared Secret into a created secret group

For the steps to follow, refer here.

f. Add a Certificate

Steps to follow

1. In the Secret Groups list view, select the secret group you need to add a certificate to and click Edit.
2. In the menu on the left, select Certificate and then click Add Certificate.
3. In the Add Certificate screen, complete these fields:

— Name: Enter a name for your certificate.

— Type: Select PEM from the drop-down menu.

— Certificate File: Click Choose File and select the certificate file to upload.

— Override Expiration Date: If you want to override the current expiration date of the certificate, select a new expiration date.

4. Click Save.

g. Add a TLS Context for Mule

Steps to follow

1. In the Secret Groups list view, select the secret group to which to add a TLS context.
2. Select TLS Context in the menu on the left, and click Add TLS Context.
3. In the Create TLS Context screen, add the required information:

— Name: Enter a name for your TLS context.

— Target: Select Mule to use the TLS context as the SSL validation for Mule 4-based API proxies. Uses the TLS context as the SSL validation for Mule 4-based API proxies.

— TLS Version: By default, TLS 1.2 is selected. You can select TLS 1.1 to support both versions.

— Keystore: From the drop-down list, select the keystore to store the TLS context.

— Truststore: Optionally select a truststore to which to add the TLS context if you are using a truststore to store certificates trusted by the client.
If the Target value for the TLS context is Mule, you can select Insecure if you don’t want certificate validation enforced.

— Expiration Date: Optionally select the expiration date for the certificate.

4. Optionally select ciphers for the TLS context. For more info. on ciphers, refer here.

5. Click Save.

h. Add a TLS Context for Anypoint Runtime Fabric

For the steps to follow, refer here.

NOTE: For info. on how to enable client authentication for TLS context, refer here.

Networking Layer

5. VPC Setup

The Anypoint Virtual Private Cloud (VPC) offering allows you to create a virtual, private, and isolated network segment in the cloud to host your CloudHub workers.

a. Provision a VPC

Steps to follow

1. Create the VPC: This is a self-service process. You can create a VPC using either the Runtime Manager UI, or the Anypoint Platform CLI.
2. Connect to your Anypoint VPC: Configure your Anypoint VPN or transit gateway to connect the Anypoint VPC to your on-premises network.

b. Create the Anypoint VPC

Prerequisites

— Anypoint VPC entitlement.

— Permissions to create and administrate a Anypoint VPC

Steps to follow

1. Sign into your Anypoint Platform account as a user with the Organization Administrators role.
2. Under Management Center, click Runtime Manager.
3. In the left navigation, click VPCs.
4. Click Create VPC, and enter the following information to define and configure the Anypoint VPC:

Name: The name to identify your Anypoint VPC. The name must:

— Be unique within the organization

— Between 3–42 characters long

— Contain only lowercase letters, numbers, and dashes

Region: The region to which the Anypoint VPC is bound.

CIDR Block: The size of the Anypoint VPC in Classless Inter-Domain Routing (CIDR) notation.

Environments: Optionally, select an environment to which to bind Anypoint VPC. If you don’t select an environment, all applications deployed to the selected region are associated with this Anypoint VPC.

Set as default VPC: Select this option to set the Anypoint VPC as the default for the region you set. This means that all environments in this region not associated with an Anypoint VPC will be, by default, associated with this Anypoint VPC.

Business Groups: Optionally, bind the Anypoint VPC with a business group.
If you don’t select a business group, the Anypoint VPC is associated with the main organization.

Entering General Information while creating a VPC

5. Click Firewall Rules to expand the fields and configure firewall rules.
By default, all inbound traffic is blocked, and you need to configure firewall rules to allow traffic to your worker. You can configure these rules later.

Configuring Firewall Rules while creating a VPC

NOTE: For more info. on Firewall Rules, refer here.

6. Optionally, you can click the Internal DNS option to set up internal DNS servers to resolve your private host names. You can do this when you initially create the Anypoint VPC, or you can configure the internal DNS later.

Option to setup Intenal DNS while creating a VPC

NOTE: For info. on how to setup internal DNS, refer here.

c. Update an Existing Anypoint VPC

For the steps to follow, refer here.

d. Connect to your Anypoint VPC

The process for requesting or updating Anypoint VPC connectivity to your network depends on the connectivity method you use: IPsec, Transit Gateway attachments, VPC Peering, or AWS Direct Connect.

For the steps to follow on how to configure any of the above connectivity methods, refer here.

Applications Layer

6. Design Considerations

MuleSoft applications leverage the RAML and OAS specifications in the code for input validation and to reject incorrect endpoints. When updates are needed the specification has to be updated and imported back into the application. This gives the security team a view into the full API specification, allowing them to make appropriate decisions regarding the design and potential policies that need to be applied.

a. Add detail to the RAML input that will help protect your API

The RAML specification can have as much, or as little detail as needed. More detail enhances the validation of the inbound content which in turn may reduce the amount of coding needed in the implementation. The following RAML snippet, for example, highlights the level of detail between two different input parameters:

get: 
  queryParameters: 
    firstParameter: string 
    secondParameter: 
      type: string 
      pattern: ^[A-Za-z]{1}[A-Za-z ]{1,49}$

The first parameter takes any string at any length which is susceptible to injection attacks, but the second parameter only accepts mixed case alphabetic strings and spaces that are from 2 to 50 characters long. The greater detail on the second parameter guards against injection attacks and gives both the consumer and the developer a better idea of the expected input.

b. Add detail to the specification when security policies are discussed

traits:
  client-id-required: 
    headers: 
      client_id: string 
      client_secret: string 

/employees: 
  get:
    is: [client-id-required]

If policies are considered at design time additional requirements can be added to the RAML specification. Not only does this help the developers understand the API for coding, but it also helps potential consumers understand what is required for adoption.

c. Determine appropriate target SLAs and application load on the API

Just as important as business requirements, non-functional requirements (like peak load volume, desired response time, and acceptable downtime) help shape the design and architecture of an API. These requirements also help with security because they drive what performance policies and alerts will be needed to protect the API and inform teams of potential attacks.

Another important reason to have predefined SLAs is to understand the impacts of downstream systems. For instance, if an API that communicates with an ERP is attacked, the attack may interrupt access to the ERP for all users. If the API was protected with rate-limiting or spike control policies, the attack would not extend to the ERP system.

d. Understand API-led connectivity and decide how each layer should be protected

API-led approach not only can accelerate the development of future projects, but it also protects the organization from potential changes to the back-end systems. The three layers (Experience, Process, and System) all have different purposes, which also leads to different security considerations.

Security considerations at each layer

7. Secure Network Communications — Transport Layer Security (TLS)

Transport Layer Security (TLS) is cryptographic protocol that secures communications in Mule applications. Mule provides out-of-the-box support for HTTPS (HTTP Secure).

One-way TLS (Basic Authentication)

In One-way TLS server presents certificate to the client but the client is not required to present a certificate to the server. The client must authenticate the server, but the server will accept any client into the connection.

Two-way TLS (Mutual Authentication)

In Two-way TLS both the client and server have to present a certificate before the connection is established between two. With two-way TLS authentication, Server not only authenticates itself to the client, it also requires authentication from the requesting client. Clients are required to submit digital certificates issued by a trusted CA.

KeyStore

A KeyStore stores public certificates plus corresponding private keys (credential) for clients or servers in a Mule application.

Public certificates in a keystore have a certificate chain associated with them, which authenticates the corresponding public key.

In TLS, the keystore determines the credentials (public certificate) sent to the remote host (e.g., client).

TrustStore

The TrustStore contains public certificates (self-signed or from a CA) for remote hosts (other parties) and perhaps also the signing CAs.

The keystore owner trusts the public certificates (and the contained public keys) contained in its truststore to identify other parties.

In TLS, the truststore determines whether credentials (public certificates) sent by the remote host (the client) are trusted and hence if the secure connection can be established.

Connectors that support TLS connections

— HTTP/S Client & Server

— SFTP Client

— SMTP/S Client

— TCP Sockets Client & Server

— JMS Client

The JMS standard does not specify TLS connections. The JMS provider must support TLS and provide a TLS connection factory in its client library.

a. Configure TLS

To enable TLS for Mule apps, configure the tls:context element in the Mule XML configuration file in one of three ways:

— Edit the XML file directly.

— Use Anypoint Studio 7.

— Use the Design Center flow designer.

Edit the XML file directly

Steps to follow

1. Globally, define a TLS Element — can be used from both the client and server sides.
2. Include at least one of the nested elements: key-store and trust-store.
3. Configure optional attributes of the tls-context Element, if required:

enabledProtocols: The protocols in the global TLS configuration.

enabledCipherSuites: The cipher suites in global TLS configuration.

These values are used if there is nothing specified in the global TLS configuration, or if the values are enabled in a global TLS configuration.

4. Configure attributes of the trust-store Element:

path: The path to the file that contains the trust store.

type: The type of the trust store. Default = JKS.

password: The trust store password (required if you specify path).

algorithm: The algorithm the trust store uses. Default is SunX509.

insecure: Boolean that determines whether or not to validate the truststore. If set to true, no validation occurs. The default value is false .

The password attribute is required if you specify a path. Otherwise, the attributes are optional.

5. Configure attributes of the key-store Element:

• path: The path to the file that contains the keystore (required).
• type: The type of the keystore (default JKS).
• password: The keystore password.
• keyPassword: The key manager password, which is the password for the private key inside the keystore.
• algorithm: The algorithm used in the keystore. The default value is SunX509.

Use Anypoint Studio (to configure in HTTP Listener)

Steps to follow

1. Open Anypoint Studio.
2. Open the project.
3. Open HTTP Listener.
4. In the General tab, select an existing configuration or create a new one.
5. In the HTTP Listener config dialog, select the TLS tab.
6. In the TLS tab, choose the TLS Configuration type Edit Inline, and supply the values.
7. Optionally, fill in the Enabled Protocols and Enabled Cipher Suites fields in the Advanced section. For more info., refer here.
8. Save your configuration.

Configuring one-way TLS for HTTPS

Configuring two-way TLS for HTTPS

Similar steps can be followed for other connectors listed above.

Use Design Center (to configure in HTTP Listener)

Steps to follow

1. Log into Design Center.
2. Open the project.
3. Open HTTP Listener.
4. In the Configuration tab, click Edit.
5. In the TLS tab, fill in the TLS Configuration fields.
6. Optionally, fill in the Enabled Protocols and Enabled Cipher Suites fields. For more info., refer here.
7. Save your configuration.

Similar steps can be followed to configure in other connectors listed above.

b. Externalize Security certificates (applicable ONLY for Customer-hosted Runtime)

There are 2 ways to do this:

Move certificates to a folder outside MULE_HOME:

a. Add a certificate folder in the classpath in the wrapper.conf file in <MULE_HOME>/conf: wrapper.java.classpath.3=%CERT_DIREFCTORY%

b. Secure %CERT_DIRECTORY% using operating system permissions.

OR

Use Secrets Manager to store certificates: This is applicable ONLY for

— Customer-hosted Mule runtimes in Runtime Fabric (RTF).

— API Manager (with an HTTPS secured API proxy).

8. Cryptography

Cryptography is the practice and study of techniques for secure communication in the presence of third parties.

The Cryptography Module supports three different strategies to encrypt and sign messages:

PGP: Signature/encryption using PGP.

XML: For signing or encrypting XML documents or elements.

JCE: For using a wider range of cryptography capabilities as provided by the Java Cryptography Extension (JCE).

The Cryptography module also provides operations to calculate and validate a checksum to check data for errors. These operations are independent of the encryption strategy used.

a. Use PGP Cryptography

Pretty Good Privacy (PGP) is often used for signing, encrypting and decrypting texts, emails, files, directories to increase the security of communications.

Public & Private keys are important in PGP to encrypt and decrypt the data. Public key is used to encrypt data and shared with end-users. The Private key is used to decrypt the encrypted data.

Steps to follow

1. Generate keys — Public & Private keys.
2. Export keys.
3. Identify fingerprints for the generated keys.
4. Configure Encryption/Decryption

Generate keys

Steps to follow

1. Use any tool (Git Bash) that support generation of PGP Public/Private keys & run this command: gpg — gen-key
2. Enter details such as desired key size, key validity, etc. Press Enter to specify the default selection.
3. Enter your user information such as ‘Real name’, ‘Email address’.
4. Type a secure ‘Passphrase’.

Export generated public key

Steps to follow

1. Run this command to list GPG keys for which you have both a public and private key:

gpg - list-secret-keys - keyid-format LONG

2. Run this command to export the generated public key to desired location to produce a corresponding key ring file:

gpg –output <<Folder_Path>>\\<<Public_Key_Name>>.gpg –export <<Email_Address>>

<<Folder_Path>>: Directory/Folder to store the public key file.

<<Email_Address>>: Email given during generation.

<<Public_Key_Name>>: Name for the public key.

Export generated private key

Steps to follow

1. Run this command to list GPG keys for which you have both a public and private key:

gpg - list-secret-keys - keyid-format LONG

2. Run this command to export the generated private key to desired location to produce a corresponding key ring file:

gpg –export-secret-keys <<Key_Value>> > <<Folder_Path>>\\<<Private_Key_Name>>.gpg

<<Key_Value>>: The value of the key

<<Folder_Path>>: Directory/Folder to store the public key file.

<<Private_Key_Name>>: Name for the private key.

Identify fingerprints for the generated keys

Steps to follow

1. Run this command to list GPG keys for which you have both a public and private key:

gpg - list-secret-keys - keyid-format LONG

2. Note down the last 16 digits of the row “sec”, which is the fingerprint of the key.

Finger of the generated key

Configure Encryption/Decryption in Anypoint Studio

Steps to follow

1. From the Mule palette, add Crypto to your project.
2. Select the desired operation and drag the component to the flow.
3. Open the component properties and select an existing Module configuration, or create a new one by specifying the Public keyring file and the Private keyring file.
4. Configure Key selection by using a Key id value previously defined in the module configuration, or define a new one for the selected operation.
5. Select the algorithm to use during the operation.

Keystore Configuration

For more info. on configuration, refer here.

b. Use XML Cryptography

The XML Cryptography provides encryption/decryption of an element within an XML document.

Key Points

It consists of elementPath, which is an XPath expression that identifies the element to encrypt.

It uses JCE Configuration.

Depending on your needs, you can use a symmetric or asymmetric key for encrypting an XML document.

It is used only for XML documents encryption.

Steps to follow

1. Generate keystore: XML Encryption/Decryption makes use of a keystore. Keystore can be in JCEKS, JKS, PKCS12 formats. Use below command (sample) to generate the keystore in JCEKS format:

keytool -genseckey -alias sample -keyalg AES -keystore sample.jceks -keysize 128 -storeType JCEKS.

2. Configure Encryption/Decryption in Anypoint Studio:

a. From the Mule palette, add Crypto to your project.

b. Select the desired operation (encrypt, decrypt, sign, validate), and drag the component to the flow.

c. Open the component properties and select an existing Module configuration, or create a new one by specifying the Keystore, Type (JKS, JCEKS, PKCS12) and Password. You can also add symmetric or asymmetric key information to be used in the sign operations.

d. Configure Key selection by using a Key id value previously defined in the module configuration, or define a new one for the selected operation.

e. Select Digest Algorithm, Canonicalization Algorithm, Type, and Element path.

For more info. on configuration, refer here.

c. Use JCE Cryptography

The JCE Cryptography enables you to use the wider range of cryptography capabilities provided by the Java Cryptography Extension (JCE).

You can use cryptography capabilities in two ways:

— Password-based encryption (PBE): This method enables you to encrypt and sign content by providing only an encryption password.

— Key-based encryption: Like how PGP and XML encryption works, this method enables you to configure a symmetric or asymmetric key to perform encryption and signing operations.

Steps to follow

1. Generate keystore: Encryption and Decryption makes use of a keystore that combines a key with a certificate. Keystore can be in JCEKS, JKS, PKCS12 formats. Use below command (sample) to generate the keystore in JCEKS format:

keytool -genkey -alias sample -keyalg RSA -keystore sample.jceks -storepass 123456 -keypass PrivateKeyPwd -dname "CN=root OU=Development, O=org, L=Pune, S=Maharashtra, C=INDIA" -storetype JCEKS -keysize 1024

2. Configure Encryption/Decryption — Password-based or Key-based.

PBE: This method applies a hash function over the provided password to generate a symmetric key that is compatible with standard encryption algorithms.

Because PBE only requires a password, a global configuration element is not needed for the PBE operations.

Configure PBE in Anypoint Studio

Steps to follow

1. From the Mule palette, add Crypto to your project.
2. Select the desired operation and drag the component to the flow.
3. In the component view, configure the Algorithm and Password properties.

Configure Key-Based Encryption in Anypoint Studio

Steps to follow

1. From the Mule palette, add Crypto to your project.
2. Select the desired operation and drag the component to the flow.
3. Open the component properties and select an existing module configuration, or create a new one by specifying values for Keystore, Type (JKS, JCEKS, PKCS12), and Password. You can also add symmetric or asymmetric key information to be used in the sign operations.
4. Configure Key selection by using a Key id value previously defined in the module configuration or define a new one for this operation.
5. Select the algorithm to use during the operation.

NOTE: For more info. on configuration, refer here.

d. Use Crypto Module (dw::Crypto) in Dataweave

DataWeave also has a Crypto module for hashing payload. This module provide functions that perform encryptions through common algorithms, such as MD5, SHA1, and so on. To use this module, you must import it to your DataWeave code by adding the line import * from dw::Crypto to the header of your DataWeave script.

For info on various functions available, refer here.

9. Input Sanitization/Validation

SQL Injection Prevention

a. Add API Policies

Add API Policies such as JSON and XML Threat Protection for the APIs exposed outside the network (Experience API). For more info., see above under section ‘API Gateway — API Management’

b. Add security elements in RAML

Secure your API by adding DataTypes and Securities in RAML Definition.

c. Use Parameterized SQL Queries in API Implementation

To protect database queries, configure the Input parameters field in the Select operation by adding variable values to the SQL statement you execute in the database.

Use input parameters to configure the WHERE clause in a SQL SELECT statement to make the query immune to SQL Injection attacks, see below (for example):

XSS (Cross-Site Scripting) Prevention

a. Limit the data that can be accepted

Design your API by specifying the type and format of data that is acceptable. Most of attack happens when dealing with HTML data and limiting what to accept is critical. You can specify what to accept in RAML Definition.

b. Deny all untrusted data

Only allow trusted party to make request to the API. You can choose one security policies from the out of box policies (For more info., see above under section ‘API Gateway — API Management’) that fits the use case.

c. Sanitize and limit the accepted data

When handling data from client, it is critical to ensure all data is escaped properly and in appropriate form. This does not only prevent XSS but also other types of attacks. For example, you can apply JSON Threat Protection Policy to limit the shape of accepted json to avoid denial of service attack.

d. Arrange a security review

Depending on the accepted data and how the data is handled (i.e. transformed, stored, presented to clients), the XSS flaws can be difficult to identify and remove from a web application. It is strongly recommended to perform a security review and check all input from client that could possibly become a part of HTML output that presents to the client.

Data Layer

10. Application Properties Configuration

You can encrypt configuration properties as another security level for your applications. We need to encrypt the data inside any property files to restrict unauthorized access and to protect the sensitive data.

Steps to follow

1. Create a secure configuration properties file.
2. Define secure properties in the file. There are 3 ways to do this: — Use Mule Properties Editor — Use Secure Properties Tool — Use Secure Properties Generator.
3. Configure the file in the project with the Mule Secure Configuration Properties Extension module. The file must point to or include the decryption key.

a. Use Mule Properties Editor

Steps to follow

1. Install the Mule properties editor into Anypoint Studio by following these steps:

— Open Install New Software from Help menu.

— Click the Add button and it will open a window, provide Name as Anypoint Enterprise Security and provide location as http://security-update-site-1.4.s3.amazonaws.com and press Add button.

— Go to the Work with drop-down and Select Anypoint Enterprise Security.

— Select the Premium checkbox & then click Next.

— Accept the policy and then click Finish.

2. Go to your <Project Folder>/src/main/resources/<your config file>, right-click, go to Open with > Mule Properties Editor, and then click on it.

3. If you do not see the Mule Properties Editor, right-click on your configuration file and go to Open with > other.

4. Search for Mule Properties Editor, you will see it if Anypoint Enterprise Security is installed correctly.

5. Double-click on the property name you want to encrypt, a window will pop up, Click Encrypt and then OK.

6. Choose the Algorithm of your choice and enter the secure Key authorized by your organization.

7. An encrypted configuration property is ready to be used. Click OK and the value is automatically replaced with the new encrypted value.

b. Use Secure Properties Tool

Steps to follow

1. Download the tool jar file using this link.

2. Now open the command prompt and navigate to the location of the tool.

3. To encrypt the values, use the following syntax:

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \
<method> \
<operation> \
<algorithm> \
<mode> \
<key> \
<value> \
 - use-random-iv [optional]

4. Set <method> to string to configure the tool to process a text string.

5. Specify the other parameters to perform your desired operation.

Sample:

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \
string \
encrypt \
Blowfish \
CBC \
mulesoft \
"some value to encrypt"

NOTE: You can encrypt or decrypt the values inside a properties file, or all the file’s content. For more info, refer here.

c. Use Secure Properties Generator

This is the easiest and quickest way to encrypt your properties. This provides you to do the exact same thing but online, without writing commands and downloading software, provided by MuleSoft + Salesforce, where you can encrypt not only string values but complete files as well.

Steps to follow

1. Navigate here and fill in the details.
2. Choose the Operation, Algorithm, and State from the drop-down. Enter your Key and Value to be encrypted/decrypted. Click on Generate, and your encrypted key is ready.

Conclusion

This is an attempt to collate good practices to build highly secure Mule applications in one place. Mule developers keen on building highly secure applications can refer to this article.

Thank you for reading !! Hope you find this article helpful in whatever possible. Please don’t forget to like, share & feel free to share your thoughts in the comments section.

If interested, please go through my previous blogs:

• Best Practices to create High Performant Applications in Mule 4.
• Best Practices to create High Reliable Applications in Mule 4.
• Best Practices to create High Available (HA) Applications in Mule 4.

References

MuleSoft Documentation

How to implement XML Cryptography (XML Encryption) in Mule 4?

Best practices to prevent SQL Injections?

Cross-Site Scripting (XSS) Prevention in Mule application

https://www.mstsolutions.com/technical/pgp-encryption-and-decryption-using-mule4/#:~:text=PGP%20Encryption%20in%20Mule%204,encrypt%20connector%20to%20your%20flow.

XML Cryptography - Apisero

PGP Encryption in Mule 4: How it Works - DZone