Security of open source, proprietary software and interoperability



Open Source and Free Software Wars: Source
dwheeler.com



Just finished speaking at the Security Day hosted by the Sardegna(Italy) Research Park where I was invited to present on the topic of Open source projects for Web Application Security and moderate a round table on security of FOSS (Free Open Source Software) vs. COTS (Commercial Off The Shelf) with participating managers from Microsoft, IBM ISS and consultants from Engineering and Ablativ consulting.

The following themes were stimulated during the round table:

1) Did FOSS adoption in EU (since 2004 directive) [1] resulted in a more secure environment because of the diversity of the systems/platforms being used by organizations/companies?

Answer: a diversity of mechanism helps security on the other hand managing different platforms and systems is very difficult. A uniformity of platforms actually helps a more secure configuration and management effort (i.e. patching). The main objective is not to establish an eterpgenoues environment rather to establish a secure environment/infrastructure as a whole such as have a patch management process in place for all type of systems and applications being used.

2) Some COTS advocate that their systems are more secured because are closed (e.g. source code is not made available). Security experts advocate the contrary because security by obscurity does not buy security (e.g. Kirckoff's second law principle)and therefore is not a good reason for keeping systems close [2].

Answer: We need a security assessment process to validate the security of any software that is acquired/integrated with either from OSS community or COTS vendors. Access to the source code should be a requirement so can be assessed for vulnerabilities before adoption/release. Keeping the software closed (security by obscurity) is not a good reason for security.

3) According to a study [3] from a source code analysis tool vendor (e.g. Fortify) FOSS is not as secure as COTS because most FOSS produced lack secure software reviews. Is this a call for vendors and companies to source code analyze FOSS before adoption/integration?

Answer: We need a process to security validate with source code analysis that libraries and systems we use/integrate independently being from FOSS or COTS. Some customers of IBM asked for a OWASP secure code certification as a way to provide evidence that the software has been security reviewed. A certification could also provide legal guarantees to FOSS and COTS users. Ideally this certification could be required by compliance with a new normative/regulation on software assurance.

4) Time to patch is critical for the security of both FOSS and COTS [4]. For example, there have been cases where Mozilla was recommended over IE by CERT (2004) based upon the fact that took Microsoft 9 months to patch it. The same happened to FOSS [5]: for example, it took more then one year to Debian to discover and patch OpenSSL. The point here is: who takes liability of un-patched vulnerabilities and how software adopters/integrators could enforce FOSS and COTS to develop patches in very short time.

Answer: Ideally you need to establish a process and work with the software vendors/communties to develop patches before the zero day vulnerabilities are disclosed. This is what Microsoft is doing with MSVR program for example. The time to release a patch is important factor but some data (e.g. IBM) shows that actually system admins still leave most systems unpatched even if patches have been available for a while. Therefore timely patch management seems still to be a bigger problem to address then timely release of patches for zero day vulnerabilities.

5) OSS is free but it is not free from maintenance cost [6]: fixing vulnerabilities via a catch and patch approach is very expensive for both software developers and adopters. Usually the cost to develop patches is a responsibility of who develop software and both FOSS and COTS would rather continue to transfer this cost to the end user instead of bearing is themselves. The fact is that would be much cheaper for FOSS and COTS software developers fixing their software bugs during the development cycle instead of during production.

Answer: Indeed we need a process to require vendors and communities developing software to fix software vulnerabilities before going into production. The cost associated with developing patches can be a good reason for promoting

secure software development in the SDLC among FOSS and COTS. In the case of COTS, Microsoft proved that an increased security (e.g. reduced number of bulletins) has an impact on costs: assuming an average cost of bulletin is 100,000 $ by comparing Windows 2003 server with Windows 2000 the reduced number of bulletins is a strong argument of adopting a SDL (Security Development LifeCycle.)

The conference was very well organized and the location was just wonderful place to visit, hope to come back on vacation during the summer.

References:

[1] European Network and Inforamation Security Agency: Security Economics and the Internal Market

[2] Ross Anderson: Security open source vs. close systems

[3] Fortify: Rising Enterprise Adoption of Open Source Software is Putting Businesses At Greater Risk

[4] David A. Wheeler: Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!

[5] Charles Hill: Thoughts on FOSS security

[6] EU Study:Economic Impact of FLOSS on innovation and competitiveness of the EU/ICT sector

New phishing attacks require adoption of different countermeasures

Phishign warning source:
Cyberpunk blog

Back in the early 2000 phishing attacks require fraudsters to clone a web site, register it on similar domain and social engineer a victim with a phishing mail. Then phishers got smarter: instead to clone the site with CGI and do all this work why not use a web proxy and exploit a man in the middle attack? Besides this is also a good way to break multi factor authentication controls!. This was back in 2006. Since then, most banks and financial institutions in US deployed strong authentication, besides to mitigate phishing also in response to FFIEC compliance on authentication guidelines. Since then, phishing attacks have evolved to exploit man in the browser vulnerabilities, inject code that can executed by the browser and exploit web site XSS vulnerabilites. In the last years, phishing resort to the use of botnets to be more even more effective such as Mpack, Storm, Asprox and RockPhish just to mention the more popular. These are the tools for the cybercrime economy built to be used by professional fraudsters to gain million of $$ not script kiddies looking for fame! The cost pf such botents in the thousands of $$ and the sale of them generates a business of millions of $$ for the underground economy. The sophistication of these botnets is that can be very stealth to IDS and difficult to tear down by IP because of use of fast flux techniques such as round robin DNS with a short TTL constantly changing the IP mapped to a domain. More information on fast flux and how is used in botnets such as ASPROX can be found here. Spear (targeted) phishing is currently a target for banks: the tools are very close to the original site and use Rockphish as a botnet. This threat is real and requires new countermeasures. It means first of all raise the bar and reduce the attack surface. For example, consider more security for the users of your web site, require them to use locked down browsers with anti-phishing plug-ins enabled with extended validation certificate support. A sandboxed browser such as the ones provided by Trusteer and Authentium could mitigate the risk of malware and keyloggers downloaded on the client browser when your customers become victims of botnet attacks. On the application side, increase defenses by using strong authentication and out of band delivery of tokens to mitigate MiTM attacks: for example using one time passwords and tokens that are delivered completely via SMS and other channels. As a bare minimum, you need to mitigate web application vulnerabilities that can be exploited to attack the browser in a phishing attack such as OWASP T10. In particular XSS and XFS vulnerabilities can be exploited for phishing to deliver attack vectors for malware and spyware. Session management flaws such as CSRF (or session riding) can also be used for phishing. Often times, your site might have design flaws exploitable with targeted attacks that exploit information disclosure, authorization and authentication vulnerabilities. For example an attacker can try to harvest/enumerate user credentials, bank account and credit card information to use to commit fraud via different channels. When you become a victim of botnet attacks, your capability to profile the attacks and alert on the intrusions is very critical for risk mitigation: an IDS that is build into the web application such as OWASP ESAPI or in the web server such as a WAF (Web Application Firewall) can log and monitor suspicious activity and trigger alerts for potential fraud attempts. Using honeypots to learn about botnet attacks can be very useful as well as to learn how to build in defenses. Threat analysis and modeling is the key for mitigation: attack trees can be used to identify possible attack scenarios, the channels being used and the vulnerabilities that can be exploited. Take the attack tree as reference to derive the right countermeasures for the most likely attack scenarios such as the ones that the frauster might use because of the path of minimum resistance and effort. For example, considers that credit card and account data can be purchased from cyber criminal organizations selling their services on line. If such attack is cheaper than to break authentication probably that's the one that a frauster will go after first. If your site has easily exploitable information disclosure vulnerabilities probably the fraudster will attack your site first instead. The most important criteria: never assume the adoption of a anti phishing security technology will solve your problem. You need to consider different mitigations wisely and a defense in depth strategy. Be proative: consider that when you rely on the law enforcement to drive countermeasures is a little too late and this can be very painful in terms of financial losses. Before your site becomes a victim of fraud with phishing 2.0, do a thoughtful review of potential threat scenarios for all your service delivery channels for example both web, ATMs, IVRs and other delivery channels you might have. You need to consider these channels as the attack surface available to a fraudster, simulate potential botnet based/phishing attack scenarios and validate the effectiveness of countermeasures.