vania-janet/multiturn-rag-retrieval-data huggingface dataset:
After you create a project in Git Repos and Issue Tracking, but before you entrust any files, issues, records, or other data with the project, review the project settings and change any settings that are necessary to protect your data. Settings to review include visibility levels, email notifications, integrations, web hooks, access tokens, deploy tokens, and deploy keys.



 Project visibility levels 

Git Repos and Issue Tracking projects can have one of the following visibility levels: private, internal, or public.



* Private projects are visible only to project members. This setting is the default visibility level for new projects, and is the most secure visibility level for your data.
* Internal projects are visible to all users that are logged in to IBM Cloud.
* Public projects are visible to anyone.



To limit project access to only project members, complete the following steps:



1. From the project sidebar, click Settings > General.
2. On the General Settings page, click Visibility > project features > permissions.
3. Locate the Project visibility setting.
4. Select Private, if it is not already selected.
5. Click Save changes.







 Project email settings 

By default, Git Repos and Issue Tracking notifies project members by way of email about project activities. These emails typically include customer-owned data that was provided to Git Repos and Issue Tracking by users. For example, if a user posts a comment to an issue, Git Repos and Issue Tracking sends an email to all subscribers. The email includes information such as a copy of the comment, the user who posted it, and when the comment was posted. To turn off all email notifications for your project, complete the following steps:



1. From the project sidebar, click Settings > General.
2. On the **General Settings **page, click Visibility > project features > permissions.
3. Select the Disable email notifications checkbox.
4. Click Save changes.







 Project integrations and webhooks
Managing security groups for virtual server traffic (ibmcloud sl securitygroup) 

A security group is a set of IP filter rules that define how to handle incoming (ingress) and outgoing (egress) traffic from the public and private interfaces of a virtual server instance. The rules that you add to a security group are known as security group rules.

Use the following commands from the IBM Cloud® Command Line Interface to manage a security group by using the IBM Cloud classic infrastructure Security Group service.



 ibmcloud sl securitygroup create 

Create a security group:

ibmcloud sl securitygroup create [OPTIONS]

Command options:

-n, --name
: The name of the security group.

-d, --description
: The description of the security group.





 ibmcloud sl securitygroup delete 

Delete the security group:

ibmcloud sl securitygroup delete SECURITYGROUP_ID [OPTIONS]

Command options:

-f, --force
: Force operation without confirmation.





 ibmcloud sl securitygroup detail 

Get details about a security group:

ibmcloud sl securitygroup detail SECURITYGROUP_ID [OPTIONS]





 ibmcloud sl securitygroup edit 

Edit details of a security group:

ibmcloud sl securitygroup edit SECURITYGROUP_ID [OPTIONS]

Command options:

-n, --name
: The name of the security group.

-d, --description
: The description of the security group.





 ibmcloud sl securitygroup interface-add 

Attach an interface to a security group:

ibmcloud sl securitygroup interface-add SECURITYGROUP_ID [OPTIONS]

Command options:

-n, --network-component
: The network component ID to associate with the security group.

-s, --server
: The server ID to associate with the security group.

-i, --interface
: The interface of the server to associate (public or private).





 ibmcloud sl securitygroup interface-list 

List interfaces associated with security group:

ibmcloud sl securitygroup interface-list SECURITYGROUP_ID [OPTIONS]

Command options:

--sortby
: Column to sort by.
CA-1 - Security Assessment and Authorization Policy and Procedures 



  Control requirements 

The organization:

CA-1 (a)
:   Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:



1.  A security assessment and authorization policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2.  Procedures to facilitate the implementation of the security assessment and authorization policy and associated security assessment and authorization controls; and



CA-1 (b)
:   Reviews and updates the current:



1.  Security assessment and authorization policy [IBM Assignment: at least annually]; and
2.  Security assessment and authorization procedures [IBM Assignment: at least annually].







  NIST supplemental guidance 

This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the CA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures.
AT-3 - Role-based Security Training 



  Control requirements 

The organization provides role-based security training to personnel with assigned security roles and responsibilities:

AT-3 (a)
:   Before authorizing access to the information system or performing assigned duties;

AT-3 (b)
:   When required by information system changes; and

AT-3 (c)
:   [IBM Assignment: at least annually] thereafter.





  NIST supplemental guidance 

Organizations determine the appropriate content of security training based on the assigned roles and responsibilities of individuals and the specific security requirements of organizations and the information systems to which personnel have authorized access. In addition, organizations provide enterprise architects, information system developers, software developers, acquisition/procurement officials, information system managers, system/network administrators, personnel conducting configuration management and auditing activities, personnel performing independent verification and validation activities, security control assessors, and other personnel having access to system-level software, adequate security-related technical training specifically tailored for their assigned duties. Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical safeguards and countermeasures. Such training can include for example, policies, procedures, tools, and artifacts for the organizational security roles defined. Organizations also provide the training necessary for individuals to carry out their responsibilities related to operations and supply chain security within the context of organizational information security programs. Role-based security training also applies to contractors providing services to federal agencies.
About security groups 

IBM Cloud® Security Groups for VPC give you a convenient way to apply rules that establish filtering to a target of a virtual server instance, based on its IP address. Security group targets include virtual server instance network interfaces, endpoint gateways, and load balancers. When you create a security group, you configure it to create the network traffic patterns you want.

By default, a security group is set up with rules that deny all inbound traffic and permit all outbound traffic. As new rules are added to a security group, the new rules redefine the scope of permitted inbound or outbound traffic.

Rules are stateful. To have stateful rules means when you create a rule that allows traffic one way, the rule automatically permits reverse traffic. For example, if you create a rule to allow inbound TCP traffic on port 80, the rule also allows replying outbound TCP traffic on port 80 back to the originating host, without the need for another rule.

Security groups are scoped to a single VPC. This scoping implies that a security group can be attached to any security group target within the same VPC. You can set up a security group's policy to allow traffic between all members of a security group.

When you create a new security group, it is assigned a default security group policy. You can modify the default security group policy settings and the rules of individual security groups.

When you create a resource that uses a security group and don't specify a security group, the resource's primary network interface is attached to the default security group of that resource's VPC.

Updating the rules fo the default security group is a separate process from updating the default security group policy. If you edit the rules of the default security group, those edited rules then apply to all current and future servers in the group. For more information, see [Updating default security group rules](https://cloud.ibm.com/docs/vpc?topic=vpc-updating-the-default-security-groupupdating-the-default-security-group).



 Security group targets 

A target is any resource you attach or detach a security group to or from.
CA-6 - Security Authorization 



  Control requirements 

The organization:

CA-6 (a)
:   Assigns a senior-level executive or manager as the authorizing official for the information system;

CA-6 (b)
:   Ensures that the authorizing official authorizes the information system for processing before commencing operations; and

CA-6 (c)
:   Updates the security authorization [IBM Assignment: at least every three (3) years or when a significant change occurs].





  NIST supplemental guidance 

Security authorizations are official management decisions, conveyed through authorization decision documents, by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems and to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. Authorizing officials provide budgetary oversight for organizational information systems or assume responsibility for the mission/business operations supported by those systems. The security authorization process is an inherently federal responsibility and therefore, authorizing officials must be federal employees. Through the security authorization process, authorizing officials assume responsibility and are accountable for security risks associated with the operation and use of organizational information systems. Accordingly, authorizing officials are in positions with levels of authority commensurate with understanding and accepting such information security-related risks. OMB policy requires that organizations conduct ongoing authorizations of information systems by implementing continuous monitoring programs. Continuous monitoring programs can satisfy three-year reauthorization requirements, so separate reauthorization processes are not necessary. Through the employment of comprehensive continuous monitoring processes, critical information contained in authorization packages (i.e., security plans, security assessment reports, and plans of action and milestones) is updated on an ongoing basis, providing authorizing officials and information system owners with an up-to-date status of the security state of organizational information systems and environments of operation. To reduce the administrative cost of security reauthorization, authorizing officials use the results of continuous monitoring processes to the maximum extent possible as the basis for rendering reauthorization decisions.
PL-8 - Information Security Architecture 



 Control requirements 

The organization:

PL-8 (a)
: Develops an information security architecture for the information system that:



1. Describes the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information;
2. Describes how the information security architecture is integrated into and supports the enterprise architecture; and
3. Describes any information security assumptions about, and dependencies on, external services;



PL-8 (b)
: Reviews and updates the information security architecture [IBM Assignment: at least annually or when a significant change occurs] to reflect updates in the enterprise architecture; and

PL-8 (c)
: Ensures that planned information security architecture changes are reflected in the security plan, the security Concept of Operations (CONOPS), and organizational procurements/acquisitions.





 NIST supplemental guidance 

This control addresses actions taken by organizations in the design and development of information systems. The information security architecture at the individual information system level is consistent with and complements the more global, organization-wide information security architecture described in PM-7 that is integral to and developed as part of the enterprise architecture. The information security architecture includes an architectural description, the placement/allocation of security functionality (including security controls), security-related information for external interfaces, information being exchanged across the interfaces, and the protection mechanisms associated with each interface. 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.
PL-2 - System Security Plan 



 Control requirements 

The organization:

PL-2 (a)
: Develops a security plan for the information system that:



1. Is consistent with the organization’s enterprise architecture;
2. Explicitly defines the authorization boundary for the system;
3. Describes the operational context of the information system in terms of missions and business processes;
4. Provides the security categorization of the information system including supporting rationale;
5. Describes the operational environment for the information system and relationships with or connections to other information systems;
6. Provides an overview of the security requirements for the system;
7. Identifies any relevant overlays, if applicable;
8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring decisions; and
9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;



PL-2 (b)
: Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles];

PL-2 (c)
: Reviews the security plan for the information system [IBM Assignment: at least annually];

PL-2 (d)
: Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and

PL-2 (e)
: Protects the security plan from unauthorized disclosure and modification.





 Additional IBM Cloud for Financial Services specifications 



* The organization shall maintain a catalog of all customer metadata processed and/or transmitted by the organization on behalf of the customer. Metadata should be defined by each customer.
* The organization must document all information flows that involve the transfer of customer data. An information flow control policy must be developed and maintained that indicates the source and destination of each flow, the system of record and whether the information is altered during transmission.







 NIST supplemental guidance 

Security plans relate security requirements to a set of security controls and control enhancements.
Security Groups docs 

An IBM Cloud® security group is a set of IP filter rules that define how to handle incoming (ingress) and outgoing (egress) traffic to both the public and private interfaces of a virtual server instance. The rules that you add to a security group are known as security group rules.

 Recommended content 

[Getting started with IBM security groups You can use security groups to enact a set of IP filter rules that define how to handle incoming and outgoing traffic to both the public and private interfaces of a virtual server instance.](https://cloud.ibm.com/docs/security-groups?topic=security-groups-getting-started)[Creating security groups and rules You can create an IBM Cloud® security group and its associated rules and then assign it to the interfaces of one or more virtual server instances to enable a virtual firewall.](https://cloud.ibm.com/docs/security-groups?topic=security-groups-creating-security-groups)[Managing security groups You can manage security groups by using the Security Groups page, or the Device Details page in the IBM Cloud console.](https://cloud.ibm.com/docs/acme-test?topic=acme-test-create-project)

 Video library 

[![carousel thumbnail](https://cloud.ibm.com/media/docs/images/homepage/default_video_thumbnail.png)<br><br>Network as a service](https://cloud.ibm.com/docs/security-groups?topic=security-groups-naas-video)

 Learn more 

[IBM Developer<br><br>Visit IBM Developer for technical articles, code patterns, tutorials, and more.<br><br>![112-Developer-tools.svg](https://cloud.ibm.com/media/docs/images/homepage/112-Developer-tools.svg)](https://developer.ibm.com/depmodels/cloud/)[Architecture Center<br><br>Discover the architecture references available for this product.<br><br>!
AC-4 (14) - Security Policy Filter Constraints 



  Control requirements 

AC-4 (14) - 0
:   The information system, when transferring information between different security domains, implements [Assignment: organization-defined security policy filters] requiring fully enumerated formats that restrict data structure and content.





  Additional IBM Cloud for Financial Services specifications 



*  This control is required for ISVs.







  NIST supplemental guidance 

Data structure and content restrictions reduce the range of potential malicious and/or unsanctioned content in cross-domain transactions. Security policy filters that restrict data structures include, for example, restricting file sizes and field lengths. Data content policy filters include, for example: (i) encoding formats for character sets (e.g., Universal Character Set Transformation Formats, American Standard Code for Information Interchange); (ii) restricting character data fields to only contain alpha-numeric characters; (iii) prohibiting special characters; and (iv) validating schema structures.
On the Security Group Details page, you can complete several management tasks.



* View a list of rules that are defined for the security group.
* Create new rules.
* Edit a rule.
* Delete a rule.
* View the virtual server instances and the associated interfaces that are assigned to the security group.





If you delete the last rule in a security group, then inbound and outbound traffic is not allowed by this security group.





 Managing security groups from the Device Details page 

To manage security groups from the Device Details page, complete the following steps:



1. From the [IBM Cloud console](https://cloud.ibm.com/), click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > Classic Infrastructure to get to the Classic Infrastructure landing page.
2. From the Classic Infrastructure menu, select Devices > Device List to get to the Devices page.
3. On the Devices page, select the device name of the virtual server that you ordered to view its details.
4. In the Security Group section, you can assign predefined security groups to a network interface of a virtual server instance.

The first time that you assign an existing security group to a network interface (public or private), a restart is required for each interface. However, if the public and private interfaces were assigned to the security group at the same time, then only one restart is required. After a restart, changes are automatically applied.

When you assign a new security group, it prevents new connections from being established according to the security group rule definitions. However, existing socket connections are not terminated.

If you remove the last security group that is assigned to a virtual server instance, then the virtual server traffic is no longer limited by security groups. A security group firewall no longer exists.
5. After you finish making changes, click Save.