Disclaimer: if you are not yet familiar with this Information Security forum, please note that the material here collected is meant for usage of an essentially non-technical audience. IT Security professional will certainly find this content “light-weight” from a technical perspective.
This post will try dig into the topic of Software security. Most non-trained audience in Information Security is familiar with terms such as Vulnerabilities, Exploits, Patches, Cyber-attacks, which relate with Software Security. The relation among those terms is the following: most Cyber-attacks are possible because of the existence of software Vulnerabilities in Applications or Operating Systems which attackers are able to exploit. More precisely, attackers are able to take advantage of a vulnerability through what is called an “Exploit”, software code which allows them to gain unauthorized access to a system or to compromise its functionality (denial of service attack) .
Software vulnerabilities represent security gaps resulting from unintended flaw (errors) in software code or a system that leaves it open to the potential for exploitation in the form of unauthorized access or malicious behavior; Vulnerabilities can be closed by software vendors through patches: it is up to the user to apply the patch, and quite surprisingly there is a small minority who apply them in a timely fashion. While for home users this is essentially unjustifiable, companies may have good practical reasons for being unable to patch on a regular and timely basis. Unless companies have a Vulnerability Management Process in place, chances are that their patching activity is other than timely and not performed on a regular basis; even when a Vulnerability Management Process is in place, it is my experience that companies may have a hard time to patch systems on a regular basis, sometimes for lack of resources within the Operation teams, sometimes because the testing phase of the process produced results which affected performance in a negative way.
This infographic produced by Trend Micro explains quite effectively how Cyber-attacks succeed:
One common way to exploit a system is through the usage of Malware, parasite software which in stealth mode will perform undesirable actions leading to system and information compromise.
Some internet domains, generally referred as “Malicious domains” are known to be offenders in this area by trying to install malware by either exploiting browser vulnerabilities or gullible user behavior (acceptance of the browser request to install some form of software, often camouflaged under a fake name, such as “latest version or Flash needed to play the content you selected” or other easily recognizable names by most users). If you are unsure whether a domain is safe (malware-free), Trend Micro offers a tool in this page. And you might be surprised to discover that most of the malicious domains are registered not in Russia, China or Africa, but rather in the United States, according to the findings of Trend Micro summarized below:
As previously mentioned, Software vendors when becoming aware of a new vulnerability in their products will take action to release a Patch which, when applied by the product user, will eliminate the vulnerability and will restore the intended safe operation of the software.
So what happens in between the moment in which a vulnerability exploit is released by hackers and the moment in which the software vendor releases the patch? This is the ground in which the so called “Zero day attacks” will go wild and likely deliver the expected results to the hackers behind them. Zero-day attacks occur during the vulnerability window that exists in the time between when vulnerability is first exploited and when software developers publish a counter to that threat. Zero-Day exploits are usually posted by well-known hacker groups. Software companies then issue a security bulletin or advisory when the exploit becomes known, but they may not be able to offer a patch to fix the vulnerability for some time after: when they do release it immediately, chances are that they “bought” the resolution from the same authors of the exploits (often true also for Anti-virus software vendors). It is a fact that one of the stronger motivations of hackers to develop vulnerability exploits is to sell the “antidote” to software vendors before zero day attacks run wild.
This study conducted by Secunia Inc. found that, in 2013, 86% of the vulnerabilities of the top 50 software programs are available on the day of disclosure, hence only 14% of the vulnerabilities are subject to zero-day-attacks (10% in 2012).
The same study, when its scope is not limited to the top 50 software programs, found out that in 2013 79% of all software has a patch available in the same day a vulnerability is discovered.
Another interesting finding from the Secunia study is the growing trend of vulnerabilities in the last 5 years, which seems to reinforce the idea that “discovering and exploiting vulnerabilities is profitable business these days”.
Also, while the number of discovered vulnerabilities is growing (over 13,000 in 2013), the number of affected software products is decreasing (2289 in 2013) as shown in the chart below:
Among those over 13,000 vulnerabilities discovered in 2013, just under 16.7% were classified highly or extremely critical. Out of 13,073, this percentage represents a hefty number of vulnerabilities : 2184 !
And, if you were wondering, no less than 73% of those discovered vulnerabilities can be exploited from remote. So most of them are exploitable by cyber-attackers located all over the world.
If you want to read more, you can download the whole Secunia study here: secunia_vulnerability_review_2014.
Once the counter is out, that exploit is no longer a “zero day exploit”. So does it mean that the threat is no longer there? No, at least until the patch is applied, which requires some form of user intervention. So cyber-attackers can still count on some form of user-inaction to continue exploiting systems affected by a known vulnerability.
Among home-users, the need for patching is not fully understood. Most non-technical users follow the reasoning that “If my system is running fine, why would I bother patching it? After all it takes quite a bit of time…”. This obviously denotes a low risk perception in most users. In fact there are many psychology studies which have proven that the more we like an activity or tool, the less we perceive its risks. So enthusiastic computer users do not fully perceive all the hazard out there. They might be concerned about the safety of their house door and windows (and justifiably so) in order to prevent theft from physical attackers, but not so much from theft from virtual attackers, which are in an enormously larger number than the thieves who may try accessing your home.
Among companies, the need for patching their systems is generally better understood, but they seldom do it timely, if they do at all.
One recent study of 2013 showed that only 36% of small business apply security patches at all and it concludes that “it is no wonder that cybercrooks are stealing their cash“. In fact, taking the U.K. as an example, the FSB (Fedearation of Small Business) has estimated that small firms lose about 700 million pounds every due to cybercrime activities (read more here). The average attack caused Small and Medium Business (SMB) between £35,000 and £65,000 worth of damage – while large firms breaches set them back by an average of £450,000 to £850,000, although several individual breaches cost more than £1m (read more here). The same survey also revealed that 93 per cent of large organisations (those which employ more than 250 workers) had reported security breaches in the past year, while the percentage of small and medium business affected by at least a security breach is 87%.
You can download the whole report here: 2013-information-security-breaches-survey-executive-summary
So even though there is a cost to it, evidence is there that not just home users but also businesses are not timely in their patching, if they do it at all. One of the most striking evidence of this was provided to the general public earlier this year when Heartbleed was discovered as a huge OpenSSL encryption bug. Users were told their account on multiple web site affected by the bug (the sites using version 1.0.1 and 1.0.2-beta releases of OpenSSL,) were compromised and, at the same time, they were told not to update their account on each web sites until those were properly patched. And it took a long while until all the affected sites were patched. CNET and other sites published and regularly updated a list of web sites which had been patched. It did take a long while until the list of sites still at risk became empty.
The main reasons why companies do not patch their systems immediately are generally rooted into either lack of resources or the time needed for the patching process to complete.
An appropriate Vulnerability Patching Process (also called System Patching Process) is a fairly complex process which can be quite resource intensive. A test environment, ideally an identical copy of the production environment, should be available to test the systems after the patches are applied. This is no trivial effort. Testing is the crucial part of the Patching process. No software vendor can guarantee that the interaction of that software with the rest of the ecosystem which it is part of will remain flawless after the patch is applied. For example, when Microsoft releases a Windows patch it does not guarantee that whatever software you have installed in your workstation or server will continue to work as before once the patch is applied. You have to test by yourself. Sometimes warnings are released along with the patch (“known issues”) as a clue of what could happen. Other software vendors may list new minimum requirements in order to successfully apply the patch and this can lead to a “no-go” decision for patching. For example in order to apply this patch to software “x”, you need to have version “y” or newer of the OS in place. If you have an earlier version, you have to hold until you upgrade your OS.
You can see easily how complex this can become. So when a company does not patch immediately their systems it is not necessarily at fault: they may have some pre-requisite actions to do first.
A few more notions I want to touch in this post are how the public is alerted about new vulnerabilities and how those are classified in terms of severity of impact.
Vulnerability Bulletins:
This is how the public is informed about the discovery of new vulnerabilities. Both non-profit and commercial organizations are publishing free vulnerability bulletins. These bulletins offer much information, including the date of discovery, systems affected, severity ranking through CVSS score and links to vendors for patching recommendations. IBM, Microsoft, Cisco, Oracle, Adobe, Red Hat, to name a few, all issue periodic vulnerability bulletins. Companies like Microsoft release updates and patches so regularly that the term “Patch Tuesday” has been adopted to refer to the second or fourth Tuesday of each month in North America when Microsoft patches and updates are released to the public.
Companies are encouraged to subscribe (for free) for getting regular updates.
Severity ranking of vulnerabilities
Vulnerability are ranked when discovered with a CVSS (Common Vulnerability Scoring System) number: the higher this number (from 1 to 10), the more critical the exposure for the company in relation to this vulnerability. The purpose of the CVSS base group is to define and communicate the fundamental characteristics of a vulnerability. However only the final users will be able to provide that contextual information that more accurately reflects the risk to their unique environment. This allows them to make more informed decisions when trying to mitigate risks posed by the vulnerabilities.
Therefore companies should prioritize their patching process based on the criticality of the vulnerability assessed first through the CVSS scoring system and then in relation to their specific environment. This last step may lead to decrease significantly the criticality level of the vulnerability espressed by the CVSS (sometimes for the presence of specific security controls, sometimes because one or more of the necessary conditions for the vulnerability to be exploited is not present) or leaving it unaltered. The more critical a vulnerability is assessed, the earlier should be addressed (if the patch is available). It is normal for most patching process to address vulnerability ranked from 7 to 10 within a month from their discovery if their environment is confirmed to be vulnerable.
Another frequently heard system to measure the severity of software vulnerabilities is the CWSS, Common Weakness Scoring System, which assigns a number between 1 and 100 to measure the severity of the vulnerability.
Top 25 Software error list (CWE/SANS Top 25)
This scoring system is used in the Top 25 Software Error list, also called CWE Top 25. This is a very important reference updated on a periodic basis: the last list is date 2011 and the results can be found here. At the top of the list of 2011 is found “SQL Injection” which, with a score of 93.5/100, is ranked as the most critical software vulnerability around. The list also assesses important factors related to each vulnerability category, such as the cost of remediation, ease of detection, consequences. etc (see screenshot below).
This is a brief summary of the 2011 list:
OWASP Top 10 Software Vulnerabilities
Another very useful list of software vulnerabilities ranked by severity is the OWASP Top 10. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. This list is updated on a periodic basis also: it most recent update is dated 2013, hence more recent than the last iteration of the CWE Top 25, dated 2011. Not surprisingly, the 2 list results are essentially consistent. For example bith rank SQL Injection as the most dangerous software vulnerability.
Companies are encouraged to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.
This is a brief summary of the 2013 list:
There is one unanswered question in all this discussion: why vulnerabilities exist and what to do about it.
This will be covered in a future, more technical post. Stay tuned if interested.
IT SECURITY FOR MANAGERS AND EXECUTIVES 