Executive summary
...
2
1. Threats to websites and countermeasures
...
4
1.1.Attacks from the Internet ... 4
1.2.Countermeasures taken by organizations for their websites ... 11
2. Threats to endpoints and countermeasures
...
19
2.1.Attacks from the Internet ... 19
2.2.Countermeasures by "people" against malware infection ... 24
2.3.Countermeasures assuming malware infection ... 27
3. Case study and issues in incident handling ...
32
3.1.Incident handling by CSIRTs ... 32
3.2.Case study and issues in incident handling ... 33
4.
Conclusion
...
39
Cyber Security Trend - Annual Review 2014
- Organizations are Centrally Aware of Only 50% of Their Own Website(s);
Call for Reconsidering Inventory Management-
e sum
mar
y
Executive summary
Threats to Websites
- Organizations are Centrally Aware of Only 50% of Their Own Website(s); Call for Reconsidering Inventory Management -
The result from the websites inventory service we provide revealed that organizations are aware and grasp only approximately 50% of sites they own. In the event of a high-risk vulnerability disclosure, an organization should investigate how vulnerable products are used as well as network configuraton such as those products are open to the Internet or not. However, as we would also be in-the-dark for approximately 50% of the company's managed website, that portion of “unknown” site would unfortunately be excluded from those investigation and remain exposed to the threats. Identifying an organization's precise inventory is the first task in securely managing their website(s). Although it may be common sense, the task is difficult and made even more-so as companies continue to grow in size and complexity. With organizations restructuring and migrating into the overseas market, and cloud services becoming even more widespread, the necessity of reconsidering inventory management of websites is intensifying.
- Understanding the Risks of Software Product Support Discontinuation and the Necessity for Product Upgrade -
When high-risk vulnerabilities in PHP and Struts2 were disclosed in 2013, we confirmed that the duration between the disclosure and attacks was shorter than similar vulnerability windows in 2012. The countermeasure against such attacks is applying security patches promptly to fix the vulnerabilities before attacks begin; however, there may be software products that no longer provide patching support for your websites. Upgrading of software products that lack patching support is necessary to continue obtaining security patches. Upgrading may involve modification of web applications and requires time; therefore, it can be extremely difficult to complete the process within a recent short vulnerability window that is disclosure and attack. Using a Web Application Firewall(WAF) as a temporary solution prior to upgrading your out-of-date products is highly recommended.
Threats from Targeted Attacks
- Call for Implementation of Operational Systems with Effective Application of Outbound Pro-tection proPro-tectionProducts -
As malware infection methods and routes are becoming more and more complex, it is also becoming more difficult to completely prevent malware infections, even if you have implemented inbound protection and endpoint protection aimed solely at preventing malware intrusion and infection. In addition to those protections, outbound protection has become the focus of attention that is a countermeasure on assumption of having internal clients that malware have infected already. Some outbound protection products can perform correlation analysis of traffic to identify clients that unknown malware have infected already. However, this requires human intervention and analysis to determine whether the detected case is legitimate malware or not, since this function does not involve pattern matching. Resolving an incident under such "gray situation" is the new big issue for organizations, and there is a growing need for implementing operational systems with the knowledge and skills to solve this issue.
■
Issues from Computer Security Incident Response Team(CSIRT) Operations
- Fusion of Systems and Human Resources, and Continuous Training and Education are Vital in CSIRT Operations -
e sum
mar
y
sophisticated and complex cyber attacks promptly and accurately is extremely difficult without appropriately combining these key factors. CSIRTs operations require continuous training and education to take on the challenges of maintaining response capability against attacks that are advancing day-by-day.
Research outline
This report analyzes data which NRI Secure collected in fiscal year 2013(April 1, 2013 to March 31, 2014) through the following security services. Older data is also used in some places in order to analyze the trend in past years.
Managed security services
- FNC1 Secure Internet Connection Service
An outsourcing service providing security countermeasures required for safe connection between customers' internal networks and the Internet, such as e-mail gateways, proxy servers, and remote access. This report summarizes logs from virus check servers for 45 companies, and next generation firewalls for 22 companies among gateway servers managed by the FNC Secure Internet Connection Service.
- FNC Secure Web-Net Management Service
An outsourcing service providing security countermeasures to protect customers' websites from cyber attack. It monitors security devices such as firewalls, intrusion detection systems(IDS2), intrusion prevention systems(IPS3), and web application firewalls(WAF4) 24/7. This report summarizes logs from WAFs for websites of 29 companies managed by FNC Secure Web-Net Management Service.
Security assessment service
- Platform Assessment
A service which inspects security holes and setting statuses of system infrastructures such as servers and network devices from outside(the Internet) or inside the LAN, and provides the assessment on the risks of detected flaws based on our own criteria. This report summarizes 126 systems on which we carried out the assessment in 2013.
- Web Application Assessment
A service which detects hidden security flaws in web applications with considerations to the web application implementation, development languages, and platforms, and reports the assessment on the risks of detected flaws based on our own criteria. This report summarizes 582 systems on which we carried out the assessment in 2013.
- Website Group Inventory Service(GR360)
A service which search public websites related to a given organization using our proprietary algorithm, and carry out simple security checks on those discovered sites to determine the overall security level of the website group. This report summarizes 6,216 sites(4,354 domestic sites and 1,862 overseas sites) on which we carried out the simple security checks in 2013.
-Targeted E-mail Attack Simulation
A service which checks and reports employees' response to targeted e-mails by sending e-mails attached with fake malware and monitors if the employees open the attached file. This report summarizes the result from 98,049 e-mails sent from April 2013 to March 2014.
* NRI Secure presented a proposal of specific countermeasures with the assessment results to organizations whose systems contained security flaws, and strongly recommended that they apply the countermeasures immediately. As a result, we assume that the most of these websites have applied the appropriate countermeasures and are now secure.
Threats to w eb site s an d count erme asure s
1. Threats to websites and countermeasures
1.1. Attacks from the Internet
The FNC Secure Web-Net Management Service monitors access from the Internet to websites, and logs rogue attempts blocked by the firewalls. Numerous attacks on websites were detected in 2013 as they were in 2012. Let us see the overview of attacks on websites in 2013. Figure 1 shows the simplified configuration diagram of WAFs that are subject to this summary.
Figure 1 Simplified WAF configuration diagram
Figure 2 Breakdown of attacks on websites detected by WAFs(n=240,403)
Figure 2 shows the breakdown of attacks on websites by the target software components. This reveals 48% of attacks were targeted at web applications. It was followed by web servers, middleware, and then OS’s. Detected attacks on web applications were mainly of SQL injection, remote file inclusion(RFI), cross-site scripting(XSS), and cross-site request forgery(CSRF). There is no major change in the trends. Detected attacks on web servers were mainly on Apache vulnerabilities(CVE-2011-3192, CVE-2011-3368) and inadequate configurations and/or vulnerabilities of IIS. Continuing attacks on vulnerabilities that were disclosed in 2011 indicate there are still many websites running without countermeasures.
Attacks on OS’s were mainly “spying” such as port scanning as they had been for past years. These attacks do not directly result in damage. While attacks on middleware made up the smallest part, they mainly targeted vulnerabilities that allowed remote execution of arbitrary code in PHP and Apache Struts 2 that were deployed in a comparatively large number of websites. The overall trend was that the duration between the disclosure of
Threats to w eb site s an d count erme asure s
Trend in attacks on middleware
Remote file inclusion(RFI) targeting PHP
RFI is an attack method which sends a malicious URL to the targeted website and make the target website read and execute attack code placed on another server. Vulnerabilities that allow RFI are highly dangerous because the attacker can execute any attack code on the targeted website if the RFI attack is successful.
Figure 3 Remote file inclusion attack
Vulnerabilities in PHP are often targeted by RFI attacks. We will take CVE-2012-1823 and CVE-2012-2311 among RFI attacks targeting PHP in 2012 as examples to make a comparison of the duration between the vulnerability disclosure and detection of attacks. An attack method on this vulnerability was disclosed first in May 2012 when the vulnerability was disclosed, and a different attack method was disclosed again a year and half later in November 20132 . Table 1 shows vulnerability information of PHP(CVE-2012-1823 and CVE-2012-2311).
Table 1 PHP vulnerability information(CVE-2012-1823 and CVE-2012-2311)
Threats to w eb site s an d count erme asure s
The attack method disclosed in 2012 enabled execution of arbitrary code by passing an argument to a PHP script to attack the vulnerability while PHP was running in a CGI environment. Therefore the general consensus was that this vulnerability had no effect in environments where PHP scripts were not placed in public areas. However, a new attack method was disclosed a year and half later on October 29th 2013. This method directly attacked PHP processing system such as "/cgi-bin/php" "/php-cgi/php" even when PHP scripts were not placed in public areas. This enabled attackers to attack more efficiently without need of searching for public PHP scripts. Figure 4 shows the number of detected attacks using new attack code.
Figure 4 Number of detected attacks using new method(daily history)
The disclosure of the vulnerabilities(and new attack code) was on October 29th 2013 and the attack was detected after 3 days on November 1st. When the given vulnerability was disclosed in May 2012, the first attack was detected 6 days later. This is an example that shows duration between the vulnerability disclosure and detection of attacks is becoming shorter. PHP users with the vulnerable version would have thought "We should not be affected because attackers cannot use the disclosed attack method", and many would have continued using the vulnerable version without upgrading it. This case also shows that even if workarounds or mitigation countermeasures are available, the fundamental solution to vulnerabilities is patching.
Attacks on vulnerabilities in Apache Struts 2
Another example is with Apache Struts 2, a popular web application framework. Among vulnerabilities in Apache Struts 2 disclosed in 2013, vulnerability information CVE-2013-2248 and CVE-2013-2251 disclosed in July are shown in Table 2 and the numbers of detected attacks on these vulnerabilities(daily history) are shown in Figure 5.
Threats to w eb site s an d count erme asure s
Figure 5 Number of detected attacks related to CVE-2013-2248 and CVE-2013-2251(daily history) High-risk vulnerabilities in Apache Struts 2 that allowed attackers to execute arbitrary code were also disclosed in 2012(2012-0391, 2012-0394, etc.) The first attacks were detected 8 days after the disclosure of CVE-2012-0391, and 6 days after the disclosure of CVE-2012-0394. Exploitation was becoming significantly spontaneous for CVE-2013-2248 and CVE-2013-2251 shown in Figure 5; the first attacks were detected on the following day of the disclosure.
Shorter duration between the disclosure of vulnerabilities and attacks means a shorter grace period to apply countermeasures on websites which deploy the software with the given vulnerabilities. Ideally, the countermeasure should be patch application as described in the example of RFI vulnerabilities in PHP; but can an organization’s website catch up with the ever-diminishing windows of vulnerability?
Threats to w eb site s an d count erme asure s
Operational status of middleware
Operational status of PHP
Our Website Group Inventory Service "GR360" checks vulnerabilities in HTTP servers and middleware running on web servers by performing simple security checks on websites. 6,216 websites underwent simple security checks by GR360 in 2013 and figure 6 summarizes PHP versions running on the websites.
Figure 6 Operational status of PHP(n=807)
Only PHP 5.3.x and later were supported and PHP 5.2.x and earlier versions were no longer supported when checks were carried out. Figure 6 shows 56% of websites were still running versions that were no longer supported. Vulnerabilities in PHP we have already discussed(CVE-2012-1823, CVE-2012-2311) were in PHP 5.3.x and PHP 5.4.x which were still supported; therefore, it was possible to apply patches supplied by the developer. However, if any vulnerability is found in PHP 5.2.x or earlier, the basic countermeasure would be to upgrade to a supported version on PHP since the developer would not supply the patches.
There are 3 types of PHP upgrades; these are major, minor, and point version upgrades. PHP manages its versions with major, minor, and point numbers.
Threats to w eb site s an d count erme asure s
New functions are not added in point version upgrades, only in minor and major version upgrades for PHP. For example, the migration guide3 for the minor version upgrade from PHP 5.2.x to PHP 5.3.x describes changes in functions that are not backward compatible and functions that are not recommended to be used with PHP 5.3.x. In other words, you need to review the effects those changes and new functions may cause to web applications before a minor version upgrade from PHP 5.2.x to PHP 5.3.x, and modify those applications if necessary. You also need to refer to the past migration guides if you are using PHP 5.2.x or earlier. This will add more time required for the upgrade preparation. While the work may be carried out relatively swiftly for point version upgrades which cause less effects on web applications, Figure 6 indicates that upgrades to supported versions of PHP were sluggish even when support for PHP 5.3.x was about to be withdrawn in July 20134.
Operational status of Struts
Among 46 websites running Struts, we found 45 sites with Struts 1 whose support was withdrawn in April 2013. A major version upgrade is required from unsupported Struts 1 to supported Struts 2; however, effects on web applications must be confirmed as described in the previous section. Structures of Struts 1 and Struts 2 differ significantly because Struts 2 is based on WebWork, a framework that is different from the one used for Struts 1. Therefore, upgrading from Struts 1 to Struts 2 is not easy. This may be the cause of sluggish migration to the supported version as it is so for PHP.
Figure 8 Operational status of Struts(n=46)
3. http://www.php.net/manual/ja/migration53.php 4. http://php.net/archive/2013.php#id2013-07-11-1
Threats to w eb site s an d count erme asure s
Operational status of HTTP servers(Apache and IIS)
Figure 9 shows the result of our investigation into operational status of Apache and IIS that are used for web servers.
Figure 9 Operational status of Apache(left, n=1052) and IIS(right, n=664)
Support for Apache 2.0.x was withdrawn in July 2013 and currently 2.2.x and later are supported; however, 24% of web servers were still running versions of Apache that were no longer supported. With regard to IIS, support for 5.x was withdrawn in July 2010 and currently 6.x and later are supported. Only 4% of web servers were running the unsupported versions of IIS. This is significantly lower than Apache. The support periods of IIS are in sync with the support periods of Windows Server OS’s. This encourages the use of supported versions because IIS is subsequently upgraded when users upgrade their Windows Server OS’s as support is withdrawn. Also, higher percentages of web servers are running supported versions of software on both Apache and IIS compared to the aforementioned PHP and Struts. This is due to the fact that the effects on web applications and middleware caused by upgrading Apache or IIS are generally less than those caused by upgrading middleware such as PHP and Struts.
Threats to w eb site s an d count erme asure s
1.2. Countermeasures taken by organizations for their websites
We have described the usage status of software with targeted vulnerabilities based on attack trends on websites in the previous sections. We will focus on countermeasures taken by organizations for their websites in this section based on the results of our assessment services for corporate websites.
Countermeasures for web networks
Our Platform Assessment Service consists of remote assessment which is carried out via the Internet through the firewall, and on-site assessment which assesses the system from inside the firewall to check the effectiveness of countermeasures in web networks. Their aims are to assess the resistance against attacks from external networks such as the Internet and attacks from internal networks initiated by malicious insiders or third parties who have overtaken servers.
The Platform Assessment Service classifies systems into one of the following three groups according to their risk levels determined by the assessment.
"Danger": Systems that can be successfully attacked at any moment.
"Warning": Systems that can be successfully attacked under certain conditions. "Safety": Systems that do not have any of the above flaws.
Systems we have assessed in the past 5 years are categorized into the above groups and shown in Figure 10.
Threats to w eb site s an d count erme asure s
The percentage of systems in "Danger" has been declining and the percentage of systems in "Safety" has been increasing since 2011. The fluctuation in the percentage of systems in "Danger" from 2010 to 2013 was mainly caused by the DoS vulnerability(CVE-2011-3192) in Apache. There were a large number of websites with this vulnerability at the time of the disclosure in 2011; however, the percentage in "Danger" decreased as countermeasures were gradually applied. Many systems in "Warning" allowed intruders to access and make login attempts with ID’s and passwords to management consoles of application servers or remote maintenance services (ssh, etc.) via the Internet. Countermeasures such as source IP address access control or public key authentication should be applied to such vulnerabilities since the system may be abused once the intruder clears ID and password authentication by a brute-force attack. Figure 11 shows the result of on-site assessment in the past 5 years.
Figure 11 Results of platform assessment(annual history, not via firewalls)
Systems in "Danger" were often using versions of platform products with high-risk vulnerabilities, versions of platform products which were no longer supported, or maintenance services which were set with easily guessable ID’s or passwords. Results shown in Figure 10 via firewalls and Figure 11 without firewalls reveal that organizations are still relying heavily on firewalls to protect their systems from attacks via the Internet, and countermeasures are only applied on software that provides public services. Based on the defense-in-depth concept, we recommend our customers to improve their security level on each server in addition to protecting their systems with firewalls. However, Figure 11 indicates organizations cannot get around to improving security level on each of their servers on their own.
Threats to w eb site s an d count erme asure s
Countermeasures for web applications
Let us see how countermeasures are applied against attacks on web applications from the results of our Web Application Assessment Service. The Web Application Assessment Service classifies websites into one of the following three groups according to their risk levels determined by the assessment.
"Danger": Websites where important information can be illegally accessed.
"Warning": Websites with possible information leakage risks while important information could not be accessed. "Safety": Websites which do not have any of the above flaws.
Figure 12 shows websites we have assessed in the past 5 years by each of the above categories.
Figure 12 Risk levels of websites over 5 years(annual history)
While approximately 30% of websites remained in "Danger" as they have been for years, websites in "Safety" increased at the expense of websites in "Warning". Therefore, it can be deemed that safe websites are on the increase as the overall trend. One of the reasons for the gradual increase in safe websites is that technical know-how of developing safe web applications accumulated in organizations as well.
Threats to w eb site s an d count erme asure s
Figure 13 Risk levels of websites over 5 years(organizations with assessment experience)
Figure 14 Risk levels of websites over 5 years(organizations without assessment experience)
Figure 13 and Figure 14 show the assessment results from organizations that had undergone the system assessment before and organizations that underwent the system assessment for the first time. Figure 13 shows a gradual increase of websites in "Safety" and a gradual decrease of websites in "Warning". On the other hand, Figure 14 shows websites in "Danger" continuously as high as 50%. Therefore, it is deemed that organizations with repeated assessment experience can accumulate know-how of web application development and are less likely to introduce flaws. However, it is also true that even organizations with assessment experience could not eliminate flaws and 30% of websites are left in "Danger".
Threats to w eb site s an d count erme asure s
Trends in typical flaws
The followings are most common among high-risk flaws detected in our Web Application Assessment. Accessing administrative functions by privilege escalation(hereinafter privilege escalation)
Spoofing due to insufficient checks(hereinafter spoofing) SQL injection(SQLI)
Figure 15 shows detected cases for the above flaws plus another major flaw, cross-site scripting(XSS), in our Web Application Assessment in the past 5 years.
Figure 15 Detected major flaws over 5 years(annual history)
While privilege escalation, spoofing, and SQLI decreased by 3% from 2012 to 2013, there has not been any major change in general for years. Reasons how flaws were introduced should be made known among developers and clear countermeasures should be implemented to prevent repeating it in the future especially for these high-risk flaws. Development processes of web applications can be defined as "Requirements(requirements definition)","Design", "Implementation(including tests)", "Deployment", and "Operations". Figure 16 shows the processes in which high-risk flaws detected in web application assessment were introduced.
Threats to w eb site s an d count erme asure s
Figure 16 Development processes where high-risk flaws were introduced(annual history)
Although there has been no major change over the years, it is clear that approximately 60% of flaws were introduced in requirements definition and design process. Privilege escalation and spoofing were introduced in these processes. If considerations to privilege escalation and spoofing are overlooked in requirements definition and design processes, functions to prevent these flaws are not implemented in the implementation process, and subsequently tests performed by the application developers would not find the flaws. In such a case, privilege escalation and spoofing flaws are finally revealed when web application assessment is carried out just before the release. Many of flaws introduced in requirement definition or design processes are due to lack of ability to clarify the necessary security requirements and issues sufficiently. In other words, this can be avoided by applying design guidelines on security issues, carrying out design reviews by experts, or establishing the necessary environment or system.
Flaws introduced in the implementation process are due to overlooking even when the developers understand the necessity of countermeasures and methods. It is difficult to completely eliminate human errors in development comparatively large project. However, mechanical countermeasures such as source code assessment tools are comprehensive and effective for detecting such flaws.
Flaws in the implementation process can be dealt with by deploying WAFs. Especially those that can cause disastrous effects such as SQLI, and that are frequently detected such as XSS can both be prevented by WAFs. However, it must be noted that WAFs are not the exhaustive solution for all flaws in the implementation process. Flaws in deployment and operations process are mainly flaws in the platforms, and these are where vulnerabilities of software become especially apparent. Since the duration between vulnerability disclosure and attacks is diminishing as described in the previous section, relying completely on patch application is no longer a realistic solution. WAFs are also effective countermeasures for flaws in this process. Placing WAFs in front of web applications with the signature to detect and block packets containing attack code for the particular vulnerability enables you to promptly apply countermeasures without checking if the patch causes performance degradation or in some cases modifying web applications. This is a great advantage in running public websites. Again, it must also
Threats to w eb site s an d count erme asure s
Figure 17 Security countermeasures for each website development process
Importance of website inventory - First step in security
Extremely high-risk vulnerabilities in Struts 1(CVE-2014-0114) and OpenSSL(CVE-2014-0160) were disclosed in quick succession in April 2014. System managers must have agonized over how to investigate whether their systems were affected by the vulnerabilities.
Investigation into whether a vulnerability affects your system involves determining whether an attack on the vulnerability would be successful. There are 2 items to be investigated here. First, you would need to identify the systems where the vulnerable version of the software was deployed e.g.you can limit the investigation to web systems for Struts 1; however, you would need to expand the investigation scope to include mail servers and network devices for OpenSSL. Second, you need to understand the network configuration. For example, if you assume the threats to be "attacks via the Internet", systems with the vulnerable software that are not affected are those that are also unreachable from the Internet. Therefore, you need to know the configuration information to understand the effects of the vulnerabilities in addition to whether or not your organization is using the vulnerable version of software. Many organizations had trouble in collecting information such as the version of software while they were aware that they were using Struts 1 and/or OpenSSL, or even the software configuration itself in this particular case.
The vulnerabilities also attracted media attention and the news on the dangers of these vulnerabilities reached system managers relatively quickly as well as the general public. However, the media does not always collect accurate information and report the true risk level of vulnerabilities. Collecting vulnerability information and determining the risk level triggers investigation into the effects, and how promptly the investigation starts determines the risks of attacks. We felt this high-profile incident impressed upon organizations "to be proactive" in collecting vulnerability information and determining risk levels.
The problem was made worse by organizations not centrally understanding all of their public websites(in many cases). Website management methods vary depending on organizations. Websites are often implemented and managed centrally by the system department, or they are implemented and managed by concerned departments individually and the department in charge of security oversees the status. However, such rules in organizations are not always correctly observed. Our Website Group Inventory Service(GR360) searches organizations' websites using our proprietary logic to make an inventory.
Figure 18 shows the ratio of the number of websites of which the managing organizations were centrally aware, and the number of websites which were discovered by GR360(that organizations were not aware of) in 2013. Organizations were only aware of less than 50% of(their) websites.
Threats to w eb site s an d count erme asure s
Figure 18 Results of GR360(n=5338 sites)
There are many reasons for websites straying from the organizations' rules. One is the spread of cloud services. Nowadays, the infrastructure for easily implementing websites by any number of non-technical departments is commonly ready at-hand; therefore, websites can be created within a short time as long as one has the motivation. Another reason can be acquisitions and entering overseas markets. Websites that were implemented by the acquired company may have slipped through the net during the acquisition process, or an overseas base of a Japanese organization may have implemented websites using a local vendor.
Over 50% of websites would not even appear on the list even when the aforementioned investigation is launched due to a disclosure of high-risk vulnerabilities. Although it is unlikely that all of them are in danger, the risk is not low when the vulnerabilities are of major software such as Struts and OpenSSL; therefore, some websites are certainly left open to attacks. Vulnerabilities in such websites of which organizations are not aware, would not have been managed thus vulnerabilities are highly likely present.
Clarifying the management object is the first task we need to carry out before applying security countermeasures to websites. Although it sounds like common sense, it is a difficult task as the organization grows larger and more complex. It is often felt that solutions for protecting websites from attacks on vulnerabilities can only be provided by technical aspects; however, they are not always technical matters. This may be our blind spot when considering security countermeasures for corporate websites. This case was an example to show the importance of inventory management such as understanding the presence of them and collecting information on software running on them, in website security management.
Threats to endpoi nt s a nd count erm easur es
2. Threats to endpoints and countermeasures
2.1. Attacks from the Internet
The most common attack methods to infect clients with malware are via websites and e-mails. For infection via websites, the attacker prepares a website with attack code or malware and redirects the target user to the illegal website. The attacker infects the client by exploiting vulnerabilities in the web browser's plug-ins while the targeted user is viewing the website. This method is also called a‘drive-by download’ attack. For infection via e-mails, the attacker sends an e-mail with a malware attachment to the target user or an e-mail with a URL to redirect the user to an illegal website. The aim here is also to infect the client with the malware. This section focuses on these two attack trends.
Detection status of malware infection via websites
Figure 19 shows the monthly history of the number of detected malware in 2013(April 2013 to March 2014) on the virus check server provided by our FNC Secure Internet Connection Service. The traffic between the corporate clients and websites flowed through the virus check service.
Figure 19 Number of malware detected by the virus check server(monthly history)
The majority of detected malware was Trojan and Exploit types. The total number of detected malware declined when the number of detected Trojan malware declined from July to October. On the other hand, the number of detected Exploit malware increased gradually from September and became almost as much as the Trojan malware.
Threats to endpoi nt s a nd count erm easur es
Figure 20 Number of Trojan malware detected by the virus check server(monthly history)
Figure 20 shows a breakdown of Trojan malware detection. The most of detected malware was Trojan(Iframe), Trojan(JS), Trojan(Script), and Trojan(Redirector). They all were attack methods used for drive-by download; this suggests that the detected packets were Iframe or JavaScripts to infect Trojan malware rather than packets with Trojan malware itself in the web browsing traffic. These packets were redirecting users to the attackers' sites using Iframe or JavaScript.
Trojan(Iframe) malware was particularly popular. Analysis on detected URLs revealed that many websites were legitimate but attackers embedded with Iframe to redirect users to other websites. Since inline frames can be hidden, malicious contents can be downloaded while users were unaware.
With regard to Trojan(JS) malware, there also were many cases of tampered legitimate websites where attackers embedded with obfuscated JavaScript. JavaScript redirected users to attackers' websites that were equipped with an easy-to-use exploitation tool called Blackhole Exploit Kit in many cases. Obfuscated JavaScript is known to be used often to redirect users to attackers' sites with Blackhole Exploit Kit; however, disabling JavaScript on the browser is not a realistic solution since many of recent websites cannot be displayed properly without enabling JavaScript. In conclusion, web infection is often carried out by attackers' tampering with legitimate websites and redirecting visiting users to other malicious sites.
Threats to endpoi nt s a nd count erm easur es
Figure 21 Number of Exploit malware detected by the virus check server(monthly history)
The most detected malware was "Exploit.Agent.AK" that exploited vulnerabilities in Java and spread mainly in Japan from September 2013. Next is Blackhole Exploit Kit that had been detected continually since February 2012 indicating it was popularly used by attackers as an easy-to-use exploitation tool. CVE-2013|2014 is the sum of Exploit malware that exploited vulnerabilities disclosed in 2013. Table 3 is a list of vulnerabilities summed in CVE-2013|2014.
Threats to endpoi nt s a nd count erm easur es
All of these vulnerabilities allowed execution of arbitrary code while browsing a website. Figure 21 shows a growth of CVE-2013|2014 in February 2014. The most of these exploited the vulnerability of CVE-2014-0322. IE is the most common browser deployed in organizations as we will describe later. An increased number of packets to infect malware that targets vulnerabilities in IE tend to be detected as shown whenever a high-risk vulnerability that allows arbitrary code execution is disclosed and attack code is published. Vulnerabilities in browser plug-ins that are commonly used in organizations such as Adobe, Flash, and Java are also targeted in the same way when they are disclosed. Attacks on the CVE-2014-0322 vulnerability were detected on the 9th day of the disclosure; this shows quick response was required. However, applying patches to IE in organizations is not always easy since IE may be used in business systems. In such a case, they have to rely entirely on the virus check function as the countermeasure against the malware infection via websites. Even when a high-risk vulnerability is disclosed in the browser in use, prohibiting whole Internet web browsing activity is impossible because of the way business operations are carried out today. Also operational countermeasures such as prohibiting access to sites that are irrelevant to the business is not effective since tampering legitimate websites is becoming common. Organizations which cannot apply patches immediately should consider a workaround such as preparing an alternative browser to view websites on the Internet.
Detection status of malware infection via e-mails
Let us examine the trend in malware infection via e-mails that is another attack method aiming at infecting clients with malware. Figure 22 shows the monthly history of the number of malicious attachments detected by the virus check e-mail server provided by our FNC Internet Connection Service.
Threats to endpoi nt s a nd count erm easur es
There was a surge in the number of Exploit and Trojan malware detections in May 2013. The number of detections decreased slightly afterwards; however, no major change occurred in the second term from October onwards. Trojan e-mails that increased in May had a subject "Your Wire Transfer XXXXXXXX canceled" and attached with a compressed file called "payment receipt 30-04-2013-gbk-75.zip". Also, many Exploit e-mails had a
subject "Your transaction is completed" and attached with a Word file called "receipt428-586.doc". As you can see from the subjects and file names, e-mails looked as if they were about bank transfer notices; however, recipients would be infected with a malware called ZeuS if they opened the attachment in both cases. Once infected with ZeuS, the clients can be controlled by attackers via C&C servers on the Internet. ZeuS is aimed at stealing online banking account information or modifying the recipient and amount in the course of transfer, and it has been causing huge financial damage worldwide in the recent few years. A specialized malware development tool(ZeuS Builder) for ZeuS is available; therefore, the malware can be developed easily without development skill. There are numerous versions of the development tool and subsequently there are numerous subspecies. We can observe wide varieties of ZeuS and ZeuS related malware since they are detected every month and their signature names vary each time.
Figure 23 Number of types of malware with the same signature name detected by the virus check server for different duration(annual comparison)
Figure 23 shows an annual summary of how long malware with the same signature name was detected. This graph indicates that the same malware was not used long, and attackers disposed of malware after a short time and created subspecies one after another. As the development costs are reduced by the readily available development tool, attackers dispose of malware quickly and generate subspecies to avoid detection by anti-virus software. This trend may continue into the future.
Threats to endpoi nt s a nd count erm easur es
2.2. Countermeasures by "people" against malware infection
If attackers continue to dispose of malware quickly to avoid detection by anti-virus software, we need countermeasures on the assumption that e-mails with malware will reach the recipients. However, clients are not infected by the malware unless the recipients execute the attached file. Although we cannot overlook the possibility where attack e-mails directly target vulnerabilities in e-mail software such as Outlook, as long as domestic attacks are concerned, most attack e-mails are attached with document files that attack vulnerabilities in Office or Adobe on the client, or executable files that infect malware without attacking vulnerabilities. Today, it is an undeniable fact that "people" in organizations are the last line of defense against malware infection via e-mails.
We have been offering the targeted e-mail training service that provides simulated experience of targeted e-mail attacks since 2011. After a series of targeted e-mail attacks on domestic companies and government agencies in 2011, an increasing number of organizations are introducing annual targeted e-mail training. Targeted e-mail training has become popular and many organizations carry out the training with hands-on education that sends fake attack e-mails to employees in a given organization(Figure 24).
Figure 24 Overview of targeted e-mail training
Targeted e-mail training has another effect as a drill. Training is to repeat basic learning and operations to improve certain ability. The targeted e-mail training is designed to prevent employees from executing the attachment file and being infected by malware in the event of their receiving attack mails that may have the same or similar subject, sender, type of attachment file, or attachment file name. In other words, training is a form of education to improve employees' abilities. On the other hand, the definition of drill has clearly the different purpose though it is sometimes used as a synonym of training. In addition to improving individuals' ability, drills are also activity to verify the plan. For example, an organization that has laid down a rule to "Contact the helpdesk if you receive any suspicious e-mail" can use the targeted e-mail training to confirm if its employees actually escalate the matter to the helpdesk upon receipt of the training e-mail, and to provide employees opportunities to reflect on their action if they executed the attachment file. Enabling organizations to verify their plans and rules is the advantage of the simulation program.
Threats to endpoi nt s a nd count erm easur es
Whether the employees observe the rules or not is qualitative. On the other hand, whether they open the attached file or not can be countermeasured quantitatively. Also, comparing the number of attached files opened by employees proved that simulation training definitely improves employee resistance to targeted e-mail attacks. Since many organizations have deployed the targeted e-mail training as malware infection countermeasures, we consider that the effectiveness of such training have been widely recognized. Assuming such training is effective, how often should it be carried out for maximum effect is the question.
Figure 25 Comparison of opening ratio in the targeted e-mail training
Figure 25 compares the percentages of employees who opened attached files from the fake attack e-mails of organizations that underwent the targeted e-mail training in 2013 for the first time and organizations which underwent the training in 2012 and 2013. The training was repeated multiple times in a year and the figure shows the percentages for the first time and second time to compare the results. The result shows that the opening ratio decreased as the targeted e-mail training was repeated, and also the open ratio can be reduced further by repeating the training twice in a year.
It is predictable that repeating training will increase the effects. However, we consider too many would have adverse effects. Effects of action to improve awareness are known to diminish as the target gets habituated to it. It is necessary to vary the contents based on the attack trend to avoid the employees feeling used to it, and also it is important to keep it occasional enough to avoid their feeling of "Oh no, not more training!". According to the questionnaire we carried out to the employees, the response was always positive for the annual training while the response varied by organizations for more than once a year. It is difficult to suggest how many times the training should be repeated in a year; however, we recommend at least once a year, and each organization can determine when and how often based on the post training questionnaires.
Threats to endpoi nt s a nd count erm easur es
Figure 26 Response to suspicious e-mails
Figure 26 shows the results of questionnaires to organizations which underwent the targeted e-mail training in 2012 and 2013. An increasing number of employees answered they would delete the mails if they receive suspicious e-mails rather than consulting the colleagues or superiors. It is deemed that more employees were taking initiative in responding to suspicious e-mails as the targeted e-mail training was repeated. Although 20% of employees answered to consult the department in charge, many commented they did not know the department in charge, or the contact details of it. While it is important not to open suspicious e-mails, the organization would not know if they are under targeted e-mail attacks if the employees delete them without reporting it to the department in charge. We felt many organizations had not clearly established rules for what to do if employees received suspicious e-mails or opened attached files even when they have rules for what to do in the event of malware infection. Determining whether suspicious e-mail could be a real attack or not does require a certain degree of IT knowledge. Considering the recent attack trends, it is essential to clarify the rules for what to do on receipt of suspicious e-mails and establish the contact to avoid confusion. However, even if the organization has established the rules and contacts, the employees would still be confused if they do not know of their existence. It is effective to display the rules where employees may see often to permeate the information.
As it has been discussed, "people" in organizations are indeed the last line of defense against malware infection via e-mails; however, it is difficult to make the opening ratio 0% even with continual targeted e-mail training because these attacks use social engineering. Also, as it has been described at the beginning of this section, malware infection may occur via websites or e-mails. Rather than the traditional targeted attack that sends e-mails to targeted organizations, we started to hear about a passive attack method called "Watering Hole" in 2013. The attackers tampered with websites that were likely to be accessed by employees of targeted organizations and lied in wait for access from those employees. This proves that all attackers have to do is to use new methods to attack the targeted organizations even if the opening ratio of targeted e-mails becomes 0%.
Improving employees' resistance against targeted e-mails reduces the risks of malware infection. However, this countermeasure alone is not enough. Since targeted attacks emerged, complete prevention of malware infection was said to have become impossible. Therefore, it is necessary to implement countermeasures assuming that
Threats to endpoi nt s a nd count erm easur es
2.3. Countermeasures assuming malware infection
As malware infection methods and infection routes are becoming more complex, it is difficult to prevent malware infection damage in the organization completely; even if you have implemented inbound protection and training against targeted e-mails that are aimed at preventing malware intrusion and infection. In addition to these, implementation of outbound protection has become the focus of attention that is a countermeasure on assumption of having internal clients that malware have infected already. One of the effective outbound protection methods against malware infection is detecting and blocking C&C traffic(communication often used by attackers to control malware infected clients), identifying the compromised client using the detection result, and removing the malware.
This section describes the countermeasure that assumes malware infection using the outbound protection deployed in our FNC Internet Connection Service as an example. We are promoting implementation of next generation firewalls as one of the outbound protection methods, and monitoring highly dangerous control packets transmitted by malware infected clients(Figure 27). Figure 28 shows the number of times we detected control traffic from October 2013 to March 2014.
Threats to endpoi nt s a nd count erm easur es
Figure 28 Number of times highly dangerous malware control traffic was detected by next generation firewalls (monthly history)
Although our FNC Internet Connection Service provides thorough inbound protection mainly with virus check servers(proxy and e-mail), we still detect control traffic from compromised clients certain times every month. Control traffic detected in 2013 included ZeroAccess that was known to be used as P2P malware for click fraud and bitcoin mining.
Malware ZeroAccess has been observed worldwide in recent few years. There may be various reasons why such well known malware was able to infect internal clients. It could have been a highly sophisticated detection avoidance technique within the malware to evade inbound protection or a compromised client was physically taken into the office. Even when malware evaded inbound protection, its control traffic was detected by the next generation firewall at outbound protection using pattern matching in this case. Thus we were able to minimize the damage by identifying the compromised client and immediately notifying the client user. However, ingress and outbound protection relying on pattern matching cannot detect new subspecies and unknown malware for which pattern files have not been created yet. In order to provide countermeasures against such unknown malware whose behavior such as characteristics of control traffic is unidentified, some security products are equipped with functions to identify clients that may have been infected with unknown malware by performing correlation analysis on client packets.
Threats to endpoi nt s a nd count erm easur es
Figure 29 Number of clients that may have been infected with malware(monthly history)
Figure 29 shows the number of clients that may have been infected with malware observed by next generation firewalls. Although correlation analysis does not always identify malware infection, it is possible that it detects clients infected with unknown malware that cannot be identified by pattern matching anti-virus software in early stage. In addition, our malware specialists perform further correlation analysis on these detection results using various event logs to identify clients that are likely to be infected with malware and raise an alert for the client users as necessary.
As you see, many of products that are regarded as effective for outbound protection can provide opportunities to organizations to detect malware that cannot be detected by pattern matching. However, this inevitably requires human intervention to determine whether the detected case is malware or not since this method does not involve pattern matching. How can we divide gray matter into black and white? This is the pressing issue for organizations. The next chapter describes this issue using our CSIRT activities as an example.
Threats to endpoi nt s a nd count erm easur es
[Column] Migration status of Windows XP and IE6 in organizations
Support for Windows XP was withdrawn on April 9, 2014. It was extensively reported by media since Windows XP OS was widely used in organizations over a long time. We carried out a questionnaire on Windows XP migration for the "Organizations Information Security Status Investigation". Approximately 30% of organizations answered to "continue using Windows XP even after the support is withdrawn" to show the migration to new OSes is not progressing. The questionnaire was carried out half a year before the withdrawal between August 29 and October 4, 2013. What happened to migration of Windows OS’s and browsers in organizations afterwards? We summarized access logs on our websites provided for organizations to find out the answer. Figure 30 shows the history of the breakdown of browsers in use in organizations and Figure 31 shows the history of the breakdown of OS’s in use in organizations.
Figure 30 History of the breakdown of browsers in organizations
Figure 31 History of the breakdown of OS’s in organizations
Threats to endpoi nt s a nd count erm easur es
XP as of April 2014 despite having upgraded their browsers from IE6. Their upgrading the browsers suggested they were aware of the danger of using software with vulnerabilities; however, they may not have been able to also upgrade OSes for some reason such as costs and time.
This research was conducted using logs from our Internet websites for organizations. Clients with IE6 and Windows XP appearing on the graph were able to connect to the Internet. High-risk vulnerabilities were discovered in all versions of IE including IE6 in April 2014; therefore, users must have known that attacks on these vulnerabilities could succeed at any time if they continue to use the browsers and Windows XP after support was withdrawn. Damage mitigation countermeasures on the client or other devices should be deployed proactively while software upgrade is not possible.
Ca se s tud y and i ssues in inci dent handli ng
3. Case study and issues in incident handling
3.1. Incident handling by CSIRTs
According to the "Organizations Information Security Status Investigation 2013" that we carried out between August and October 2013 with system managers and security manager in organizations' information system departments, 20.5% of these organizations had already established a CSIRT(Computer Security Incident Response Team), and 1.8% were considering doing so. This is approximately 27 times more than the same research in 2012. This indicates that the importance of CSIRTs has been gradually realized as a major part of security countermeasures in organizations. Figure 32 shows examples5 of services provided by a CSIRT.
Figure 32 Examples of services provided by a CSIRT
An organization that provides part or all of these services and is responsible for responding to security incidents is called a CSIRT. Among those, the core of the post-incident service is incident handling. Incident handling mainly consists of detection, triage, and response stages as indicated in Figure 33.
Ca se s tud y and i ssues in inci dent handli ng
These steps can all be covered by the internal CSIRT; however, detection requires design, implementation, and operation of security devices to detect events and triage requires design, implementation, and operation of the mechanism to summarize and analyze the detected events. Smoothly performing these tasks requires specialist knowledge and technique concerning security; therefore, covering everything by the internal CSIRT may be difficult in some organizations. Such organizations can consider outsourcing to security vendors' MSS(Managed Security Service) or SOC(Security Operation Center) services. They can also enjoy benefits of using external services such as installing detection devices, monitoring events, determining whether attacks were successful, and advice on necessary response.
Our FNC service established a CSIRT called NCSIRT(NRI Secure Technologies Computer Security Incident Response Team) in 2007 and it has been providing security monitoring and incident handling services for our customers' systems. Let us focus on issues in incident handling based on data and case study information that we have obtained through the NCSIRT.
3.2. Case study and issues in incident handling
This section describes the specific operational issues at work places that emerged through activities of our CSIRT called NCSIRT that has been providing services internally and externally. We will focus on incident handling that is the most important element among numerous CSIRT functions. We will describe issues in CSIRT operations that were revealed through actual activities of our NCSIRT from collecting security events, analyzing data, investigating the effects, to examining the response. We hope these results will help organizations to see the required elements to acquire ability to carry out even more motivated incident response.
Issues in incident handling
NCSIRT provides high-level real-time analysis especially correlation analysis called SIEM(Security Information and Event Management) on communications logs and security events from security devices provided by our Managed Security Service such as firewalls, IDSes, IPSes, WAFs, URL filters, and anti-virus software. The main objective of deploying SIEM is minimizing the costs of event analysis and the time to find incidents by summing a large number of events and automating the analysis. Even if you have established a CSIRT and the system to collect numerous events, you would not be able to provide prompt response to a security incident and would allow the damage to spread unless the time to investigate each event can be reduced. Figure 34 shows an incident response flow using SIEM as an example.
Ca se s tud y and i ssues in inci dent handli ng
Figure 34 Incident response flow using SIEM
As you can see, using a SIEM allows you to gather events from various security devices to one place for easy analysis. However, analysis would be too time-consuming if the volume of collected events is too large. The total number of events taken into our SIEM in 3 months from January to March in 2014 was approximately 17 billion. After taking the large number of events into SIEM, the SIEM extracts alert events that are likely to lead to an incident. NCSIRT automatically extracts high-risk events as alert by mechanically separating the events taken into SIEM by the security analysis criteria created by our analysts. The analysts then analyze the extracted alert event as the subject to triage. According to our record, 493 events were subjected to triage out of all the events taken into SIEM in the above period.
Ca se s tud y and i ssues in inci dent handli ng
Figure 35 High-risk alert extraction by SIEM
These alert events contain obvious attacks, harmless false positive cases, and gray events that could not be determined to be attacks or false positives. Figure 36 shows the breakdown of all 493 events mechanically extracted by SIEM's. As you can see, approximately 55% was “gray”.
Ca se s tud y and i ssues in inci dent handli ng
Basically, mechanical extraction by SIEM cannot accurately extract high-risk alerts. We have been endeavoring to improve detection accuracy by cross-device and cross-customer correlation analysis and introducing a mechanism to detect new attack methods into detection rules as the preparation to incident response; however, there are still alerts that require human-intervention and analysis. Therefore, NCSIRT carries out the second level analysis on the “gray” events. Security analysts with wide and highly specialized knowledge manually analyze the events on this level rather than the mechanical process on SIEM. Figure 37 shows alerts that were subjected to the manual analysis by our security analysts categorized into attack types.
Figure 37 Events triaged by security analysts in attack types(n=271)
As shown in Figure 37, manually analyzing alerts in incident handling requires wide-ranging expertise according to the provided CSIRT functions such as knowledge in web applications and client security such as malware infection, in addition to infrastructure such as networks and servers.
The final "response" step determines the attack status and the effects of events identified by the triage, and examines the final countermeasures and applies them. If NCSIRT detects an attack on a website that requires urgent attention, it comprehensively examines whether or not to block the attack packets with considerations to the website configuration(network configuration, web server application configuration, etc.), and blocks the attack packets if necessary. Such response also applies to attacks on endpoints such as malware(virus) attacks on client PCs. Countermeasures are considered on a case-by-case basis such as blocking attack packets(C&C traffic, etc.), scanning viruses, isolating the network that contains the client in question, etc.
Even a small part of CSIRT activities and incident handling involves system related aspects such as implementing and operating a high-level analysis platform such as a SIEM and/or creating security analysis rules for SIEM, as well as the human resource related aspect such as securing highly specialized human resources. Responding to the recent sophisticated and complex cyber attacks promptly and accurately is extremely difficult without appropriately combining these two CSIRT aspects.
Ca se s tud y and i ssues in inci dent handli ng
Specialized security skills in demand
As it has been discussed, those in charge of incident response in organizations must have various specialized knowledge required by the scope of their CSIRT functions. It requires a “tough mentality” to respond to alerts and incidents that occur day and night while continuously improving your own skills to combat increasingly sophisticated and complex attacks. The role was filled by system or network staff when information security was not discussed as an independent issue However, information security became an independent issue and shortages of InfoSec human resources in organizations became apparent as attacks became more sophisticated and complex, and security incidents that impacted these businesses occurred one after another.
According to our research, the "Organizations Information Security Status Investigation 2013", 85% of organizations felt shortages of human resource for information security. Also, the organization’s belief in the "development of internal human resources and employee training" as one of the most important security countermeasures increased from 28% in the previous year to 40%(3rd to 1st in the list). And the reasons were because they felt InfoSec HR shortages were "skill shortages in security personnel"(47%), followed by "significant increase in security related operations"(40%). This seems to suggest shortages of personnel with knowledge and experience to cover the aforementioned wide areas of security even if the organization manages to appoint/hire security personnel.
What are the necessary roles in incident response? Which skills are required to each role? As it was mentioned in the beginning of this section, events that may lead to incidents must be detected as early as possible, then passed on to the triage and response stages. These tasks require the following roles.
Network Security Engineer
Operate and manage systems and networks from the viewpoint of detecting attacks. Incident Handler
Respond swiftly in the event of an incident. Apply countermeasures and perform recovery in liaison with system and/or network managers.
Forensic Analyst
Find the evidence in the systems and/or networks in the event of an incident and preserve it appropriately. Malware Analyst
Analyze malware, find the attack method, and determine the countermeasure. Also, investigate unknown malware based on the trace found in the systems and/or networks.
It should be noted that the necessary human resources are not those who can examine these things at just the desktop but those who can actually investigate “hands-on”. Even if you are leaving investigation and response to security vendors or system management vendors, the person in charge should have enough knowledge to be able to talk with the vendor in the same language. Otherwise, the organization would not be able to determine if the vendor's investigation or work is appropriate.
Learning from incident impact investigation and policy examination
The common denominator among incident handling activities is that you must have in-depth understanding of the targeted system and surrounding system configurations before examining the countermeasures; therefore, it is important to have various configuration information beforehand. It takes time before determining the countermeasures, resulting in the damage to spread, or even effective countermeasures may not be found if you do not have such information. Also, the organizational system and response flow should be predetermined to make all decisions swiftly within the limited time. Therefore, it is extremely important that the organization is "prepared" to take a series of actions in an emergency situation, for example, by carrying out operational drills.
Our NCSIRT obligates all members involved in the given operations to take part in an operational drill which has been modeled after a real incident.
Ca se s tud y and i ssues in inci dent handli ng
Figure 38 Operational drill scenario
The program is aimed at all members to be able to provide incident response at a certain level. The contents are reviewed every year based on feedback from the participants to improve the effectiveness and keep the program close to the real attack trends. In addition, all members have participated in the security training course by SANS Institute, the major security training organization in the US to improve their skills, and all have acquired high-level GIAC certificates.
CSIRTs' activities must be continuous. We would say that their most difficult and most important mission is to maintain their response level to ever-advancing attacks through drills and continuous training.
Conclusio
n
4. Conclusion
We saw numerous website defacement incidents including the homepage of a major automobile manufacturer in 2013 aiming at malware distribution. These incidents were the result of attacks on vulnerabilities in software products used in the websites. Viewers with old versions of vulnerable software such as Java could be infected with malware only by accessing these websites and their account information stolen as they enter it to use online banking or web services.
Also, support for widely used and long-lived Windows XP was withdrawn in April 2014. However, approximately 20% of clients were still using Windows XP to access the Internet even after April 2014. Since security patches will no longer be released for Windows XP, it may become the target for attackers in the future. As support for Windows XP was withdrawn, support for software products running on it such as Java is being withdrawn as well. The possibility of malware infection in the aforementioned websites will further increase if such unsupported software is left unpatched and upgrading is not applied.
Organizations must recognize that they would be targeted by attackers if they continue to use vulnerable software products that are no longer supported. However, findings in our report suggest sluggish progress in applying countermeasures because applying such countermeasures on information systems that grow with the business would incur substantial costs and they simply do not know where exactly to begin the process. And again, risks of attacks will only increase if such issues are left unaddressed. We hope this report will be useful for applying countermeasures against such security risks.
- Organizations are Centrally Aware of Only 50% of Their Own Website(s);
Call for Reconsidering Inventory Management-
Writing and data preparation Atsushi Fukao Sukehiro Nishita Ryosuke Hatsugai Takehiro Kyoyama Kensuke Masaki Masato Yamane Hiroyuki Oki Masanori Iwahara Kenta Kakei Peter Vu Supervision Koutaro Kando
Yukinori Hashimoto Takaaki Kimura Jun Odashima
This research is an autonomous endeavor by NRI Secure Technologies, Ltd. in order to promote security countermeasures in corporate and public organizations.
NRI, the NRI logo, NRI Secure Technologies are the trademarks or registered trademarks of Nomura Research Institute.
Company names, product names, and logos mentioned in this report are the trademarks or registered trademarks of their respective owners in Japan and other countries.
The source data in this research cannot be provided.
NRI Secure Technologies, Ltd. holds the copyright of this report.
Mention our company name and the name of our research "Cyber Security Trend - Annual Review 2014" when reproducing or quoting part of this report. Also in such a case, please notify us.(Phone: 03-6706-0500, E-mail: info@nri-secure.co.jp)
The following actions are prohibited.
• Modifying part of or all of data.
