Application Security Guide for CISOs

To make OWASP more visible to Chief Information Security Officers (CISO)s I put together an initial draft of an application security guide that can be downloaded from here. I believe the time is mature for an organization like OWASP to reach up CISOs directly with a targeted guide. The first part of this OWASP guide, need to document the business cases and risk-cost criteria for budgeting application security processes, tools/technologies and training. This is not an easy task because of the current economic recession requiring organizations to operate with tight budgets for information technology including application security while confronted with the need to mitigate the risk of increased number of attacks and security incidents. Therefore, CISOs today need to be able to articulate the business cases for application security and made the application security budget justifiable according to both risk mitigation and cost efficiency criteria. From risk mitigation perspective, it means to be able factor how much security incidents cost to the organization specifically when such incidents are caused by exploiting application vulnerabilities. Security incidents caused by malware and hacking threat agents that exploit application vulnerabilities such as SQL injection for example could cost businesses lots of money. For an business critical web application such as online banking for example that means several million of dollars of potential losses. By adopting criteria such as quantitative risk analysis, it is possible to calculate how much money should be spent in application security measures and justify this by comparing it with the cost of potential losses. When these losses are potential the cost need to be estimated, when these losses are the consequence of a security incident, this can be calculated based upon real operational costs such as the ones to recover from the security incident. From the application security costs efficiency perspective, criteria such as return of investment can help CISO in deciding how to spend the application security budget effectively such as in which SDLC activity (e.g. pen tests, source code analysis, threat modeling). In order to validate the assumptions of the guide, it would also required to gather CISO feedback such as in a form of a survey to assess risk mitigation from exploit of vulnerabilities by hacking and malware as well as other needs such as compliance so that this application security guide can be documented.

Identity Theft and Phishing and How Affects Financial Institutions



MiTM attack to a bank:
 source http://www.securelist.com/



In the USA, online fraud has overtaken viruses as the greatest source of financial loss (Symantec threat report http://www.symantec.com/business/theme.jsp?themeid=threatreport )

Among on-line fraud threats, phishing represents a major threat for financial institutions and according to the Anti-Phishing group organization, 93.8% of all phishing attacks in 2007 are targeting financial institutions. Also a recent study indicates that phishing attacks in the USA alone soared in 2007 to 3.6 Million victims for a total reported customer loss of USD 3.2 Billion. In 2006 , the USA had 2.3 Million victims of phishing and USD 500 million in losses (Gartner study: http://www.gartner.com/it/page.jsp?id=565125)

Recent research on phishing by Rachna Dhamija at Harvard and J.D. Tygar and Marti Hearst at US Berkeley "Why Phishing works" http://people.seas.harvard.edu/~rachna/papers/why_phishing_works.pdf indicates the phishing is a very effective attack (how could not, target human factor that is the weakest!), and that the best phished sites were able to spoof 90% of participants in the study.

We tend to forget that most of web site phishing controls are "trust indicators" that are try to tell the user that indeed this is a trusted site. Among the controls, showing the address bar with a branded domain and obliviously prompting the user to recognize SSL are the most effective but from the user perspective can be ignored and from the hacker perspective can be spoofed. Therefore this is an area where better controls need to be addressed from usability and security perspective: if I force the user to use mutual authentication via SSL I will implement an effective control for phishing but I will impact usability (scaring my customers away) as well as my costs (for PKI for example). Deploy PKI for each customer is a cost that most financial institutions cannot afford today.

So there is a need to design a antu phishing solution at the application layer that addressed both usability and security. A possible solution could be using multi-layerd security such as to deploy multiple controls:anti-phishing deterrent controls and multi factor authentication preventive controls. The problem with phishing today is that the threat exploit is cheap to make. For example right now is very easy for an hacker to phish a site by exploiting web application vulnerabilities: it does not require an hacker to spoof the legitimate site and recreate all web pages but rather to send a malicious link to the user (the legitimate one) with the attack vector (for example an XSS vector) as part of the URL. Another very dangerous attack is phishing with a web proxy for a Man in the Middle Attack (MiTM). Assuming that the hacker get the opportunity to phish a victim via a malicious link that point to one or more web proxies (such as via a botnet), this attack will be very effective in breaking MFA authentication controls too.

Since a large amount of phshing attacks exploit web application vulnerabilities it is important to test that you build your web site immune from these vulnerabilities. Examples of vulnerabilities that you should tackle for mitigating phishing attacks are weak authentication and authorization controls, weak session management and especially input validation vulnerabilities. The OWASP Top Ten provides a mapping to vulnerabilities to attacks for phishing, privacy violations, identity theft, system alteration and data destruction, financial loss and reputation loss http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf

An example on how XSS vulnerabilities can be exploited for phishing is via a login page that uses frames: a malicious user can inject a malcious frame to collect username and passwords via the legitimate login web page. This attack has been used for identity theft with bank sites in Europe and has been covered on the February 2008 edition of the in-secure magazine http://www.net-security.org/dl/insecure/INSECURE-Mag-15.pdf

Unfortunately, phishing attacks through MiTM via a web proxy are not mititigated with one countermeasure alone such as a strong authentication control. For example the strongest multi factor authentication MFA solutions commercially available right now such as RSA OTPs, Cyota Risk Authentication, SiteKey etc are still vulnerable to these attacks. By RSA's Uri River admission, any type of token, if deployed as a single layer of security, is vulnerable to good social engineering and a MITM attack so the threat has to be addressed with multi layer controls and not MFA alone: http://www.rsa.com/blog/blog_entry.aspx?id=1114 The best way to respond to these threats is do a threat analysis and address the risk with multiple countermeasures such as multiple layer security controls not just MFA.

Regarding identity theft threats, a must read for information security practitioners that work for financial institutions is the recently published data from UC Berkeley Center for Law and Technology. This study is the first attempt to quantify risk of identity theft among institutions. Being the financial institutions the largest target for phishing I was not surprised to see some of the largest banks in USA being on the top of the list for number of reported identity theft incidents in 2006 by the FTC (Federal Trade Commission). The most surprise on my opinion was to see the largest telco At&t/Cingular/SBC coming #2 after BofA/MBNA. Among the largest financial institutions (based upon number of bank deposits) , HSBC has the highest number of incident reported then BofA, ING Bank with only one single event had the lowest no. of incidents of identify theft reported. The bank that I work for, Citibank ranks #7 among the top 25 in this study: http://repositories.cdlib.org/cgi/viewcontent.cgi?article=1045&context=bclt

These metrics should drive US banks to reconsider how effective are the countermeasures. Assuming that most US banks had MFA solution rolled out because of FFIEC compliance by 2006 these data tells us that the threat is still not adequately mitigated. IHMO this is a call for banks CIOs to change strategy and update the necessary audit controls by signing off new policies for mititigating the threat, for CISOs to implement more effective security review processes for threat analysis and for security practioners to test the effectiveness of current controls so that new countermeasures can be implemented as required.

MFA security controls and their adequacy to mitigate financial fraud and identity theft

The FFIEC compliance for authentication in the banking environment guideline, states that single factor authentication is not adequate to secure high risk banking transactions such as the ones involving the transfer of funds and dealing with customer sensitive information (e.g. PII, Account Numbers etc). To comply with this guidance (that was EOY 2006) most banks implemented custom based authentication solutions on top of typical credentials authentication (username and password) such as One Time Password (OTP) tokens (e.g. Secure IDs), challenge/responses questions based on shared secrets and risk based authentication solutions (e.g. Cyota). Unfortunately, the fact of the matter is that most of these MFA banking solutions have not being implemented with the real intent of the FFIEC mandate to banks that is perform a risk analysis, identify the financial transactions that are at high risk, evaluate how effective are the security controls to mitigate threats and implement a security solution that is not necessarily a MFA control but can also be multi-layered security mechanism.

There is evidence from publicly available research that most MFA solutions are still vulnerable to fraud via phishing and MiTM (Man In The Middle) attacks, a proof that in the trade-off between FFIEC compliance, usability and security, security did not become the main outcome of the implementation.

In the case of SiteKey (i.e. PassMark Security ® (now RSA ®, the security division of EMC ®)authentication technology used as MFA (Multi-Factor Authentication) for on-line banking sites such as Bank of America and other banks ( Vanguard and Pentagon Federal Credit Union) several fraud vulnerabilities have been indentified. In particular SiteKey is not a sufficient deterrent to phishing ot other online frauds: http://cr-labs.com/publications/SiteKey-20060718.pdf

On SiteKey Technology specifically, Christopher Soghoian and Prof. Markus Jakobsson, both with the Stop-Phishing Research Group at Indiana University presented a demonstration of a "man in the middle attack" against it: http://paranoia.dubfire.net/2007/04/deceit-augmented-man-in-middle-attack.html

Back in July 2006, Ravi Ganesan CEO of TriCipher was interviewed by Martin McKeay on the MiTM web proxy attacks to MFA http://media.libsyn.com/media/mckeay/nsp-072506-ep36.mp3. In the podcast Ravi explains how easy was to replicate the attack and pointed out that all token based MFA solutions such as RSA tokens, cookies, challenge response/risk based authentication with device fingerprinting, IP address and geolocation, scratch pad OTPs. were vulnerable to this class of attacks. Especially in the case of MFA that use geolocations and device fingerprinting, Ravi made the clear point that such countermeasures are not effective to mitigate phishing attacks that use botnets in different locations and are re-routed from different proxies. Also, when using cookies for authenticating (recognizing) the machine the mechanism of registering the cookie based upon a user correct answer to a challenge question was also proved to be exposed to phishing: the phisher will send a message to the victim user to provide the answer to the challenge question because the machine could not be recognized.

The main problem is probably that these MFA solutions were implemented to buy a checkmark from a FFIEC auditors and quickly adopted in a rush to comply with the 2006 EOY FFIEC deadline. Now, two years later we wonder why these MFA controls are not actually mitigating the identity theft and financial fraud that were supposed to prevent.

Nowdays there is a need of a viable MFA control that provides a good compromise between (1) cost, (2) usability and least and but last (3) security. I would not be surprised if in light of the growing identity theft and fraud threats we saw in 2007 some and the high Total Cost of Ownership (TCO) to keep these vulnerable MFA technologies, some banks will implement cheaper and more threat mitigation effective MFA controls.

Lessons learnt from TJ Maxx data breach and credit card fraud

The main security lesson that credit card issuers learnt from TJ Maxx companies 95 million credit cards data loss and 1 Million USD transaction fraud is the need to require merchants to secure the weakest ring of the chain: the WLAN connection between POS (Point Of Sale) terminal and branch servers . Merchants should learn from POS vulenarbilities and apply the right countermeasures like the ones identified in the research paper herein http://www.hackerfactor.com/papers/cc-pos-20.pdf. Now, despite the major exposure of the TJ Maxx security incident was due to weak wireless encryption such as WEP (Wired Equivalent Privacy) http://online.wsj.com/article_email/SB117824446226991797-lMyQjAxMDE3NzA4NDIwNDQ0Wj.html) there are still a large amount of retailers that either do not secure their WLAN at all or still use the flawed Wired Equivalent Privacy (WEP) protocol or the pre-shared key mode of the Wi-Fi Protected Access (WPA PSK) specification, which was originally intended as basic security for home or SOHO WLANs:http://www.pcworld.com/article/id,141429-c,privacysecurity/article.html

The other lesson is that VISA PCI compliance is more a vehicle to recoup fraud losses rather then proactive security. In the case of TJX Maxx VISA fined 53rd Bank (the TJ Maxx VISA Card processor) 880,000 USD for non being not in compliance with PCI in light of 2005 incidents but gave the credit card processor a 2008 deadline to comply http://www.scmagazineus.com/Visa-fines-TJX-credit-card-processor/article/58255/ Now 1 ML fraud vs. 880,000 fine still seem to repay VISA for most of the losses.

The other lesson is that law suits are not a strong enough deterrent for being secure in case of large retailers such as TJX Maxx. The 257 Million USD law suit that TJX Maxx settled with smaller banks http://www.boston.com/business/globe/articles/2007/10/24/court_filing_in_tjx_breach_doubles_toll/?page=2 certainly did not put TJX out of business: http://www.darkreading.com/blog.asp?blog_sectionid=403&doc_id=137756&f_src=darkreading_section_403

In Italian we have a say that "il rischio non vale la candela" (the risk does not warrant lighting the candle) saying if the air smells like the all environment is about to explode probably is better not to light the candle. Now in this case I think retailers will probably continue not being compliant with PCI standard while the fraudsters that are still uncaught and out in the wild we will continue to light the candles.