vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Vulnerability Advisor checks for vulnerable packages in specific Docker base images, and known vulnerabilities in app configuration settings. When vulnerabilities are found, information about the vulnerability is provided. You can use this information to resolve security issues so that containers are not deployed from vulnerable images.

Review the following table to find an overview of benefits of using Container Registry.



Table 1. Container Registry benefits

 Benefit Description 

 Highly available and scalable private registry. Set up your own image namespace in a multi-tenant, highly available, scalable, encrypted private registry that is hosted and managed by IBM.<br><br>Store your private Docker images and share them with users in your IBM Cloud account. 
 Image security compliance with Vulnerability Advisor. Benefit from automatic scanning of images in your namespace.<br><br>Review recommendations that are specific to the operating system to fix potential vulnerabilities and protect your containers from being compromised. 
 Quota limits for storage and pull traffic. Benefit from free storage and pull traffic to your private images until you reach your free quota.<br><br>Set custom quota limits for the amount of storage and pull traffic per month to avoid exceeding your preferred payment level. 





 Service plans 

You can choose between the free or standard Container Registry service plans to store your Docker images and make these images available to users in your IBM Cloud account.

The IBM Cloud Container Registry service plan determines the amount of storage and pull traffic that you can use for your private images. The service plan is associated with your IBM Cloud account, and limits for storage and image pull traffic apply to all namespaces that you set up in your account.

Service plans are scoped to the specific registry instance (one of the regional registries or the global registry) that you're currently working with. Plan settings must all be managed separately for your account in each registry instance. For more information, see [Regions](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions).

The following table shows available IBM Cloud Container Registry service plans and their characteristics.
Your build runs in a secure enclave, which protects the build environment, the build process, and the build output from malicious internal or external actors. You used the Hyper Protect Virtual Servers BYOI feature to set up your Secure Bitcoin Wallet instance in a secure enclave, which protects the wallet from threats and hackers.





 References 



* [Secure Build Server CLI](https://github.com/ibm-hyper-protect/secure-build-cli)
* [Protecting your image build](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-imagebuild), in particular: [Deploying the Secure Build Server as a Hyper Protect Virtual Server](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-imagebuilddeploysecurebuild)
* [Using your own image](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-byoi)
* [Secure Bitcoin Wallet](https://github.com/IBM/secure-bitcoin-wallet)
Check out the [Hyper Protect Crypto Services offering details page](https://cloud.ibm.com/catalog/services/hyper-protect-crypto-services) to learn more.





 How Key Protect works 

IBM Key Protect helps you manage encryption keys throughout your organization by aligning with IBM Cloud IAM roles.

An IT or security admin might need advanced permissions to your instance, keys, or key rings that other users, including auditors, might not. For this reason, Key Protect maps to established IAM roles to allow fine-grained access for each user as needed. For more information, check out [Managing users and access](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessmanage-access-roles).

The following diagram shows how the default IAM roles of manager, reader, and writer can interact with keys that are managed in the service.

Zoom

![The diagram shows the same components as described in the previous definition list.](https://cloud.ibm.com/docs-content/v1/content/0bc8db34a3d90b2a5103c9c71b08a96de9525bbc/key-protect/images/keys-use-cases.svg)

Figure 1. Shows how different access roles interact with keys.

While a particular user can be assigned specific roles over specific resources (a user with a "Reader" role at the instance level might be a "Manager" of a particular key or key ring), in general:



* Readers can access information about keys.
* Writers can use keys with an application or service that is integrated with Key Protect
* Managers create keys and control their lifecycle (in addition to being able to do everything Readers and Writers can do).





 Architecture overview 

Key Protect uses the Advanced Encryption Standard algorithm in Galois/Counter Mode (AES GCM) to wrap and unwrap DEKs. CRKs that are not imported are created with 256-bit key material. Imported CRKs can be have 128, 192, or 256-bit key material.

The following architecture diagram shows how Key Protect components work to protect your sensitive data and keys.
[Enforce information flow policies and protect the boundaries of your application](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-boundary-protection) <br><br> * Use separate network areas for control plane hosts and workload hosts for more specific network flow restrictions.<br> * Only allow network access to control plane for components (for example, management plane) that use services provided by control plane hosts.<br> * Identify interconnects between your Satellite workloads and your other services outside of the Satellite components and allow required network flows only.<br> * Use Satellite Link endpoints to provide secure access to private endpoints of IBM Cloud services.<br> * Use edge plane and restrict access to workloads deployed on your Red Hat OpenShift on IBM Cloud cluster so that security and management-related services can be accessed from the management plane only.<br><br><br> <br><br> * Plan your virtual or physical network infrastructure for Satellite deployment to facilitate clear network flow restrictions based on proper identification of source and destination network areas.<br><br><br> 
 [Ensure that all operator actions are run through a bastion host](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-bastion-host) <br><br> * Ensure all interactive operator actions to manage the application in your Satellite locations can be run through a bastion host only in your dedicated edge or management plane.<br> * Enable recording of bastion sessions for auditing.<br><br><br> <br><br> * Ensure all interactive operator actions to manage your on-premises infrastructure can be run through a bastion host only.<br> * Enable recording of bastion sessions for auditing.<br><br><br> 
 [Capture audit events and forward to a SIEM](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-best-practicesbest-practices-audit-logs) <br><br> * For IBM Cloud resources, capture audit events by using Activity Tracker Event Routing event routing and Object Storage encrypted using KYOK.
See also [image](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2024928), [registry](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2064940), [layer](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2028320).





 context 

Environmental or conditional information that can be used to define when rules that restrict access to resources should be applied. A context can be a set of properties or attributes like client IP addresses, office hours, time of day, or multi-factor authentication.





 context-based restriction 

An access management method that defines and enforces access for resources based on the network location of the access request.





 control 

A technical, administrative, or physical safeguard designed to meet a set of defined security and privacy requirements. Controls exist to prevent, detect, or lessen the ability of a threat to exploit a vulnerability.





 control assessment 

The evaluation of a configuration for compliance with applicable standards.





 control library 

A collection of similar predefined or custom controls.





 control specification 

A statement that defines the specific security and privacy requirements that a control must meet.





 coreference 

A relationship between two words or phrases in which both refer to the same person or thing and one stands as a linguistic antecedent of the other. For example, there is a coreference between the two pronouns in the phrase "She taught herself" but not in the phrase "She taught her". A coreference links two equivalent entities in the same text.





 coreference chain 

A list of entities that were annotated as coreferences. When a mention is annotated as a coreference, the system creates a coreference chain. The coreference chain provides a way to view all of the mentions in context and verify that all of the occurrences belong together under the same entity type.





 corpus 

A collection of source documents that are used to train a machine learning model.





 credential 

Information acquired during authentication that describes a user, group associations, or other security-related identity attributes, and that is used to perform services such as authorization, auditing, or delegation.
The first release of the Key Protect on Satellite provides the basic functions to allow for secure handling of the encryption keys for the key services available in Satellite, such as IBM Cloud Public (ROKS) and Cloud Object Storage (COS).



* At present, the only locations supported in this offering are in user-owned on-prem Satellite locations associated with the IBM Cloud us-east host Multi-Zone Region (MZR), though eventually it will be available in Satellite locations associated with all IBM Cloud MZRs that Satellite supports. Note that each IBM Cloud MZR can host multiple Satellite locations that are in close proximity to that MZR. While it is possible for a user to have their HSMs in another location as long as there is network connectivity (preferably on a private network) between the worker nodes hosting Key Protect and your HSMs, the preferred method is a close physical proximity between HSMs and worker nodes.
* While the IBM Cloud console is used to create the Key Protect service on Satellite, the UI itself cannot currently be used to access the Key Protect APIs that are used to create keys or perform other key actions (such as rotating keys, deleting keys, editing keys, and so on). Those key actions must be performed using the [Key Protect CLI](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-up-cli). Note that you must set the [KP_PRIVATE_ADDR environment variable](https://cloud.ibm.com/docs/key-protect?topic=key-protect-private-endpoints) to the Key Protect on Satellite endpoint for the CLI to work. You can also make direct calls to the [Key Protect APIs](https://cloud.ibm.com/apidocs/key-protect), also through the Key Protect on Satellite endpoint. For more information about how to obtain the Key Protect on Satellite endpoint from GhoST, check out [Obtaining the Key Protect endpoint](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-aboutsatellite-about-before-begin-endpoint). Note that keys you create using the CLI or API will not show up in the Key Protect UI.
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}

zones {
security-zone trust {
tcp-rst;
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/0.0;
ge-0/0/1.0;
}
}
security-zone untrust {
screen untrust-screen;
interfaces {
ge-0/0/2.0;
}
}
}
}

interfaces {

ge-0/0/0 {
unit 0 {
family inet {
address 10.135.70.22/26;
}
}
}

ge-0/0/1 {
unit 0 {
family inet {
address 10.134.217.140/26;
}
}
}

ge-0/0/2 {
unit 0 {
family inet {
address 169.50.51.92/29;
}
}
}

ge-0/0/3 {
unit 0;
}

fxp0 {
unit 0;
}

}

routing-options {

static {
route 10.0.0.0/8 next-hop 10.135.70.1;
route 0.0.0.0/0 next-hop 169.50.51.89;
}

}
Show more



 Set commands 

set system login user pokeyjo uid 2000

set system login user pokeyjo class super-user

set system login user pokeyjo authentication encrypted-password
"removed for security"

set system root-authentication encrypted-password
"removed for security"

set system services ssh

set system services web-management http interface fxp0.0
RA-2 - Security Categorization 



  Control requirements 

The organization:

RA-2 (a)
:   Categorizes information and the information system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;

RA-2 (b)
:   Documents the security categorization results (including supporting rationale) in the security plan for the information system; and

RA-2 (c)
:   Ensures that the authorizing official or authorizing official designated representative reviews and approves the security categorization decision.





  Additional IBM Cloud for Financial Services specifications 



*  Customer PII must be categorized and stored in appropriate data structures to meet customer, including regulatory and/or financial institution, requirements.







  NIST supplemental guidance 

Clearly defined authorization boundaries are a prerequisite for effective security categorization decisions. Security categories describe the potential adverse impacts to organizational operations, organizational assets, and individuals if organizational information and information systems are comprised through a loss of confidentiality, integrity, or availability. Organizations conduct the security categorization process as an organization-wide activity with the involvement of chief information officers, senior information security officers, information system owners, mission/business owners, and information owners/stewards. Organizations also consider the potential adverse impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives, potential national-level adverse impacts. Security categorization processes carried out by organizations facilitate the development of inventories of information assets, and along with CM-8, mappings to specific information system components where information is processed, stored, or transmitted.
There are two approaches to IBM MQ AMS, which we will refer to as Application AMS and [Queue Manager AMS](https://cloud.ibm.com/docs/services/mqcloud?topic=mqcloud-mqoc_qm_ams). This tutorial focuses on Application AMS.



 AMS Protection Policy 

Protection policy defines the quality of protection to be used for protecting the messages. AMS provides message protection policies to allow message content to be signed and encrypted. AMS policies are defined by the MQ administrator on the target queues and each queue can have exactly zero or one policy. Policy can specify the algorithms that are used for signing and encryption operations. There are two types of message protection policies:



* Message integrity policy where a digital signature is applied to the message, but the contents of the message remain in the plain text.
* Message privacy policy where the contents of the message are also encrypted. Message privacy policies also include message integrity.



When encryption is specified, the policy must also specify all authorized recipients and the sender must have the public key of those recipients in the local keystore.





 End to End Message Security 

End to End protection of the message requires us to consider the following aspects:



1. Messages in transit are secured.
2. Assurance that messages have originated from the expected source.
3. Messages can only be viewed by the intended recipient.
4. Assurance that messages have not been altered in transit.



Putting the encryption mechanism into the queue manager itself eliminates the expense of modifying the applications but it doesn't fully solve the problem. Since the queue manager has the capability of encrypting and decrypting the messages, the recipient has no guarantee that the message that it receives is authentic. For example, in the cases of B2B, the topology is that of a hub and spoke where the clearinghouse serves as the hub and each spoke is a different business partner. In such scenarios for assurance of a tamper-proof and authentic message, an end to end protection will be the desired solution.
[Sharing of security-related resources](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution65-resource-sharing/resource-sharing-architecture-security.svg)

Sharing of security-related resources

The above diagram shows the following scenarios:



1. Instances of Object Storage and Databases for MongoDB in Account A and Account B utilize encryption keys managed in the Main Account in Key Protect.
2. Security and Compliance Center in the Main Account governs resources in all three accounts (see black lines above).
3. Instances of Activity Tracker in Account A and Account B direct security logs with Activity Tracker Event Routing to Object Storage buckets in the Main Account (see blue lines above).



Sharing can be between accounts in an [IBM Cloud Enterprise environment](https://cloud.ibm.com/docs/account?topic=account-what-is-enterprise) or without a formal enterprise organization.



 Encryption key management 

In almost all environments, data is stored encrypted. By default, encryption is provider-managed which means the encryption key is provided and maintained by the cloud provider. To increase security, customers can use their own keys by utilizing a key management service (KMS). In IBM Cloud, the KMS can be either located in the same or in another account as the service using an encryption key. This allows to centrally manage encryption keys for all corporate accounts. That way, it is possible to monitor usage and invalidate encryption keys when needed.

[Key Protect](https://cloud.ibm.com/docs/key-protect) and [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) support this deployment pattern. You can configure access to an entire instance or, for enhanced security, to individual [key rings - a collection of keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-grouping-keys).
Root key rotation - Standard Plan 

You can rotate root keys managed in your Hyper Protect Crypto Services instance on demand or by setting a rotation policy. Key rotation takes place when you retire the original key material of the root key, and you re-key it by generating a new cryptographic key material.

Rotating keys regularly helps you meet industry standards and cryptographic best practices. The following table describes the main benefits of key rotation:



Table 1. Describes the benefits of key rotation

 Benefit Description 

 Cryptoperiod management for keys Key rotation limits how long your information is protected by a single key. By rotating your root keys at regular intervals, you also shorten the cryptoperiod of the keys. The longer the lifetime of an encryption key, the higher the probability for a security breach. 
 Incident mitigation If your organization detects a security issue, you can immediately rotate the key to mitigate or reduce costs that are associated with key compromise. 



Key rotation is treated in the NIST Special Publication 800-57, Recommendation for Key Management. To learn more, see [NIST SP 800-57 Pt. 1 Rev. 5](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final)



 Comparing your root key rotation options 

In Hyper Protect Crypto Services, you can [rotate a root key on demand](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-rotate-keys) or [by setting a rotation policy](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-rotation-policy), without needing to keep track of your retired root key material.

Setting a rotation policy for a key
: Hyper Protect Crypto Services helps you simplify rotation for encryption keys by enabling rotation policies for keys that you generate in the service. After you create a root key, you can manage a rotation policy for the key in the IBM Cloud console or with the API.
About insights 

IBM Cloud® Security and Compliance Center Workload Protection has a powerful visualization tool for threat detection, investigation, and risk prioritization, to help identify compliance anomalies and ongoing threats to your environment. With Insights, all findings are aggregated into a visual platform that streamlines threat detection and forensic analysis.

IBM Cloud Security and Compliance Center Workload Protection implements Sysdig Secure functionality. Information that is provided by the Sysdig Secure documentation applies to Workload Protection as well.

For more information, see [Insights](https://docs.sysdig.com/en/docs/sysdig-secure/insights/insights)
- "/var/hyperprotect/:/var/hyperprotect/:ro"







 Understanding attestation flows 

The following diagram shows two scenarios for attestation from the point of view of the auditor to validate that the deployment is the expected one. The left side of the diagram shows the establishment of trust by the auditor who is rooted on a third-party certificate authority. Any key used is kept in a Hyper Protect Crypto Service and signed in a certificate chain based on the third-party authority. The Build environment that is used by Hyper Protect is running in a trusted execution environment by using IBM Secure Execution Technology.

The result is a secure execution image that is seen at the end of the diagram, which is an encrypted secure execution image. To the right of the diagram, the validation of the deployment is outlined. For this, the auditor includes into the encrypted workload contract of the IBM Hyper Protect instance, the public key of a secret, which only the auditor has control over. Such secrets might be protected by appropriate means, like a Hyper Protect Crypto Service, HSM or just a random key. Only the Hyper Protect bootloader that is executed in the trusted execution environment provided through IBM Secure Execution for Linux on IBM LinuxONE, can run the secure execution image of IBM Cloud Hyper Protect Virtual Servers for IBM Cloud® Virtual Private Cloud. The bootloader contains the secret to decrypt the contract.

During boot several hashes of components and measures of code are taken and added to the attestation record. To further protect this attestation record, the record is encrypted with the public key that the auditor provided. By doing so, only the auditor is in the position to decrypt the attestation record and can validate that the workload that is deployed in the enclave is the expected and untampered version of the workload that is expected to be deployed into the Hyper Protect Virtual Servers for VPC instance.

Zoom

!
FAQs 

Frequently asked questions for IBM Cloud® Security and Compliance Center might include questions about managing profiles, defining custom rules, attaching scopes, and evaluating resources for compliance. To find all FAQs for IBM Cloud, see the [FAQ library](https://cloud.ibm.com/docs/faqs).



  How do I start monitoring a rule? 

Security and Compliance Center supports two types of rules - predefined and custom. Predefined rules are associated with specifications by default and are automatically monitored when you create an attachment to a profile. Custom rules can be monitored after they are associated with a specification by customizing a control library. Then, you select those controls when you create an attachment.





  Can I create a rule for a service that I didn't provision? 

Yes, you can create rules for services or resources that are not already provisioned in your accounts. When the service or resource is created, it is automatically evaluated according to your rule definition.