vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For further information, users can review [Getting started, Step 2](https://cloud.ibm.com/docs/quantum-computing?topic=quantum-computing-get-startedinstall-packages).







 Example scenario 

In our example, we want to create the following setup:



* We have two projects, ml and finance.



* The ml project needs access to the service instances QR-ml and QR-common.
* The finance project should have access to the service instances QR-finance and QR-common.



* We have three users:



* Fatima needs access to the ml project.
* Ravi needs access to the finance project.
* Amyra needs access to both projects.



* We will use access groups without resource groups.
* Users are defined in IBM Cloud but project assignments are done in an App ID instance.
* Users should be able to delete jobs.



The steps to implement this setup are:



1. The Cloud administrator creates an App ID instance and ensures that it is linked in the Cloud administrator's account. The administrator notes the ID provider URL to share it with users.
2. The Cloud administrator creates three service instances: QR-ml, QR finance, and QR-common.
3. The Cloud administrator creates a custom rule that includes the quantum-computing.job.delete action.
4. The Cloud administrator creates two access groups:



* The ml access group can access QR-ml and QR-common. This access group needs a dynamic rule for the App ID IDP that accepts users whose project attribute contains ml.
* The finance access group can access QR-finance and QR-common. This access group nees a dynamic rule for the App ID IDP that accepts users whose project attribute contains finance.



5. The ID provider administrator defines the three users in the IBM Cloud user interface.
6. Users log in at least once.
7. The cloud administrator assigns access by adding users to the access groups that give them access to the projects:



* Fatima is given access to the ml project.
* Ravi is given access to the finance project.
Cluster settings 

Before the addition of attached storage, the VMware vCenter Server® solution didn't enable advanced features such as VMware® vSphere Distributed Resource Scheduler (DRS) and VMware vSphere® High Availability (HA). With the addition of the NFS attached storage device, these features are enabled on the cluster with the settings that are listed in the following sections.



 vSphere Distributed Resource Scheduler 

Two main features are enabled when you turn on vSphere DRS on a cluster: load balancing and power management.



 Load balancing 

With load balancing, the distribution and usage of CPU and memory resources for all hosts and virtual machines (VMs) in the cluster are continuously monitored. DRS compares these metrics to an ideal resource usage given the attributes of the cluster’s resource pools and VMs, and the current demand. It then completes or recommends VM migrations as needed.

When a VM is first powered on in the cluster, DRS tries to maintain proper load balancing by either placing the VM on an appropriate host or by making a recommendation. The placement or recommendation settings are set in the DRS Automation section of the cluster settings.

In this design, the DRS Automation level is set to fully automated so when VMs are powered on they're automatically placed onto hosts with sufficient capacity. The VMs are also automatically migrated from one host to another to load balance the cluster. Additionally, the migration threshold of the DRS cluster is set at the midpoint between conservative and aggressive such that priority 1, priority 2, and priority 3 recommendations are applied. vCenter Server provides at least good improvements to the cluster’s load balance.

The following table shows the settings for the vSphere DRS cluster in the VMware vSphere Web Client.



Table 1. DRS Automation settings for the vSphere DRS cluster

 Setting Value 

 Turn on vSphere DRS Selected 
 Automation Level Fully Automated 
 Migration Threshold Apply priority 1, priority 2, and priority 3 recommendations 
 Enable individual machine automation levels Selected, set to 15 ms
IR-6 - Incident Reporting 



  Control requirements 

The organization:

IR-6 (a)
:   Requires personnel to report suspected security incidents to the organizational incident response capability within [IBM Assignment: no longer than 24 hours for systems related to FS-ready public cloud customers]; and

IR-6 (b)
:   Reports security incident information to [IBM Assignment: Information Security Incident Response Team of the FS-ready public cloud customers].





  Additional IBM Cloud for Financial Services specifications 



*  The organization shall ensure that data management issues are treated as incidents and are reported to the customer as they arise.







  NIST supplemental guidance 

The intent of this control is to address both specific incident reporting requirements within an organization and the formal incident reporting requirements for federal agencies and their subordinate organizations. Suspected security incidents include, for example, the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Current federal policy requires that all federal agencies (unless specifically exempted from such requirements) report security incidents to the United States Computer Emergency Readiness Team (US-CERT) within specified time frames designated in the US-CERT Concept of Operations for Federal Cyber Security Incident Handling.
SI-3 - Malicious Code Protection 



 Control requirements 

The organization:

SI-3 (a)
: Employs malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code;

SI-3 (b)
: Updates malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy and procedures;

SI-3 (c)
: Configures malicious code protection mechanisms to:



1. Perform periodic scans of the information system [IBM Assignment: at least weekly] and real-time scans of files from external sources at [IBM Assignment: to include endpoints, including removable media and devices (e.g., USB drives, CD/DVDs)] as the files are downloaded, opened, or executed in accordance with organizational security policy; and
2. [IBM Assignment: to include alerting administrator or defined security personnel] in response to malicious code detection; and



SI-3 (d)
: Addresses the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system.





 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).



Rules for SI-3 in IBM Cloud for Financial Services v1.2.0 profile

 Requirement ID Rules 

 SI-3 (a) <br><br> * Check whether Container Registry Vulnerability Advisor scans for critical or high vulnerabilities in the system at least every # day(s)<br><br><br> 







 NIST supplemental guidance 

Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote-access servers, workstations, notebook computers, and mobile devices. Malicious code includes, for example, viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats (e.g., UUENCODE, Unicode), contained within compressed or hidden files, or hidden in files using steganography.
Troubleshooting 500 class errors 

Diagnose and resolve 500 class errors for CIS proxied sites using the following sections.



 Before you begin 

To assist in troubleshooting errors in the 500 class range, check your origin logs or contact site administrator to gather the following information:



1. The specific 500 class error code and message, and any Ray ID (cf-ray) that might be associated
2. The time and time zone in which the error occurred
3. The URL that resulted in the HTTP 500 class error



Check the logs between CIS and the origin web server, including all load balancers, caches, proxies and firewalls.





 Error 500: internal server error 

Error 500 generally indicates an issue with your origin web server. Error establishing database connection is a common HTTP 500 error message generated by your origin web server. Check your origin logs for more details to resolve.



 Error 500 resolution 

If the 500 error contains “cloudflare” or “cloudflare-nginx” in the HTML response body, provide support with the following information:



* Your domain ID and instance CRN
* The time and timezone of the 500 error occurrence
* The output of www.example.com/cdn-cgi/trace from the browser where the 500 error was observed (replace www.example.com with your actual domain and host name)



If you observe blank or white pages when visiting your website, confirm whether the issue occurs when temporarily pausing CIS and check your origin logs for more details.







 Error 502 or 504: bad gateway or gateway timeout 

An HTTP 502 or 504 error occurs when CIS is unable to establish contact with your origin web server.

There are two possible causes:



* 502/504 from your origin web server (most common)
* 502/504 from Cloudflare





 Error 502 resolution 

If the 502/504 error is from your origin web server, CIS returns a HTTP 502 or 504 error when your origin web server responds with a standard HTTP 502 bad gateway or 504 gateway timeout error. Check the origin logs to troubleshoot these common causes at your origin web server:
The approach is to configure load balancing in NSX-T in parallel to the existing NSX-V configuration. This action allows testing and then, when verified, cut-over to NSX-T load balancing. To migrate the load-balancing service from NSX-V to NSX-T, consider the following steps:



* Deploy a new NSX-T Edge cluster that contains two Edge node VMs with active or standby configurations.
* Deploy a T1 router into the Edge cluster with centralized service ports (CSP).
* Deploy a load balancer, with the same configuration as the NSX-V load balancer, into the Edge cluster and linked with the T1 router.
* Assign a new VIP for each server pool to allow the testing of connectivity from the client to the servers.
* Add the new NSX-T segment that is created for the VIPs to any security group rules. At this stage, you have:



* NSX-V load balancers are active as the DNS records point to the VIP on the NSX-V load balancer.
* NSX-T load balancers can be used for testing the configurations.



* To cut over from the NSX-V to NSX-T load balancers, point DNS record to NSX-T VIP.







 Considerations for configuration migration 

When you plan and design configuration migration, consider the following aspects:



* Are you using vCenter-specific objects (for example, clusters, folders) in NSX-V distributed firewall rules? While micro-segmentation is similar in NSX-V and NSX-T, there are differences that must be considered for during the migration. Customers that write distributed firewall rules for NSX-V might use vCenter-specific objects (for example, clusters, folders) which are not available in NSX-T. Those rules must be rewritten to ensure that the overall micro-segmentation design and granularity are maintained after NSX-T migration.
* Are you using IP Sets and Security Groups? You must create new security groups in NSX-T based on the security groups in NSX-V. You must identify IP sets and security groups with exclusions, and security groups with the dynamic inclusion rule that contains multiple criteria.
Check out the [What makes a good access group strategy](https://cloud.ibm.com/docs/account?topic=account-account_setupaccessgroup_strategy) best practices documentation. 
 <br><br> * Configure access groups for Activity Tracker and Log Analysis<br><br><br> You can configure, control, and manage events and logging data that is available to users by configuring groups in the logging instance. Access groups provide extra security by allowing users to see only a subset of auditing events, as opposed to all auditing events that are generated in the account. For example, you might grant a group of users access to see auditing events that are only related to development services in the account. Learn more by reviewing [Using groups to control data access](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-group_data_access) and [RBAC, groups, and IAM integration](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-iam_grant_group). 
 <br><br> * Organize resource groups<br><br><br> A resource group is a way for you to organize your account resources in customizable groupings so that you can quickly assign users access to multiple resources at a time. It is generally recommended to create a resource group per project. Learn more about [managing resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs). 
 <br><br> * Invite users to your account<br><br><br> Users are invited to an account and given access to the resources. Use IAM to invite users, cancel invitations, or resend a pending invitation. You can invite a single user or multiple users. Start [inviting users to an account](https://cloud.ibm.com/docs/account?topic=account-iamuserinv).
A page rule takes effect on a specific URL pattern, matching the following format:

<scheme>://<hostname><:port>/<path>

An example that uses each component would be:

https://www.example.com:80/image.png

The scheme and port components are optional. If the scheme is omitted, it covers both http:// and https:// protocols. If the port is not specified, then the rule matches all ports. You can perform basic wildcard matches by using an asterisk (&asterisk;) symbol in your rule pattern, allowing it to match a series of similar patterns rather than just one.

Here are three important things to remember with page rules:



* Only one page rule takes effect on any given request.
* Page rules are given priority in order from top to bottom.
* After a URL matches a rule, only that rule is applied; that is, if a page rule was already triggered on a request, any subsequent rules that also match the URL pattern do not take effect. Generally, it is recommended to order your rules from most specific to least specific.



Page rules can be disabled, in which case they take no action. You can still see them in the list and edit them. Setting the Enabled toggle to Off creates a page rule that initially is disabled.

For more information, see [Using page rules with caching](https://cloud.ibm.com/docs/cis?topic=cis-use-page-rules-with-caching).
Assign a class to represent the pattern DictMonth + numeric token + comma + RegExpYear.

Notice the four empty cells that represent the four tokens that you selected from the document. To select all the cells, select the first cell, and then press Shift + click each additional cell. Enter RuleDate as the class name, and then click it to create the new class.

![Shows that all four cells in the top row have been selected and the span is being defined as the "RuleDate" class.](images/rule-add8.png "Shows that all four cells in the top row have been selected and the span is being defined as the "RuleDate" class.")
8. In the Rule name field, enter MyDateRule and click Save.

After you save the rule, it is automatically applied to the sample documents. If the Technology - computerworld.com document is still open in the rule editor, you will see that the February 3, 2009 text in the document is now annotated as a mention of the RuleDate class.

![Shows text from the "Technology - computerworld.com" document with only the text "February 3, 2009" annotated as a mention of the "RuleDate" class.](images/rule-add10.png "Shows text from the "Technology - computerworld.com" document with only the text "February 3, 2009" annotated as a mention of the "RuleDate" class.")

You can search for all occurrences of RuleDate class mentions in the sample documents by clicking the Search annotation in documents icon ![A magnifying glass to represent a search](https://cloud.ibm.com/docs-content/v1/content/148d3bd95f946aa1bb53ea1540475f522e6b61c9/watson-knowledge-studio-data/images/filter_gray.png) next to the RuleDate class from the Class panel. It is a good practice to check that all dates are captured properly to confirm that you defined the pattern correctly.

!
Open the Slack app in a new browser tab, so you can easily switch back and forth between the Slack app settings page and Watson Assistant Slack integration configuration page.
6. From the settings page for your Slack app, open the App Home page.
7. Add access scopes for your Slack app.

The button label might be Review Scopes to Add or Update scopes depending on whether you are creating a new app or editing an app that you created before February 2020.

The method for Slack access changed. For more information about it, read the [Slack blog post](https://medium.com/slack-developer-blog/more-precision-less-restrictions-a3550006f9c3) about it.
8. Assign bot token scopes to your Slack app. At a minimum, apply the following scopes:



* app_mentions:read
* chat:write
* im:history
* im:read
* im:write



9. Click Install App to Workspace, and then allow the installation when prompted.

If you are editing scopes for an existing application, reinstall it.
10. From the Slack settings App Home page, enable the Always Show My Bot As Online setting.
11. Go to the OAuth and Permissions page in Slack, copy the Bot User OAuth Access Token.
12. From the Watson Assistant Slack integration configuration page, paste the token that you copied in the previous step into both the OAuth access token and Bot user OAuth access token fields.
13. On the Slack app settings page, go to the Basic Information page, and then find the App Credentials section. Copy the app credential verification token.
14. From the Watson Assistant Slack integration configuration page, paste the verification token that you copied in the previous step into the Verification token field.
15. Click Generate request URL, and then copy the generated request URL.
16. Return to the Slack app settings page. Open the Event Subscriptions page, and then turn on Enable Events. Paste the request URL that you copied in the previous step into the field.
17.
To begin protecting your Security and Compliance Center resources with context-based restrictions, see the tutorial for [Leveraging context-based restrictions to secure your resources](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-tutorial).



 How Security and Compliance Center integrates with context-based restrictions 

Context-based restrictions that are set to Security and Compliance Center apply holistically to all components of Security and Compliance Center. By enabling context-based restrictions, you can restrict access to Security and Compliance Center’s user interface features and Security and Compliance Center’s public APIs.

To restrict access, you must create [zones](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=uinetwork-zones-create) and [rules](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=uicontext-restrictions-create-rules). First, create a zone with the appropriate details for network or resource definitions. Then, create a rule, and attach that zone to the rule to restrict access. After you create or update a zone or a rule, it might take a few minutes for the change to take effect.





 Limitations 

After you create a rule, it might take up to 10 minutes for the rule to take effect.

Security and Compliance Center does not support granular adoption of context-based restrictions to specific resources. When you're creating a new rule, you must ensure that the restrictions are scoped to “All resources,” instead of “Specific resources.”

Security and Compliance Center makes service-to-service calls to Cloud Object Storage. To ensure your Security and Compliance Center features are functioning correctly, you must add Security and Compliance Center as a service reference in network zones for rules that target Cloud Object Storage. You must use the same process for rules that target Event Notifications.

Context-based restrictions are available only for the updated architecture.

Context-based restrictions protect only the actions associated with the [Security and Compliance Center API](https://cloud.ibm.com/apidocs/security-compliance/posture-v2.0).
Check whether Virtual Private Cloud (VPC) network access control lists don't allow ingress from 0.0.0.0/0 to SSH port 4.43 The rule was removed. 
 Check whether Virtual Private Cloud (VPC) network access control lists don't allow ingress from 0.0.0.0/0 to RDP port 4.44 The rule was removed. 
 Check whether Virtual Private Cloud (VPC) security groups have no inbound rules that specify source IP 0.0.0.0/0 to SSH port 4.4 The rule was removed. 
 Check whether Virtual Private Cloud (VPC) security groups have no inbound rules that specify source IP 0.0.0.0/0 to RDP port 4.5 The rule was removed. 
 IBMid does not allow changed or reset passwords to be the same as any of the 24 previously used passwords 1.62 The rule was removed. 







 Version 1.1.0 

The following changes have been made to the IBM Cloud Security Best Practices library and profile.



 17 April 2023 

The following controls and rules have been updated in the IBM Cloud Security Best Practices library and profile as of 17 April 2023.

Control

Rule



Table. Understanding control and rule updates

 Control ID Original control text Updated control text 

 6.1 Ensure Toolchain scans during continuous integration the source code to identify vulnerabilities Ensure DevSecOps Toolchain scans source code and their dependencies to identify vulnerabilities 
 6.2 Ensure Toolchain has unit tests that are continuously run to validate source code changes Ensure DevSecOps Toolchain passes unit tests to validate all code changes 
 6.3 Ensure Toolchain has Code Risk Analyzer configured that collects a bill of materials for pipeline run Ensure DevSecOps Toolchain collects software bills of materials (SBOM) to provide transparency in build artifacts 
 6.4 Ensure Toolchain is configured with image signing Ensure DevSecOps Toolchain signs build artifacts to attest their provenance 
 6.5 Ensure Toolchain source code meets Center for Internet Security Docker benchmarks Ensure DevSecOps Toolchain validates code against Center for Internet Security (CIS) Docker benchmarks to ensure container runtimes are configured securely