vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Physical access devices include, for example, keys, locks, combinations, and card readers. Safeguards for publicly accessible areas within organizational facilities include, for example, cameras, monitoring by guards, and isolating selected information systems and/or system components in secured areas. Physical access control systems comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. The Federal Identity, Credential, and Access Management Program provides implementation guidance for identity, credential, and access management capabilities for physical access control systems. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural (e.g., a written log of individuals accessing the facility and when such access occurred), automated (e.g., capturing ID provided by a PIV card), or some combination thereof. Physical access points can include facility access points, interior access points to information systems and/or components requiring supplemental access controls, or both. Components of organizational information systems (e.g., workstations, terminals) may be located in areas designated as publicly accessible with organizations safeguarding access to such devices.
Security and Compliance 



 Protection Against Unauthorized Access 

IBM Cloud® Databases for EnterpriseDB use the following methods to protect data in transit or in storage.



* All Databases for EnterpriseDB connections use TLS/SSL encryption for data in transit. The current supported version of this encryption is TLS 1.2.
* Access to the Account, Management Console UI, and API is secured via [Identity and Access Management (IAM)](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=cloud-databases-iam).
* Access to the database is secured through the standard access controls provided by the database. These access controls are configured to require valid database-level credentials that are obtainable only through prior access to the database or through our Management Console UI or API.
* All Databases for EnterpriseDB storage is provided on storage encrypted with LUKS using AES-256. The default keys are managed by [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about). Bring-your-own-key (BYOK) for encryption is also available through [Key Protect Integration](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=cloud-databases-key-protect).
* IP allowlisting - All deployments support [allowlisting IP addresses](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=cloud-databases-allowlisting) to restrict access to the service.
* Public and Private Networking - Databases for EnterpriseDB is integrated with [Service Endpoints](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=cloud-databases-service-endpoints). You can select whether to use connections over the public network, the IBM Cloud internal network, or both.
* Dedicated Cores - Allocating dedicated cores to your deployment introduces hypervisor-level isolation to your database instance, by using isolated virtual machines to ensure that your data processing remains separated from other customers. It also provides a guaranteed minimum number of CPUs to your deployment.
* You might choose to enable the HIPAA Supported setting if you plan to include Protected Health Information (PHI) in HIPAA-enabled services. For more information, see [Set the HIPAA flag on in your account](https://cloud.ibm.com/docs/account?topic=account-eu-hipaa-supportedenabling-hipaa).



Only the account owner can enable the account to be EU supported and HIPAA supported.



 HIPAA 

If you're the account owner, you can enable your IBM Cloud® account to be HIPAA supported. For example, you might choose to enable the HIPAA Supported setting if you plan to include Protected Health Information (PHI) in HIPAA-enabled services.

The US Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act define standards for handling electronic healthcare transactions and information. If you or your company is a covered entity as defined by HIPAA, you must enable the HIPAA supported setting if you run sensitive workloads that are regulated under HIPAA and the HITECH Act. Learn more about IBM Cloud compliance in [Compliance on the IBM Cloud](https://www.ibm.com/cloud/compliance).

When you configure your account to be HIPAA enabled:



* You can filter on HIPAA Enabled services in the catalog. Accounts that enable the HIPAA Supported setting still have access to the full catalog of services.
* You indicate to IBM that your account stores protected health information (PHI).
* You digitally accept the IBM Business Associate Addendum (BAA) for covered entities.



Enable this setting only if you or your company is a covered entity as defined by HIPAA. If you or your company is a business associate of a covered entity, [contact IBM Cloud Sales](https://www.ibm.com/account/reg/us-en/signup?formid=MAIL-wcp) to accept the applicable BAA. For more information about HIPAA definitions of covered entities and business associates, see the [US Department of Health & Human Services](https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html) website.







 Define the auditing instances strategy
$ curl -X PUT "https://api.<region>.hs-crypto.cloud.ibm.com/api/v2/instance/policies?policy=allowedNetwork" -H "accept: application/vnd.ibm.kms.policy+json" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>" -H "content-type: application/vnd.ibm.kms.policy+json" -d '{
"metadata": {
"collectionType": "application/vnd.ibm.kms.policy+json",
"collectionTotal": 1
},
"resources": [
{
"policy_type": "allowedNetwork",
"policy_data": {
"enabled": false,
"attributes": {
"allowed_network": "private-only"
}
}
}
]
}'

Replace the variables in the example request according to the following table.



Table 2. Describes the variables needed to disable a network access policy at the instance level

 Variable Description 

 region Required. The region abbreviation, such as us-south or eu-de, that represents the geographic area where your Hyper Protect Crypto Services instance resides. For more information, see [Regional service endpoints](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regionsservice-endpoints). 
 port Required. The port number of the API endpoint. 
 IAM_token Required. Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the cURL request. For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Hyper Protect Crypto Services service instance.
Security and compliance 

You can use built-in security features in IBM Cloud Satellite® for risk analysis and security protection. These features help you to protect your Satellite workloads that run on your location infrastructure and network communication.



 Data security 

Learn more about options to secure the data that you use for workloads in IBM Cloud Satellite.



 What data is stored when I use Satellite? How can I use my own keys to encrypt my data? 

See [Securing your data in IBM Cloud Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-data-security).





 How do I make my data secure over Satellite Link? 

Your Satellite location infrastructure is a part of your local network (on-prem hosts) or the network of your cloud provider, but is managed remotely by using secure Satellite Link access from IBM Cloud. All communication over Satellite Link is encrypted by IBM. When you create an endpoint, you can optionally specify an additional data encryption protocol for the endpoint connection between the client source and destination resource. For example, even if the traffic is not encrypted on the source side, you can specify your own additional TLS encryption for the connection that goes over the internet.

To review information about how Satellite Link handles each type of connection protocol, see [Encryption protocols](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-protocols). To review other frequently asked questions about Satellite Link network security, see [External network requirements and security](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloudlink-security).





 What measures can I take to secure user access to data in my location? 

Review the following ways that you can secure access to your location.



* Consider the types of [user access to resources that run in your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-service-connectionuser-access)
* [Manage access for Satellite by using IBM Cloud Identity and Access Management (IAM)](https://cloud.ibm.com/docs/satellite?topic=satellite-iam)
Security 



 Security by design 

Security considerations are a critical part of the design of any API. The following principles SHOULD be applied during an service API's design and development:



* Operations SHOULD be simple and narrowly scoped such that they that are easy to reason about, easy to test, and closely match specific authorizations.
* Convenience features SHOULD be carefully weighed against the additional complexity they require, and eschewed where a strong justification is not present.
* Features and data that are not solving a well-understood use case SHOULD NOT be included in a service API.
* Sensitive information SHOULD NOT be returned in more operations and resource contexts than necessary.
* Where feasible, resources SHOULD be designed to be simple, easy to delete and recreate, and with immutable qualities. Large, complex, long-lived resources with large numbers of mutable properties SHOULD be avoided.



These approaches contain the attack surface of an API, and allow for more comprehensive security testing.





 Attack vector analysis 

When designing and developing a service API, industry resources on common attacks and attack mitigation SHOULD be considered. Recommended resources include:



* [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)
* [NIST Guide to Secure Web Services](https://csrc.nist.gov/publications/detail/sp/800-95/final)
* MITRE attack matrices for [SaaS](https://attack.mitre.org/matrices/enterprise/cloud/saas/) and [IaaS](https://attack.mitre.org/matrices/enterprise/cloud/iaas/)







 See also 

Important best practices with security implications are addressed across this handbook:



* [Authentication](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-authentication)
* [Authorization](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-authorization)
* [Encryption](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-encryption)
Requirement: Ensure that security engineering principles are applied in the design, development, implementation, and modification of your software. Maintain software integrity by using signed images, applying security patches, doing vulnerability scans, etc.

Purpose & value: It is critical to follow security engineering principles and manage changes to your software using a system development life cycle (SDLC) that incorporates information security considerations. Doing so minimizes the risk of introducing code or configuration changes that undermine your software's security.

Lack of software integrity leaves your operator vulnerable to security problems. So, it is critical for you to be able to assert the origin of all software components in your application and to keep software components up to date.

Most Relevant Control Groups or Controls:



Table 3. Related controls for development processes

 Family Control 

 System and Services Acquisition (SA) [SA-8 Security Engineering Principles](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-8) <br>[SA-11 Developer Security Testing and Evaluation](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-11) <br>[SA-12 Supply Chain Protection](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-12) <br>[SA-14 Criticality Analysis](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-14) <br>[SA-15 Development Process, Standards, and Tools](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-15) 







 5. Ensure consumer data can be encrypted at rest and in transit 

Requirement: Ensure operator can configure your software so that consumer data can be encrypted properly at rest and in transit.

Purpose & value: Consumers do not want their data to be accessible to bad actors.
Requirement: Ensure that security engineering principles are applied in the design, development, implementation, and modification of the system. Maintain software integrity by using signed images, applying security patches, doing vulnerability scans, etc.

Purpose & value: It is critical to follow security engineering principles and manage changes to your service using a system development life cycle (SDLC) that incorporates information security considerations. Doing so minimizes the risk of introducing code or configuration changes that undermine your system security.

Lack of software integrity leaves you vulnerable to security problems. So, it is critical for you to be able to assert the origin of all software components in the system and to keep software up to date. In addition, running regular scans on software to detect vulnerabilities allows you to more quickly take corrective action.

Implementation guidance:



* [VPC reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-development-processes)
* [Satellite reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-development-processes)



Most Relevant Controls:



Table 10. Related controls for development processes

 Family Control 

 System and Information Integrity (SI) [SI-7 Software & Information Integrity](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-si-7)
Security <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-access)<br><br><br> <br><br> * [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-access)<br><br><br> <br><br> * [App ID](https://cloud.ibm.com/docs/appid?topic=appid-service-access-management)<br><br><br> 
 Logging and monitoring <br><br> * [Activity Tracker Event Routing](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iam)<br> * [Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-access-management)<br> * [Flow Logs for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-authorizations-required-for-api-and-cli-calls)<br><br><br> <br><br> * [Activity Tracker Event Routing](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iam) <br> [Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-access-management)<br><br><br> 
 Integration <br><br> * [Event Streams](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-security)<br><br><br>
In addition, the security architecture can include other important security-related information, for example, user roles and access privileges assigned to each role, unique security requirements, the types of information processed, stored, and transmitted by the information system, restoration priorities of information and information system services, and any other specific protection needs. In today’s modern architecture, it is becoming less common for organizations to control all information resources. There are going to be key dependencies on external information services and service providers. Describing such dependencies in the information security architecture is important to developing a comprehensive mission/business protection strategy. Establishing, developing, documenting, and maintaining under configuration control, a baseline configuration for organizational information systems is critical to implementing and maintaining an effective information security architecture. The development of the information security architecture is coordinated with the Senior Agency Official for Privacy (SAOP)/Chief Privacy Officer (CPO) to ensure that security controls needed to support privacy requirements are identified and effectively implemented. PL-8 is primarily directed at organizations (i.e., internally focused) to help ensure that organizations develop an information security architecture for the information system, and that the security architecture is integrated with or tightly coupled to the enterprise architecture through the organization-wide information security architecture. In contrast, SA-17 is primarily directed at external information technology product/system developers and integrators (although SA-17 could be used internally within organizations for in-house system development). SA-17, which is complementary to PL-8, is selected when organizations outsource the development of information systems or information system components to external entities, and there is a need to demonstrate/show consistency with the organization’s enterprise architecture and information security architecture.
What is a secret? 

A secret is a piece of sensitive information. For example, an API key, password, or any type of credential that you might use to access a confidential system.

By using secrets, you're able to authenticate to protected resources as you build your applications. For example, when you try to access an external service API, you're asked to provide a unique credential. After you supply your credential, the external service can understand who you are and whether you're authorized to interact with it.

To learn more about the general characteristics of a secret, check out the following video.



* Video transcript

How are you making sure that your secrets are securely stored so that you can avoid data breaches and chaos in your DevOps workflows?

Hi, I'm Alex Greer with the IBM Cloud team, and before I get started make sure to like and subscribe now.

What is a secret?

A secret is a digital credential that is going to allow entities to communicate and perform actions on a service. This discrete piece of information keeps that access point secure. So let's look at how this paradigm exists.

Let's start with an entity here that needs to access some sort of service. We'll leave it little ambiguous for now, but some sort of service. To properly communicate with the service and be able to take the action that it needs to get its job done, this entity is going to need to communicate to the service two things: One, who it is, so that service can understand what or who is interacting with it. Two, it's going to have to know the set of permissions that it should grant in the context of its service. With these, the service can now properly allow that entity to interact with them. How we enable this interaction is with something we call a "secret."

Now, with this dynamic established, let's move into an example with users. For users, we'll say that this user here is our entity, and we'll say our service here – let's say that it's a developer, and they happen to need read or write access. They're interacting with the development repo to do that.
System and Services Acquisition (SA) [SA-8 Security Engineering Principles](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-8) <br>[SA-11 Developer Security Testing and Evaluation](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-11) <br>[SA-12 Supply Chain Protection](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-12) <br>[SA-14 Criticality Analysis](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-14) <br>[SA-15 Development Process, Standards, and Tools](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-sa-15) 







 5. Ensure consumer data can be encrypted at rest and in transit 

Requirement: Ensure operator can configure your software so that consumer data can be encrypted properly at rest and in transit.

Purpose & value: Consumers do not want their data to be accessible to bad actors. Protecting consumer data against unauthorized disclosure, modification, or destruction throughout the data lifecycle is of paramount importance in the IBM Cloud for Financial Services. Encryption is a major component of this protection, and operators must be able to configure your software to meet the data encryption requirements of the IBM Cloud Framework for Financial Services.

Implementation guidance:



* You must implement and document application capabilities and configuration requirements in accordance with the cryptographic specifications provided in the Supplemental Guidance for Cryptography section of the CIO template.
* You must implement and document application capabilities and configuration requirements related to using cryptographic keys provided via [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-overview) to protect data in transit and at rest.



Most Relevant Control Groups or Controls:



Table 4. Related controls for data encryption
Frequently Asked Questions 

FAQs for Secure Gateway might include questions about automation or logs. To find all FAQs for IBM Cloud®, see our FAQ library.



 What layer of the OSI model does the Secure Gateway service represent? 

The Secure Gateway service represents layer 4 of the OSI model.





 What version of TLS does the Secure Gateway service support? 

The Secure Gateway service supports TLS version 1.2.





 Why would I disable my gateway or destination? 

You might want to disable a destination or gateway for one of the following reasons:



* You create a destination, but you have not set up the security. In this case, you might disable the destination until its security is set up.
* You do not want the service to be available to users because you are making some updates to the service. In this case, you might temporarily disable the necessary gateways and wait for the service to be updated.
* You have set up all your gateways and destinations on the front end, but your backend is still building. In this case, you would disable your gateways or destinations until the backend build is complete.



For more information on disabling a gateway or a destination, see [how to manage your Secure Gateway service instance](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-manage-sg-service).





 What is the recommended approach to creation automation across multiple spaces? 

For example, your environment has one org and three spaces. One space is for development, another for staging, and the final one for production. Should you create a single Secure Gateway instance or multiple (that is, one for each space)? If you can create multiple gateways, are there any considerations for reusing a Node.js application to create a gateway and destination in each space?

The approach is as follows:



* You can create a single Secure Gateway instance for all three spaces. However, you must remember the gateway and destination [limitations for your specific plan](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-secure-gateway-service-plans).