vania-janet/multiturn-rag-retrieval-data huggingface dataset:
CA-8 - Penetration Testing 



  Control requirements 

CA-8 - 0
:   The organization conducts penetration testing [IBM Assignment: prior to production use, at least annually, and after significant changes] on [IBM Assignment: applications that are utilized by FS-ready public cloud customers or process customer’s data].





  NIST supplemental guidance 

Penetration testing is a specialized type of assessment conducted on information systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Such testing can be used to either validate vulnerabilities or determine the degree of resistance organizational information systems have to adversaries within a set of specified constraints (e.g., time, resources, and/or skills). Penetration testing attempts to duplicate the actions of adversaries in carrying out hostile cyber attacks against organizations and provides a more in-depth analysis of security-related weaknesses/deficiencies. Organizations can also use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls. A standard method for penetration testing includes, for example: (i) pretest analysis based on full knowledge of the target system; (ii) pretest identification of potential vulnerabilities based on pretest analysis; and (iii) testing designed to determine exploitability of identified vulnerabilities. All parties agree to the rules of engagement before the commencement of penetration testing scenarios. Organizations correlate the penetration testing rules of engagement with the tools, techniques, and procedures that are anticipated to be employed by adversaries carrying out attacks. Organizational risk assessments guide decisions on the level of independence required for personnel conducting penetration testing.
A deployment with n+2 pods that are managed by a replica set and spread across multiple nodes (anti-affinity) in a multizone cluster across zones.



You can also [connect multiple clusters in different regions with a global load balancer](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmultiple-clusters-glb) to increase the high availability.



 How can I increase the availability of my app? 

Consider the following options to increase availability of your app.

Use deployments and replica sets to deploy your app and its dependencies
: A deployment is a Kubernetes resource that you can use to declare all the components of your app and its dependencies. With deployments, you don't have to write down all the steps and instead can focus on your app. When you deploy more than one pod, a replica set is automatically created for your deployments that monitors the pods and assures that the specified number of pods is up and running. When a pod goes down, the replica set replaces the unresponsive pod with a new one. You can use a deployment to define update strategies for your app, including the number of pods that you want to add during a rolling update and the number of pods that can be unavailable at a time. When you perform a rolling update, the deployment checks whether the revision is working and stops the rollout when failures are detected. With deployments, you can concurrently deploy multiple revisions with different options. For example, you can test a deployment first before you decide to push it to production. By using Deployments, you can track any deployed revisions. You can use this history to roll back to a previous version if you encounter that your updates are not working as expected.

Include enough replicas for your app's workload, plus two
: To make your app even more highly available and more resilient to failure, consider including extra replicas than the minimum to handle the expected workload. Extra replicas can handle the workload in case a pod crashes and the replica set did not yet recover the crashed pod. For protection against two simultaneous failures, include two extra replicas.
Policies include a subject, target, and role. The subject is the user, service ID, or access group that you are providing access. The target of the policy is the resource to which you want to provide access. And, the IAM roles define the level of access or allowed actions on the target of the policy.

A policy assigns the subject one or more roles that define the level of access and one or more attributes that define the target that the policy allows access to. The policy can provide access to a single service at the instance level, to a set of resources that are organized together in a resource group or to any set of resources that can be defined by a set of attributes such as location or resource type. A policy can also provide access to account management services. Depending on the IAM roles that you assign, the subject is allowed varying levels of access for completing account management tasks, working with service instances, or accessing a service by using the console or completing API calls.

There are different types of policies that allow access to account resources for users and service IDs: a resource group policy, a resource instance policy, an account-wide policy for access to all IAM-enabled services or all instances of a specified service, and a policy on all or one account management services. Depending on your selections, custom configuration options, such as defining access to resources in a specific location or defining access to the granular level of a service-specific resource within an instance, might be available.

In addition to access policies for users and service IDs, there is a policy type that is called an authorization that allows specific services or instances of services access to other services. You can learn more about assigning access between services in the [Using authorizations to grant access between services](https://cloud.ibm.com/docs/account?topic=account-serviceauth) documentation.





 Roles 

IBM Cloud access roles are a group of actions. Access roles allow users and service IDs to complete specific tasks within the context of the target resources that are defined in the policy. There are two types of predefined access roles: platform management and service access. The third type of access role is a custom role that you can create for a service to combine any set of available actions to meet your organizational needs.
If the client installed the following, you can monitor them.



* VMware Aria Automation
* VMware Aria Orchestrator
* VMware Aria Business for Cloud
* VMware Site Recovery Manager



The VMware SDDC Health Management Pack provides the following dashboards:



* SDDC Management Health Overview Dashboard - You can use SDDC Management Health overview dashboard to view and analyze the application-specific problems in the SDDC components.
* SDDC Health Historic Trend Dashboard - The VMware SDDC Health Management Pack consists of SDDC health historic trend dashboard, which displays the health trend for each component in the SDDC stack.
* SDDC VMware Aria Operations Manager Sizing Dashboard - The SDDC VMware Aria Operations Manager Sizing Dashboard provides VMware Aria Operations Manager cluster capacity to process object and metrics.



The plug-ins in the VMware SDDC Health Management Pack collect metrics for object types that are contained in the plug-ins. The Management Pack collects health metrics for the following components:



* vCenter Server
* Management Pack for NSX for vSphere
* VMware Aria Automation
* VMware Aria Operations Manager
* VMware Aria Business
* VMware Aria Operations for Logs
* VMware Site Recovery Manager
* vCenter HA
* vMware vSAN Health
* Services in vCenter Server Appliance
* VMware Aria Operations Manager Sizing
* VMware Aria Orchestrator







 Management Pack for NSX-T 

The NSX-T management pack extends VMware Aria Operations core analytics, correlation, predictive capacity, and visualization capabilities to virtual networks. The pack includes the following items.



* Configuration assurance
* Health
* Performance
* Capacity
* Troubleshooting for NSX-T objects







 Management Pack for NSX for vSphere 

The NSX for vSphere management pack offers operations management coverage for deployments of VMware's NSX virtual networking technologies. This management pack extends VMware Aria Operations core analytics, correlation, predictive capacity, and visualization capabilities to virtual networks.
Configuring which metrics to monitor 

You can customize a Monitoring agent and specify which metrics to include and which ones to filter out.





  Filtering custom metrics in a Monitoring agent 

To filter custom metrics, you must customize the metrics_filter section in the agent configuration file. You can specify which metrics to include and which ones to filter out by configuring the include and exclude filtering parameters.

For more information on how to configure the Monitoring agent, see:



*  Linux Monitoring agent: [Including and excluding metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-change_linux_agentchange_linux_agent_inc_exc_metrics)
*  Kubernetes Monitoring agent: [Including and excluding metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-change_kube_agentchange_kube_agent_inc_exc_metrics)
*  Docker container Monitoring agent: [Including and excluding metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-change_agentparams)





  Logging into a file what metrics are included or excluded 

You can log the custom metrics that are collected by an agent. You must set the metrics_excess_log to true in the log section will enable logging of the custom metrics that are included or excluded.

For more information on how to configure the Monitoring agent to report which metrics are collected, see:



*  Linux Monitoring agent: [Logging into a file what metrics are included or excluded](https://cloud.ibm.com/docs/monitoring?topic=monitoring-change_linux_agentchange_linux_agent_log_level)
*  Kubernetes Monitoring agent: [Logging into a file what metrics are included or excluded](https://cloud.ibm.com/docs/monitoring?topic=monitoring-change_kube_agentchange_kube_agent_log_metrics)
*  Docker container Monitoring agent: [Logging into a file what metrics are included or excluded](https://cloud.ibm.com/docs/monitoring?topic=monitoring-change_agentlog_level)
: Uses a [fast Fourier transform (FFT)](https://en.wikipedia.org/wiki/Fast_Fourier_transform) algorithm to return the discrete Fourier transform of a time series. The string that is specified for the second parameter determines the type of transform:



* forward or f for a forward transform
* inverse or i for an inverse transform



TS_SEG_FFT(DoubleSegmentTimeSeries, String)
: Output: DoubleArrayTimeSeries
: Uses a [fast Fourier transform (FFT)](https://en.wikipedia.org/wiki/Fast_Fourier_transform) algorithm to return the discrete Fourier transform for each segment of the input time series. The string that is specified for the second parameter determines the type of transform:



* forward or f for a forward transform
* inverse or i for an inverse transform



: Each timetick in the output time series is the timetick of the corresponding segment.

TS_AUTO_CORRELATION(DoubleTimeSeries)
: Output: DoubleArray
: Use an [auto correlation](https://en.wikipedia.org/wiki/Autocorrelation) algorithm to return the correlation of a time series with a delayed copy of itself.

TS_SEG_AUTO_CORRELATION(DoubleSegmentTimeSeries)
: Output: DoubleArrayTimeSeries
: Use an [auto correlation](https://en.wikipedia.org/wiki/Autocorrelation) algorithm to return the correlation of each segment of the input time series with a delayed copy of itself. Each timetick in the output time series is the timetick of the corresponding segment.

TS_CROSS_CORRELATION(DoubleTimeSeries, DoubleTimeSeries)
: Output: DoubleArray
: Use a [cross correlation](https://en.wikipedia.org/wiki/Cross-correlation) algorithm to return a measure of the similarity of two time series.

TS_SEG_CROSS_CORRELATION(DoubleSegmentTimeSeries, DoubleSegmentTimeSeries)
: Output: DoubleArrayTimeSeries
CA-7 - Continuous Monitoring 



 Control requirements 

The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes:

CA-7 (a)
: Establishment of [Assignment: organization-defined metrics] to be monitored;

CA-7 (b)
: Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring;

CA-7 (c)
: Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;

CA-7 (d)
: Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy;

CA-7 (e)
: Correlation and analysis of security-related information generated by assessments and monitoring;

CA-7 (f)
: Response actions to address results of the analysis of security-related information; and

CA-7 (g)
: Reporting the security status of organization and the information system to [IBM Assignment: to meet customer requirements][IBM Assignment: monthly].





 Additional IBM Cloud for Financial Services specifications 



* The customer has the right to request and review organization processes, procedures, and documentation (e.g. architecture diagrams, security and control environment, data management, incident management, etc.) in order to validate customer's policy, standards, outsourcing risk management framework, and regulatory requirements are being met by the organization.







 Implementation guidance 

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



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







 IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



Rules for CA-7 in IBM Cloud for Financial Services v1.2.0 profile

 Requirement ID Rules
The pack includes the following items.



* Configuration assurance
* Health
* Performance
* Capacity
* Troubleshooting for NSX-T objects







 Management Pack for NSX for vSphere 

The NSX for vSphere management pack offers operations management coverage for deployments of VMware's NSX virtual networking technologies. This management pack extends VMware Aria Operations core analytics, correlation, predictive capacity, and visualization capabilities to virtual networks. Coverage includes configuration assurance, health, performance, capacity, and troubleshooting for NSX logical switches, logical routers, edge services, distributed firewall, and load balancers.

The NSX for vSphere management pack is tightly integrated with VMware Aria Operations and vSphere host data is correlated with the NSX services that run with these hosts. With log integration by VMware Aria Operations for Logs, error and outage conditions, triggered by log messages, are alerted within the management pack object and problem windows.





 VMware Aria Operations Federation Management Pack 

VMware Aria Operations Federation Management Pack enables a multisite VMware Aria Operations deployment into a single pane of glass. It allows a deployment of VMware Aria Operations with the capability of receiving key metrics for specified objects from VMware Aria Operations deployments.





 Management Pack for Hybrid Cloud Extension (HCX) 

VMware Aria Operations Management Pack for HCX extends the Operations Management capabilities of VMware Aria Operations to hybrid capabilities presented by HCX. With the management pack, you can collect metrics, change events, and resource topology information from HCX. It enables the monitoring, isolation, and resolution of performance bottlenecks in the HCX Interconnects, Migrations, or Protected workloads.







 Related links 



* [VMware Aria Operations 8.12.x Sizing Guidelines](https://kb.vmware.com/s/article/91692)
* [VMware Aria Operations Documentation](https://docs.vmware.com/en/VMware-Aria-Operations/index.html)
However, IBM Cloud does not automate the installation, configuration, and bring-up of the optional VMware components for the VMware vSphere instance.
* The functions that are supported by vCenter Server instances and VMware vSphere instances are different. For more information, see [Offering comparison chart](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-inst_comp_chart).



* What is included in a vCenter Server instance?

For more information, see [Technical specifications for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverviewvc_vcenterserveroverview-specs).
* What is included in a VMware vSphere instance?

For more information, see [Technical specifications for VMware vSphere instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_vsphereclusteroverviewvs_vsphereclusteroverview-specs).
* Is a two node vCenter Server instance highly available?

Deploy production workloads into environments that have at least three nodes.

The VMware vSphere DRS (Distributed Resource Scheduler) and VMware HA (High Availability) are enabled by default. However, VMware suggests that you place each of the three NSX Controllers on an individual node.

In the two-node minimum deployment, one node has one NSX Controller, and the other node has two NSX Controllers. If the node with two NSX Controllers goes down, NSX Controller operations are placed in read-only mode, and new VMs (virtual machines) or vMotion VMs might experience networking issues.

When a third node is added to a two-node cluster, vCenter Server automatically rebalances the three NSX Controllers across the three nodes and creates a highly available environment.
* Can I set up VMware vCenter HA configuration?
Segment by Application load balancer appliance metrics and Application load balancer listener metrics 







 Total Members 

The total members count is the number of members created in a pool. This metric is only available for TCP, HTTP, and HTTPS listeners.



Table 10: Application load balancer total members count metric metadata

 Metadata Description 

 Metric name ibm_is_load_balancer_backend_total_members 
 Metric type gauge 
 Value type none 
 Segment by Application load balancer appliance metrics, Application load balancer listener metrics and Application load balancer pool metrics 







 Active Members 

The active members count is the number of healthy members in a pool. This metric is only available for TCP, HTTP, and HTTPS listeners.



Table 11: Application load balancer active members count metric metadata

 Metadata Description 

 Metric name ibm_is_load_balancer_backend_active_members 
 Metric type gauge 
 Value type none 
 Segment by Application load balancer appliance metrics, Application load balancer listener metrics and Application load balancer pool metrics 









 Metric segmentation 

You can split the data into various visualizations in the IBM Cloud Monitoring dashboard, allowing views of different metrics based on your preferences. For example, if you have multiple load balancers or accounts with different load balancers in each account, you might want to focus on a particular listener port.

As an example, you can segment the active connections by Application load balancer listener port to show how many active users are connected to the load balancer through each listener type. To illustrate this, let's assume that your load balancer has two different listener protocols one HTTP on port 80 and another for TCP on port 8080. The dashboard would contain different lines showing 10 users who are connected through HTTP on Port 80 in one color, and 6 users connected through TCP on port 8080 in another color.



 Global attributes 

The following attributes are available for segmenting the three metrics.



Table 12: Global attributes

 Attribute Attribute Name Attribute Description 

 Resource ibm_resource A load balancer's unique ID 
 Scope ibm_scope The account that is associated with a given load balancer 
 Service name ibm_service_name ibm-is-load-balancer 







 Additional attributes
As an industry best practice, Akamai only trusts the root certificates and not the intermediate certificates because the set of intermediary certificates that is trusted changes frequently. You can find the Akamai trusted certificates on the Akamai community site at [SSL/TLS certificate chains for Akamai-managed certificates](https://community.akamai.com/docs/DOC-4447-ssltls-certificate-chains-for-akamai-managed-certificates).





 Large file optimization 

Large file optimization allows the CDN network to optimize the delivery of content greater than 10 MB. This enablement increases performance for large files and reduces latency and download times. Without this feature, the CDN cannot service files greater than 1.8 GB. This feature allows file downloads greater than 1.8 GB, up to a maximum of 320 GB.

For large file optimization to work, byte-range requests must be enabled on the origin server. Akamai CDN employs a technique that is called Partial Object Caching for this optimization. When a large file is requested, the Edge server checks whether the file meets the size requirements. This means that files larger than 10 MB are requested from the origin server in chunks. After the chunk arrives at the Edge server, it is cached and immediately served to the user. The next chunk is pre-fetched in parallel by the Edge server, thus reducing latency. This process continues until the entire file is retrieved, or the connection is terminated.

When this feature is enabled, there is a slight performance cost that is associated with serving content smaller than 10 MB. Therefore, this feature is recommended only for serving large files. A typical use case would be to create a new origin path in the CDN configuration and enable large file optimization for that path.





 Metrics with graphical views 

Metrics for an individual CDN are provided on the Overview tab of the customer portal for that CDN mapping. Two types of metrics are calculated from the CDN's usage: those that show the metrics over a time period as a graph, and those that are shown as aggregate values.

For metrics that display the change over a period of time as a graph, you can see three line graphs and a pie chart.