From 548f663acf06b6f6094eda374f8cbccbbcb05d73 Mon Sep 17 00:00:00 2001 From: Randy Woods Date: Thu, 8 Feb 2024 11:52:39 -0700 Subject: [PATCH] Get Question Group Headings translated in API --- .../LanguagePacks/UK/NEW_REQUIREMENT.json | 58 +++++++++---------- .../UK/QUESTION_GROUP_HEADING.json | 10 ++-- .../CSETWebCore.Helpers/TranslationOverlay.cs | 1 + .../CSETWebCore.Model/Analysis/ChartData.cs | 12 ++-- .../Analysis/usp_getRankedCategories.cs | 1 + .../Controllers/AnalysisController.cs | 51 +++++----------- .../analysis/dashboard/dashboard.component.ts | 16 ++--- .../question-filters.component.ts | 2 - CSETWebNg/src/assets/i18n/en.json | 4 +- CSETWebNg/src/assets/i18n/es.json | 4 +- CSETWebNg/src/assets/i18n/uk.json | 8 ++- 11 files changed, 76 insertions(+), 91 deletions(-) diff --git a/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/NEW_REQUIREMENT.json b/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/NEW_REQUIREMENT.json index 0588d1cfae..dade36d113 100644 --- a/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/NEW_REQUIREMENT.json +++ b/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/NEW_REQUIREMENT.json @@ -3,168 +3,168 @@ { "requirementId": "12292", "requirementTextEnglish": "Physical devices and systems within the organization are inventoried", - "requirementText": "12292 Physical devices and", + "requirementText": "Фізичні пристрої та системи всередині організації інвентаризовано", "supplementalInfoEnglish": "Organizations may choose to implement centralized information system component inventories that include components from all organizational information systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., information system association, information system owner). Information deemed necessary for effective accountability of information system components includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include, for example, manufacturer, device type, model, serial number, and physical location.", "supplementalInfo": "12292 Organizations may ch" }, { "requirementId": "12293", "requirementTextEnglish": "Software platforms and applications within the organization are inventoried", - "requirementText": "12293 Software platforms a", + "requirementText": "Програмні платформи та програми в межах організації інвентаризовано", "supplementalInfoEnglish": "Organizations may choose to implement centralized information system component inventories that include components from all organizational information systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., information system association, information system owner). Information deemed necessary for effective accountability of information system components includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include, for example, manufacturer, device type, model, serial number, and physical location.", "supplementalInfo": "12293 Organizations may ch" }, { "requirementId": "12294", "requirementTextEnglish": "Organizational communication and data flows are mapped", - "requirementText": "12294 Organizational commu", + "requirementText": "Комунікації та потоки даних в організації структуровано", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, AC-4 Supplemental Guidance: Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include, for example, keeping export-controlled information from being transmitted in the clear to the Internet, blocking outside traffic that claims to be from within the organization, restricting web requests to the Internet that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between information systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes, for example: (i) prohibiting information transfers between interconnected systems (i.e., allowing access only); (ii) employing hardware mechanisms to enforce one-way information flows; and (iii) implementing trustworthy regrading mechanisms to reassign security attributes and security labels. Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering/inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 22 primarily address cross-domain solution needs which focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, for example, high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf information technology products. Supplemental Guidance from NIST 800-53 Rev 4, CA-3 Supplemental Guidance: This control applies to dedicated connections between information systems (i.e., system interconnections) and does not apply to transitory, user-controlled connections such as email and website browsing. Organizations carefully consider the risks that may be introduced when information systems are connected to other systems with different security requirements and security controls, both within organizations and external to organizations. Authorizing officials determine the risk associated with information system connections and the appropriate controls employed. If interconnecting systems have the same authorizing official, organizations do not need to develop Interconnection Security Agreements. Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. Organizations may also incorporate Interconnection Security Agreement information into formal contracts, especially for interconnections established between federal agencies and non-federal (i.e., private sector) organizations. Risk considerations also include information systems sharing the same networks. For certain technologies (e.g., space, unmanned aerial vehicles, and medical devices), there may be specialized connections in place during preoperational testing. Such connections may require Interconnection Security Agreements and be subject to additional security controls. Supplemental Guidance from NIST 800-53 Rev 4, CA-9 Supplemental Guidance: This control applies to connections between organizational information systems and (separate) constituent system components (i.e., intra-system connections) including, for example, system connections with mobile devices, notebook/desktop computers, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each individual internal connection, organizations can authorize internal connections for a class of components with common characteristics and/or configurations, for example, all digital printers, scanners, and copiers with a specified processing, storage, and transmission capability or all smart phones with a specific baseline configuration. Supplemental Guidance from NIST 800-53 Rev 4, PL-8 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. 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.", "supplementalInfo": "12294 Supplemental Guidanc" }, { "requirementId": "12295", "requirementTextEnglish": "External information systems are catalogued", - "requirementText": "12295 External information", + "requirementText": "Зовнішні інформаційні системи каталогізовано", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, AC-20 Supplemental Guidance: External information systems are information systems or components of information systems that are outside of the authorization boundary established by organizations and for which organizations typically have no direct supervision and authority over the application of required security controls or the assessment of control effectiveness. External information systems include, for example: (i) personally owned information systems/devices (e.g., notebook computers, smart phones, tablets, personal digital assistants); (ii) privately owned computing and communications devices resident in commercial or public facilities (e.g., hotels, train stations, convention centers, shopping malls, or airports); (iii) information systems owned or controlled by nonfederal governmental organizations; and (iv) federal information systems that are not owned by, operated by, or under the direct supervision and authority of organizations. This control also addresses the use of external information systems for the processing, storage, or transmission of organizational information, including, for example, accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational information systems. For some external information systems (i.e., information systems operated by other federal agencies, including organizations subordinate to those agencies), the trust relationships that have been established between those organizations and the originating organization may be such, that no explicit terms and conditions are required. Information systems within these organizations would not be considered external. These situations occur when, for example, there are pre-existing sharing/trust agreements (either implicit or explicit) established between federal agencies or organizations subordinate to those agencies, or when such trust agreements are specified by applicable laws, Executive Orders, directives, or policies. Authorized individuals include, for example, organizational personnel, contractors, or other individuals with authorized access to organizational information systems and over which organizations have the authority to impose rules of behavior with regard to system access. Restrictions that organizations impose on authorized individuals need not be uniform, as those restrictions may vary depending upon the trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments. This control does not apply to the use of external information systems to access public interfaces to organizational information systems (e.g., individuals accessing federal information through www.usa.gov). Organizations establish terms and conditions for the use of external information systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum: types of applications that can be accessed on organizational information systems from external information systems; and the highest security category of information that can be processed, stored, or transmitted on external information systems. If terms and conditions with the owners of external information systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems. Supplemental Guidance from NIST 800-53 Rev 4, SA-9 Supplemental Guidance: External information system services are services that are implemented outside of the authorization boundaries of organizational information systems. This includes services that are used by, but not a part of, organizational information systems. FISMA and OMB policy require that organizations using external service providers that are processing, storing, or transmitting federal information or operating information systems on behalf of the federal government ensure that such providers meet the same security requirements that federal agencies are required to meet. Organizations establish relationships with external service providers in a variety of ways including, for example, through joint ventures, business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, and supply chain exchanges. The responsibility for managing risks from the use of external information system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a level of confidence that each participating provider in the potentially complex consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust varies based on the relationships between organizations and the external providers. Organizations document the basis for trust relationships so the relationships can be monitored over time. External information system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define expectations of performance for security controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of non-compliance.", "supplementalInfo": "12295 Supplemental Guidanc" }, { "requirementId": "12296", "requirementTextEnglish": "Resources (e.g., hardware, devices, data, and software) are prioritized based on their classification, criticality, and business value", - "requirementText": "12296 Resources (e.g., har", + "requirementText": "Ресурси (наприклад, апаратне забезпечення, пристрої, дані, час, персонал та програмне забезпечення) пріоритизовано на підставі їх класифікації, критичності та вартості для бізнесу", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, CP-2 Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Supplemental Guidance from NIST 800-53 Rev 4, RA-2 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. Supplemental Guidance from NIST 800-53 Rev 4, SA-14 Supplemental Guidance: Criticality analysis is a key tenet of supply chain risk management and informs the prioritization of supply chain protection activities such as attack surface reduction, use of all-source intelligence, and tailored acquisition strategies. Information system engineers can conduct an end-to-end functional decomposition of an information system to identify mission-critical functions and components. The functional decomposition includes the identification of core organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and beyond the information system boundary. Information system components that allow for unmediated access to critical components or functions are considered critical due to the inherent vulnerabilities such components create. Criticality is assessed in terms of the impact of the function or component failure on the ability of the component to complete the organizational missions supported by the information system. A criticality analysis is performed whenever an architecture or design is being developed or modified, including upgrades.", "supplementalInfo": "12296 Supplemental Guidanc" }, { "requirementId": "12297", "requirementTextEnglish": "Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established", - "requirementText": "12297 Cybersecurity roles ", + "requirementText": "Роль і обов'язки з кібербезпеки для всієї робочої сили та сторонніх зацікавлених сторін (постачальників, клієнтів, партнерів) визначено", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, CP-2 Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Supplemental Guidance from NIST 800-53 Rev 4, PS-7 Supplemental Guidance: Third-party providers include, for example, service bureaus, contractors, and other organizations providing information system development, information technology services, outsourced applications, and network and security management. Organizations explicitly include personnel security requirements in acquisition-related documents. Third-party providers may have personnel working at organizational facilities with credentials, badges, or information system privileges issued by organizations. Notifications of third-party personnel changes ensure appropriate termination of privileges and credentials. Organizations define the transfers and terminations deemed reportable by security-related characteristics that include, for example, functions, roles, and nature of credentials/privileges associated with individuals transferred or terminated. Supplemental Guidance from NIST 800-53 Rev 4, PM-11 Supplemental Guidance: Information protection needs are technology-independent, required capabilities to counter threats to organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality, integrity, or availability). Information protection needs are derived from the mission/business needs defined by the organization, the mission/business processes selected to meet the stated needs, and the organizational risk management strategy. Information protection needs determine the required security controls for the organization and the associated information systems supporting the mission/business processes. Inherent in defining an organization’s information protection needs is an understanding of the level of adverse impact that could result if a compromise of information occurs. The security categorization process is used to make such potential impact determinations. Mission/business process definitions and associated information protection requirements are documented by the organization in accordance with organizational policy and procedure.", "supplementalInfo": "12297 Supplemental Guidanc" }, { "requirementId": "12298", "requirementTextEnglish": "The organization's role in the supply chain is identified and communicated", - "requirementText": "12298 The organization's r", + "requirementText": "Роль організації в ланцюжку поставок визначено та повідомлено", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, CP-2 Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Supplemental Guidance from NIST 800-53 Rev 4, SA-12 Supplemental Guidance: Information systems (including system components that compose those systems) need to be protected throughout the system development life cycle (i.e., during design, development, manufacturing, packaging, assembly, distribution, system integration, operations, maintenance, and retirement). Protection of organizational information systems is accomplished through threat awareness, by the identification, management, and reduction of vulnerabilities at each phase of the life cycle and the use of complementary, mutually reinforcing strategies to respond to risk. Organizations consider implementing a standardized process to address supply chain risk with respect to information systems and system components, and to educate the acquisition workforce on threats, risk, and required security controls. Organizations use the acquisition/procurement processes to require supply chain entities to implement necessary security safeguards to: (i) reduce the likelihood of unauthorized modifications at each stage in the supply chain; and (ii) protect information systems and information system components, prior to taking delivery of such systems/components. This control enhancement also applies to information system services. Security safeguards include, for example: (i) security controls for development systems, development facilities, and external connections to development systems; (ii) vetting development personnel; and (iii) use of tamper-evident packaging during shipping/warehousing. Methods for reviewing and protecting development plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements.", "supplementalInfo": "12298 Supplemental Guidanc" }, { "requirementId": "12299", "requirementTextEnglish": "The organization's place in critical infrastructure and its industry sector is identified and communicated", - "requirementText": "12299 The organization's p", + "requirementText": "Місце організації в критично важливій інфраструктурі та її секторі промисловості визначено та повідомлено", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-8 Supplemental Guidance: Protection strategies are based on the prioritization of critical assets and resources. The requirement and guidance for defining critical infrastructure and key resources and for preparing an associated critical infrastructure protection plan are found in applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.", "supplementalInfo": "12299 Supplemental Guidanc" }, { "requirementId": "12300", "requirementTextEnglish": "Priorities for organizational mission, objectives, and activities are established and communicated", - "requirementText": "12300 Priorities for organ", + "requirementText": "Пріоритети організаційної місії, цілей та заходів встановлено та повідомлено", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-11 Supplemental Guidance: Information protection needs are technology-independent, required capabilities to counter threats to organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality, integrity, or availability). Information protection needs are derived from the mission/business needs defined by the organization, the mission/business processes selected to meet the stated needs, and the organizational risk management strategy. Information protection needs determine the required security controls for the organization and the associated information systems supporting the mission/business processes. Inherent in defining an organization’s information protection needs is an understanding of the level of adverse impact that could result if a compromise of information occurs. The security categorization process is used to make such potential impact determinations. Mission/business process definitions and associated information protection requirements are documented by the organization in accordance with organizational policy and procedure. Supplemental Guidance from NIST 800-53 Rev 4, SA-14 Supplemental Guidance: Criticality analysis is a key tenet of supply chain risk management and informs the prioritization of supply chain protection activities such as attack surface reduction, use of all-source intelligence, and tailored acquisition strategies. Information system engineers can conduct an end-to-end functional decomposition of an information system to identify mission-critical functions and components. The functional decomposition includes the identification of core organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and beyond the information system boundary. Information system components that allow for unmediated access to critical components or functions are considered critical due to the inherent vulnerabilities such components create. Criticality is assessed in terms of the impact of the function or component failure on the ability of the component to complete the organizational missions supported by the information system. A criticality analysis is performed whenever an architecture or design is being developed or modified, including upgrades.", "supplementalInfo": "12300 Supplemental Guidanc" }, { "requirementId": "12301", "requirementTextEnglish": "Dependencies and critical functions for delivery of critical services are established", - "requirementText": "12301 Dependencies and cri", + "requirementText": "Залежності та критично важливі функції для надання критично важливих послуг встановлено", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, CP-8 Supplemental Guidance: This control applies to telecommunications services (data and voice) for primary and alternate processing and storage sites. Alternate telecommunications services reflect the continuity requirements in contingency plans to maintain essential missions/business functions despite the loss of primary telecommunications services. Organizations may specify different time periods for primary/alternate sites. Alternate telecommunications services include, for example, additional organizational or commercial ground-based circuits/lines or satellites in lieu of ground-based communications. Organizations consider factors such as availability, quality of service, and access when entering into alternate telecommunications agreements. Supplemental Guidance from NIST 800-53 Rev 4, PE-9 Supplemental Guidance: Organizations determine the types of protection necessary for power equipment and cabling employed at different locations both internal and external to organizational facilities and environments of operation. This includes, for example, generators and power cabling outside of buildings, internal cabling and uninterruptable power sources within an office or data center, and power sources for self-contained entities such as vehicles and satellites. Supplemental Guidance from NIST 800-53 Rev 4, PM-8 Supplemental Guidance: Protection strategies are based on the prioritization of critical assets and resources. The requirement and guidance for defining critical infrastructure and key resources and for preparing an associated critical infrastructure protection plan are found in applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Supplemental Guidance from NIST 800-53 Rev 4, SA-14 Supplemental Guidance: Criticality analysis is a key tenet of supply chain risk management and informs the prioritization of supply chain protection activities such as attack surface reduction, use of all-source intelligence, and tailored acquisition strategies. Information system engineers can conduct an end-to-end functional decomposition of an information system to identify mission-critical functions and components. The functional decomposition includes the identification of core organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and beyond the information system boundary. Information system components that allow for unmediated access to critical components or functions are considered critical due to the inherent vulnerabilities such components create. Criticality is assessed in terms of the impact of the function or component failure on the ability of the component to complete the organizational missions supported by the information system. A criticality analysis is performed whenever an architecture or design is being developed or modified, including upgrades.", "supplementalInfo": "12301 Supplemental Guidanc" }, { "requirementId": "12302", "requirementTextEnglish": "Resilience requirements to support delivery of critical services are established", - "requirementText": "12302 Resilience requireme", + "requirementText": "Вимоги стійкості для підтримки надання критично важливих послуг для всіх операційних станів (наприклад, під примусом/ атакою, під час відновлення, звичайних операцій) встановлено", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, CP-2 Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Supplemental Guidance from NIST 800-53 Rev 4, CP-11 Supplemental Guidance: Contingency plans and the associated training and testing for those plans, incorporate an alternate communications protocol capability as part of increasing the resilience of organizational information systems. Alternate communications protocols include, for example, switching from Transmission Control Protocol/Internet Protocol (TCP/IP) Version 4 to TCP/IP Version 6. Switching communications protocols may affect software applications and therefore, the potential side effects of introducing alternate communications protocols are analyzed prior to implementation. Supplemental Guidance from NIST 800-53 Rev 4, SA-14 Supplemental Guidance: Criticality analysis is a key tenet of supply chain risk management and informs the prioritization of supply chain protection activities such as attack surface reduction, use of all-source intelligence, and tailored acquisition strategies. Information system engineers can conduct an end-to-end functional decomposition of an information system to identify mission-critical functions and components. The functional decomposition includes the identification of core organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and beyond the information system boundary. Information system components that allow for unmediated access to critical components or functions are considered critical due to the inherent vulnerabilities such components create. Criticality is assessed in terms of the impact of the function or component failure on the ability of the component to complete the organizational missions supported by the information system. A criticality analysis is performed whenever an architecture or design is being developed or modified, including upgrades.", "supplementalInfo": "12302 Supplemental Guidanc" }, { "requirementId": "12303", "requirementTextEnglish": "Organizational information security policy is established", - "requirementText": "12303 Organizational infor", + "requirementText": "Організаційну політику з кібербезпеки встановлено та повідомлено", "supplementalInfoEnglish": "Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, AC family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, AU family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, CA family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, CM family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, CP family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, IA family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, SA family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, SC family. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the NIST 800-53 Rev 4, SI family.", "supplementalInfo": "12303 Supplemental Guidanc" }, { "requirementId": "12304", "requirementTextEnglish": "Information security roles & responsibilities are coordinated and aligned with internal roles and external partners", - "requirementText": "12304 Information security", + "requirementText": "Ролі та обов'язки з кібербезпеки координуються та узгоджуються з внутрішніми ролями та зовнішніми партнерами", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-1 Supplemental Guidance: Information security program plans can be represented in single documents or compilations of documents at the discretion of organizations. The plans document the program management controls and organization-defined common controls. Information security program plans provide sufficient information about the program management controls/common controls (including specification of parameters for any assignment and selection statements either explicitly or by reference) to enable implementations that are unambiguously compliant with the intent of the plans and a determination of the risk to be incurred if the plans are implemented as intended. The security plans for individual information systems and the organization-wide information security program plan together, provide complete coverage for all security controls employed within the organization. Common controls are documented in an appendix to the organization’s information security program plan unless the controls are included in a separate security plan for an information system (e.g., security controls employed as part of an intrusion detection system providing organization-wide boundary protection inherited by one or more organizational information systems). The organization-wide information security program plan will indicate which separate security plans contain descriptions of common controls. Organizations have the flexibility to describe common controls in a single document or in multiple documents. In the case of multiple documents, the documents describing common controls are included as attachments to the information security program plan. If the information security program plan contains multiple documents, the organization specifies in each document the organizational official or officials responsible for the development, implementation, assessment, authorization, and monitoring of the respective common controls. For example, the organization may require that the Facilities Management Office develop, implement, assess, authorize, and continuously monitor common physical and environmental protection controls from the PE family when such controls are not associated with a particular information system but instead, support multiple information systems. Supplemental Guidance from NIST 800-53 Rev 4, PS-7 Supplemental Guidance: Third-party providers include, for example, service bureaus, contractors, and other organizations providing information system development, information technology services, outsourced applications, and network and security management. Organizations explicitly include personnel security requirements in acquisition-related documents. Third-party providers may have personnel working at organizational facilities with credentials, badges, or information system privileges issued by organizations. Notifications of third-party personnel changes ensure appropriate termination of privileges and credentials. Organizations define the transfers and terminations deemed reportable by security-related characteristics that include, for example, functions, roles, and nature of credentials/privileges associated with individuals transferred or terminated.", "supplementalInfo": "12304 Supplemental Guidanc" }, { "requirementId": "12305", "requirementTextEnglish": "Legal and regulatory requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed", - "requirementText": "12305 Legal and regulatory", + "requirementText": "Законодавчі та нормативні вимоги щодо кібербезпеки, включаючи зобов'язання щодо конфіденційності та громадянських свобод, розуміються, та управління ними здійснюється", "supplementalInfoEnglish": "Supplemental Guidance: Organizations take reasonable steps to confirm the accuracy and relevance of PII. Such steps may include, for example, editing and validating addresses as they are collected or entered into information systems using automated address verification look-up application programming interfaces (API). The types of measures taken to protect data quality are based on the nature and context of the PII, how it is to be used, and how it was obtained. Measures taken to validate the accuracy of PII that is used to make determinations about the rights, benefits, or privileges of individuals under federal programs may be more comprehensive than those used to validate less sensitive PII. Additional steps may be necessary to validate PII that is obtained from sources other than individuals or the authorized representatives of individuals. When PII is of a sufficiently sensitive nature (e.g., when it is used for annual reconfirmation of a taxpayer’s income for a recurring benefit), organizations incorporate mechanisms into information systems and develop corresponding procedures for how frequently, and by what method, the information is to be updated. Supplemental Guidance: Organizations take appropriate steps to ensure that the collection of PII is consistent with a purpose authorized by law or regulation. The minimum set of PII elements required to support a specific organization business process may be a subset of the PII the organization is authorized to collect. Program officials consult with the Senior Agency Official for Privacy (SAOP)/Chief Privacy Officer (CPO) and legal counsel to identify the minimum PII elements required by the information system or activity to accomplish the legally authorized purpose. Organizations can further reduce their privacy and security risks by also reducing their inventory of PII, where appropriate. OMB Memorandum 07-16 requires organizations to conduct both an initial review and subsequent reviews of their holdings of all PII and ensure, to the maximum extent practicable, that such holdings are accurate, relevant, timely, and complete. Organizations are also directed by OMB to reduce their holdings to the minimum necessary for the proper performance of a documented organizational business purpose. OMB Memorandum 07-16 requires organizations to develop and publicize, either through a notice in the Federal Register or on their websites, a schedule for periodic reviews of their holdings to supplement the initial review. Organizations coordinate with their federal records officers to ensure that reductions in organizational holdings of PII are consistent with NARA retention schedules. By performing periodic evaluations, organizations reduce risk, ensure that they are collecting only the data specified in the notice, and ensure that the data collected is still relevant and necessary for the purpose(s) specified in the notice. Supplemental Guidance: Consent is fundamental to the participation of individuals in the decision-making process regarding the collection and use of their PII and the use of technologies that may increase risk to personal privacy. To obtain consent, organizations provide individuals appropriate notice of the purposes of the PII collection or technology use and a means for individuals to consent to the activity. Organizations tailor the public notice and consent mechanisms to meet operational needs. Organizations achieve awareness and consent, for example, through updated public notices. Organizations may obtain consent through opt-in, opt-out, or implied consent. Opt-in consent is the preferred method, but it is not always feasible. Opt-in requires that individuals take affirmative action to allow organizations to collect or use PII. For example, opt-in consent may require an individual to click a radio button on a website, or sign a document providing consent. In contrast, opt-out requires individuals to take action to prevent the new or continued collection or use of such PII. For example, the Federal Trade Commission’s Do-Not-Call Registry allows individuals to opt-out of receiving unsolicited telemarketing calls by requesting to be added to a list. Implied consent is the least preferred method and should be used in limited circumstances. Implied consent occurs where individuals’ behavior or failure to object indicates agreement with the collection or use of PII (e.g., by entering and remaining in a building where notice has been posted that security cameras are in use, the individual implies consent to the video recording). Depending upon the nature of the program or information system, it may be appropriate to allow individuals to limit the types of PII they provide and subsequent uses of that PII. Organizational consent mechanisms include a discussion of the consequences to individuals of failure to provide PII. Consequences can vary from organization to organization. Supplemental Guidance: Effective notice, by virtue of its clarity, readability, and comprehensiveness, enables individuals to understand how an organization uses PII generally and, where appropriate, to make an informed decision prior to providing PII to an organization. Effective notice also demonstrates the privacy considerations that the organization has addressed in implementing its information practices. The organization may provide general public notice through a variety of means, as required by law or policy, including System of Records Notices (SORNs), Privacy Impact Assessments (PIAs), or in a website privacy policy. As required by the Privacy Act, the organization also provides direct notice to individuals via Privacy Act Statements on the paper and electronic forms it uses to collect PII, or on separate forms that can be retained by the individuals. The organization Senior Agency Official for Privacy (SAOP)/Chief Privacy Officer (CPO) is responsible for the content of the organization’s public notices, in consultation with legal counsel and relevant program managers. The public notice requirement in this control is satisfied by an organization’s compliance with the public notice provisions of the Privacy Act, the E-Government Act’s PIA requirement, with OMB guidance related to federal agency privacy notices, and, where applicable, with policy pertaining to participation in the Information Sharing Environment (ISE).124 Changing PII practice or policy without prior notice is disfavored and should only be undertaken in consultation with the SAOP/CPO and counsel. Supplemental Guidance: Organizations take steps to ensure that they use PII only for legally authorized purposes and in a manner compatible with uses identified in the Privacy Act and/or in public notices. These steps include monitoring and auditing organizational use of PII and training organizational personnel on the authorized uses of PII. With guidance from the Senior Agency Official for Privacy (SAOP)/Chief Privacy Officer (CPO) and where appropriate, legal counsel, organizations document processes and procedures for evaluating any proposed new uses of PII to assess whether they fall within the scope of the organizational authorities. Where appropriate, organizations obtain consent from individuals for the new use(s) of PII.", "supplementalInfo": "12305 Supplemental Guidanc" }, { "requirementId": "12306", "requirementTextEnglish": "Governance and risk management processes address cybersecurity risks", - "requirementText": "12306 Governance and risk ", + "requirementText": "Процеси врядування та безпеки управління ризиками усувають ризики для кібербезпеки", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-9 Supplemental Guidance: An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process for consistently evaluating risk across the organization with respect to the organization’s risk tolerance, and approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent, organization-wide application of the risk management strategy. The organization-wide risk management strategy can be informed by risk-related inputs from other sources both internal and external to the organization to ensure the strategy is both broad-based and comprehensive. Supplemental Guidance from NIST 800-53 Rev 4, PM-11 Supplemental Guidance: Information protection needs are technology-independent, required capabilities to counter threats to organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality, integrity, or availability). Information protection needs are derived from the mission/business needs defined by the organization, the mission/business processes selected to meet the stated needs, and the organizational risk management strategy. Information protection needs determine the required security controls for the organization and the associated information systems supporting the mission/business processes. Inherent in defining an organization’s information protection needs is an understanding of the level of adverse impact that could result if a compromise of information occurs. The security categorization process is used to make such potential impact determinations. Mission/business process definitions and associated information protection requirements are documented by the organization in accordance with organizational policy and procedure.", "supplementalInfo": "12306 Supplemental Guidanc" }, { "requirementId": "12307", "requirementTextEnglish": "Asset vulnerabilities are identified and documented", - "requirementText": "12307 Asset vulnerabilitie", + "requirementText": "Вразливості об'єктів визначені та задокументовані", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, CA-2 Supplemental Guidance: Organizations assess security controls in organizational information systems and the environments in which those systems operate as part of: (i) initial and ongoing security authorizations; (ii) FISMA annual assessments; (iii) continuous monitoring; and (iv) system development life cycle activities. Security assessments: (i) ensure that information security is built into organizational information systems; (ii) identify weaknesses and deficiencies early in the development process; (iii) provide essential information needed to make risk-based decisions as part of security authorization processes; and (iv) ensure compliance to vulnerability mitigation procedures. Assessments are conducted on the implemented security controls from Appendix F (main catalog) and Appendix G (Program Management controls) as documented in System Security Plans and Information Security Program Plans. Organizations can use other types of assessment activities such as vulnerability scanning and system monitoring to maintain the security posture of information systems during the entire life cycle. Security assessment reports document assessment results in sufficient detail as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements. The FISMA requirement for assessing security controls at least annually does not require additional assessment activities to those activities already in place in organizational security authorization processes. Security assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted. For example, assessments conducted in support of security authorization decisions are provided to authorizing officials or authorizing official designated representatives. To satisfy annual assessment requirements, organizations can use assessment results from the following sources: (i) initial or ongoing information system authorizations; (ii) continuous monitoring; or (iii) system development life cycle activities. Organizations ensure that security assessment results are current, relevant to the determination of security control effectiveness, and obtained with the appropriate level of assessor independence. Existing security control assessment results can be reused to the extent that the results are still valid and can also be supplemented with additional assessments as needed. Subsequent to initial authorizations and in accordance with OMB policy, organizations assess security controls during continuous monitoring. Organizations establish the frequency for ongoing security control assessments in accordance with organizational continuous monitoring strategies. Information Assurance Vulnerability Alerts provide useful examples of vulnerability mitigation procedures. External audits (e.g., audits by external entities such as regulatory agencies) are outside the scope of this control. Supplemental Guidance from NIST 800-53 Rev 4, CA-7 Supplemental Guidance: Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess/analyze security controls and information security-related risks at a frequency sufficient to support organizational risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations. Continuous monitoring programs also allow organizations to maintain the security authorizations of information systems and common controls over time in highly dynamic environments of operation with changing mission/business needs, threats, vulnerabilities, and technologies. Having access to security-related information on a continuing basis through reports/dashboards gives organizational officials the capability to make more effective and timely risk management decisions, including ongoing security authorization decisions. Automation supports more frequent updates to security authorization packages, hardware/software/firmware inventories, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of information systems. Supplemental Guidance from NIST 800-53 Rev 4, CA-8 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. Supplemental Guidance from NIST 800-53 Rev 4, RA-3 Supplemental Guidance: Clearly defined authorization boundaries are a prerequisite for effective risk assessments. Risk assessments take into account threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation based on the operation and use of information systems. Risk assessments also take into account risk from external parties (e.g., service providers, contractors operating information systems on behalf of the organization, individuals accessing organizational information systems, outsourcing entities). In accordance with OMB policy and related E-authentication initiatives, authentication of public users accessing federal information systems may also be required to protect non-public or privacy-related information. As such, organizational assessments of risk also address public access to federal information systems. Risk assessments (either formal or informal) can be conducted at all three tiers in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any phase in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including categorization, security control selection, security control implementation, security control assessment, information system authorization, and security control monitoring. RA-3 is noteworthy in that the control must be partially implemented prior to the implementation of other controls in order to complete the first two steps in the Risk Management Framework. Risk assessments can play an important role in security control selection processes, particularly during the application of tailoring guidance, which includes security control supplementation. Supplemental Guidance from NIST 800-53 Rev 4, RA-5 Supplemental Guidance: Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan. Organizations also consider using tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS). Supplemental Guidance from NIST 800-53 Rev 4, SA-5 Supplemental Guidance: This control helps organizational personnel understand the implementation and operation of security controls associated with information systems, system components, and information system services. Organizations consider establishing specific measures to determine the quality/completeness of the content provided. The inability to obtain needed documentation may occur, for example, due to the age of the information system/component or lack of support from developers and contractors. In those situations, organizations may need to recreate selected documentation if such documentation is essential to the effective implementation or operation of security controls. The level of protection provided for selected information system, component, or service documentation is commensurate with the security category or classification of the system. For example, documentation associated with a key DoD weapons system or command and control system would typically require a higher level of protection than a routine administrative system. Documentation that addresses information system vulnerabilities may also require an increased level of protection. Secure operation of the information system, includes, for example, initially starting the system and resuming secure system operation after any lapse in system operation. Supplemental Guidance from NIST 800-53 Rev 4, SA-11 Supplemental Guidance: Developmental security testing/evaluation occurs at all post-design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Supplemental Guidance from NIST 800-53 Rev 4, SI-2 Supplemental Guidance: Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures. Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified. Flaw remediation actions that can be tracked and verified include, for example, determining whether organizations follow US-CERT guidance and Information Assurance Vulnerability Alerts. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types. Organizations determine the degree and type of testing needed for the specific type of flaw remediation activity under consideration and also the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software and/or firmware updates is not necessary or practical, for example, when implementing simple anti-virus signature updates. Organizations may also consider in testing decisions, whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Supplemental Guidance from NIST 800-53 Rev 4, SI-4 Supplemental Guidance: Information system monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system. Organizations can monitor information systems, for example, by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. Information system monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include, for example, selected perimeter locations and near server farms supporting critical applications, with such devices typically being employed at the managed interfaces associated with controls SC-7 and AC-17. Einstein network monitoring devices from the Department of Homeland Security can also be included as monitoring devices. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of information systems to support such objectives. Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. Information system monitoring is an integral part of organizational continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Supplemental Guidance from NIST 800-53 Rev 4, SI-5 Supplemental Guidance: The United States Computer Emergency Readiness Team (US-CERT) generates security alerts and advisories to maintain situational awareness across the federal government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance to security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include, for example, external mission/business partners, supply chain partners, external service providers, and other peer/supporting organizations.", "supplementalInfo": "12307 Supplemental Guidanc" }, { "requirementId": "12308", "requirementTextEnglish": "Threat and vulnerability information is received from information sharing forums and sources", - "requirementText": "12308 Threat and vulnerabi", + "requirementText": "Розвідувальна інформація про кібер-загрози отримується з форумів та джерел обміну інформацією", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-15 Supplemental Guidance: Ongoing contact with security groups and associations is of paramount importance in an environment of rapidly changing technologies and threats. Security groups and associations include, for example, special interest groups, forums, professional associations, news groups, and/or peer groups of security professionals in similar organizations. Organizations select groups and associations based on organizational missions/business functions. Organizations share threat, vulnerability, and incident information consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Supplemental Guidance from NIST 800-53 Rev 4, PM-16 Supplemental Guidance: Because of the constantly changing and increasing sophistication of adversaries, especially the advanced persistent threat (APT), it is becoming more likely that adversaries may successfully breach or compromise organizational information systems. One of the best techniques to address this concern is for organizations to share threat information. This can include, for example, sharing threat events (i.e., tactics, techniques, and procedures) that organizations have experienced, mitigations that organizations have found are effective against certain types of threats, threat intelligence (i.e., indications and warnings about threats that are likely to occur). Threat information sharing may be bilateral (e.g., government-commercial cooperatives, government-government cooperatives), or multilateral (e.g., organizations taking part in threat-sharing consortia). Threat information may be highly sensitive requiring special agreements and protection, or less sensitive and freely shared. Supplemental Guidance from NIST 800-53 Rev 4, SI-5 Supplemental Guidance: The United States Computer Emergency Readiness Team (US-CERT) generates security alerts and advisories to maintain situational awareness across the federal government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance to security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include, for example, external mission/business partners, supply chain partners, external service providers, and other peer/supporting organizations.", "supplementalInfo": "12308 Supplemental Guidanc" }, { "requirementId": "12309", "requirementTextEnglish": "Threats, both internal and external, are identified and documented", - "requirementText": "12309 Threats, both intern", + "requirementText": "Загрози, як внутрішні, так і зовнішні, ідентифіковано та документовано", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-16 Supplemental Guidance: Because of the constantly changing and increasing sophistication of adversaries, especially the advanced persistent threat (APT), it is becoming more likely that adversaries may successfully breach or compromise organizational information systems. One of the best techniques to address this concern is for organizations to share threat information. This can include, for example, sharing threat events (i.e., tactics, techniques, and procedures) that organizations have experienced, mitigations that organizations have found are effective against certain types of threats, threat intelligence (i.e., indications and warnings about threats that are likely to occur). Threat information sharing may be bilateral (e.g., government-commercial cooperatives, government-government cooperatives), or multilateral (e.g., organizations taking part in threat-sharing consortia). Threat information may be highly sensitive requiring special agreements and protection, or less sensitive and freely shared. Supplemental Guidance from NIST 800-53 Rev 4, SI-5 Supplemental Guidance: The United States Computer Emergency Readiness Team (US-CERT) generates security alerts and advisories to maintain situational awareness across the federal government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance to security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include, for example, external mission/business partners, supply chain partners, external service providers, and other peer/supporting organizations. Supplemental Guidance from NIST 800-53 Rev 4, SI-5 Supplemental Guidance: The United States Computer Emergency Readiness Team (US-CERT) generates security alerts and advisories to maintain situational awareness across the federal government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance to security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include, for example, external mission/business partners, supply chain partners, external service providers, and other peer/supporting organizations. Supplemental Guidance from NIST 800-53 Rev 4, PM-12 Supplemental Guidance: Organizations handling classified information are required, under Executive Order 13587 and the National Policy on Insider Threat, to establish insider threat programs. The standards and guidelines that apply to insider threat programs in classified environments can also be employed effectively to improve the security of Controlled Unclassified Information in non-national security systems. Insider threat programs include security controls to detect and prevent malicious insider activity through the centralized integration and analysis of both technical and non-technical information to identify potential insider threat concerns. A senior organizational official is designated by the department/agency head as the responsible individual to implement and provide oversight for the program. In addition to the centralized integration and analysis capability, insider threat programs as a minimum, prepare department/agency insider threat policies and implementation plans, conduct host-based user monitoring of individual employee activities on government-owned classified computers, provide insider threat awareness training to employees, receive access to information from all offices within the department/agency (e.g., human resources, legal, physical security, personnel security, information technology, information system security, and law enforcement) for insider threat analysis, and conduct self-assessments of department/agency insider threat posture. Insider threat programs can leverage the existence of incident handling teams organizations may already have in place, such as computer security incident response teams. Human resources records are especially important in this effort, as there is compelling evidence to show that some types of insider crimes are often preceded by non-technical behaviors in the workplace (e.g., ongoing patterns of disgruntled behavior and conflicts with coworkers and other colleagues). These precursors can better inform and guide organizational officials in more focused, targeted monitoring efforts. The participation of a legal team is important to ensure that all monitoring activities are performed in accordance with appropriate legislation, directives, regulations, policies, standards, and guidelines. Supplemental Guidance from NIST 800-53 Rev 4, PM-16 Supplemental Guidance: Because of the constantly changing and increasing sophistication of adversaries, especially the advanced persistent threat (APT), it is becoming more likely that adversaries may successfully breach or compromise organizational information systems. One of the best techniques to address this concern is for organizations to share threat information. This can include, for example, sharing threat events (i.e., tactics, techniques, and procedures) that organizations have experienced, mitigations that organizations have found are effective against certain types of threats, threat intelligence (i.e., indications and warnings about threats that are likely to occur). Threat information sharing may be bilateral (e.g., government-commercial cooperatives, government-government cooperatives), or multilateral (e.g., organizations taking part in threat-sharing consortia). Threat information may be highly sensitive requiring special agreements and protection, or less sensitive and freely shared.", "supplementalInfo": "12309 Supplemental Guidanc" }, { "requirementId": "12310", "requirementTextEnglish": "Potential business impacts and likelihoods are identified", - "requirementText": "12310 Potential business i", + "requirementText": "Визначено потенційні ділові наслідки та ймовірності", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, RA-2 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. Supplemental Guidance from NIST 800-53 Rev 4, RA-3 Supplemental Guidance: Clearly defined authorization boundaries are a prerequisite for effective risk assessments. Risk assessments take into account threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation based on the operation and use of information systems. Risk assessments also take into account risk from external parties (e.g., service providers, contractors operating information systems on behalf of the organization, individuals accessing organizational information systems, outsourcing entities). In accordance with OMB policy and related E-authentication initiatives, authentication of public users accessing federal information systems may also be required to protect nonpublic or privacy-related information. As such, organizational assessments of risk also address public access to federal information systems. Risk assessments (either formal or informal) can be conducted at all three tiers in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any phase in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including categorization, security control selection, security control implementation, security control assessment, information system authorization, and security control monitoring. RA-3 is noteworthy in that the control must be partially implemented prior to the implementation of other controls in order to complete the first two steps in the Risk Management Framework. Risk assessments can play an important role in security control selection processes, particularly during the application of tailoring guidance, which includes security control supplementation. Supplemental Guidance from NIST 800-53 Rev 4, PM-9 Supplemental Guidance: An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process for consistently evaluating risk across the organization with respect to the organization’s risk tolerance, and approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent, organization-wide application of the risk management strategy. The organization-wide risk management strategy can be informed by risk-related inputs from other sources both internal and external to the organization to ensure the strategy is both broad-based and comprehensive. Supplemental Guidance from NIST 800-53 Rev 4, PM-11 Supplemental Guidance: Information protection needs are technology-independent, required capabilities to counter threats to organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality, integrity, or availability). Information protection needs are derived from the mission/business needs defined by the organization, the mission/business processes selected to meet the stated needs, and the organizational risk management strategy. Information protection needs determine the required security controls for the organization and the associated information systems supporting the mission/business processes. Inherent in defining an organization’s information protection needs is an understanding of the level of adverse impact that could result if a compromise of information occurs. The security categorization process is used to make such potential impact determinations. Mission/business process definitions and associated information protection requirements are documented by the organization in accordance with organizational policy and procedure. Supplemental Guidance from NIST 800-53 Rev 4, SA-14 Supplemental Guidance: Criticality analysis is a key tenet of supply chain risk management and informs the prioritization of supply chain protection activities such as attack surface reduction, use of all-source intelligence, and tailored acquisition strategies. Information system engineers can conduct an end-to-end functional decomposition of an information system to identify mission-critical functions and components. The functional decomposition includes the identification of core organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and beyond the information system boundary. Information system components that allow for unmediated access to critical components or functions are considered critical due to the inherent vulnerabilities such components create. Criticality is assessed in terms of the impact of the function or component failure on the ability of the component to complete the organizational missions supported by the information system. A criticality analysis is performed whenever an architecture or design is being developed or modified, including upgrades.", "supplementalInfo": "12310 Supplemental Guidanc" }, { "requirementId": "12311", "requirementTextEnglish": "Threats, vulnerabilities, likelihoods, and impacts are used to determine risk", - "requirementText": "12311 Threats, vulnerabili", + "requirementText": "Для визначення ризику використовуються загрози, вразливості, вірогідність та наслідки", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, RA-2 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. Supplemental Guidance from NIST 800-53 Rev 4, RA-3 Supplemental Guidance: Clearly defined authorization boundaries are a prerequisite for effective risk assessments. Risk assessments take into account threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation based on the operation and use of information systems. Risk assessments also take into account risk from external parties (e.g., service providers, contractors operating information systems on behalf of the organization, individuals accessing organizational information systems, outsourcing entities). In accordance with OMB policy and related E-authentication initiatives, authentication of public users accessing federal information systems may also be required to protect nonpublic or privacy-related information. As such, organizational assessments of risk also address public access to federal information systems. Risk assessments (either formal or informal) can be conducted at all three tiers in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any phase in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including categorization, security control selection, security control implementation, security control assessment, information system authorization, and security control monitoring. RA-3 is noteworthy in that the control must be partially implemented prior to the implementation of other controls in order to complete the first two steps in the Risk Management Framework. Risk assessments can play an important role in security control selection processes, particularly during the application of tailoring guidance, which includes security control supplementation. Supplemental Guidance from NIST 800-53 Rev 4, PM-16 Supplemental Guidance: Because of the constantly changing and increasing sophistication of adversaries, especially the advanced persistent threat (APT), it is becoming more likely that adversaries may successfully breach or compromise organizational information systems. One of the best techniques to address this concern is for organizations to share threat information. This can include, for example, sharing threat events (i.e., tactics, techniques, and procedures) that organizations have experienced, mitigations that organizations have found are effective against certain types of threats, threat intelligence (i.e., indications and warnings about threats that are likely to occur). Threat information sharing may be bilateral (e.g., government-commercial cooperatives, government-government cooperatives), or multilateral (e.g., organizations taking part in threat-sharing consortia). Threat information may be highly sensitive requiring special agreements and protection, or less sensitive and freely shared.", "supplementalInfo": "12311 Supplemental Guidanc" }, { "requirementId": "12312", "requirementTextEnglish": "Risk responses are identified and prioritized", - "requirementText": "12312 Risk responses are i", + "requirementText": "Реагування на ризик ідентифіковано та пріоритизовано", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-4 Supplemental Guidance: The plan of action and milestones is a key document in the information security program and is subject to federal reporting requirements established by OMB. With the increasing emphasis on organization-wide risk management across all three tiers in the risk management hierarchy (i.e., organization, mission/business process, and information system), organizations view plans of action and milestones from an organizational perspective, prioritizing risk response actions and ensuring consistency with the goals and objectives of the organization. Plan of action and milestones updates are based on findings from security control assessments and continuous monitoring activities. OMB FISMA reporting guidance contains instructions regarding organizational plans of action and milestones. Supplemental Guidance from NIST 800-53 Rev 4, PM-9 Supplemental Guidance: An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process for consistently evaluating risk across the organization with respect to the organization’s risk tolerance, and approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent, organization-wide application of the risk management strategy. The organization-wide risk management strategy can be informed by risk-related inputs from other sources both internal and external to the organization to ensure the strategy is both broad-based and comprehensive.", "supplementalInfo": "12312 Supplemental Guidanc" }, { "requirementId": "12313", "requirementTextEnglish": "Risk management processes are established, managed, and agreed to by organizational stakeholders", - "requirementText": "12313 Risk management proc", + "requirementText": "Процеси управління ризиками встановлені, керовані та узгоджені із зацікавленими сторонами організації", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-9 Supplemental Guidance: An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process for consistently evaluating risk across the organization with respect to the organization’s risk tolerance, and approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent, organization-wide application of the risk management strategy. The organization-wide risk management strategy can be informed by risk-related inputs from other sources both internal and external to the organization to ensure the strategy is both broad-based and comprehensive.", "supplementalInfo": "12313 Supplemental Guidanc" }, { "requirementId": "12314", "requirementTextEnglish": "Organizational risk tolerance is determined and clearly expressed", - "requirementText": "12314 Organizational risk ", + "requirementText": "Стійкість організації до ризику визначена та чітко виражена", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-9 Supplemental Guidance: An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process for consistently evaluating risk across the organization with respect to the organization’s risk tolerance, and approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent, organization-wide application of the risk management strategy. The organization-wide risk management strategy can be informed by risk-related inputs from other sources both internal and external to the organization to ensure the strategy is both broad-based and comprehensive.", "supplementalInfo": "12314 Supplemental Guidanc" }, { "requirementId": "12315", "requirementTextEnglish": "The organization's determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis", - "requirementText": "12315 The organization's d", + "requirementText": "Визначення організацією стійкості до ризику визначається її роллю у критично важливій інфраструктурі та аналізом конкретних ризиків, пов'язаних із сектором", "supplementalInfoEnglish": "Supplemental Guidance from NIST 800-53 Rev 4, PM-8 Supplemental Guidance: Protection strategies are based on the prioritization of critical assets and resources. The requirement and guidance for defining critical infrastructure and key resources and for preparing an associated critical infrastructure protection plan are found in applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Supplemental Guidance from NIST 800-53 Rev 4, PM-9 Supplemental Guidance: An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process for consistently evaluating risk across the organization with respect to the organization’s risk tolerance, and approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent, organization-wide application of the risk management strategy. The organization-wide risk management strategy can be informed by risk-related inputs from other sources both internal and external to the organization to ensure the strategy is both broad-based and comprehensive. Supplemental Guidance from NIST 800-53 Rev 4, PM-11 Supplemental Guidance: Information protection needs are technology-independent, required capabilities to counter threats to organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality, integrity, or availability). Information protection needs are derived from the mission/business needs defined by the organization, the mission/business processes selected to meet the stated needs, and the organizational risk management strategy. Information protection needs determine the required security controls for the organization and the associated information systems supporting the mission/business processes. Inherent in defining an organization’s information protection needs is an understanding of the level of adverse impact that could result if a compromise of information occurs. The security categorization process is used to make such potential impact determinations. Mission/business process definitions and associated information protection requirements are documented by the organization in accordance with organizational policy and procedure. Supplemental Guidance from NIST 800-53 Rev 4, SA-14 Supplemental Guidance: Criticality analysis is a key tenet of supply chain risk management and informs the prioritization of supply chain protection activities such as attack surface reduction, use of all-source intelligence, and tailored acquisition strategies. Information system engineers can conduct an end-to-end functional decomposition of an information system to identify mission-critical functions and components. The functional decomposition includes the identification of core organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and beyond the information system boundary. Information system components that allow for unmediated access to critical components or functions are considered critical due to the inherent vulnerabilities such components create. Criticality is assessed in terms of the impact of the function or component failure on the ability of the component to complete the organizational missions supported by the information system. A criticality analysis is performed whenever an architecture or design is being developed or modified, including upgrades.", "supplementalInfo": "12315 Supplemental Guidanc" }, @@ -689,35 +689,35 @@ { "requirementId": "28188", "requirementTextEnglish": "Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders", - "requirementText": "28188 Cyber supply chain r", + "requirementText": "Процеси управління кібер- ризиками для ланцюжків поставок визначено, встановлено, оцінено, керовано та узгоджено з зацікавленими сторонами організації", "supplementalInfoEnglish": "Firewalls and routers are key components of the architecture that controls entry to and exit from the network. These devices are software or hardware devices that block unwanted access and manage authorized access into and out of the network. Configuration standards and procedures will help to ensure that the organization's first line of defense in the protection of its data remains strong.", "supplementalInfo": "28188 Firewalls and router" }, { "requirementId": "28189", "requirementTextEnglish": "Suppliers and third party partners of information systems, components, and services are identified, prioritized, and assessed using a cyber supply chain risk assessment process", - "requirementText": "28189 Suppliers and third ", + "requirementText": "Постачальники та сторонні партнери інформаційних систем, компонентів та послуг ідентифіковані, пріоритизовані та оцінeні за допомогою процесу оцінювання кібер-ризику для ланцюжків поставок", "supplementalInfoEnglish": "", "supplementalInfo": "28189 " }, { "requirementId": "28190", "requirementTextEnglish": "Contracts with suppliers and third-party partners are used to implement appropriate measures designed to meet the objectives of an organization’s cybersecurity program and Cyber Supply Chain Risk Management Plan.", - "requirementText": "28190 Contracts with suppl", + "requirementText": "Контракти з постачальниками та сторонніми партнерами використовуються для здійснення відповідних заходів, спрямованих на досягнення цілей програми кібербезпеки організації та Плану управління кібер-ризиками ланцюжків поставок", "supplementalInfoEnglish": "", "supplementalInfo": "28190 " }, { "requirementId": "28191", "requirementTextEnglish": "Suppliers and third-party partners are routinely assessed using audits, test results, or other forms of evaluations to confirm they are meeting their contractual obligations.", - "requirementText": "28191 Suppliers and third-", + "requirementText": "Контракти з постачальниками та сторонніми партнерами використовуються для здійснення відповідних заходів, спрямованих на досягнення цілей програми кібербезпеки організації та Плану управління кібер-ризиками ланцюжків поставокПостачальники та сторонні партнери регулярно оцінюються за допомогою аудитів, результатів тестів або інших форм оцінок, щоб підтвердити, що вони виконують свої договірні зобов'язання.", "supplementalInfoEnglish": "", "supplementalInfo": "28191 " }, { "requirementId": "28192", "requirementTextEnglish": "Response and recovery planning and testing are conducted with suppliers and third-party providers", - "requirementText": "28192 Response and recover", + "requirementText": "Планування та перевірка реагування та відновлення проводяться з постачальниками та сторонніми провайдерами", "supplementalInfoEnglish": "", "supplementalInfo": "28192 " }, diff --git a/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/QUESTION_GROUP_HEADING.json b/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/QUESTION_GROUP_HEADING.json index 7294ab964a..5e8d35cea8 100644 --- a/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/QUESTION_GROUP_HEADING.json +++ b/CSETWebApi/CSETWeb_Api/CSETWebCore.Business/App_Data/LanguagePacks/UK/QUESTION_GROUP_HEADING.json @@ -226,15 +226,15 @@ }, { "key": "58", - "value": "[UK]Detect" + "value": "Виявлення" }, { "key": "59", - "value": "[UK]Identify" + "value": "Ідентифікація" }, { "key": "60", - "value": "[UK]Protect" + "value": "Захист" }, { "key": "61", @@ -242,7 +242,7 @@ }, { "key": "62", - "value": "[UK]Respond" + "value": "Реагування" }, { "key": "63", @@ -310,7 +310,7 @@ }, { "key": "80", - "value": "[UK]Recover" + "value": "Відновлення" }, { "key": "81", diff --git a/CSETWebApi/CSETWeb_Api/CSETWebCore.Helpers/TranslationOverlay.cs b/CSETWebApi/CSETWeb_Api/CSETWebCore.Helpers/TranslationOverlay.cs index f2db32e760..c09f51a3a4 100644 --- a/CSETWebApi/CSETWeb_Api/CSETWebCore.Helpers/TranslationOverlay.cs +++ b/CSETWebApi/CSETWeb_Api/CSETWebCore.Helpers/TranslationOverlay.cs @@ -76,6 +76,7 @@ public Model.Question.KeyValuePair GetValue(string collection, string key, strin { GenericTranslation langPack = null; + // trying to get out cheaply and not waste time looking up English if (lang == "en") { return null; diff --git a/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/ChartData.cs b/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/ChartData.cs index c225d1e2a1..bcc0445d9b 100644 --- a/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/ChartData.cs +++ b/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/ChartData.cs @@ -21,17 +21,19 @@ public class ChartData public string backgroundColor { get; set; } public string borderColor { get; set; } public string borderWidth { get; set; } - public List data { get; set; } - public List Labels { get; set; } + public List data { get; set; } = []; + public List Labels { get; set; } = []; + public List EnglishLabels { get; set; } = []; public int ComponentCount { get; set; } - public List DataRows { get; set; } - public List DataRowsPie { get; set; } - public List Colors { get; set; } + public List DataRows { get; set; } = []; + public List DataRowsPie { get; set; } = []; + public List Colors { get; set; } = []; public ChartData() { data = new List(); Labels = new List(); + EnglishLabels = new List(); dataSets = new List(); DataRows = new List(); } diff --git a/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/usp_getRankedCategories.cs b/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/usp_getRankedCategories.cs index 95286aaa55..7534bbdbe9 100644 --- a/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/usp_getRankedCategories.cs +++ b/CSETWebApi/CSETWeb_Api/CSETWebCore.Model/Analysis/usp_getRankedCategories.cs @@ -11,6 +11,7 @@ namespace CSETWebCore.Model.Analysis public class usp_getRankedCategories { public String Question_Group_Heading { get; set; } + public int QGH_Id { get; set; } public int? qc { get; set; } public int? cr { get; set; } public int? Total { get; set; } diff --git a/CSETWebApi/CSETWeb_Api/CSETWeb_ApiCore/Controllers/AnalysisController.cs b/CSETWebApi/CSETWeb_Api/CSETWeb_ApiCore/Controllers/AnalysisController.cs index 9f2ec6de19..317b3f9a4c 100644 --- a/CSETWebApi/CSETWeb_Api/CSETWeb_ApiCore/Controllers/AnalysisController.cs +++ b/CSETWebApi/CSETWeb_Api/CSETWeb_ApiCore/Controllers/AnalysisController.cs @@ -328,17 +328,8 @@ public IActionResult GetDashboard() { string label = j.Item1; - if (lang != "en") - { - var val = _overlay.GetValue("GENERIC", j.Item1, lang)?.Value; - if (val != null) - { - label = val; - } - } - - - overallBars.Labels.Add(label); + overallBars.EnglishLabels.Add(j.Item1); + overallBars.Labels.Add(_overlay.GetValue("GENERIC", j.Item1, lang)?.Value ?? j.Item1); overallBars.data.Add(j.Item2); } @@ -376,6 +367,8 @@ public IActionResult GetTopCategories(int? total) } int assessmentId = _tokenManager.AssessmentForUser(); + var lang = _tokenManager.GetCurrentLanguage(); + ChartData chartData = null; var results = new RankedCategoriesMultiResult(); @@ -403,7 +396,7 @@ public IActionResult GetTopCategories(int? total) foreach (usp_getRankedCategories c in results.Result1.Take((int)total)) { chartData.data.Add((double)c.prc); - chartData.Labels.Add(c.Question_Group_Heading); + chartData.Labels.Add(_overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value ?? c.Question_Group_Heading); } } @@ -489,6 +482,8 @@ private ChartData TransformToChart(GetCombinedOveralls c) public IActionResult GetOverallRankedCategories() { int assessmentId = _tokenManager.AssessmentForUser(); + var lang = _tokenManager.GetCurrentLanguage(); + ChartData chartData = null; var results = new RankedCategoriesMultiResult(); @@ -517,14 +512,14 @@ public IActionResult GetOverallRankedCategories() foreach (usp_getRankedCategories c in results.Result1) { chartData.data.Add((double)(c.prc ?? 0)); - chartData.Labels.Add(c.Question_Group_Heading); + chartData.Labels.Add(_overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value ?? c.Question_Group_Heading); chartData.DataRows.Add(new DataRows() { failed = (c.nuCount ?? 0), percent = (c.prc ?? 0), total = (c.qc ?? 0), - title = c.Question_Group_Heading, + title = _overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value ?? c.Question_Group_Heading, rank = i++ }); @@ -821,18 +816,8 @@ orderby an.Question_Group_Heading chartData.DataRows = new List(); foreach (var c in labels) { - var label = c.Question_Group_Heading.ToString(); - - if (lang != "en") - { - var val = _overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value; - if (val != null) - { - label = val; - } - } - - chartData.Labels.Add(label); + chartData.Labels.Add(_overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value ?? + c.Question_Group_Heading); } ColorsList colors = new ColorsList(); @@ -852,24 +837,14 @@ orderby an.Question_Group_Heading nextChartData.backgroundColor = colors.getNext(set.Set_Name); foreach (usp_getStandardsResultsByCategory c in nextSet) { - if (lang != "en") - { - var val = _overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value; - if (val != null) - { - c.Question_Group_Heading = val; - } - } - - nextChartData.data.Add((double)c.prc); - nextChartData.Labels.Add(c.Question_Group_Heading); + nextChartData.Labels.Add(_overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value ?? c.Question_Group_Heading); nextChartData.DataRows.Add(new DataRows() { failed = c.yaCount, percent = c.prc, total = c.Actualcr, - title = c.Question_Group_Heading + title = _overlay.GetValue("QUESTION_GROUP_HEADING", c.QGH_Id.ToString(), lang)?.Value ?? c.Question_Group_Heading }); } } diff --git a/CSETWebNg/src/app/assessment/results/analysis/dashboard/dashboard.component.ts b/CSETWebNg/src/app/assessment/results/analysis/dashboard/dashboard.component.ts index 61df648b38..e3124651d7 100644 --- a/CSETWebNg/src/app/assessment/results/analysis/dashboard/dashboard.component.ts +++ b/CSETWebNg/src/app/assessment/results/analysis/dashboard/dashboard.component.ts @@ -23,11 +23,11 @@ //////////////////////////////// import { Component, OnInit } from '@angular/core'; import Chart from 'chart.js/auto'; -import { Router } from '../../../../../../node_modules/@angular/router'; import { AssessmentService } from '../../../../services/assessment.service'; import { AnalysisService } from './../../../../services/analysis.service'; import { ConfigService } from '../../../../services/config.service'; import { NavigationService } from '../../../../services/navigation/navigation.service'; +import { TranslocoService } from '@ngneat/transloco'; declare var $: any; @Component({ @@ -58,7 +58,7 @@ export class DashboardComponent implements OnInit { public assessSvc: AssessmentService, public navSvc: NavigationService, public configSvc: ConfigService, - private router: Router) { } + private tSvc: TranslocoService) { } ngOnInit() { this.analysisSvc.getDashboard().subscribe(x => this.setupPage(x)); @@ -75,10 +75,12 @@ export class DashboardComponent implements OnInit { this.overallScoreDisplay = this.getScore(x.overallBars, 'Overall').toFixed(0) + '%'; this.standardBasedScore = this.getScore(x.overallBars, 'Standards'); - this.standardBasedScoreDisplay = this.standardBasedScore > 0 ? this.standardBasedScore.toFixed(0) + '%' : 'No Standards Answers'; + this.standardBasedScoreDisplay = this.standardBasedScore > 0 ? + this.standardBasedScore.toFixed(0) + '%' : this.tSvc.translate('reports.core.dashboard.no standards answers'); this.componentBasedScore = this.getScore(x.overallBars, 'Components'); - this.componentBasedScoreDisplay = this.componentBasedScore > 0 ? this.componentBasedScore.toFixed(0) + '%' : 'No Components Answers'; + this.componentBasedScoreDisplay = this.componentBasedScore > 0 ? + this.componentBasedScore.toFixed(0) + '%' : this.tSvc.translate('reports.core.dashboard.no components answers'); // Assessment Compliance @@ -131,12 +133,12 @@ export class DashboardComponent implements OnInit { /** - * Returns the 'data' element that corresponds to the position of the 'Label.' + * Returns the 'data' element that corresponds to the position of the English 'Label.' * @param overallBars */ getScore(overallBars, label) { - for (let i = 0; i < overallBars.labels.length; i++) { - if (overallBars.labels[i].toLowerCase() === label.toLowerCase()) { + for (let i = 0; i < overallBars.englishLabels.length; i++) { + if (overallBars.englishLabels[i].toLowerCase() === label.toLowerCase()) { return overallBars.data[i]; } } diff --git a/CSETWebNg/src/app/dialogs/question-filters/question-filters.component.ts b/CSETWebNg/src/app/dialogs/question-filters/question-filters.component.ts index ad6d06751a..f2183ca144 100644 --- a/CSETWebNg/src/app/dialogs/question-filters/question-filters.component.ts +++ b/CSETWebNg/src/app/dialogs/question-filters/question-filters.component.ts @@ -40,7 +40,6 @@ export class QuestionFiltersComponent implements OnInit { @Output() filterChanged = new EventEmitter(); - question = "Question"; /** * Holds the word "questions" or "statements" @@ -75,7 +74,6 @@ export class QuestionFiltersComponent implements OnInit { */ ngOnInit(): any { if (this.configSvc.installationMode === 'ACET') { - this.question = "Statement"; this.skin = "ncua"; if (this.assessSvc.isISE()) { this.observations = "issues"; diff --git a/CSETWebNg/src/assets/i18n/en.json b/CSETWebNg/src/assets/i18n/en.json index 2be63b7c63..d4537f2f63 100644 --- a/CSETWebNg/src/assets/i18n/en.json +++ b/CSETWebNg/src/assets/i18n/en.json @@ -543,7 +543,9 @@ "score": "Score", "overall score": "Overall Score", "standard based": "Standard Based", - "component based": "Component Based" + "component based": "Component Based", + "no standards answers": "No Standards Answers", + "no components answers": "No Components Answers" }, "executive summary": { "executive summary": "Executive Summary", diff --git a/CSETWebNg/src/assets/i18n/es.json b/CSETWebNg/src/assets/i18n/es.json index a1218ccf1c..39f146ba10 100644 --- a/CSETWebNg/src/assets/i18n/es.json +++ b/CSETWebNg/src/assets/i18n/es.json @@ -540,7 +540,9 @@ "score": "Puntaje", "overall score": "Puntuación general", "standard based": "Basada en estándares", - "component based": "Basada en componentes" + "component based": "Basada en componentes", + "no standards answers": "[ES]No Standards Answers", + "no components answers": "[ES]No Components Answers" }, "executive summary": { "executive summary": "Resumen ejecutivo", diff --git a/CSETWebNg/src/assets/i18n/uk.json b/CSETWebNg/src/assets/i18n/uk.json index b0f2c82693..969ababcd4 100644 --- a/CSETWebNg/src/assets/i18n/uk.json +++ b/CSETWebNg/src/assets/i18n/uk.json @@ -424,8 +424,8 @@ "question": "Питання", "assessment compliance text": "Ця діаграма показує загальні відсоткові бали.
Будь ласка, зверніть увагу, що питання без відповіді зараховуються як відповідь НІ в цих балах.", "ranked categories text": "На цій діаграмі показано найпоширеніші проблемні сфери. Вони розраховуються на основі зваженої оцінки ризику на основі складності атаки. Вага атаки має найбільшу вагу для легких атак і меншу для більш складних для атаки.", - "passed": "[UK]Passed", - "failed": "Не вдалося", + "passed": "Пройшло", + "failed": "Невдачі", "total": "Всього", "percent": "Відсоток", "number": "кількість", @@ -466,7 +466,9 @@ "score": "Оцінка", "overall score": "Загальний рахунок", "standard based": "Стандартна оцінка", - "component based": "На основі компонентів" + "component based": "На основі компонентів", + "no standards answers": "Немає стандартних відповідей", + "no components answers": "Компоненти відповіді відсутні" }, "executive summary": { "executive summary": "Резюме",