+3.14 System and Information Integrity
---+03.14.01E Software, Firmware, and Information Integrity
---+03.14.02E
---+03.14.03E
---+03.14.04E Refresh From Trusted Sources
---+03.14.05E Non-Persistent Information
---+03.14.06E
---+03.14.07E
---+03.14.08E Integrity Checks
---+03.14.09E Cryptographic Protection
---+03.14.10E Protection of Boot Firmware
---+03.14.11E Integration of Detection and Response
---+03.14.12E Information Input Validation
---+03.14.13E Error Handling
---+03.14.14E Memory Protection
---+03.14.15E Non-Persistent System Components and Services
---+03.14.16E Tainting
---+03.14.17E System-Generated Alerts
---+03.14.18E Automated Organization-Generated Alerts
---+03.14.19E Wireless Intrusion Detection
|
3.14 System and Information Integrity
System and Information Integrity
1. Resumen
| Título |
Estándar |
|
03.14.01E Software, Firmware, and Information Integrity
|
StatementEmploy integrity verification tools to detect unauthorized changes to the following software, firmware, and information: {{ insert: param, A.03.14.01E_prm_1 }}. Take the following actions when unauthorized changes to the software, firmware, and information are detected: {{ insert: param, A.03.14.01E_prm_2 }}.
GuidanceVerifying the integrity of security-critical or essential software is an important capability since corrupted software is the primary attack vector used by adversaries to undermine or disrupt the proper functioning of systems. Unauthorized changes to software, firmware, and information can occur due to errors or malicious activity. Software includes boot firmware, operating systems with key internal components (e.g., kernels or drivers), middleware, and applications. Firmware interfaces include Unified Extensible Firmware Interface (UEFI) and Basic Input/Output Systems (BIOS). Information includes CUI and metadata that contains security attributes associated with information. Integrity-checking mechanisms—including parity checks, cyclical redundancy checks, cryptographic hashes, and associated tools—can automatically monitor the integrity of systems and hosted applications. There are many ways to verify software integrity throughout the system development life cycle. Root of trust mechanisms (e.g., secure boot, trusted platform modules, UEFI) verify that only trusted code is executed during boot processes. The employment of cryptographic signatures ensures the integrity and authenticity of critical software that stores, processes, or transmits, CUI. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171. Statement(includes preempt)
Ensure that the threat event does not have an impact. (includes detect)
Reduce risk due to ignorance of threat events and possible replicated or similar threat events in the same or similar environments.
Assessment objectiveintegrity verification tools are employed to detect unauthorized changes to {{ insert: param, A.03.14.01E.ODP.01 }}. Assessment objectiveintegrity verification tools are employed to detect unauthorized changes to {{ insert: param, A.03.14.01E.ODP.02 }}. Assessment objectiveintegrity verification tools are employed to detect unauthorized changes to {{ insert: param, A.03.14.01E.ODP.03 }}. Assessment objective{{ insert: param, A.03.14.01E.ODP.04 }} are taken when unauthorized changes to software are detected. Assessment objective{{ insert: param, A.03.14.01E.ODP.05 }} are taken when unauthorized changes to firmware are detected. Assessment objective{{ insert: param, A.03.14.01E.ODP.06 }} are taken when unauthorized changes to information are detected. Assessment methodSystem and information integrity policy
system and information integrity procedures
procedures addressing software, firmware, and information integrity
system configuration settings and associated documentation
integrity verification tools and associated documentation
records generated or triggered by system design documentation
integrity verification tools regarding unauthorized software, firmware, and information changes
system audit records
system security plan
other relevant documents or records
Assessment methodAssessment method
|
|
03.14.02E
|
|
|
03.14.03E
|
|
|
03.14.04E Refresh From Trusted Sources
|
StatementObtain software and data employed during system component and service refreshes from the following trusted sources: {{ insert: param, A.03.14.04E.ODP.01 }}. GuidanceTrusted sources include software and data from write-once, read-only media or from selected offline secure storage facilities. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets. StatementAssessment objectivethe software and data used during system component and service refreshes are obtained from {{ insert: param, A.03.14.04E.ODP.01 }}. Assessment methodAssessment methodAssessment method
|
|
03.14.05E Non-Persistent Information
|
StatementGuidanceRetaining information longer than is required makes that information a potential target for advanced adversaries searching for high value assets to compromise through unauthorized disclosure, unauthorized modification, or exfiltration. For system-related information, unnecessary retention provides adversaries with information that can assist in their reconnaissance and lateral movement through the system. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets. StatementAssessment objective{{ insert: param, A.03.14.05E.ODP.01 }} is performed. Assessment objectiveinformation is deleted when no longer needed. Assessment methodAssessment methodAssessment method
|
|
03.14.06E
|
|
|
03.14.07E
|
|
|
03.14.08E Integrity Checks
|
StatementPerform an integrity check of {{ insert: param, A.03.14.08E_prm_1 }} {{ insert: param, A.03.14.08E.ODP.02 }}. GuidanceSecurity-relevant events include the identification of new threats to which organizational systems are susceptible and the installation of hardware, software, or firmware. Transitional states include system startup, restart, shutdown, and abort. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171. StatementAssessment objectivean integrity check of {{ insert: param, A.03.14.08E.ODP.01 }} is performed {{ insert: param, A.03.14.08E.ODP.02 }}. Assessment objectivean integrity check of {{ insert: param, A.03.14.08E.ODP.05 }} is performed {{ insert: param, A.03.14.08E.ODP.06 }}. Assessment objectivean integrity check of {{ insert: param, A.03.14.08E.ODP.09 }} is performed {{ insert: param, A.03.14.08E.ODP.10 }}. Assessment methodSystem and information integrity policy
system and information integrity procedures
procedures addressing software, firmware, and information integrity testing
system design documentation
system configuration settings and associated documentation
system security plan
integrity verification tools and associated documentation
records of integrity scans
other relevant documents or records
Assessment methodAssessment method
|
|
03.14.09E Cryptographic Protection
|
StatementImplement cryptographic mechanisms to detect unauthorized changes to software, firmware, and information. GuidanceCryptographic mechanisms used to protect integrity include digital signatures and the computation and application of signed hashes using asymmetric cryptography, protecting the confidentiality of the key used to generate the hash, and using the public key to verify the hash information. Organizations that use cryptographic mechanisms also consider cryptographic key management solutions. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets. Statement(includes preempt)
Ensure that the threat event does not have an impact. (includes exert)
Make it more difficult for threat events to cause adverse impacts or consequences. Reduce likelihood of impact and reduce level of impact. Adversary activities are restricted in scope, fail to achieve full effect, do not take place in accordance with adversary timeline, or require greater resources than adversary had planned.
(includes detect)
Reduce risk due to ignorance of threat events and possible replicated or similar threat events in the same or similar environments.
Assessment objectivecryptographic mechanisms are implemented to detect unauthorized changes to software. Assessment objectivecryptographic mechanisms are implemented to detect unauthorized changes to firmware. Assessment objectivecryptographic mechanisms are implemented to detect unauthorized changes to information. Assessment methodSystem and information integrity policy
system and information integrity procedures
procedures addressing software, firmware, and information integrity
system design documentation
system configuration settings and associated documentation
system audit records
system security plan
cryptographic mechanisms and associated documentation
records of detected unauthorized changes to software, firmware, and information
other relevant documents or records
Assessment methodAssessment methodSoftware, firmware, and information integrity verification tools
cryptographic mechanisms implementing software, firmware, and information integrity
|
|
03.14.10E Protection of Boot Firmware
|
StatementImplement the following mechanisms to protect the integrity of boot firmware in {{ insert: param, A.03.14.10E.ODP.01 }}: {{ insert: param, A.03.14.10E.ODP.02 }}. GuidanceUnauthorized modifications to boot firmware may indicate a sophisticated, targeted attack. These types of targeted attacks can result in a permanent denial of service or a persistent malicious code presence. These situations can occur if the firmware is corrupted or malicious code is embedded in the firmware. System components can protect the integrity of boot firmware in organizational systems by verifying the integrity and authenticity of updates to the firmware prior to applying changes to the system component and preventing unauthorized processes from modifying the boot firmware. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets. StatementAssessment objective{{ insert: param, A.03.14.10E.ODP.01 }} are implemented to protect the integrity of boot firmware in {{ insert: param, A.03.14.10E.ODP.02 }}. Assessment methodSystem and information integrity policy
system and information integrity procedures
procedures addressing software, firmware, and information integrity
system design documentation
system configuration settings and associated documentation
system security plan
integrity verification tools and associated documentation
records of integrity verification scans
system audit records
other relevant documents or records
Assessment methodAssessment methodSoftware, firmware, and information integrity verification tools
mechanisms supporting and/or implementing protection of the integrity of boot firmware
safeguards implementing protection of the integrity of boot firmware
|
|
03.14.11E Integration of Detection and Response
|
StatementIncorporate the detection of the following unauthorized changes into the organizational incident response capability: {{ insert: param, A.03.14.11E.ODP.01 }}. GuidanceIntegrating detection and response ensures that detected events are tracked, monitored, corrected, and available for historical purposes. Maintaining historical records is important to identify and discern adversary actions over an extended time period and for possible legal actions. Security-relevant changes include unauthorized changes to established configuration settings or the unauthorized elevation of system privileges. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171. StatementAssessment objectivethe detection of {{ insert: param, A.03.14.11E.ODP.01 }} are incorporated into the organizational incident response capability. Assessment methodSystem and information integrity policy
system and information integrity procedures
procedures addressing software, firmware, and information integrity
procedures addressing incident response
system design documentation
system configuration settings and associated documentation
incident response records
audit records
system security plan
other relevant documents or records
Assessment methodAssessment methodProcesses for incorporating the detection of unauthorized security-relevant changes into the incident response capability
mechanisms supporting and/or implementing the incorporation of detection of unauthorized security-relevant changes into the incident response capability
software, firmware, and information integrity verification tools
|
|
03.14.12E Information Input Validation
|
StatementCheck the validity of the following information inputs: {{ insert: param, A.03.14.12E.ODP.01 }}. GuidanceChecking the valid syntax and semantics of system inputs—including character set, length, numerical range, and acceptable values—verifies that inputs match specified definitions for format and content. Valid inputs are likely to vary from field to field within a software application. Applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the corrupted output will perform incorrect operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing them to interpreters prevents content from being unintentionally interpreted as commands. Input validation ensures accurate and correct inputs and prevents attacks, such as cross-site scripting and a variety of injection attacks. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171. StatementAssessment objectivethe validity of the {{ insert: param, A.03.14.12E.ODP.01 }} is checked. Assessment methodAssessment methodAssessment method
|
|
03.14.13E Error Handling
|
StatementGenerate error messages that provide information necessary for corrective actions without revealing information that could be exploited. Reveal error messages only to {{ insert: param, A.03.14.13E.ODP.01 }}.
GuidanceOrganizations consider the structure and content of error messages. The extent to which systems can handle error conditions is guided and informed by organizational policy and operational requirements. Exploitable information includes stack traces and implementation details; erroneous logon attempts with passwords mistakenly entered as the username; mission or business information that can be derived from, if not stated explicitly by, the information recorded; and personally identifiable information, such as account numbers, Social Security numbers, and credit card numbers. Error messages may also provide a covert channel for transmitting information. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171. StatementAssessment objectiveerror messages that provide the information necessary for corrective actions are generated without revealing information that could be exploited. Assessment objectiveerror messages are revealed only to {{ insert: param, A.03.14.13E.ODP.01 }}. Assessment methodAssessment methodAssessment method
|
|
03.14.14E Memory Protection
|
StatementImplement the following safeguards to protect the system memory from unauthorized code execution: {{ insert: param, A.03.14.14E.ODP.01 }}. GuidanceSome adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. The safeguards used to protect memory include data execution prevention and address space layout randomization (ASLR). Data execution prevention safeguards can be hardware- or software-enforced with hardware enforcement providing the greater strength of mechanism. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171. StatementAssessment objective{{ insert: param, A.03.14.14E.ODP.01 }} are implemented to protect the system memory from unauthorized code execution. Assessment methodAssessment methodAssessment method
|
|
03.14.15E Non-Persistent System Components and Services
|
StatementImplement non-persistent {{ insert: param, A.03.14.15E.ODP.01 }}. Initiate non-persistent {{ insert: param, A.03.14.15E.ODP.01 }} from a known state. Terminate non-persistent {{ insert: param, A.03.14.15E.ODP.02 }} {{ insert: param, A.03.14.15E.ODP.01 }}.
GuidanceImplementation of non-persistent components and services mitigates risk from advanced persistent threats (APTs) by reducing the targeting capability of adversaries (i.e., window of opportunity and available attack surface) to initiate and complete attacks. By implementing the concept of non-persistence for selected system components and services, organizations can provide a trusted computing resource for a specific time period that does not give adversaries sufficient time to exploit vulnerabilities in their systems and operating environments. The use of non-persistent components and services mitigates risk by limiting the targeting capability of adversaries (i.e., reducing the window of opportunity and available attack surface) to initiate and complete attacks. Non-persistent system components and services are activated as required from a known (trusted) state and terminated periodically or at the end of sessions. The use of non-persistent system components and services also increases the work factor of adversaries.
Non-persistence can be achieved by refreshing system components, periodically reimaging components, or using a variety of common virtualization techniques. Non-persistent services can be implemented by using virtual machines or as new instances of processes on physical machines (persistent or non-persistent). The benefit of periodic refreshes of system components and services is that it does not require organizations to determine in advance whether compromises have occurred, which may be difficult or impossible. The refresh of selected system components and services occurs with sufficient frequency to prevent the spread or intended impact of attacks but not with such frequency that it makes the system unstable. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets. Statement(includes preempt)
Ensure that the threat event does not have an impact. (includes exert)
Make it more difficult for threat events to cause adverse impacts or consequences. Reduce likelihood of impact and reduce level of impact. Adversary activities are restricted in scope, fail to achieve full effect, do not take place in accordance with adversary timeline, or require greater resources than adversary had planned.
(includes shorten and reduce)
Restrict the consequences of realized threat events by limiting the damage or effects they cause in terms of time, system resources, and/or mission or business impacts.
Assessment objective{{ insert: param, A.03.14.15E.ODP.01 }} are implemented. Assessment objective{{ insert: param, A.03.14.15E.ODP.01 }} are initiated from a known state. Assessment objective{{ insert: param, A.03.14.15E.ODP.01 }} are terminated {{ insert: param, A.03.14.15E.ODP.02 }}. Assessment methodAssessment methodAssessment method
|
|
03.14.16E Tainting
|
StatementEmbed data or capabilities in the following systems or system components to determine if CUI has been exfiltrated or improperly removed from the organization: {{ insert: param, A.03.14.16E.ODP.01 }}. GuidanceMany cyber-attacks target organizational information or information that the organization holds on behalf of other entities with the intent to exfiltrate that information. In addition, insider attacks and erroneous user procedures can remove information from the system in violation of organizational policies. Tainting approaches can range from passive to active. A passive tainting approach can be as simple as adding false email names and addresses to an internal database. If the organization receives email at one of the false email addresses, it knows that the database has been compromised. Moreover, the organization knows that the email was sent by an unauthorized entity, so any packets it includes potentially contain malicious code, and the unauthorized entity may have potentially obtained a copy of the database. Another tainting approach includes embedding false data or steganographic data in files to enable the data to be found via open-source analysis. An active tainting approach can include embedding software in the data that is able to “call home,” thereby alerting the organization to its capture and possibly its location and the path by which it was exfiltrated or removed. This requirement does not enhance a specific requirement in SP 800-171 but can be used to strengthen the protection of CUI associated with critical programs or high value assets. StatementAssessment objectivedata or capabilities are embedded in {{ insert: param, A.03.14.16E.ODP.01 }} to determine if CUI has been exfiltrated or improperly removed from the organization. Assessment methodAssessment methodAssessment methodAutomated mechanisms for post-breach detection
decoys, traps, lures, and methods for deceiving adversaries
detection and notification mechanisms
|
|
03.14.17E System-Generated Alerts
|
StatementAlert {{ insert: param, A.03.14.17E.ODP.01 }} when the following system-generated indications of compromise or potential compromise occur: {{ insert: param, A.03.14.17E.ODP.02 }}. GuidanceAlerts may be generated from different sources internal to the system, including audit records, inputs from malicious code protection mechanisms, intrusion detection or prevention mechanisms, or boundary protection devices such as firewalls, gateways, and routers. Compromise indicators could include CUI being accessed by unauthorized users or when CUI traverses architecture outside of defined data flows. Alerts can be automated and transmitted telephonically, by electronic mail messages, or by text messaging. Organizational personnel on the alert notification list can include system administrators, mission or business owners, system owners, information owners or stewards, chief information security officers, and system security officers. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171. StatementAssessment objective{{ insert: param, A.03.14.17E.ODP.01 }} are alerted when system-generated {{ insert: param, A.03.14.17E.ODP.02 }} occur. Assessment methodAssessment methodPersonnel with information security responsibilities
system developers
personnel installing, configuring, and/or maintaining the system
personnel responsible for monitoring the system
personnel on the system alert notification list
personnel responsible for the intrusion detection system
system/network administrators
Assessment method
|
|
03.14.18E Automated Organization-Generated Alerts
|
StatementAlert {{ insert: param, A.03.14.18E.ODP.01 }} using {{ insert: param, A.03.14.18E.ODP.02 }} when the following indications of inappropriate or unusual activities with security implications occur: {{ insert: param, A.03.14.18E.ODP.03 }}. GuidanceOrganization-generated alerts are focused on information sources that are external to the system, such as suspicious activity reports and reports on potential insider threats. Organizational personnel on the system alert notification list include system administrators, mission or business owners, system owners, chief information security officers, and system security officers. This requirement enhances SP 800-171 requirement 03.14.06. StatementAssessment objective{{ insert: param, A.03.14.18E.ODP.01 }} are alerted using {{ insert: param, A.03.14.18E.ODP.02 }} when {{ insert: param, A.03.14.18E.ODP.03 }} indicate inappropriate or unusual activities with security implications. Assessment methodAssessment methodPersonnel with information security responsibilities
system developers
personnel installing, configuring, and/or maintaining the system
personnel responsible for monitoring the system
personnel responsible for the intrusion detection system
system/network administrators
Assessment method
|
|
03.14.19E Wireless Intrusion Detection
|
StatementEmploy a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises or breaches to the system GuidanceWireless signals may radiate beyond organizational facilities. Organizations proactively search for unauthorized wireless connections, including the conduct of thorough scans for unauthorized wireless access points. Wireless scans are not limited to those areas within facilities containing systems but also include areas outside of facilities to verify that unauthorized wireless access points are not connected to organizational systems. This requirement enhances SP 800-171 requirement 03.14.06 and 03.01.16. StatementAssessment objectivea wireless intrusion detection system is employed to identify rogue wireless devices. Assessment objectivea wireless intrusion detection system is employed to detect attack attempts on the system. Assessment objectivea wireless intrusion detection system is employed to detect a potential compromise or breach to the system. Assessment methodAssessment methodSystem/network administrators
organizational personnel with information security responsibilities
organizational personnel installing, configuring, and/or maintaining the system
organizational personnel responsible for monitoring the system
organizational personnel responsible for the intrusion detection system
Assessment method
|
1.1 Referencias
1.2 Requisitos identificados
1.3 Regulaciones relacionadas
2. Requisitos identificados
Requisitos
| Fuente |
Requisito |
3. Regulaciones relacionadas
Regulaciones
| Fuente |
Regulación |
|