Malware is the most common external threat to information systems. It causes widespread damage and disruption and necessitates extensive recovery efforts. Many of today’s malware threats are stealthy and designed to avoid detection. They gather information over extended periods of time. Malware can lead to exfiltration of sensitive data and other negative impacts. Malware prevention should include administrative controls, such as policy statements, awareness training. It should also include technical controls such as vulnerability mitigation and defensive architecture. This blog will discuss the following topics around NIST SP 800-171 practices 3.14.2, 3.14.4, and 3.14.5:
NIST first introduced special publication (SP) 800-171 in 2015. NIST kept the practice numbers 3.14.2, 3.14.4, and 3.14.5 through their first and second revisions. NIST SP 800-171 Revision 3 consolidates these three requirements into 03.14.02.
The cybersecurity maturity model certification (CMMC) rule will verify SP 800-171 Rev 2. CMMC 1.02 numbered these practices SI.1.211, SI.1.212, and SI.1.213. CMMC 2.0 renamed these requirements SI.L1-3.14.2, SI.L1-3.14.4, and SI.L1-3.14.5. These practices apply to organizations seeking compliance within any level of CMMC.
As of December 2023, CMMC 2.1 created two numbers for these practice:
CMMC Level 1 uses the labels SI.L1-B.1.XIII, SI.L1-B.1.XIV, and SI.L1-B.1.XV. Section b references the Federal Acquisition Regulation (FAR) clause 52.204-21.
CMMC Level 2 uses the label SI.L2-3.14.2, SI.L2-3.14.4, and SI.L2-3.14.5. SI identifies the system and information integrity domain. L2 identifies the applicability to CMMC Level 2. 3.14.2, 3.14.4, and 3.14.5 reference the practice numbers from NIST SP 800-171 Rev 2.
Practice Statement
NIST derived basic security requirements with SP 800-171 from FIPS 200. Below is the original language from FIPS 200:
NIST SP 800-171A provides the assessment procedures for SP 800-171 security requirements. These procedures apply assessment methods to assessment objects. Methods include examining artifacts, interviewing personnel, and testing mechanisms. An assessor checks each part of the practice to determine a finding. Satisfied findings identify acceptable implementations. Other than satisfied findings identify one or more anomalies.
The assessment objectives for 3.14.2 contains two parts:
Appendix D maps SP 800-171 requirements to controls from SP 800-53 Rev 4. This mapping relates 3.14.2 to SI-2, SI-3 and SI-5. The mapping also suggests the same relationship exists for 3.14.1 and 3.14.3. Mapping this practice to SP 800-53 is more challenging since NIST derived it from FIPS 200.
Appendix D maps both 3.14.4 and 3.14.5 to SI-3.
We mapped these six objectives to the closest SP 800-53A Rev 5 objectives. NIST IR 8477 guidance helped define the nature and strength of the relationships. The findings indicated that:
SI.L1-3.14.2(a) intersects with SI-03a.[01] (strong relationship)
SI.L1-3.14.2(b) is a superset of SI-03a.[01] (moderate strength)
SI.L1-3.14.4(a) intersects with SI-3b. (strong relationship)
SI.L1-3.14.5(a) is equal to SI-3_ODP[02]
SI.L1-3.14.5(b) is equal to SI-03c.01[01]
SI.L1-3.14.5(c) is a superset of SI-03c.01[02] (strong relationship)
The CMMC Assessment Guide includes supplemental guidance from SP 800-53 Rev 4. Have you ever wondered why the discussion overlapped for these three practices?
The CMMC guide derived the discussion for all three from SI-3 supplemental guidance.
The CMMC Assessment Guide also provides a further discussion for each practice. The actionable steps for 3.14.2 include:
A designated location may be a network device such as a firewall or an end user’s computer.
Delivery of malicious code occurs through a range of means. This includes email, removable media, and websites. Malicious code includes the following:
virus – program designed to damage a system and or extract sensitive information;
spyware – program designed to gather information about a person’s activity in secret. This is usually installed without the person knowing when they click on a link;
trojan horse – type of malware made to look like legitimate software. Cyber criminals use them to gain access to a company’s systems; and
ransomware – type of malware that threatens to publish the contractor’s data. It may also block access to data unless the victim pays a ransom.
Use anti-malware tools to stop or lessen the impact of malicious code.
The further discussion for 3.14.4 reads:
Malware changes on an hourly or daily basis. It is important to update detection and protection mechanisms to maintain effective protection.
The further discussion for 3.14.5 reads:
Use anti-malware software to scan for and identify viruses in your computer systems. Determine how often to conduct scans. Real-time scans look at the system whenever downloading, opening, or saving new files. Periodic scans check saved files against updated malware information.
The CMMC Assessment Guide also provides examples for each practice. The example for 3.14.2 reads:
You are buying a new computer and want to protect your company’s information from malware. You buy and install anti-malware software [a,b].
The example for 3.14.4 reads:
You have installed anti-malware software to protect a computer from malicious code.
Configure the software to check for updates every day and update as needed [a].
The example for 3.14.5 reads:
You work with your company’s email provider to enable enhanced protections. These protections will scan all attachments to identify those that may be harmful. You configure the system to quarantine those deemed harmful before a user can open them [c]. You also configure antivirus software on each computer to scan for malicious code every day [a,b]. The software also scans downloaded or copied files from removable media. It quarantines any suspicious files and notifies the security team [c].
DoD Criticality
The NIST SP 800-171 DoD Assessment Methodology Version 1.2.1 assigns 5-point value to 3.14.2 and 3.14.4. Failing these practices may lead to data exfiltration or exploitation of the network. 3.14.5 has a 3-point value. Failing this practice may lead to confined effects on the security of the network. CMMC section 170.21(ii) removed eligibility for limited deficiencies for these practices. All three practices align to the basic cybersecurity safeguards requirements of 52.204-21.
(S) implemented by an information system through technical means
(O) implemented by an individual through nontechnical means
(O/S) implemented by an organization, system, or combination of the two
NIST defines the SI-3 as implemented through both technical and nontechnical means. The first three parts of the control use technical means. The crosswalk suggests that:
3.14.2 uses technical means to enable malicious code protection mechanism
3.14.4 uses technical means to update the malicious code protection mechanism
3.14.5 uses technical means to configure the malicious code protection mechanism
Consider scoping the system components that provide or support the security functions, including:
antivirus software
content filtering/inspection
firewalls
intrusion prevention systems
application whitelisting
SIEM technologies
network behavior analysis (NBA) systems
Inheritance
It is possible to inherit or share this practice with an external service provider. The Ariento shared responsibility matrix indicates all three as inherited practices. When Ariento does not manage the network, they assign responsibility to the client for 3.14.2.
The PreVeil solution also shows 3.14.2 and 3.14.4 as inherited practices. Part (c) of 3.14.5 is a shared practice. The PreVeil solution does not address endpoints. Contractor must find other means to meet that part.
Policy statements and supporting procedures should define locations for malicious code protection. NIST SP 800-83 advises deploying antivirus on all systems for which it is available. NIST also recommends using more than one antivirus product. To avoid causing conflicts between two products, install them on separate system components. You may install one on perimeter email servers and another on internal email servers. Although more expensive, this may provide better detection of new threats.
SI-03a.[01] - Use signature based and non-signature based malicious code protection mechanisms. Install them at system entry and exit points to detect malicious code;
Signatures are a set of characteristics of known malware instances. Signature-based mechanisms detect malware by comparing files to a database of malware signatures. Non-signature based mechanisms look at behavior to identify new threats. New and evolving threats may not have defined signatures. Relevant tools that may use both signature-based and non-signature-based mechanisms include:
antivirus software
network-based intrusion prevention systems
content filtering/inspection
next-generation firewalls
Other tools may only use non-signature based mechanisms, including:
network behavior analysis (NBA) systems
host-based intrusion prevention systems
traditional firewalls
application whitelisting
security information and event management (SIEM) technologies
Organizations should assess the capabilities of their own products within these categories. Verify the use of both signature-based and non-signature based mechanisms.
Provide protection from malicious code
NIST SP 800-83 includes prevention and incident response as protection methods against malware.
Malware Prevention
Malicious code is also known as Malware. Malware inserts itself into other programs without the user's knowledge. The degree of customization distinguishes today’s malware from previous generations. Adversaries design today’s malware to avoid detection as it spreads to other systems. Current malware leverages social engineering to trick people into performing certain actions. Attackers harvest information through social networks to craft superior social engineering attacks.
Preventing malware incorporates the following activities:
Organizational Policies
Awareness Training
Vulnerability and Threat Mitigation
Defensive Architecture
Organizational Policies
Policy statements should provide flexibility in implementation but specificity to clarify intent. Organizations may incorporate relevant policy statements into their acceptable use policies. Malware prevention policy should include provisions related to remote workers. This includes employees using organizational systems and systems outside of the organization's control.
Awareness Training
An effective awareness training program should explain the proper use of organizational systems. Awareness training programs should include guidance to users on:
The risks that malware poses
The importance of users in preventing incidents
The inability of technical controls to prevent all incidents
The ways in which malware enters and infects hosts
Social engineering techniques designed to trick users into disclosing information
Recommendations for avoiding phishing attacks and social engineering, including
Never reply to email requests for financial or personal information
Contact the person or the organization at the legitimate phone number or website
Do not use the contact information provided in the email
Do not provide passwords, PINs, or other access codes in response to emails
Only enter such information into the legitimate website or application.
Do not open suspicious email file attachments, even if they come from known senders
After receiving an unexpected attachment, contact the sender via phone to confirm
Do not respond to any suspicious or unwanted emails
Organization’s policies and procedures related to malware prevention, including
How to identify signs of system infections
How to report a suspected incident
What users might need to do to assist with incident handling
How the organization will communicate notices of major malware incidents
How to verify the authenticity of all communication notices
Users should not forward malware alerts to others without confirming legitimacy.
Temporary changes to the environment that may occur to contain an incident
Generally recommended practices for avoiding malware incidents, including
Not opening suspicious emails or attachments
Not clicking on hyperlink from unknown or known senders
Not visiting websites that are likely to contain malicious content
Not clicking on suspicious web browser popup windows
Not opening file extensions associated with malware (e.g., .bat,.com, .exe, .pif, .vbs)
Not disabling malware security control mechanisms
Not using administrator-level accounts for regular host operation
Not downloading or executing applications from untrusted sources.
The awareness program should also train IT staff involved in malware incident prevention. This includes security, system, and network administrators roles. All IT staff should have some basic level of awareness around malware prevention. Provide role-based training to individuals assigned malware prevention related tasks. Assigned team members should review bulletins on new types of malware threats. After assessing the risk, they should inform IT staff of new relevant threats.
Vulnerability Mitigation
Mitigating vulnerabilities is very important to the prevention of malware incidents. Vulnerability mitigation includes applying patches, updating or reconfiguring software. Consider using security automation technologies with operation systems (OSs) and applications. Security automation technologies may also identify, receive, and install security-related patches.
Altering application configuration settings can remediate vulnerabilities. Security automation technologies can apply and verify configuration settings. For example, only provide minimal necessary rights to users, processes, and devices. Malware often requires administrator-level privileges to exploit vulnerabilities. Least privilege minimizes the amount of damage that the malware can cause. Other hardening measures include:
Disabling or removing unneeded services to reduce ways malware can spread
Eliminating common mediums used to spread malware like unsecured file shares
Removing or changing default usernames and passwords for OSs and applications
Disabling automatic execution of binaries and scripts, including AutoRun on Windows devices
Changing the default file associations for file types used by malware but not users. Ensure files are not run if users attempt to open them.
Disabling or limiting macros to trusted locations within word processors and spreadsheets.
Preventing software installation within web browsers by prohibiting plug-in installations.
Threat Mitigation
Several types of security tools that can mitigate malware threats. Mitigation may include detecting and stopping malware. Some tools only address specific attack vectors. NIST recommends the use of complementary tools. This decreases the likelihood and impact of malware incidents. These tools fall into six broad categories, including:
Antivirus Software scans files for known malware and attacker tools. Organizations should use host-based and network-based antivirus software. Scan critical system components such as startup files and boot records. Antivirus software is also capable of monitoring the behavior of common applications. This should include applications most likely used to infect systems or spread malware. Such applications include email clients, web browsers, and instant messaging software.
Intrusion Prevention Systems (IPS) perform packet sniffing and analyze network traffic. These tools can identify and stop suspicious activity. There are three main types of IPS solutions:
Network-based IPS tools act like a network firewall. They receive packets, analyze them, and allow acceptable packets to pass through. They compare network activity for often attacked applications to expected behavior. This enables identification of malicious activity. Some are capable of deploying attack signatures for new threats in a matter of minutes. Network-based IPS products are effective at stopping known threats with recognizable characteristics.
Network behavior analysis (NBA) systems work by monitoring normal network traffic patterns. They establish baselines of normal traffic flows. This allows for identification of deviations from the baselines. An NBA system can detect and block suspicious activity. They can identify malware as well as the use of attacker tools. This may include backdoors and email generators.
Host-based IPS work by monitoring the characteristics of a single system. They establish a baseline for normal events occurring within it. This may include file access, network traffic, logs, and processes running. It may also include file modification and application or system configuration changes. These tools may combine attack signatures and behavior analysis to identify attacks. They are effective at detecting viruses as well as the use of attacker tools.
Firewalls restrict certain types of traffic using a defined set of rules. A network firewall is a device that restricts traffic between two networks. A host-based firewall is software running on a single system. Host-based firewalls can restrict network activity for that system. Both types of firewalls are useful for preventing malware incidents. Organizations should configure firewalls to deny all incoming traffic that is not permitted. Organizations should restrict outgoing traffic from using services often associated with malware. Firewalls are effective at preventing malware from using services deemed unnecessary. They can also stop malware that relies on particular external systems.
Content Filtering/Inspection uses real-time blacklists and reputation services to protect against malware. Real-time blacklists are often based on observed malware activity. Reputation services may incorporate user opinions or automated analysis without detecting malware. They are effective at stopping email-based and web-based malware threats. NIST SP 800-83 discusses two relevant malware prevention capabilities these solutions offer:
Spam filtering technologies reduce the amount of spam that reaches users. Spam is often used for malware delivery. Reducing spam should lead to a corresponding decline in spam-triggered malware incidents. Configure email servers to block attachments with file extensions associated with malicious code.
Web content filtering prevents access to materials that are inappropriate for the workplace. It can also block undesired file types, such as by file extension or by mobile code type. Blocking undesired web browser popup windows is another form of content filtering. Popup windows can trick users into performing malicious actions. Third-party popup blockers and web browsers can block popup windows.
Application Whitelisting specifies applications authorized for use on a system. Most run in two modes: audit and enforcement. Audit mode logs all instances of non-whitelisted but it doesn’t stop them. Organizations first deploy audit mode to identify whitelist applications. Enforcement mode prohibits the execution of applications that are not in the whitelist. Using enforcement mode will stop malware from executing. It may also prevent benign applications not included on the whitelist from running.
Security Information and Event Management (SIEM) technologies analyze security data from various sources. They look at log data, events, and network traffic for known indicators of compromise. These tools help detect threats using non-signature based mechanisms. They may also trigger automated responses. This might include isolating a device or blocking suspicious traffic.
Defensive Architecture
No matter how rigorous mitigation efforts are, malware incidents will still occur.
NIST SP 800-83 discusses five ways to enhance the defensive architecture:
Basic Input/Output System (BIOS) Protection focuses on firmware. Firmware initializes the hardware and loads the operating system. BIOS firmware has a privileged position within the system architecture. This makes it an attractive target for attack. Because the BIOS loads first, anti-malware products cannot scan the BIOS. Malware written into a BIOS could re-infect machines after installing a new OS or hard drive. BIOS exploits are often directed at specific BIOS versions or hardware components. They are more likely employed in targeted attacks on high-value computer systems. NIST SP 800-147 recommends the following to prevent unauthorized modification of the BIOS:
Verify the authenticity and integrity of BIOS updates. Use a secure update mechanism that verifies the BIOS update’s digital signature. A Root of Trust for Update (RTU) contains a signature verification algorithm and a public key. The update mechanism matches the update’s digital signature to verify the signature. An alternative control requires physical presence to install BIOS updates.
Sandboxing refers to a security model that runs applications within a controlled environment. These environments can reset to a known good state during initialization. Sandboxing can restrict applications' access to system resources and operations they can perform. It can also isolate them from other applications.
Browser Separation uses separate web browsers for specific functions. You may use one web browser for corporate applications and another for web browsing. Accessing web sites containing malicious content is a common attack vector. Browser separation reduces the risk that malware encountered browsing websites affects corporate applications. Having a separate browser also allows for tighter security. For example, you can disabling all forms of mobile code not required.
Segregation through virtualization separates applications or operating systems (OS) from each other. An organization could use a guest OS for web browsing and the host OS for corporate applications. A more secure approach may entail using two separate guest OSs. One for corporate applications and one for all other activities. Each OS comes from a known-good virtualized image. These images contain appropriate applications and security controls. Users load these virtualized images and do their work within these guest OS images. A compromise occurring within one image reduces the risk of affecting the other. Restarting would reload a known-good image, eradicating any compromises occurring within the image.
Network Segregation may involve using subnets or virtual local area networks (VLANs). Organizations may decide to place servers and workstations on separate subnets. This enables malware containment of one subnet without impacting the other. Having a separate VLAN may restrict what they can do until they receive updates or patches.
Incident Response
NIST SP 800-61 describes four major phases of an incident response capability. NIST SP 800-83 provides details relevant to malware incidents.
Preparation includes all preventative measures discussed above. Despite these measures, residual risk will persist. NIST recommends taking the following preparatory measures:
Build malware-related skills within the incident response team. Organizations should also identify which individuals can assist in identifying malware. All incident handlers should understand how malware infects hosts and spreads. They should have familiarity with the organization’s implementation of malware detection tools. All incident handlers should remain abreast of the evolving malware landscape.
Several roles may contribute to the identification of malware. This includes security, system, network, desktop, and mobile device administrators. Ensure that everyone involved knows their role and how to perform related tasks. Many organizations use the help desk as the initial point of contact. They give help desk staff access to malware information sources. Staff may reference this information to determine the legitimacy of an alert.
Enable coordination. Assign responsibility for coordinating malware incident responses to a small team. The coordinator’s primary goal is to maintain situational awareness. They should gather all pertinent information and provide technical guidance to support staff. They should provide updates to management and may interact with external parties.
Enable communication. Email might not provide reliable or timely communications during a malware incident. Organizations should identify alternate mechanisms for distributing information. This may include sending messages to mailboxes, posting signs, and handing out instructions.
Deploy the necessary tools to assist in malware incident handling. Ensure incident handlers have the necessary tools to protect against malware.
Detection and Analysis
Rapid detection of malware helps limit system infections and damages. Recommended actions include:
Analyzing suspected incidents and validating malware is the cause. Incident handlers may identify characteristics of the malware activity by examining detection sources. Incident handlers should identify these sources in advance. The most obvious sources of evidence are those designed to identify malware activity. This includes antivirus software, content filtering, IPS, and SIEM technologies.
It may take considerable analysis to confirm that malware caused an incident. The goal is to determine the type of malware threat responsible for an incident. Understanding its characteristics helps assign an appropriate priority to the incident response efforts. Handlers can search for those characteristics in malware databases and identify the following:
Relevant services, ports, protocols
Relevant vulnerabilities
Relevant OSs and applications
Malicious file metadata
How the malware affects systems
How the malware propagates
How to approach containment
How to remove the malware
Malware databases may not include information on newer threats. Incident handlers may need to consult their peers, or perform their own analysis.
Identifying infected systems. It is often most effective to use more than approach at the same time or in sequence to provide the best results. Organizations should develop procedures and technical capabilities to perform each approach. NIST discusses three identification techniques:
Forensic Identification involves looking for evidence of recent infections from several data sources. Forensic data may provide the most effective way of identifying infections. Forensic data should be accurate, comprehensive, and current. Data might come from antivirus software, IDSs, SIEMs, and user reports. If these sources do not contain the necessary information, considering using alternative sources:
DNS Server Logs
Application Server Logs
Network Forensic Tools
Network Device Logs
Active Identification methods use automated means to identify malware. This approach may produce the more accurate results. As a trade-off, it may take considerable time to scan every system. Scans will not identify disconnected or systems shut off. Active identification includes the following:
Security Automation. Security automation technologies can check host characteristics for signs of a current infection. This might include configuration settings or a system file with a certain size. Security automation technologies are generally the preferred method for active identification.
Custom Network-Based IPS or IDS Signature. An effective technique is writing a custom IPS or IDS signature. Some organizations have separate IPS or IDS sensors with strong signature-writing capabilities. They are often dedicated to identifying malware infections. This provides a high-quality source of information while not overloading other sensors.
Packet Sniffers and Protocol Analyzers look for network traffic that matches malware characteristics. This is most effective when traffic passes through a small number of network devices.
Manual Identification is by far the most labor-intensive of the three methods. Only consider this option in situations where automated methods are not available. A manual approach can supplement automated approaches. This is especially true when systems are diverse and automated methods are inaccurate.
Prioritizing incident response handling. Base prioritization on the type, extent, and scope of the problem. Establish a set of criteria that identify appropriate responses for various malware-related situations. The criteria should incorporate considerations such as the following:
How the malware entered the environment
What transmission mechanisms it uses
What type of malware it is (e.g., virus, worm, Trojan horse)
What types of attacker tools did malware place on the system
What networks and systems the malware is affecting
How is the malware affecting those systems
How the impact is likely to increase if the incident is not contained
Organizations should act to mitigate incident impacts through containment, eradication, and recovery. NIST advises creating a single set of procedures for handling all malware incidents. Modern malware can exhibit a variety of characteristics. This reduces the effectiveness of having different handling procedures for each type.
Containment
Most malware incidents will include containment actions. Containment stops the spread but does not prevent further damage to infected systems. Malware might perform new actions once it loses network connectivity. Organizations should decide which methods of containment to use early in the response. Organizations should define who has authority to make containment decisions. This includes under what circumstances various actions are appropriate. Incident handlers should select methods most likely to contain the malware. Selections should seek to limit the impact of containment on other systems. NIST SP 800-83 divides containment methods into four basic categories:
Containment through user participation. Organizations should have mechanisms in place for distributing information to users. Organizations should not rely on this means for containing malware incidents.
Containment Through Automated Detection. Automated technologies can contain many malware incidents. Antivirus software can detect and remove infections. This makes it the preferred method for assisting in containment. Containment through antivirus software alone is not as effective against today’s malware. Antivirus software may not recognize new forms of malware. Some malware disables antivirus software by compromising the operating system. Organizations should have alternatives to contain malware until antivirus signatures can contain it. Examples of other automated detection methods are as follows:
Content Filtering. Email servers, clients, and anti-spam software can block emails with certain characteristics. This includes a known bad subject, sender, message text, or attachment name or type. This is only helpful when the malware has static characteristics. Content filtering cannot usually block customized malware.
Network-Based IPS Software. Most IPS products enable prevention capabilities for specific signatures. Network-based IPS devices that are active parts of a network can stop malware. Their effectiveness depends on the accuracy of a signature to identify the malware.
Executable Blacklisting. Some systems can restrict running certain executables. Administrators can enter the names of files prohibited from executing. Blacklisting may block the execution of malware when antivirus signatures are not available.
Network access control software. A system agent may check its security posture when it attempts to join the network. It may also check the system's posture at scheduled intervals while connected. The check may assess OS patches and antivirus updates. If the agent identifies security flaws on the host, a network device can place it onto a separate VLAN.
Containment through disabling services. You may need to shut down, block, or disable portions of a service for some incidents. This action is often performed at the application level or at the network level. Organizations should maintain lists of the TCP and UDP ports used by each service. Organizations should also maintain a list of dependencies between major services. These lists will help incident handlers when making containment decisions. Organizations might find it helpful to identify alternative services with similar functionality.
Containment through disabling connectivity. Placing temporary restrictions on network connectivity can contain malware incidents. Blocking access to an external host prevents infected hosts from downloading rootkits. Blocking network traffic from the infected hosts’ IP address stops malware's spread. An alternative is to disconnect the infected hosts from the network. Organizations may reconfigure network devices to deny network access or disconnect network cables. The most drastic containment step is breaking network connectivity for uninfected hosts.
Eradication
The primary goal of eradication is to remove malware from infected systems. NIST describes two eradication techniques:
Disinfection is the process of removing malware from a system. The most common tool for disinfection is antivirus software. Disinfection should also include the elimination or mitigation of weaknesses. This protects against reinfection from the original malware or a variant of it. Vulnerability management and network access control software are common tools for correcting vulnerabilities.
Rebuilding includes the reinstallation and securing of the OS and applications. For many malware incidents, simple disinfection is not possible. Some types of malware are difficult to remove from hosts. Organizations should rebuild any host that has any of the following incident characteristics:
One or more attackers gained administrator-level access to the host.
Administrator-level access was available through a backdoor or other means.
A Trojan horse, backdoor, rootkit, or other tools replaced system files.
The host is unstable or exhibits functional impairment after disinfection.
There is doubt about the nature and extent of the infection or any access gained.
Recovery
Recovery involves restoring the functionality and data of infected systems. Disinfection may resolve malware that only causes limited system damage. For more damaging incidents, it is best to rebuild the host and ensure that it is no longer vulnerable. Organizations should consider worst-case scenarios. For example, a malware incident that requires rebuilding a large percentage of workstations. Determine who would perform the recovery tasks and estimate the labor hours needed. Also consider how much time would elapse and recovery effort priorities.
Another aspect of recovery is removing temporary containment measures. Determining when to remove temporary containment measures is often a difficult decision. Keep containment measures until the number of infected and vulnerable systems is low. Incident handlers can also consider switching to less restrictive containment measures. Incident handlers should communicate the risks of restoring the service to management. Management should consider the business impact and the incident response team’s recommendations.
Conduct an assessment of lessons learned after major incidents
Organizations should conduct lessons learned activities for major malware incidents. Review meetings should occur soon after the incident, while it is still fresh in everyone’s minds. Examples of possible outcomes for malware incidents include:
Security Policy Changes
Awareness Program Changes
Software Reconfiguration
Malware Detection Software Deployment
Malware Detection Software Reconfiguration
Increasing the frequency of software and signature updates
Improving the accuracy of detection
Increasing the scope of monitoring
Changing the automated actions performed in response to detected malware
Improving the efficiency of update distribution
Updating malicious code protection mechanisms
Antivirus and other signature-based tools are most effective when their signatures are up-to-date. Organizations should use software with unified controls and automatic updates. Administrators should perform continuous monitoring activities to verify updates to signatures and configurations. Organizations may use manual updates on infected systems contained during an incident. It is prudent to test updated signatures before deployment. This ensures that the update does not cause a negative impact on the system.
Define the frequency for malicious code scans
Define the frequency for malicious code scans within policy statements and procedures. Applying the FedRAMP moderate baseline organization defined-parameters, the first part of SI-3 reads:
Organizations should configure antivirus software to scan all hard drives at least weekly. Organizations may also enable on-access scanning . This performs real-time scans of files downloaded, opened, or executed.
Perform real-time scans of files from external sources
Organizations should include real-time monitoring of activities to check for suspicious activity. This includes scanning removable media inserted into a system before allowing its use. It also includes scanning incoming and outgoing email attachments for known malware.
Continuous Monitoring Tasks
A continuous monitoring task verifies that controls produce their desired outcome(s). These three practices have six desired outcomes:
Define locations for malicious code protection
Provide protection from malicious code at designated locations
Update malicious code protection mechanisms when new releases become available
Define the frequency to conduct malicious code scans
Perform malicious code scans within the defined frequency
Perform real-time scans of files from external sources
Update Network Diagram identifies dependencies between major services. This information is useful when making containment decisions in response to malware incidents.
Checking for New Vulnerabilities includes reviewing security alerts and weekly antivirus scans. This task may also include running monthly vulnerability scans.
Reporting Vulnerabilities involves documenting and prioritizing vulnerabilities based on their severity. This task should occur after identifying new vulnerabilities.
Patching Vulnerabilities should occur within 30-days of the release of a patch. Test patches before their deployment and verify deployed patches remain in place.
Develop and Maintain a Maintenance Log to ensure signature updates occur as scheduled. Verify configuration settings match any updates to the baselines.
Other tasks might include:
Review malware incident response procedures on an annual basis and after major incidents. Ensure incident handlers understand their role and how to perform their assigned tasks.
Verify log capture from malware detection sources on a weekly basis. This should include antivirus software, IDSs, SIEMS, DNS servers, applications, and network devices.
Conduct lessons learned assessment following major malware incidents. Review and update policies, awareness training, baseline configurations, and malware detection software settings.
Test and maintain backups monthlyto enable reinstallation of operating systems and applications.
Test the incident response plan on an annual basis to include malware scenarios.
Provide malware awareness training to all users on an annual basis.
Policy Statements
System Component Inventory
IT hardens system components by implementing security configuration checklists
The IT department maintains an inventory of system assets that
Documents ports used by each service
Identifies dependencies between major services
Awareness Training
IT provides training each year to make users aware of their role reducing malware risk
Malware Protection
IT staff complete annual training for malware prevention and incident handling procedures
IT deploys antivirus software on all system components for which it is available
IT configures systems to scan external media for malware before use
IT configures systems to scan email file attachments before use
IT prohibits the use of unnecessary software
IT prohibits the sending or receipt of certain types of files (e.g., .exe files) via email
IT restricts the use of removable media on systems accessible to the public
IT verifies antivirus software receive signature updates and scan systems weekly
IT restricts the use of mobile devices on the organization’s networks
Incident response
IT maintains an incident response capability that detects and responds to malware incidents
IT tests malware incident response plans on an annual basis
Proposed Rev 3 Changes
NIST SP 800-171 Rev 3 aligns 03.14.02 with SI-3 from SP 800-53 Rev 5. NIST consolidated these three Rev 2 practices into 03.04.02.
ODP[01] - define the frequency for malicious code protection mechanism scans
A[01] - deploy mechanisms to detect malicious code at system entry and exit points
A[02] - deploy mechanisms to eradicate malicious code at system entry and exit points
B - update malicious code protection mechanisms as new releases become available
C.01[01] - scan the system for malicious code at ODP[01]:frequency
C.01[02] - perform real-time scans of files from external sources for malicious code
C.02 - block, quarantine, or take other actions in response to malicious code detection
The crosswalk below shows the mapping to related practices from Revision 2:
Protection from malware threats involves both preventative controls and an incident response capability. Awareness and role-based training should supplement technical controls. Defensive architecture can reduce the likelihood and impacts of malware threats. Antivirus software alone may not detect new or evolving malware threats. Organizations should use both signature based and non-signature based detection methods. Establish and test malware incident response procedures to include containment, eradication, and recovery. Assign continuous monitoring tasks to ensure the effectiveness of all related controls.
If 3.1.1 authorizes access to the system, 3.1.2 authorizes permissions within the system. The rules of chess, for example, limit the types of functions allowed for each piece...
Organizations should prevent the release of nonpublic information on systems accessible to the public. Systems accessible to the public include websites and social media...
Identifying accounts and devices is foundational to creating a secure and accountable system. Accounts may have assignments to people and non-person entities...
%201.png)
%201.png)
