vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"message": "Sorry, I could not find an agent."
},
"message_to_human_agent": "The caller needs help resetting their password"
}
]
}
Show more





 Transferring upon failure 

To configure transfer on failures, go to the Advanced tab in the phone integration settings. The following selections can be configured:



* Transfer failure message
* Disconnect call on transfer failure



For more information, see [Handling call and transfer failures](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-deploy-phone-configdeploy-phone-config-failure).





 Passing Watson Assistant Metadata in SIP Signaling 

To support loading the conversational history between the caller and Watson Assistant, the phone integration specifies a value for the User-to-User header as a key that can be used with the web chat integration. If User-to-User is specified in the transfer_headers list, the session history key is sent in the X-Watson-Assistant-Session-History-Key header.

The value of the SIP header is limited to 1024 bytes.

How this data is presented in the SIP REFER message also depends on the value of transfer_headers_send_method(as defined in [Generic Service Desk SIP Parameters](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-phone-actionsgeneric-service-desk-sip-parameters)).

The following example shows the data included as headers:

REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 23 REFER
Max-Forwards: 7
Refer-To: sip:user@domain.com
Valid values for group are all, domain, reliability, performance, security. This option is mutually exclusive with -f, --feature.

-f, --feature
: Feature of domain settings to check. This option is mutually exclusive with g, --group. Valid values are as follow:



* always_use_https: Redirect all requests with scheme http to https. This applies to all http requests to the domain.
* automatic_https_rewrites: Help fix mixed content by changing http to https for all resources or links on your web site that can be served with HTTPS.
* brotli: When the client requesting an asset supports the brotli compression algorithm, CIS will serve a brotli compressed version of the asset.
* browser_check: Evaluate HTTP headers from your visitors browser for threats. If a threat is found a block page will be delivered.
* challenge_ttl: Specify how long a visitor with a bad IP reputation is allowed access to your website after completing a challenge.
* ciphers: A whitelist of ciphers for TLS termination in the BoringSSL format. This command only lists ciphers specifically whitelisted by customers. If no ciphers are whitelisted, the list is empty and the default ciphers are used. See [TLS Options](/docs/cis? topic=cis-cis-tls-options#cipher-suites) for the list of default ciphers.
* cname_flattening: Follow a CNAME to where it points and return that IP address instead of the CNAME record. By default, only flatten the CNAME at the root of your domain.
* email_obfuscation: Encrypt email addresses on your web page from bots while keeping them visible to humans.
* opportunistic_onion: Allow legitimate users of Tor Browser to access your websites.
* hotlink_protection: Protect your images from off-site linking.
* http2: Accelerate your website with HTTP/2.
* http3: Accelerate your website with HTTP/3.
* image_load_optimization: Improve load time for pages that include images on mobile devices with slow network connections.
Encrypting data source information 

When applications use IBM® Cognos Dashboard Embedded, they provide data source modules (JSON documents) to describe the metadata of the data that they want Cognos Dashboard Embedded to query. Part of this information is the database connection and credential information.

To provide a secure way to pass this information from the embedding application to Cognos Dashboard Embedded, and keep the plain text of these sensitive fields out of the browser, you must ensure that the calling application does things that are described in this section.

When your embedding application creates a session, a public encryption key, in JSON Web Key format, is returned. For more information on a Cognos Dashboard Embedded session, see [Getting started tutorial](https://cloud.ibm.com/docs/services/cognos-dashboard-embedded?topic=cognos-dashboard-embedded-gettingstartedtutorialstep3). For information on JSON Web Key, see [JSON Web Key](https://tools.ietf.org/html/rfc7517).

Public encryption key in JSON Web Key format: ![opendashboardflow](https://cloud.ibm.com/docs-content/v1/content/2781097afe16f2d329d7a606ddd260fb1a3e355c/services/cognos-dashboard-embedded/publicencryptionkey.jpg)

When the embedding application provides a data source module specification, then the calling application provides a module to Cognos Dashboard Embedded, for exampling with the methods addSources() or updateModuleDefinitions(), then you can choose to provide any of the following fields in an encrypted form:



* user
* password
* schema
* jdbcUrl
* sourceUrl
* value of a header property for CSV urls



Before sending the module, your application uses the public key to encrypt the sensitive fields of the module.

If you have a string to encrypt that is longer than 245 bytes, then do the following steps:



1.
The VPN server receives the username and passcode from the VPN client and makes an IAM call to verify the passcode and permission with IAM policy.



* The passcode is an one-time password. The user MUST re-generate the passcode for re-connection, even if the re-connection is initiated by the VPN server.
* The SoftLayer MFA is not supported because SoftLayer MFA enforcement is not done via the browser.



If you use user ID/passcode authentication, maintenance activities force users to re-authenticate by fetching and re-entering the code. The connection is restored only after the new code is entered. This is applicable using stand-alone or HA mode.





 Client certificate revocation lists 

Optionally, you can import a certificate revocation list (CRL), which is a time-stamped list of certificates that have been revoked by a certificate authority (CA). A certificate in a certificate revocation list (CRL) might not be expired, but is no longer trusted by the certificate authority that issued the certificate. The VPN client uses this list to validate digital certificates.

After you import a CRL, the VPN client uses this list to validate digital certificates. The CRL is saved as a string (not a file) in the system. If you need to download the CRL in the future, it is renamed as <vpn_server_name>.pem.

For more information, see [Setting up client-to-server authentication](https://cloud.ibm.com/docs/vpc?topic=vpc-client-to-site-authentication).





 Transport protocol 

The transport layer oversees the delivery of data from a process on one device to a process on another device. Transport layer protocols act as liaisons between the application layer protocols and the services that are provided by the network. Client VPN for VPC supports the following protocols:

UDP is recommended for optimal performance; TCP for reliability.



* User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) is a simple, lightweight protocol with minimum overhead. If a process wants to send a small message and doesn't care about reliability, it can use UDP.
For SG client v186 and later, there will be error shown in SG client log in each 30 seconds when the concurrent connections exceed the limit on cloud side.





 What are the recommended configurations to make my connections more secure? 

Set these configuations to make connections more secure:



 Reject unauthorized 

To protect against Man-in-the-middle attack, reject connections to the resource which is not authorized with the list of supplied CAs. On the Resource Authentication, check the box Reject unauthorized, then upload the certificate if the certificate of the resource is self-signed. Please see [Cloud/On-Premises Authentication](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-add-destcloud-or-on-prem-auth) for more information.





 Use Mutual Authentication 

Enable Mutual Authentication for both sides of on-premise destinations makes Secure Gateway more secure. On User Authentication side, enable mutual authentication to restrict the access of Secure Gateway cloud node by authenticating using a client certificate when the request is over TLS/HTTPS. On Resource Authentication side, enable mutual authentication to provide appropriate credential when connecting to destination endpoint, and ensure secure/encrypted access to on-premise resource. Please see [Configuring Mutual Authentication](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-add-destdest-mutual-auth) and [Node.js TLS Mutual Authentication](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-nodejs-tls-manodejs-tls-ma) for more information.





 Set IP Table Rules (For on-premises destination) 

The Secure Gateway cloud host and port of an on-premises destination is in the public space; therefore it is allowed everyone to access by default. To control the traffic accessing on Secure Gateway, set iptables rules to only allow access by a specific range of IPs and ports to secure on-premises resources.
Data encryption in transit 

Data in transit must always be encrypted. Cryptographic controls must be in place in all regions and availability zones to protect the confidentiality and integrity of data. Data must be protected by at least two levels of encryption such as transport and field level or envelope level.

As an application provider, you must:



* Ensure that all traffic, tunneling, and other protection of data in transit is encrypted by using TLS 1.2 at a minimum. You must disable the SSL/TLS 1.0/TLS 1.1 protocols on all software that is deployed in your VPCs. See the following [TLS requirements](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-encryption-in-transitvpc-architecture-encryption-in-transit-tls-requirements) section for more details.
* Use Hyper Protect Crypto Services for TLS offload for all data that is requested from outside of IBM Cloud (inbound traffic to IBM Cloud) and protected by a certificate that is signed by a public certificate authority. In this scenario, you should configure any web servers to use TLS offload to set up the session so that the private key never leaves Hyper Protect Crypto Services. See [Use IBM Cloud Hyper Protect Crypto Services to offload NGINX TLS](https://developer.ibm.com/tutorials/use-hyper-protect-crypto-services-to-offload-nginx-tls/) for an example.
* Enforce encryption that uses directives like HTTP Strict Transport Security (HSTS).
* Disable caching for responses that contain sensitive data.
* Never send confidential information with URL parameters.
* Use HTTPS for all connections from the web. HTTP connections must be refused or redirected to HTTPS.



The requirement to encrypt data in transit also applies to traffic within your VPCs. This might be traffic from one virtual server instance to another, or from one Red Hat OpenShift on IBM Cloud container to another Red Hat OpenShift on IBM Cloud container.
SI-10 - Information Input Validation 



  Control requirements 

SI-10 - 0
:   The information system checks the validity of [IBM Assignment: organization-defined information inputs including checks for injection attacks (e.g., SQL, XSS, etc.)].





  IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



*  Check whether DevSecOps Toolchain passes dynamic code scan to identify vulnerabilities in deployed artifacts
*  Check whether DevSecOps Toolchain passes static code scan to identify vulnerabilities in source code







  NIST supplemental guidance 

Checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, and acceptable values) verifies that inputs match specified definitions for format and content. Software applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the tainted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing to interpreters prevents the content from being unintentionally interpreted as commands. Input validation helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks.
https://example.com/disaster-recovery?token=R4nd0m5tr1ng0fCh4r4ct3r5
* When TLS is implemented during the connection (using HTTPS) the entire url, including the query parameter, is encrypted as it flows over the network, so the query parameter cannot be seen by a malicious user observing network traffic



* Click 'Create' to finish configuring your DR notification.
* To enable these notifications, ensure the 'Active' toggle switch is on.

![Image of the created notification](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_dr_created.png)
* To test your notification configuration, under 'Actions', select the ellipsis (...) and click 'Test'.

![Image of the testing the notification](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_dr_test.png)
* In order to send a test to your endpoint, click 'Send test notification'.
* If you receive a response status of 200 in the testing tool, your notification was successfully delivered to you endpoint. You can see the body and header to check the endpoint's response.

![Image of a successful notification](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_dr_success.png)
* If you receive a failure response, your test was not successful. The response body and response header tabs should be examined to identify the problem.

!
* [Data encryption in transit](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-in-transit)







 IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



* Check whether App ID email dispatchers are using HTTPS only
* Check whether Cloud Object Storage is accessible only through HTTPS
* Check whether Application Load Balancer for VPC is configured to convert HTTP client requests to HTTPS
* Check whether App ID webhooks are using HTTPS only
* Check whether App ID redirect URIs are using HTTPS only
* Check whether Cloud Internet Services (CIS) has TLS mode set to End-to-End CA signed
* Check whether Application Load Balancer for VPC pool uses the HTTPS protocol for HTTPS listeners
* Check whether Application Load Balancer for VPC uses HTTPS (SSL & TLS) instead of HTTP







 NIST supplemental guidance 

Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Alternative physical security safeguards include, for example, protected distribution systems.
For more information about SSML validation and the requirements that marked-up text must meet, see [SSML validation](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-ssmlssml-errors).

Defect fix: The gender listed for the en-US_MichaelExpressive voice is now correct
: Defect fix: When you list information about the available voices, the gender of the en-US_MichaelExpressive voice is now male. Previously, the voice's gender was mistakenly described as female. For more information, see [Listing information about voices](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-voices-list).

Security vulnerabilities addressed
: The following security vulnerabilities have been fixed:



* [Security Bulletin: IBM Watson Speech Services Cartridge for IBM Cloud Pak for Data is vulnerable to issues in OpenSSL (CVE-2022-1434, CVE-2022-1343, CVE-2022-1292, CVE-2022-1473)](https://www.ibm.com/support/pages/node/6890819)
* [Security Bulletin: IBM Watson Speech Services Cartridge for IBM Cloud Pak for Data is vulnerable to arbitrary command execution in OpenSSL (CVE-2022-2068)](https://www.ibm.com/support/pages/node/6890831)
* [Security Bulletin: IBM Watson Speech Services Cartridge for IBM Cloud Pak for Data is vulnerable to a denial of service in protobuf (CVE-2022-1941)](https://www.ibm.com/support/pages/node/6890835)
* [Security Bulletin: IBM Watson Speech Services Cartridge for IBM Cloud Pak for Data is vulnerable to a buffer overflow in GNU glibc (CVE-2021-3999)](https://www.ibm.com/support/pages/node/6890837)
The metadata service can also be configured to use HTTP Secure protocol (HTTPS). For more information, see [Enable secure access by using the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-configure-service&interface=uisecure-access-ui).

The instance metadata service is not intended for sensitive data. The service end-point is open to all processes on the instance. Information that is exposed through this service is to be considered as shared information to all applications that are running inside the virtual server instance.

For more information about extra security measures that you can take, see [Security best practices for the Instance Metadata service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-security-best-practices).





 Next steps 



* [Create an instance identity access token for accessing the metadata service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-configure-serviceimd-get-token).
* [Retrieve data by using the metadata service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-get-metadata).
For SG client v186 and later, there will be error shown in SG client log in each 30 seconds when the concurrent connections exceed the limit on cloud side.
* What are the recommended configurations to make my connections more secure?

Set these configuations to make connections more secure:



 Reject unauthorized 

To protect against Man-in-the-middle attack, reject connections to the resource which is not authorized with the list of supplied CAs. On the Resource Authentication, check the box Reject unauthorized, then upload the certificate if the certificate of the resource is self-signed. Please see [Cloud/On-Premises Authentication](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-add-destcloud-or-on-prem-auth) for more information.





 Use Mutual Authentication 

Enable Mutual Authentication for both sides of on-premise destinations makes Secure Gateway more secure. On User Authentication side, enable mutual authentication to restrict the access of Secure Gateway cloud node by authenticating using a client certificate when the request is over TLS/HTTPS. On Resource Authentication side, enable mutual authentication to provide appropriate credential when connecting to destination endpoint, and ensure secure/encrypted access to on-premise resource. Please see [Configuring Mutual Authentication](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-add-destdest-mutual-auth) and [Node.js TLS Mutual Authentication](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-nodejs-tls-manodejs-tls-ma) for more information.





 Set IP Table Rules (For on-premises destination) 

The Secure Gateway cloud host and port of an on-premises destination is in the public space; therefore it is allowed everyone to access by default. To control the traffic accessing on Secure Gateway, set iptables rules to only allow access by a specific range of IPs and ports to secure on-premises resources.
For more information about data privacy in IBM Cloud Pak for Data, see [IBM Cloud Pak for Data considerations for GDPR readiness](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=compliance-considerations-gdpr-readiness).





 Labeling and deleting data in Watson Assistant 

1.5.0 and later Support for deleting data was added when log retention and analytics support were added to the product.

Do not add personal data to the training data (entities and intents, including user examples) that you create.

If you need to remove a customer's message data from a Watson Assistant instance, you can do so based on the customer ID of the client, as long as you associate the message with a customer ID when the message is sent to Watson Assistant.



* The preview link integration does not support the labeling and therefore deletion of data based on customer ID. Do not use the preview link integration in a solution that must support the ability to delete data based on a customer ID.
* For the web chat integration, the service takes the user_id that is passed in and adds it as the customer_id parameter value to the X-Watson-Metadata header with each request.





 Before you begin 

To be able to delete message data associated with a specific user, you must first associate all messages with a unique customer ID for each user. To specify the customer ID for any messages sent from a custom client application by using the /message API, include the X-Watson-Metadata: customer_id property in your header. For example:

curl -X POST -u "apikey:3Df... ...Y7Pc9"
--header
'Content-Type: application/json'
'X-Watson-Metadata: customer_id=abc'
--data
'{"input":{"text":"hello"}}'
'{url}/v2/assistants/{assistant_id}/sessions/{session_id}/message?version=2019-02-28'

where {url} is the appropriate URL for your instance.
auth_token = "<YOUR_AUTH_TOKEN>"
client = Client(account_sid, auth_token)

message = client.messages 
.create(
body="Alert " + args['alert_name'] + " in " + args['entities']['entity'] + " is " + args['state'],
from_='<TWILIO_NUMBER>',
to='<YOUR_DESTINATION_NUMBER>'
)

return {"result": "Message status " + message.status}

Show more

An SMS message similar to the following would be sent when an issue is alerted:

Sent from your Twilio trial acount - Alert example in agent_tag_Tag = 'test=1' and agent_tag_sysdig_secure_enabled = 'true' and host = 'myhost' and host_name ='myhost' and host_mac = '00:00:00:00:00:00' is ACTIVE

When the alert is resolved an SMS similar to the following will be sent:

Sent from your Twilio trial acount - Alert example in agent_tag_Tag = 'test=1' and agent_tag_sysdig_secure_enabled = 'true' and host = 'myhost' and host_name ='myhost' and host_mac = '00:00:00:00:00:00' is OK