«June 2011 BITS A DIVISION OF THE FINANCIAL SERVICES ROUNDTABLE 1001 PENNSYLVANIA AVENUE NW SUITE 500 SOUTH WASHINGTON, DC 20004 202-289-4322 ...»
Within the categories of customer attacks, there will be different risks associated with the type of customer relationship, e.g., individual versus corporate clients. FI risk management strategies will differ based on the target of the attack. FIs should examine the flow of sensitive data through computing devices, and conduct multiple risk assessment scenarios. Each scenario should assume that different subsets of the devices through which sensitive data flows are infected with malware.
Each scenario should be analyzed from multiple perspectives. For example, here are some simple
questions to be answered in the course of each assessment:
1. What is the potential harm to ourselves/our partner/ our customer if the device(s) involved in the scenario is infected with type of malware?
2. How might we detect the infection?
© BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report
3. How could we remediate the infection?
4. If we are unable to remediate the infection, is there someone else who could? How would we initiate that process?
5. If we are unable to detect the infection, when/how will we become aware of the consequences of the infection?
6. Is there a stage of the attack where we might become aware of the attack before we/our partner/our customer suffers harm?
If and where any of the analysis of malware infection scenarios results in probable damage or loss, FIs should consider products, services, partnerships, or industry initiatives that may be leveraged to improve the scenario’s risk profile. Of course, this exercise will be guided by the FI’s evaluation with respect to both risk tolerance and cost/benefit trade-offs.
Options for risk mitigation will also vary, and these will be based on the attack vector as well as the target. In order for any FI to successfully complete a scenario-based malware risk assessment, it must employ personnel who are cognizant of malware threats from all kinds of technical devices, including customized corporate devices, personal devices used for FI business communication or transactions, and third-party devices such as partner-provided network connections or airport or hotel kiosks used by traveling employees for remote access. As the threat environment continually evolves, personnel must continually seek new sources of current information on the types of malware being distributed and the common modus operandi deployed by cybercriminals. The FSISAC exists to serve this purpose, and has several processes with which to facilitate the communication of threat, vulnerability, and countermeasure information among FIs, software vendors, and government intelligence sources.
5.1 Situational Awareness
Regardless of its source, for a malware attack to be effective, each of the multiple steps – reconnaissance, assembly, delivery, compromise and execution (Figure 1) – must be successful.
Reconnaissance may occur internally or from remote sources. Assembly may make use of java toolkits, php scripts, or command line batches. Delivery and compromise may occur via WebInternet User-Initiated attacks or any other vector listed in Section 4.1. Command stages may include remote control of dormant bots or active and continuous keystroke logging. Exfiltration may be continuous or malware may stash data locally until it is retrieved. There are also a variety of other attack choice combinations, limited only by the imagination and programming skills of the adversary.
Although end-user awareness and training had typically provided defense in depth in security measures, malware attacks tend to follow the same pattern as a variety of legitimate software installation processes that conflict with typical FI security software setting, and so easily escapes even vigilant end-user detection. Users have been inundated with security instructions over the past decade that have not been effective in reducing their vulnerability to data loss and identity theft, © BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report while at the same time they are constantly exposed to unnecessary security pop-up warnings. So real malware would appear to them to be yet another false positive. Unless an FI can develop accurate guidance on how to tell the difference between false positives and malware, most security advice will seems like a poor cost-benefit tradeoff to users, and so will be rationally rejected .
Moreover, malware operators will constantly vary attacks so that if any one is discovered, it will not lead to the detection of a similar one. Figure 12 is an example of alternative pathways for attack progression. It is important that FI detection processes be as flexible and adaptable as the capabilities of the adversary. The earlier in this attack progression an FI can detect that an attack is underway, the more damage may be averted.
Figure 12: Alternative Attack Choices 
FIs must be careful not to over-rely on traditional anti-virus software to detect malware infections.
Polymorphic malware has made those methods unreliable. To keep pace with these new malware trends, many anti-virus and anti-malware software providers are incorporating heuristic capabilities into their products. These monitor software process behavior and attempt to identify anomalies.
Heuristic malware detection can be effective, but often at the price of system performance.
While polymorphic malware may be capable of evading detection by traditional mechanisms, it can often be detected through the effects of the actions it takes. Organizations that monitor for unauthorized file level changes and for unauthorized or unusual communications patterns both within a network and through the network’s perimeter may have a view into activity associated with © BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report malware. Botnet and APT command and control activity can often be detected at the network level with specialized appliances being offered by a number of security vendors. This activity can also be gleaned from the analysis of server, proxy and firewall logs.
FIs typically monitor multiple aspects of their operation, and these monitoring processes may be engaged to assist in identifying and minimizing the impact of malware attacks. For example, FIs have monitoring processes that detect red flags in customer transactions. These range from anomalies in web server logs to unusual customer transaction patterns . FIs also have monitoring processes designed to detect and respond to events that impact technology operations. Malware operators will attempt to stay below the radar of these monitoring processes, so FIs may need to adjust them in order to bring malware to the forefront of situation awareness. Red flag detection processes in different departments or business units may be combined with IT incident detection.
Where malware incidents are detected, appropriate responses should not only mitigate the financial damage, but may involve redesigning internal processes to ensure the same attack vector will not be successful in the future.
Figure 13: Enterprise Incident Response 
Figure 13 depicts a typical FI enterprise incident monitoring and response process that may be utilized to detect and respond to malware. Those with responsibilities for first response to technology and operations incidents are typically technicians who follow rote procedures to © BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report determine the scope of an incident, resolve it if possible, and if not, hand it off to a more skilled administrative contact in the problem domain. This next level of support will attempt to resolve problems, but also recognize when the problem solution is beyond their capability and so requires escalation to more specialized expertise such as that found in systems engineers or application developers. Wherever an FI has such an alert and incident response process in place, whether based on automated monitoring or end-user trouble reports, there should be increased recognition at all levels of escalation that the root cause of the incident may be malware.
Additional processes designed to respond to malware that FIs should consider implementing at an enterprise level, if they are not already incorporated into existing incident detection response
Identification: to ensure that incidents that have been identified as caused by malware are catalogued as such so that appropriate follow-up may be thorough and provide comprehensive insight into the overall state of the malware situation in proper context Eradication: to ensure that systems infected with malware are removed from service and reconstituted in such a way that does not allow malware persistence post reconstitution; reconstitution differs from recovery in that it implies rootcause forensic analysis and system configurations developed to ensure that the entity is no longer vulnerable to the same type of attack Resilience: to ensure that malware incidents do not have a lasting effect on business operations, damaging impact is minimized, and that operations processes are modified to incorporate prevention and detection techniques that would prevent the same type of attack in the future The proper selection of controls to be included in each process will of course be based on circumstances specific to the FI business process. However, the scope of controls may extend to the customer, vendor, or business partner environment. For example, malware at a customer site may result in transfer of customer account balances to a malware operator. In this case, the FI may identify and catalogue the event via a Red Flag monitoring process, recommend that the customer initiate an eradication process, and provide services such as positive pay or two-factor authentication as resilience measures.
5.2 Risk Management
A 2010 end-of-year Gartner technology report warned clients to make a strategic planning assumption that by 2015, a G20 nation's critical infrastructure will be disrupted and damaged by online sabotage . The report cautioned that, although such attacks may appear to begin with a narrow scope, they should be assumed to be capable of lasting repercussions due to the inclusion of multimodal attack techniques over time. By several estimates, a large percentage of both internal and external users experienced an average of more than 100 web malware encounters per month, increasing the probability that any given user will be infected [31, 32]. Although specific numbers in various surveys that chronicle increasing costs of data breaches may be debated, it is obvious that © BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report both the variety of incidents and the quantity of data lost is constantly rising, and that each incident is accompanied by monetary loss [45-47]. FIs should do their own risk analysis. According to the US Secret Service, given current evidence that there are large criminal communities directly targeting the US financial sector, FI exposure to malware is extremely high and should be treated with the probability of 1 in FI risk management calculations .
Malware presents a range of evolving risks: reputational, regulatory, financial, and legal. Reputational risk is increased because of the high visibility created by reporting requirements and the volume of information at risk. Regulatory risk is derived from the types of information assets targeted by malware operators, which include personally identifiable information, account information, and deposits, as well as the criticality of the service and the provider to the monetary system. Security requirements for these information assets are included in the Gramm-Leach-Bliley Act (GLBA), Sarbanes-Oxley Act (SOX), Payment Card Industry (PCI) Data Security Standard, and the Health Insurance Portability and Accountability Act (HIPAA) [48-51]. Financial risk may be estimated using potential losses associated with successful malware attacks. Legal risk may be associated with civil challenges on due care and due diligence issues .
Proceeding on the assumption that malware presents risk to FIs, there are a number of standard controls that may mitigate the risk. The first and most important is software change control.
Software change control refers to a process whereby software is developed, compiled into packages for installation, labeled with version numbers, deployed by authorized personnel, and tracked on production systems. To be effective against malware, software change control processes must continue to track software through its deployment and operation. Changes to software must be automatically detected. Upon detection of a change, the change must be analyzed by someone with sufficient knowledge and reference materials to tell the difference between an authorized change and an unauthorized change. The reference materials should include tests such as cryptographic checksums that can be used to verify that code deployed in production is the same as the package that was delivered from a development environment or vendor. These detection processes must occur immediately after changes are detected. Changes must be detected on all operating system platforms and monitored for integrity, as malware operators are likely to attempt to disable or corrupt the software used for change monitoring.
Change monitoring should not be limited to software, but should extend to security configuration and role assignments such as start-up variables, firewall rules, and privileged accounts. Privileged account monitoring must be established in conjunction with a policy of authorized account usage so that authorized use may be distinguished from unauthorized use. For example, where users or software running in an administrator context is typical in a firm, this scenario used to install malware would not be detected as an intrusion. Even desktop administrators should be furnished with separate accounts reserved for privileged operations. Ideally, administrative access would be segmented so that systems would be subject to malware compromise via only a small percentage of total system users.
© BITS/The Financial Services Roundtable 2011. All Rights Reserved.
BITS Malware Risk and Mitigation Report Another standard control that is a critical component of any malware mitigation strategy is control over the network periphery. This control requires that an FI establish a clear policy that allows administrators to determine authorized from unauthorized connections, and oversight that ensures compliance with these policies. Firewall rules and security configurations over all network equipment should also be subject to change control as described above for software. FIs with network peripheries that are too large to manually review firewall rules in near real-time should have automated means to determine policy compliance for both inbound and outbound network connections. Lists of malicious sites are published and announced to FIs by the FS-ISAC.
Connections to or from the FI network to any published malicious site should be restricted via automated means. Both inbound and outbound network traffic should be examined for known malware patterns and signatures using intrusion and/or prevention detection systems. Any discretionary Internet traffic generated by FI users that may be a conduit for malicious content, such as email and web browsing, should be routed to choke points where proxy servers may be employed to inspect content for malware signatures as well as sensitive data. Proxy servers are frequently capable of decrypting encrypted web traffic, and these servers should block encrypted traffic if it cannot be decrypted for inspection (of course, exceptions may be made for authorized business applications).
A third critical component of any malware mitigation strategy is vulnerability management.