Adults don’t really like new ideas, and while cyber risk may have been born around the time of the first mainframes, it can still feel new today. CEB reported last month that 66 percent of business leaders don’t understand the cyber security information that goes to the board. This isn’t a failure of business leaders but of the messages they’re receiving.
While children consume and learn voraciously, adults struggle with finding context, skepticism, and social conditioning. Overcoming these cognitive biases to drive your company toward more risk-savvy behavior means you’re going to have to deliver a pretty clear and effective message. Keep in mind these three rules of thumb to improve how well your risk reporting is understood.
One message at a time. Yes, IT risk is complicated and often there are many steps between a threat and the preventative actions needed to keep them from happening. Keep those connections in your appendix for later questions. Instead, focus your reports on the actions needed to be taken. Don’t contrast vulnerability scans with failures in change management controls on the same page. The risk is different, the response is different, and you’re inviting confusion.
A single message has another benefit: if you are only trying to change one behavior, you’ll have a much easier time tracking the effectiveness of your message and adjusting in the future.
Risks become consequences. A focus on threat vectors, incidents and trends is good for figuring out where controls are weak or strong, but sometimes bad for grounding the danger in something meaningful for a non-cyber savvy professional.
Focus on the consequences of the risks being reported. Phishing simulations may show an increase of management clicking on suspicious links, but other than potentially receiving a scolding, why should people care? Link phishing to a particularly painful data loss event, or laptops held ransom, and include recovery time as well. There may be no effective recovery from ransomware, and reparations for exposed personal information could cost millions and take years. The Anthem data breach from February 2015 is still in the courts.
Consider your audience. One kind of message will rarely work for everyone. Not only will managers, VPs and executives all have different perspectives on the world and the work that IT security is doing, but they all have different backgrounds and interests.
Take a look at your audience. Will executive management be making decisions about change control check gates? Generally not, so your one message to them shouldn’t be to get them to improve the sign-off process in application development. Maybe the better message is that investments in release management software haven’t been effective in reducing production failures.
Tailoring risk reporting to the people receiving it is the best way to increase the odds that your message is received. It’s cumbersome, but this is the heart of risk management: to reveal connections between sometimes esoteric events and business opportunities so that leaders can make the right calls at the right time.
Editor’s note: Adam Leigh will present on “Consequences That Matter – IT Risk” at North America CACS 2017, which will take place 1-3 May in Las Vegas, Nevada, USA.
Adam Leigh, CISA, CISM, CGEIT, CRISC, Manager, ITRM Operations, MetLife
The New York State Department of Financial Services (DFS) cybersecurity regulations go into effect today. In this blog post, I’ll share what these regulations mean and the biggest changes that financial services companies can expect over the next several months.
As a recap, in late December 2016, the DFS published its revised proposal for cybersecurity regulations. The proposal explicitly calls out the need for and the responsibilities of a Chief Information Security Officer (CISO) function. The occupant of this role must be a qualified individual responsible for overseeing and implementing the cybersecurity program. Similarly, the regulation calls for the use of qualified cybersecurity personnel with current knowledge and ongoing training in that discipline. Although the qualifications of these individuals are not explicitly defined, the implication is that they are and must remain well-versed in cybersecurity.
The DFS also puts explicit demands on the senior officers or board of directors to ensure their active participation in the cybersecurity program. This includes approval of the cybersecurity policy, review of an annual report by the CISO (effective February 15, 2018), and an annual certification of compliance – signed by an individual. This last piece is reminiscent of the Sarbanes-Oxley Act and opens the door for potential individual liability. Clearly, the intent is for that senior officer and the entire board to take their cybersecurity responsibility seriously.
Compliance dates for various portions of the proposed regulation are staggered over the next 24 months. This was a change from the original proposal and is an acknowledgement of the challenges that covered financial institutions will face in complying with specific provisions of the regulation. Here’s a look at a few of these just to provide a flavor for the difficulties to achieve compliance.
At the 12-month stage, covered entities will need to have multi-factor or risk-based authentication in place for access to nonpublic information – even internally. Many financial institutions use multi-factor authentication (MFA) for remote access to their corporate networks, but few have adopted it for access to internal resources as there are additional complexities and costs involved. Moreover, for legacy applications or systems that do not support MFA natively, a compensating control will be needed to protect the nonpublic information there.
At 18 months, encryption of nonpublic information both in transit and at rest will be required. Where this is infeasible, CISO-approved compensating controls are acceptable, but they must be reviewed annually. Financial institutions typically encrypt the data on laptops as those are prone to loss or theft. However, encryption of data at rest on servers or in databases may not be common practice, except where payment cardholder information is involved. This will have to be expanded to include any nonpublic information. Data, in transit, should ideally be encrypted by the application. Consequently, this may require changes to a large number of commercial and internally developed applications. However, some older applications may be unable to encrypt natively. In such cases, encryption could be delegated to the network as an alternate control.
At the 24-month mark, financial institutions will need measures in place to ensure the security of nonpublic information that is accessible to or held by third-party service providers. The long lead time for this is necessary, given the quantity of suppliers or partners that may have access to or handle nonpublic information. The initial risk assessment, definition of minimum cybersecurity practices, subsequent contract revisions, etc. with third-party services providers will clearly be time-consuming. Some financial institutions already have enterprise risk management programs in place, which include some degree of vendor risk management. However, even these will need to be broadened to monitor cybersecurity risks at providers that touch nonpublic information.
At the federal level, the themes of active board participation and concern over third-party cybersecurity risks have also been echoed. The Federal Reserve Board, the Office of the Comptroller of the Currency (OCC), and the Federal Deposit Insurance Corporation (FDIC) have issued an advance notice of proposed rulemaking (ANPR) for enhanced cyber risk management. Public comments were due in late January 2017, but as written, the ANPR calls for more active board-level involvement in cybersecurity programs and the extension of enhanced standards to address cyber risk at third-party providers to the financial sector as well.
Financial institutions licensed by the state of New York should develop their plans to address the provisions of the newly effective cybersecurity regulation but keep an eye on the progress of the proposed federal regulations as well, if applicable. In the end, financial institutions may be better served by developing an overarching cybersecurity program that will encompass their risks and ultimately subsume regulatory requirements. Other states may follow New York’s lead and conceivably introduce their own cybersecurity regulations as well. As global financial institutions already know, variations in regulations across jurisdictions can be complex to manage in a piecemeal fashion.
Recently, we have discovered 132 Android apps on Google Play infected with tiny hidden IFrames that link to malicious domains in their local HTML pages, with the most popular one having more than 10,000 installs alone. Our investigation indicates that the developers of these infected apps are not to blame, but are more likely victims themselves. We believe it is most likely that the app developers’ development platforms were infected with malware that searches for HTML pages and injects malicious content at the end of the HTML pages it finds. If this is this case, this is another situation where mobile malware originated from infected development platforms without developers’ awareness. We have reported our findings to Google Security Team and all infected apps have been removed from Google Play.
Figure 1: A subset of all infected samples on Google Play
The infected apps that we observed included apps for design ideas ranging from cheesecake, to gardening and coffee tables, as shown in Figure 1. What all the apps have in common is that they employ Android WebView to display static HTML pages. At the first glance, each page does nothing more than loading locally stored pictures and show hard-coded text. However, a deep analysis of the actual HTML code reveals a tiny hidden IFrame that links to well-known malicious domains. Although the linked domains were down at the time of investigation, the fact that so many apps on Google Play are infected is notable.
What is more notable is that, one of the infected pages also attempts to download and install a malicious Microsoft Windows executable file at the time of page loading, but as the device is not running Windows, it will not execute. This behavior fits well in the Non-Android Threat category recently released by the Google Android Security. According to the classification, Non-Android Threat refers to apps that are unable to cause harm to the user or Android device, but contains components that are potentially harmful to other platforms.
How the Infection Works
All infected apps currently only require the INTERNET permission and are equipped with two activities, one is to load interstitial advertisements and the other one is to load the main app. The latter one instantiates an Android WebView component and displays a local HTML page (Figure 2). The WebView component has JavaScriptInterface enabled. This functionality isn’t used by the samples we’ve examined, but this enables loaded JavaScript code to access the app’s native functionality.
Figure 2: An example of the infected sample’s UI and its underlying code
Each HTML page only displays pictures and text. However, at the end of each HTML page, a tiny hidden IFrame component has been added. We have observed two techniques used to hide this IFrame. One is to make the IFrame tiny by setting its height and width to be 1pixel. The other one is to set the display attribute in the IFrame specification to None. Finally, to evade detection based on simple string matching, the source URLs are obfuscated using HTML number codes. In the examples shown in Figure 3, browser automatically performs the following conversions:
‘.’ → ‘.’
‘i’ → ‘i’
‘u’ → ‘u’
Figure 3: Two techniques observed in infected samples to hide the IFrame region
Eventually, all IFrame sources converge to two domains:
www[.]Brenz[.]pl/rc/
jL[.]chura[.]pl/rc/
The Polish CERT (cert.pl) took over both of these domains in 2013 and directed them to their sinkhole server to prevent them from harming users (Figure 4). Given that, both domains are not hosting malware at the time of our investigation, but they have a notorious history[1,2,3,4,5].
Figure 4: Both malicious domains current resolve to a sinkhole server.
During our investigation, we also identified a sample that didn’t contain an infected IFrame, but an entire VBScript was injected into the HTML (Figure 5). The script contained a Base64 encoded Windows executable that (on a Windows system) the script would decode, write to the file system, and execute. Since VBScript is a proprietary Microsoft Windows scripting language, the script is inert and does not execute on the Android platform: this piece of code will not cause damage to Android users. First of all, the code is appended outside the <HTML> tag, which makes it an illegal HTML page. But browsers have always attempted to render pretty much anything, whether it is malformed or not, in order not to make creating HTML pages difficult for people who might not understand the standard completely.
WildFire detects several malicious behaviors within the dropped PE file, including:
modify the network hosts file
modify windows firewall settings
inject code into another process
copy itself
Figure 5: Infected sample attempts to drop a window executable file
The Origin of the Infection
The 132 infected apps we discovered belong to seven different, unrelated developers. There is a geographical connection among the seven different developers: all seven have connections to Indonesia. The most straightforward clue comes from the app name. A significant number of discovered samples have the word “Indonesia” in their names. Moreover, one developer’s website links to a personal blog page written in Indonesian. The clearest pointer, though, is one developer’s certificate clearly states the state to be Indonesia.
Figure 6: Infected samples’ connection to Indonesia
One common way HTML files have been infected with malicious IFrames has been through file infecting viruses like Ramnit. After infecting a Windows host, these viruses search the hard drive for HTML files and append IFrames to each document. If a developer was infected with one of these viruses, their app’s HTML files could be infected. However, given that the developers may all be Indonesia, it’s also possible they may have downloaded an infected IDE from the same hosting website or they used the same infected online app generation platform.
In either case, we believe the developers are not malicious and are victims in this attack. There are a few other pieces of supporting evidences from our investigation:
All samples share similarities in their coding structure, suggesting that they may be generated from the same platform;
Both malicious domains used resolve to sinkholes. If developers were the attacks behind all these, they could have replaced them with working domains to cause real damage;
One infected sample attempts to download windows executable file. It suggests that, the attacker does not know about the target platform. Clearly, this is not the case for app developers.
Potential Damages and Mitigation
Currently, infected apps will not cause damage to Android users. However, this does represent a novel way for platforms to be a “carrier” for malware: not be infected themselves but spread the malware to other platforms without realizing it. Similar to the XcodeGhost attack we identified in 2015, this threat shows how attacking developers can impact end-users.
It’s easy to envision a more focused and successful attack: an attacker could easily replace the current malicious domains with advertising URLs to generate revenue. This not only steals revenue from app developers, but also can damages the developers’ reputation. Secondly, aggressive attackers could place malicious scripts on the remote server and utilize the JavaScriptInterface to access the infected apps’ native functionality. Through this vector, all resources within the app would be available to the attackers and under their control. They could also operate silently to replace the developer’s designated server with their own, and as a result, whatever information that was sent to developer’s server now falls in hands of the attacker. Advanced attackers can also directly modify the app’s internal logic, i.e., adding rooting utility, declaring additional permissions, or dropping malicious APK file, to escalate their capabilities.
WildFire customers are automatically protected against all infected samples. The APK analysis engine inside WildFire is capable of not only identifying the tiny hidden IFrame, but also correlating with the embedded domains.
Acknowledgements
We would like to thank Zhi Xu and Claud Xiao from Palo Alto Networks for their assistance and comments during the investigation. We greatly appreciate the expedited response from Google Security Team to help verify and take actions on the infected apps.
Appendix
Malicious domains:
www[.]Brenz[.]pl/rc/
jL[.]chura[.]pl/rc/
Infected samples’ hashes and package names (additional samples are available upon request through the blog comments):
Today we announced that LightCyber has joined Palo Alto Networks. LightCyber’s technology will bring award-winning, highly automated and accurate behavioral analytics technology to our Next-Generation Security Platform, enhancing our ability to catch hard-to-find threats like internal reconnaissance and lateral movement inside the network.
What does LightCyber technology do?
Founded by cybersecurity experts in 2012, LightCyber has been leading the industry in the development of automated behavioral analytics capabilities. LightCyber uses sophisticated machine learning to quickly, efficiently and accurately identify attacks, based on identifying behavioral anomalies inside the network. LightCyber’s products have been successfully deployed by top-tier companies in the financial, healthcare, legal, telecom, government, media and technology sectors.
How does LightCyber fit into the Palo Alto Networks Next-Generation Security Platform?
LightCyber enhances our ability to prevent attacks across the attack lifecycle, especially at the internal reconnaissance and lateral movement stages that are often very important to a successful attack. With LightCyber added to our platform, we can further prevent command-and-control activity and data exfiltration by detecting anomalous behavior. Customers will gain unrivaled protection against targeted attacks, insider threats, risky behavior and malware inside the network.
Since our inception, Palo Alto Networks has pioneered new ways of tackling seemingly impossible security challenges, providing unprecedented visibility into user and application traffic as well as exceptional breach prevention capabilities. The LightCyber automated behavioral analytics technology represents another step in our evolution toward delivering a platform at the forefront of the innovation curve.
Adults don’t really like new ideas, and while cyber risk may have been born around the time of the first mainframes, it can still feel new today. CEB reported last month that 66 percent of business leaders don’t understand the cyber security information that goes to the board. This isn’t a failure of business leaders but of the messages they’re receiving.
While children consume and learn voraciously, adults struggle with finding context, skepticism, and social conditioning. Overcoming these cognitive biases to drive your company toward more risk-savvy behavior means you’re going to have to deliver a pretty clear and effective message. Keep in mind these three rules of thumb to improve how well your risk reporting is understood.
One message at a time. Yes, IT risk is complicated and often there are many steps between a threat and the preventative actions needed to keep them from happening. Keep those connections in your appendix for later questions. Instead, focus your reports on the actions needed to be taken. Don’t contrast vulnerability scans with failures in change management controls on the same page. The risk is different, the response is different, and you’re inviting confusion.
A single message has another benefit: if you are only trying to change one behavior, you’ll have a much easier time tracking the effectiveness of your message and adjusting in the future.
Risks become consequences. A focus on threat vectors, incidents and trends is good for figuring out where controls are weak or strong, but sometimes bad for grounding the danger in something meaningful for a non-cyber savvy professional.
Focus on the consequences of the risks being reported. Phishing simulations may show an increase of management clicking on suspicious links, but other than potentially receiving a scolding, why should people care? Link phishing to a particularly painful data loss event, or laptops held ransom, and include recovery time as well. There may be no effective recovery from ransomware, and reparations for exposed personal information could cost millions and take years. The Anthem data breach from February 2015 is still in the courts.
Consider your audience. One kind of message will rarely work for everyone. Not only will managers, VPs and executives all have different perspectives on the world and the work that IT security is doing, but they all have different backgrounds and interests.
Take a look at your audience. Will executive management be making decisions about change control check gates? Generally not, so your one message to them shouldn’t be to get them to improve the sign-off process in application development. Maybe the better message is that investments in release management software haven’t been effective in reducing production failures.
Tailoring risk reporting to the people receiving it is the best way to increase the odds that your message is received. It’s cumbersome, but this is the heart of risk management: to reveal connections between sometimes esoteric events and business opportunities so that leaders can make the right calls at the right time.
Editor’s note: Adam Leigh will present on “Consequences That Matter – IT Risk” at North America CACS 2017, which will take place 1-3 May in Las Vegas, Nevada, USA.
Adam Leigh, CISA, CISM, CGEIT, CRISC, Manager, ITRM Operations, MetLife
