vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Role-based access control checks are performed on a resource level to allow only authorized users to perform certain operations on project resources.



* The authorization is controlled by the customer by assigning manager, reader, or writer roles to users for a Code Engine project resource within IAM.
* To restrict customer workload, Code Engine enforces the following concepts,



* Container isolation through various Linux isolation techniques. These techniques ensure multiple layers of security to prevent the privilege escalation of containers and to restrict containers to use a limited set of system privileges.
* Resource quota and LimitRange to prevent excessive resource consumption.
* Network policies to control the network flows within the environment.



* Shared multi-tenant components are secured, for example, by disabling reverse lookup in KubeDNS.
* To limit the blast radius, each shard cluster is running in its own VPC, which is isolated from other shard VPCs.
* DDoS protection is enabled automatically for all endpoints, including customer applications, through Cloud Internet Services (CIS) with no additional cost to you.
This policy determines what actions the user can perform within the console. Blockchain-specific permissions (for example, which users can create components) are based on the IAM roles that are mapped to blockchain permissions in this [Role to permissions mapping table](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-manage-consoleibp-console-manage-console-role-mapping).

When the IBM Blockchain Platform console is provisioned, the email address of the IBM Cloud account owner is set as the console administrator, known in IAM as the Manager role. All new access requests will be sent to this user. This console administrator can then grant other IBMid users access to the console by using the IAM UI. For more information about IAM on IBM Cloud, see [What is IAM](https://cloud.ibm.com/docs/account?topic=account-iamoverview). For the steps required to add new users, see [Adding and removing users from the console](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-manage-consoleibp-console-manage-console-add-remove).





 Ports 

If you are using a client application to send requests to the console, either via the blockchain APIs or the Fabric SDKs, the associated HTTPS console port needs to be exposed in your firewall. In IBM Cloud use the default port 443.





 Key management 

The IBM Blockchain Platform network is based on trusted identities. Customers use the Certificate Authorities (CAs) in the console to generate the identities and associated certificates that are required by all members to transact on the network. The generated public and private keys are ECDSA with Curve P256. These keys are stored in the browser when they are added to the member's blockchain wallet so that the console can use them to manage blockchain components. However, it is recommended that customers export these keys and import them into their own key management system in case they clear their browser cache or switch browsers. Customers are responsible for the storage, backup, and disaster recovery of all keys that they export.
Understanding your responsibilities when using CIS 

Learn about the management responsibilities and terms and conditions that you have when you use IBM Cloud® Internet Services. For a high-level view of the service types in IBM Cloud® and the breakdown of responsibilities between the customer and IBM for each type, see [Shared responsibilities for IBM Cloud offerings](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities).

Review the following sections for the specific responsibilities for you and for IBM when you use IBM Cloud Internet Services. For the overall terms of use, see [IBM Cloud® Terms and Notices](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms).



 Incident and operations management 



Table 1. Responsibilities for incident and operations

 Task IBM Responsibilities Your responsibilities 

 Availability IBM Cloud Internet Services provides high availability through multi-zone region deployment and automatic failover between different regions in case of a region-wide failure. 
 Monitoring and ongoing operation of production environments IBM Cloud Internet Services provides continuous around the clock operational monitoring and coverage by on-call personnel with minimal response times. 
 Deployments and cluster management New features, updates, and bug fixes are continuously delivered as needed in a manner transparent to the customer. Maintenance with client impact is scheduled in advance with notifications posted to the IBM Cloud® status page. Set preferences to receive email notifications. Monitor the IBM Cloud® status page for general announcements. 
 Incident management Unplanned incidents with customer impact are communicated using the CIE process. Impacted customers can obtain a report about the incident upon request. 







 Change management 



Table 2. Responsibilities for change management

 Task IBM Responsibilities Your responsibilities 

 Updates, fixes, and new features IBM Cloud Internet Services provides regular updates and bug fixes, as well as new features following a continuous delivery model in a manner transparent to the customer. 
 Updates to edge capabilities Updates are made regularly as part of continuous delivery. IBM sends notifications for customer impacting changes. Set preferences to receive email notifications. Monitor the IBM Cloud® status page for general announcements. 







 Identity and access management 



Table 3. Responsibilities for identity and access management

 Task IBM Responsibilities Your responsibilities
Because the website owner performed the blocking, CIS support cannot override a customer’s security settings.







 Error 1013: HTTP hostname and TLS SNI hostname mismatch 

A common cause of 1013 errors is when the hostname sent by the client or browser via Server Name Indication (SNI) does not match the request host header.

Error 1013 is commonly caused by the following:



* your local browser setting the incorrect SNI host header
* a network proxying SSL traffic caused a mismatch between SNI and the Host header of the request.





 Resolution 

Test for an SNI mismatch via an online tool such as SSL Shopper.

Provide CIS Support a HAR file captured while duplicating the error.







 Error 1014: CNAME Cross-User Banned 

By default, CIS prohibits a DNS CNAME record between domains in different CIS accounts. CNAME records are permitted within a domain (www.example.com CNAME to api.example.com) and across zones within the same user account (www.example.com CNAME to www.example.net).



 Resolution 

To allow CNAME record resolution to a domain in a different CIS account, the domain owner of the CNAME target must contact CIS Support and specify the domains allowed to CNAME to their target domain.







 Error 1015: You are being rate limited 

A common cause of 1015 errors is when the site owner implemented Rate Limiting that affects your visitor traffic.

Unable to purge is another 1015 error code relating to CIS cache purge. Retry the cache purge and contact CIS support if errors persist.



 Resolution 



* If you are a site visitor, contact the site owner to request exclusion of your IP from rate limiting.
* If you are the site owner, review CIS Rate Limiting thresholds and adjust your Rate Limiting configuration.
* If your Rate Limiting blocks requests in a short time period (for instance, 1 second) try increasing the time period to 10 seconds.



For guidance on when you expect a new Edge function to exceed rate limits, see [Working wiht Edge functions](https://cloud.ibm.com/docs/cis?topic=cis-working-with-edge-functions).







 Error 1016: Origin DNS error
Auditing events for CIS 

As a security officer, auditor, or manager, you can use the Activity Tracker service to track how users and applications interact with the CIS service in IBM Cloud®.

IBM Cloud Activity Tracker records user-initiated activities that change the state of a service in IBM Cloud. You can use this service to investigate abnormal activity and critical actions and to comply with regulatory audit requirements. In addition, you can be alerted about actions as they happen. The events that are collected comply with the Cloud Auditing Data Federation (CADF) standard. For more information, see the [getting started tutorial for IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-started).

Names for auditing events changed on 1 July 2020. The change replaced all underscore (_) characters in the names with dash (-) characters.



 List of events: DNS domains 

The following table lists the actions that are related to DNS domains and generate an event:



Table 1. Actions that generate DNS domain events

 Action Description 

 internet-svcs.zones.create Create a DNS domain. 
 internet-svcs.zones.update Update a DNS domain. 
 internet-svcs.zones.delete Delete a DNS domain. 
 internet-svcs.zones-activation-check.update Perform activation check for a DNS domain. 
 internet-svcs.dnssec.update Enable or disable DNSSEC for a DNS domain. 







 List of events: DNS records 

The following table lists the actions that are related to DNS records and generate an event:



Table 2. Actions that generate DNS record events

 Action Description 

 internet-svcs.dns-records.create Create a DNS record. 
 internet-svcs.dns-records.update Update a DNS record. 
 internet-svcs.dns-records.delete Delete a DNS record. 
 internet-svcs.dns-records-bulk.create Import DNS records from zone file. 







 List of events: Load balancers 

The following table lists the actions that are related to load balancers and generate an event:
In a DDoS attack, multiple compromised computer systems attack a target such as a server, website, or other network resource, affecting users of the targeted resource.

The flood of incoming messages, connection requests, or malformed packets to the target system forces it to slow down or even crash and shut down, thereby denying service to legitimate users or systems. DDoS attacks have been carried out by diverse threat actors, ranging from individual criminal hackers to organized crime rings and government agencies.
* What do I do if I’m under a DDoS attack?

Step 1: Turn on “Defense mode" in the Overview screen.

![Defense Mode](https://cloud.ibm.com/images/defense-mode.png)

Figure 1. Defense mode

Step 2: Set your DNS records for maximum security.

Step 3: Do not rate-limit or throttle requests from IBM CIS, we need the bandwidth to assist you with your situation.

Step 4: Block specific countries and visitors, if necessary.
* I got a 522 error, what do I do now?

A 522 error indicates we weren't able to establish a connection with your origin server (that is, your host). After about 15 seconds of connection failure, we close the connection and display a 522 error page.

This issue usually is caused by firewall or security software that accidentally blocks our IP addresses. Because CIS acts as a reverse proxy, connections to your site appear to come from a range of CIS IPs. This behavior can cause certain firewalls to block these connections, which prevents us from serving content to your site visitors properly.

To fix this issue, ask your host to allowlist all of the CIS IP ranges, listed [here](https://cloud.ibm.com/docs/cis?topic=cis-cis-allowlisted-ip-addresses).

All of these IPs must be allowlisted to avoid 522 errors. It's also worth checking to see if any IPs in these ranges are blocked.

522 errors can also be caused by network connectivity issues, so confirm that your server and network is generally healthy and not overloaded.

If after taking the above steps you still receive errors, contact IBM CIS support and confirm the following:
CM-8 (2) - Automated Maintenance 



  Control requirements 

CM-8 (2) - 0
:   The organization employs automated mechanisms to help maintain an up-to-date, complete, accurate, and readily available inventory of information system components.





  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 collects software bills of materials (SBOM) to provide transparency in build artifacts
*  Check whether DevSecOps Toolchain deployment has approved change documentation including security impact analysis







  NIST supplemental guidance 

Organizations maintain information system inventories to the extent feasible. Virtual machines, for example, can be difficult to monitor because such machines are not visible to the network when not in use. In such cases, organizations maintain as up-to-date, complete, and accurate an inventory as is deemed reasonable. This control enhancement can be satisfied by the implementation of CM-2 (2) for organizations that choose to combine information system component inventory and baseline configuration activities.
: The Management Utilities are composed of the Smart Card Utility Program and the Trusted Key Entry (TKE) application, which provide GUI for you to initialize service instances. With signature keys and master key parts that are stored on smart cards, the Management Utilities provide an approach to initializing service instances with the highest level of security.

TKE CLI plug-in
: A CLI plug-in working with IBM Cloud CLI for you to initialize service instances. Depending on whether recovery crypto units are assigned to your instance, the plug-in provides two ways for instance initialization: by using recovery crypto units and by using key part files.

Operational crypto unit
: Each service instance is composed of multiple operational crypto units. The operational crypto units are located in different availability zones of the same region for high availability. They are used to manage encryption keys and perform cryptographic operations. The number of crypto units that you specify when you create your instance is the number of operational crypto units.

Recovery crypto unit
: The purpose of recovery crypto units is to generate a random master key value and to save a backup copy of the master key value. You can use recovery crypto units to load the master key and restore the master key when it is destroyed or lost.

Currently, recovery crypto units are enabled only in the region of Dallas (us-south) and Washington DC (us-east). If you create your instance in either of the two regions, two recovery crypto units are automatically assigned to your instance without extra costs: one is in the us-south; the other is in the us-east.

If smart cards are used to load the master key, the recovery crypto units are not applicable and can be ignored. The backup of the master key relies on the backup of the smart cards in that case.

For more information about the Hyper Protect Crypto Services components, see [Components and concepts](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-understand-concepts).





 Hyper Protect Crypto Services workload isolation 

Hyper Protect Crypto Services is a single-tenant, regional service that supports complete tenant-based workload isolation with the following characteristics:
CM-6 (1) - Automated Central Management / Application / Verification 



  Control requirements 

CM-6 (1) - 0
:   The organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].





  Implementation guidance 

See the resources that follow to learn more about how to implement this control.



*  [Compliance monitoring](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-monitoring-compliance)







  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 validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely
*  Check whether DevSecOps Toolchain deployment has approved change documentation including security impact analysis
CIS caches static content depending on where your visitors come from, which CIS data center your visitors reach, and how often visitors request a resource at the specific data center.

CIS only caches a resource within the CIS data center that serves the request and doesn’t cache:



* off-site or third-party resources (for example, Facebook and Flickr)
* content hosted on unproxied DNS records



By default, CIS respects the origin web server’s cache headers in the following manner unless overridden by an edge cache TTL page rule:



* If the cache-control header is set to private, no-store, no-cache, or max-age=0, or if there is a cookie in the response, then CIS does not cache the resource.
* Otherwise, if cache-control is set to public and the max-age is greater than 0, or if the expires header is a date in the future, CIS caches the resource.
* If both max-age and an expires header are set, max-age is used.



By default, CIS caches certain HTTP response codes with the following edge cache TTL when no cache-control directive or expires response header are present:



Table 1. Default cache response codes

 Response code TTL 

 200, 206, 301 120m; 
 302, 303 20m; 
 404, 410 3m; 
 403 1m; 



CIS provides several cache customization options:



* Specify caching behavior for individual URLs via CIS page rules
* Customize caching with CIS [edge functions](https://cloud.ibm.com/docs/cis?topic=cis-edge-functions-use-casescaching-using-fetch) or the [API](https://cloud.ibm.com/docs/cis?topic=cis-edge-functions-use-casescache-api)
* Adjust caching level, cache TTL, and more via the [CIS CLI](https://cloud.ibm.com/docs/cis?topic=cis-cli-plugin-cis-clicache)



The maximum file size CIS caches is 512MB for Trial and Standard customers and 5GB for Enterprise customers.
Scope the access to Specific resources based on selected attributes.
9. Select Resource group. Marla can select or input the name of the resource group that's created for the chatbot project.
10. Select Viewer and Reader roles to define the scope of access, and click Review.
11. Click Add to add your policy configuration to your policy summary.
12. Review the profile summary and click Create.







 Next steps 

Now that you learned the basics of how to create a trusted profile, you can create the Chatbot Ops (prod) trusted profile that gives employees who need broader privileges more access. To do so, repeat step 1. In step 2.11.a, enter the condition job-role equals dev-lead. Assign this profile Editor and Writer access. For more information, see [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile&interface=ui).

You can also use Activity Tracker to monitor which federated users and compute resources apply a trusted profile. For more information, see [Monitoring login sessions for trusted profiles](https://cloud.ibm.com/docs/account?topic=account-trusted-profile-monitor).
Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts
// of the vulnerability management process by using standards for:..
// SA-11(1) DEVELOPER SECURITY TESTING AND EVALUATION | STATIC CODE ANALYSIS
// The organization requires the developer of the information system, system component, or information system service to employ static code
// analysis tools to identify common flaws and document the results of the analysis.
// Control passed if:
// 1- the script is one of the blessed ones AND
// 2- the status is passed OR
// 3- the status is failed AND issues have been opened AND there are no expired issues AND prod CR approved manually
"evidence_type_id": "com.ibm.static_scan",
"version": "1.0.0",
"date": "2020-05-06T12:00:00Z", // date of task run
"origin": {
"url":"https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines/-/blob/master/definitions/mytask.yaml", // where the task is taken from
"version": "423792" // commit id representing the task version used to produce the evidence
}
"toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/190e0b4ce4cd013159917665213ddc51:7467a214-f404-4e23-acab-2e57e935d138::" // CRN of the toolchain
"pipeline_id": "b1cfb6a4-813d-4fec-bbf7-ce662e8ce4e0", // the id of the pipeline that generated this piece of evidence
"pipeline_run_id": 12345, // this is the id of the pipeline run that generated this piece of evidence
* For a full list of command arguments of fteSetupCommands, Refer to this link [fteSetupCommands KnowledgeCenter](https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.wmqfte.doc/setup_cmds_cmd.html)







 Setting up an Agent Queue Manager and Agents 

In this section, you will setup an agent queue manager that is targeted at the MQ on Cloud Queue Manager. As part of the configuration for the Agent Queue Manager, the following commands should be executed.

Configuration Steps :



1. Open two admin_terminals and name them as terminal 1 and terminal 2.
2. Go to terminal 1 and create a SRC_AGENT:

2.1. In terminal 1 run the following commands to create a SRC_AGENT (Source Agent):



* fteCreateAgent -agentName <agentName> -agentQMgr <agentQueueManager> -agentQMgrHost <agentQueueManagerHost> -agentQMgrPort <agentQueueManagerPort> -agentQMgrChannel <agentQueueManagerChannel> -p <configurationOptions> -f -credentialsFile <filePath>



* agentName - Required. Name of the agent to create.
* agentQueueManager - Required. Name of the agents's Queue Manager.This is ’queueManagerName’ in the file coordinationQMgrConnectionDetails.json
* agentQueueManagerHost - Required. this is the ‘hostname’ in the file coordinationQMgrConnectionDetails.json
* agentQueueManagerPort - Required. this is the ‘listenerPort’ in the file coordinationQMgrConnectionDetails.json
* agentQueueManagerChannel - Required. this is the ‘adminChannelName’ in the file coordinationQMgrConnectionDetails.json
* configurationOptions - by convention this is the name of a coordination queue manager