Attack Simulation and Threat Analysis of Banking Malware-Based Attacks

I presented on the topic of threat modeling of banking malware attacks at the Security Summit conference in Rome, Italy and at the OWASP Appsec EU conference in Dublin Ireland. A new application threat modeling methodology called P.A.S.T.A. (Process for Attack Simulation and Threat Analysis) is featured, this can be used as risk framework for analyze malware-based threats and the impact to online banking applications.

P.A.S.T.A has a provisional patent from US Patent Office and will be published in a book on Application Threat Modeling  co-authored by myself and Tony UV to be published this year. There is also a new threat modeling tool, "ThreatModeler" developed by MyAppSecurity Inc that support this methodology. So far the presentation had good reception and comments, you can follow these comments on the OWASP Linkedin group. Some companies also posted comments herein.

The business impact of banking malware-based attacks for financial institutions today can no longer be neglected since it consists on several millions of dollars in fraudulent transactions, replacing compromised bank accounts as as well as potential legal costs for law suits in case the bank account compromised are business accounts.  The impact for banks due to banking malware attacks is also increasing worldwide: in the U.S.A. alone, according to data from FDIC (Federal Deposit Insurance Corporation) that were presented by David Nelson at RSA Conference in San Francisco last February, during the third quarter of 2009, malware-based online banking fraud rose to over $ 120 million. In the UK, according to data from the UK Cards Association, losses from the online banking sector due to credit card theft totaled 60 million pounds during 2009.  The aggregated losses suffered by banks because of banking malware attacks is very significant and cannot no longer be neglected: according to Gary Warner, director of research in computer forensics at the University of Alabama at Birmingham,“Just one of the Zeus controllers steals about $10 million a week from the United States,”. Targets are web applications, financial data and authentication data:  according to the data breach investigation report of Verizon in 2010 the top five types of data sought by attackers are credit card and authentication data and web applications are the primary target for these attacks since constitute the attack path sought for the highest percentage of data record breached (38% of overall).

To mitigate banking malware threats online banking applications need to be resilient and bullet proof to banking malware attacks and implement new countermeasures. But the first step in threat mitigation with countermeasures is to understand the threat and the threat agents to procect from. Today, banking and malware attacks come from fraudsters and cybercrime threat actors, these are financially motivated, part of organized cybercrime groups and use sophisticated crimeware tools specifically designed to attack banking sites online. To mitigate these threats businesses and specifically financial need to adopt a new risk mitigation strategy and adopt a risk analysis process that allows to understand the new threat scenario of banking malware and to analyze the banking malware attack vectors.  For example, in the typical banking malware attack, initially the banking malware is dropped into the victim's PC either by social engineering the victim with phishing by infecting the victim;s browser with drive by download. After the banking malware has infected the victim's PC, since will be undetected by most of antivirus, it will be transparent to the user and wait for when the user log into the online banking site. At this point, the banking trojan on the infected PC will inject HTML directly into the user's browser (outside of security controls of the site)  by presenting extra data fields that seek to harvest the victim's PII data such as CCN, CVV, PINs and SSNs. Later on when the user will perform an high risk transactions such as a wire transfer, will transfer money from the victim account  to a fraudulent account controlled by the fraudster. The transaction will occur as authentic since is done by the frauster on behalf of the user by using the user's session. 

Stages of P.A.S.T.A. (Process For Attack
Simulation and Threat Analysis)

Understanding the threat scenario of banking malware is the first step, the next one is to adopt an effective risk mitigation strategy that includes people prepared to learn/deal/respond to new threats and attacks, processes that identify security design flaws in applications and gaps in current security controls and innovative tools and countermeasures that mitigate the risk posed by banking malware and cyber threats and the attacks realized by these threats such as Man In The Middle and Man In The Browser attacks.
Regarding the application risk mitigation processes, we are promoting P.A.S.T.A. (Process for Attack Simulation and Threat Analysis).  This is a process designed to mitigate the risk represented by cyber threats to on-line applications in general, including banking malware threats. This process is conducted in seven stages, each stage has specific objectives. For the use case of banking malware, the focus and objectives of each of the seven stages is outlined herein:

The first stage focuses on the understanding of malware-based threat mitigation as a business problem: the objective is to understand the business impact, determine the risk mitigation objectives and derive security and compliance requirements to achieve these objectives.

The second stage consists on the definition of the technical scope for the analysis that consists on the on-line banking application and the production environment. This stage consists on documenting the application profile and gather all application "design blueprints" such as architecture design documents, sequence diagram documents and transaction flow diagrams for all use cases and transactions of the application.

The third stage focuses on the analysis of the on-line banking site from the perspective of secure architecture. This consists on identifying the application existing security controls and the dependencies of application functions/transactions from these. The scope is to support the threat analysis of the effectiveness of security controls in mitigating the threats.

The fourth stage consists on the gathering of threat and attack information from threat intelligence and from internal sources. The objective is to learn from the attack scenarios and the attack vectors used by different banking malware. Internal incidents and security events are then correlated to banking malware attacks and are also used to qualify the likelihood and impact of banking malware threats.

In the fifth stage, the threat analyst looks at the potential application vulnerabilities and the design flaws identified by other assessments such as black box (e.g. pen test) and white box (e.g. source code analysis)security testing. These are the vulnerabilities  that can possibly exploited by banking malware. This analysis of vulnerabilities in this case ought to be "end to end", that is from the client/browser to the servers (e.g. web server, app servers) and back-ends systems (e.g. middleware and mainframes) that are used by the online banking application. A generic correlation framework for mapping of vulnerabilities to threats can also used to identify which vulnerabilities can be potentially exploited by banking malware (e.g. browser vulnerabilities, session management vulnerabilities).

The sixth stage consists on analyzing and simulating the attack scenarios as the attackers will do by using the same attack vectors used by malware. The purpose of this exercise is to identify IF and WHICH vulnerabilities and weaknesses such as design flaws in the application are exploited. This stage includes the analysis of banking malware attacks using attack trees, the analysis of attacks as these will the vulnerabilities using attack libraries and the analysis of the abuse of security controls for hacking financial transactions using the "use and abuse cases" techniques. At this stage, design flaws and gaps of security controls in the application are identified both at the application-architecture level and at the function-transaction level.

Finally, in the last stage, risk managers can analyze the risks and impacts and formulate the risk mitigation strategy for mitigating risks of banking malware. The basis of the risk analysis is the categorization and calculation of the risk factors (e.g. threats, attacks, vulnerabilities, technical and business impact) and the calculation of risks of each exploit with qualitative and quantitative risk models. The risk mitigation strategy includes both preventive and detective controls, defense in depth criteria for application of countermeasures at different layers of the application (browser, web application, and infrastructure) as well as new governance processes: risk based testing, improved fraud detection, threat analysis and cyber-intelligence.

The ultimate goal was to be able to provide application security practitioners with different roles and responsibility (e.g. appsec/infosec risk managers and application security architects), a use case example of P.A.S.T.A ™ threat modeling for modelling banking malware attacks, identifying gaps in security controls-vulnerabilities and identifying protective and detective countermeasures that can be rolled out by following a risk mitigation strategy. The application risk framework provided seek to empower risk management to make informed risk management decisions to protect online banking applications from banking malware.

BlackHat, Defcon, BSides, Here We Come..





It is time to attend BlackHat U.S.A. conference again and join the crowd (or herd?) of hackers (white and black hats), security researchers, consultants, security manager, information security officers. Since the conference is held in Las Vegas at the Caesar Palace Casino, it is kind of interesting to watch the scene of geeky crowd mingling with the gamblers and people nicely dressed ready for the night shows.

I attended BlackHat the first time in 2006 when I presented at a turbo talk session on Building Security In the SDLC, not quite the hacker's topic ...as I remember, it was quite stressful to be a speaker and I was rather scared to confront a very knowledgeable crowd of security folks that each attends BH...  Overall my presentation went OK but I remember I enjoyed more stressful free sunbathing at the Cabana/Booth that Foundstone Inc prepared at the venus/European syle pool at the Caesar palace casino :).

I attended BH and also Defcon in 2008 and 2009 but no longer as a speaker. I actually think Defcon is a lot of fun, you can learn from the real hackers (including the ones the get caught hacking on the Riviera Casino ATMs) and you can learn from thought leaders and stars of security like Bruce Schneier, Dan Kaminsky and others. You also get the most of your money attending Defcon instead of Blackhat since the conference fee only costs a small fraction (10% ) of what BH conference fee costs: compare $ 140 or Defcon vs. $1,800 for Blackhat....The value to attend BH nowadays, in my opinion, is mostly being able to get first hand information on exploits/hacks. As a zero-day vulnerability is announced, you ca get your company to act promptly remedied as soon as vulnerabilities are released to public. The other value of attending BH is the opportunity to network with other security professionals, promote your research/books and for me, to find good speakers for our local OWASP chapter.

Regarding the scheduled presentations of this year BH conference, there are several good ones that I would recommend attending such as Jack Barnaby's "Jackpotting the ATM" (this is the talk that was pulled out last year but now can be released), Robert Hansen's "HTTPs can beat me", Jeremiah Grossman's "Breaking Browsers Hacking Autocomplete" and Gunter Ollmann's "becoming the six-million-dollar man". There are also several presentations on mobile security that look very interesting to me, among them David Kane Perry's "More Bugs in More Places: Secure Development on Mobile Platforms". I usually tend to select talks based upon relevance for my work such as web application security as well as the reputation/bio of the presenter. I shared my selections on http://sched.blackhat.com/mmorana

Since I am staying in Las Vegas till Sunday for attending Defcon (the sister security conference that starts on Thursday till Sunday at the Riviera Hotel) I also plan to attend the few talks that were also presented at BH but that I could not attend over there.

There is also a new conference this year: BSides. BSides is an open security conference that combines structured events with grass-root security talks. I heard good things about BSides, it was held before during the RSA conference in San Francisco. My friend Tony UcedaVelez (co-author with me of the future Application Threat Modeling book) and his company Versprite are among the sponsors of the BSides Las Vegas conference. If you are in Las Vegas and you read this post, hope to meet you over there at either one of these conferences. I also kindly recommend my favorite place for breakfast, that for me is cappuccino and croissants: Payard Pastisserie and Bistro @ Ceasar Palace...

IMI Security Summit in Northern Kentucky: awesome security conference



I presented at the IMI Security Summit on the topic of "Threat Analysis as methodology for deriving risk-based security tests of web application software". This conference, gave me the opportunity to present for OWASP thanks to the invitation from Dr James Walden that teaches Software Security at Northern Kentucky University. This is the second time that I give the talk at the IMI security conference. The organization of this conference is very good as well as the quality of the speakers, one outstanding speaker to mention this year was Patrick Gray, Principal Security Strategist of CISCO and ex collegue of mine at the company Internet Security Systems.

Patrick Gray is truly an awesome speaker and presenter. I thought it is was worth attendingthe conference just for listening to his keynote. Patrick can communicate effectively to a wide audience of security folks, he gets people to think about security with simple messages, examples and with sense of humor. On the main message of his presentation, I think is 100% right in my opinion: the main security challenge the society as whole faces today besides combacting organized cybercrime, is the increased imporance of the human factor (he refers is as the human firewall) as a way to mitigate the new threats such as social networking threats and phishing. The new targets nowdays scale up to 300 + million facebook users and involve a new demographics such as a generation Y that is proned to use social networks like facebook and twitter.  As security industry and as security practitioners, according to Patrick we are challenged to respond to these new threats with increased education/awareness and the development of more effective security measures.

During luncheon, I attended the presentation from Dr Kevin Gallenger, "State of IT Security 2009". The survey data being presented are also in agreement on other surveys such as the ones from Ponemon Institute, CSI-FBI and Verizon on state of information security within organizations. For example, the survey shows that less then 60 % of organizations conduct a formal IT audit and that hackers and employees are equally problematic as source of attacks (27%). A recent Ponemon-Imperva institute survey. also shows that 71% of companies do not think compliance is strategic to security even after experiencing at least one data breach. Also, according to the same survey, internal sources of attacks are around 20-30 % of overall threat agents.

The part that I liked the most of the survey was the emphasis on the difference between "acquisition" of security and "adoption" of security in particular as related to compliance. Most companies for example, acquire security tools and produce security policies in response to compliance requirements, but they do not fully implement and/or enforce them: the survey shows for example that only 54% of companies do that. Financial services are the ones to score better.

The survey also touches the problem of incident disclosure: 44% of respondents indicated that they were unwilling to disclose the types of breaches. 

Two Weights-Two Measures

I believe that security incident disclosure is one of the main problem we face in information security today: because  we lack data on losses, fraud and incidents affecting different business sectors, we cannot identify needs and opportunities to improve security and make business case for new security investments to mitigate these risks.



But there are some exceptions, compliance with SB (Senate Bill) 1386 that is currently enforced in several US States for example, forces companies affected by data breaches to publicly disclose the losses including customer's PII such as SSNs. Thanks to SB 1386, we can still factor business impact of data breaches. For example, 100 million records of PII being reported as loss at 25 $/piece per record (estimated at the cost to buy that PII on the black market) equals 2.5 billion $ impact. I believe that only by factoring the business impact of data losses and fraud it is possible to make informed risk decisions.

I also had a nice conversation with NKU's professor Dr. Frank Braun. Dr Braun research covered business cases for software security such as ROSI, cost/benefit analysis and quantitative risk analysis as factors for making business cases. We shared some thoughts about business risk impact analysis and the human factors in risk decision making.  We mostly agreed that 1: business security is the most important factor to security 2 we lack data that prove the point about business value of security  and 3 there is a need to approach security from business perspective instead of technical perspective such as to take into consideration business impacts as well as the organizational culture of risk decision makers.

Unfortunately, most of security decision making nowdays follows different factors such as what "Gartner says" or what security vendor says or what my competitor does. Instead of rational thinking backed by quantitative data, we follow an apparoach that it either purely speculative of security business impacts or that follows the so called herd mentality...

Therefore we also concluded, that there is a need of a new culture for security management that puts the quality of securty data, expecially data on business impact of security losses as priority so it is possible to made informed risk decisions. This would require a change culture and a new School Of Information Security that put the focus on meaninful metrics such as the risk as business impact of data losses and fraud data. To know more on what I mean for New School Of Information Security, I recommend reading Adam Shostack book The New School Of Information Security.

My presentation ( please refer to our local OWASP chapter web page for further info) covered the topic of risk based security testing and was nicely attended by several folks. I had a lot of questions after my presentation, that I usually consider the best evidence that I raised enough interest on the topic being presented. I think most organizatons today are not doing good enough security testing as they should do. It is not enough to test for postive requirements to build secure applications, we need security tests that are driven by misuse and abuse cases. We also need to prioritize tests according to risks such to test first the ones that are most likely to exploit vulnerabilities and produce the largest impact. My presentation was also an opportunity to present the vs 3 of the OWASP Testing guide. This guide includes several security test cases that can be used to test for most commong vulnerabilities in web applications. The OWASP testing guide also includes information of testing tools (most of the them are OWASP tools) as well as techniques that can be used. The OWASP testing guide is considered by software security experts and thought leaders such as Dr. Gary McGraw, one of the best pieces of intellectual property ever produced by OWASP.

Business Cases For Your Software Security Initiative

I dealt with the topic of the business case for software security initiatives in the past: you can refer to published articles (ISSA Journal 2006, In-secure Magazine 2008) and presentations(Black Hat in 2006 and OWASP in 2008). Interesting enough, this seems to be still an hot topic: I am often inquired on this by CISOs and CIOs in the past as well in my current ISO work, hence I decided to articulate my answer again with more details with this post.

Building software security into the organization’s software engineering and information security practices can be accomplished by following software security maturity models (e.g. BSIMM or SAMM) as well as by adopting software frameworks to integrate software security activities within the SDLC along with security processes such as information risk management, patch management and security training and awareness.

From the software engineering perspective for example, the assumption is that your organization already measures the costs for fixing software security failures due to known vulnerabilities as well as the cost of fixing the ones resulting from incidents/exploits. Total software security failure costs include both the cost of business impact in exploiting software failures (e.g. cost of a vulnerability exploit that caused harm to the organization such as denial of service) as well as the cost to fixing a known defect due to a security issue found with testing, being a security bug, a design flaw or a mis-configuration.

The problem of the software security metrics is that implies that the organization software and information security practices are matured enough to produce this data so you can correlate this information from risk management, fraud management, vulnerability assessment, software engineering/project management and quality assurance. The availability of such metrics implies that development teams have already started to build software security activities into the SDLC such as source code analysis, penetration testing, threat modeling but also that they have started working together with security teams to measure software security risks and manage them during the different phases of the SDLC.

A pre-requisite for any software security initiative business case is the availability of the organization's information risk data that include risk management, vulnerability metrics as well as software security engineering data such as defect management and patch management.

From information security perspective, the business case for software security need to start from the organization's information risk management data, business impact analysis and correlate application vulnerabilities as critical when these correlate to business impacts. For this reason (i.e. the lack of organization software security data) the business case for software security is one that is hard to make.

Based upon my experience on the topic, that is working both as consultant as well as security technology officer for large software organizations, you can make the business case (or the case for the business) for software security initiative by following the approach outlined herein:
1) Adopt an information risk management perspective, that is using your vulnerability, incident and fraud data for the business case
2) Gather software engineering data and categorize them in terms of when are found, when are fixed, when the fixes are tested and deployed. Correlate this data on how much it costs to fix vulnerabilities at different phases of the SDLC.
3) Gather data on security incidents and fraud because of the application/software being attacked. Quantify in dollar amount how much these security incidents and fraud cost to your organization.
4) Analyze the business case by analyzing/quantifying the following factors:
• Cost vs. benefit: by comparing software failure costs vs. security assumption costs
• Quantitative risk: by comparing cost of mitigation vs. impact of probable loss
• Return of Security Investment (ROSI): by quantifying $$ saving amounts for adoption of software security activities early in the SDLC

Basically the business case for the software security initiative needs the data that the initiative is suppose to provide. In essence this is a chicken vs. egg problem you can only manage what you measure and you need metrics to make the business case for.

So what are the alternatives for the business case in absence of such data ? You need to make assumptions on what are you software engineering costs, estimate the cost of patching and to fix vulnerabilities as well the security costs because of software failing such as for example financial losses that vulnerability exploits might cause, include for example the cost of loosing customer data, money losses because of fraud via the web channel, disruption or denial of service and least and not last intangible reputation loss because of vulnerabilities being publicly disclosed.

The data to produce for the case depends on who the case is made for. If the business case needs to be made for engineering and software development teams for example, you can assume a software engineering perspective. You can refer to public studies that analyze the cost of fixing software defects.

A NIST study on the economic impact of insecure testing for example shows that cost of fixing defects is 100 times more expensive during system testing than coding. You can tailor this data to estimate how much it would cost to your organization fixing vulnerability from quality/defect management perspective. If development teams already started doing vulnerability assessments such as by including web application penetration testing in the SDLC, the vulnerability metrics can also be used and correlated with the cost of fixing them.

If your organization is mostly relying on patching to fix security defects, you can refer to the cost of producing security patches (e.g. hotfixes) to fix vulnerabilities vs. the cost saving of testing and fixing software security defects earlier in the SDLC.

Let's say the cost of engineering, developing, testing and deploying a patch to your vulnerable software/web application is 10,000: it is realistic to estimate using NIST data that the fixing this patch earlier in the SDLC would have cost you 10% of the patching costs and your company 90 % of overall patching costs (e.g. 9,000 $)

Just including patching costs is not conservative enough for a real estimate of total software security failure costs: you need also to include the business impact of exploits such as either the risk of exploiting a known vulnerability or an unknown vulnerability (e.g. Zero Day) such as the ones exploited and do not follow responsible public disclosure causing the organization intangible costs..

Even in absence of a vulnerability exploit it is still important to factor the cost posed by the business impact to the organization caused by the exploit of the vulnerability. In the case of intangible costs for example what is the intangible cost of cross site scripting vulnerability publicly disclosed on XSSEd.com site? How much is the cost of reputation damage to have such vulnerability publicly disclosed? Any public published vulnerability can cause intangible loss to company reputation, the company brand and the franchise and affect customer confidence on the company product and services.
Would intangible costs by themselves justify the existence of a responsible disclosure process to engage security researchers that have found your site vulnerabilities: YES. Would this justify fixing all known vulnerabilities before going into production with a penetration test? YES

But to really factor software failure costs as the business impact of exploiting a vulnerability it is important to correlate attacks with vulnerabilities and the business impact that cause. The recent data from the Web Hacking Incident DB that correlates public information from security incidents with web application attack vectors for example has SQL injection as #1 (19% of all attacks) that includes manual targeted attacks as well as mass SQL injection bots. From the perspective of attack vs. risk prioritization SQL injection vulnerabilities represents the ones that most likely will be exploited to cause harm to your organization and are the ones that would produce high failure costs (e.g. use for break into authentication, upload malware, denial of service, un-authorized access to sensitive data), when mitigated, SQL injection vulnerabilities would provide the most benefit in terms of mitigating business impacts.Since the SQL injection vulnerabilities root cause is coding such as using concatenated SQL statements instead of store procedures or prepared statements, fixing SQL injection vulnerabilities in the code alone would make the case of adopting secure code reviews.

Most organization's directors of technology and security try to sell technologies and new initiatives to high management with the sales pitch of getting the most "Bang For The Buck" BFTB. But the BFTB business case need to answer the basic question: if I spend that much on a security technology or process what is the benefit for security ? In technical terms this means doing a Cost vs Benefit Analysis (CBA). CBA can be used in security to correlate the total cost of security to increased information or software security assurance. Dan Geer covers well this analysis as related to data security in his book "Economics and Strategies of Data Security".

By analogy, in the case of software security, "Bang For The Buck" decision spending need to take into account the total security costs that is all failure costs such as the total cost of failing as business impact as well the total cost of finding, fixing, testing and deploying the security defect. Only then, the total cost of software security (the BUCK) can be compared against the BANG that is the increased level of software security assurance.

The general law for bang for the buck is that you are getting the most bang for the buck when your total costs (cost of failure/data loss/fraud + cost of security/countermeasure) reaches a minimum. As failure costs decrease exponentially, the "anticipation costs" that you take proactively by spending in software security initiatives will increase.

From risk management perspective this means that the total software security costs decrease up to a minimum to raise again as you keep spending on security measures. You will reach an optimal cost vs. benefit where more spending in anticipation cost (e.g. countermeasures) will not provide the most benefit (e.g. spending more in countermeasures then the value of the assets that the countermeasure is supposed to protect)

This optimal spending for anticipation costs (proactive countermeasures) is about 40% of your failure costs (to be exact 37% according to Gordon and Loeb research: The Economics of Information Security Investment).

According to the empirical law of the most bang for the buck applied to software failure costs vs. assumption costs it is therefore fair to assume that you get the most of security by spending 37% of what your software failure costs are.

Assume for example software security failures costs are $ 10 ML it would be reasonable for an organization to spend as much as $ 3.7 ML in acquiring software security tools and technology, develop new software security process as well as in new software security training activities.

Application security failure costs can be also factored as monetized fraud occurring via your web site/channel: a spending of as much as 37% of the fraud costs in securing the web site can be justified according to the most bang for the buck law.

In the case of business impact due to data loss such as identity theft for example, you can factor the overall fraud related to data loss potentially impacting your organization: consider that 14% of all publicly reported data loss incidents occur via the web channel according to the data collected from datalossdb.org.

Assume that according that 2003 FTC data the potential loss per identity theft incident is $ 655 per incident. Assume you are serving via your web site a population of 4 million customers, the potential loss of losing your customer data such as credit card accounts for example would be of $ 2,6 Billion and with probability of identity theft occurrence of 4.6 % (also FTC data) the projected loss for your company could be $ 120 ML for which 14% or $ 16 ML would be the cost of data losses via the web channel alone.

With these assumptions based upon publicly disclosed data losses, a security program (that include both information and application security) that cost as much as $ 16 ML would be justified for a company with a customer base of 4 million on-line customers for example.

A quantitative risk assessment can also be used to determine the extent on which a software security initiative can reduce risk from potential losses. The correlation has to take into account the probability of the event and the loss that the event can cause. This is difficult to quantify in general for software security issues since assumes a cause-effect between vulnerability exploit and financial impact. Nevertheless it can be used for rough estimates.

Assume a web application that delivers banking services for example and that the loss caused by an event such as denial of service impact on-line transactions for 3 million customers with an average of $ 20 per transaction: the loss per single DOS event (SLE) is $ 60 ML.

Assume that the probability that a new SQL injection vulnerability would cause a denial of service is 30% (Annualized Rate of Occurrence) then the Annual Loss Expected (ALE) is $ 1.8 ML. If the cost of the new security countermeasures that will stop the security incident is less than $ 1.8 M than the organization should implement it.

Assume the countermeasure in this case is the total cost of secure code reviews, you need to factor the cost of tools and technologies/APIs (e.g. source code analysis and penetration tools), of the security engineering process (e.g. documentation and metrics) as well of software security training and awareness for developers. The tools and technologies need to include the Total Cost Of ownership that is both the cost of acquiring and maintaining the technology.

Besides cost vs benefit analysis and quantitative risk assessment, the return of security investment (ROSI) can be used to make the software security business case around effectiveness of a software security initiative.

ROSI answers the question if I spend $ 100K in software security initiative do I save more money by fixing defects with a penetration test, secure coding or threat modeling. Again this is where the metrics is essential:making the case with ROSI assumes you already collect SDLC data that show how much it cost to perform software security per each phase, the number of issues being identified at each phase and the how many are fixed at each phase you can make the business case for an activity vs another. Otherwise you can reference public study of ROSI from Kevin Soo Study " for every $ 100,000 spent on software security, $ 21,000 are saved by doing application threat modeling during design, $ 15,000 are saved by doing source code analysis and $ 12,000 are saved when defects are found with penetration tests. Overall the earlier you invest in security the greater the return.

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

Application Security Conferences/Events (July-November)

I thought to announce herein a provisional list of conferences/meetings that I plan to attend:
July 30th Local OWASP Chapter: Presenting on Building Security In The SDLC
August 6-7 Blackhat, J.C. Palace Las Vegas: Attending
August 8-10 Defcon16: Riviera Hotel, Las Vegas: Attending
September 23rd Local OWASP Chapter: Co-Presenting with Scott Nusbaum on Encoded Attack Vectors, Threats and Countermeasures
October 3rd : IMI security symposium, Northern Kentucky University: " Managing Software Security Risks Using Application Threat Modeling"
October 30th : Rochester Security Summit, Presenting: Producing Secure Applications with Software Security Engineering and Risk Management Processes
November 5th Security Day in Sardegna (Italy): Presenting On Web Application Security Initiatives: The Open Source Way and Moderator for the Round Table on Open Source vs. Commercial Software Security
November 10 and 11: IASA IT Architect Regional Conference in Singapore: Presenting on: Architecting Secure Web Applications Using Security Engineering Design and Risk Management Processes

If you plan to attend any of these events/conferences please send me a note.

Security and Privacy Day @ Stony Brook

Stony Brook University is hosting a Security and Privacy Day next Friday May 30th http://web.crypto.cs.sunysb.edu/spday/. The topics being covered are pretty interesting such as language based security, security and outsourcing, network security, trusted hardware and privacy:

Use of Links programming language to enforce security policies http://www.cs.umd.edu/projects/PL/selinks/ from Dr Michael Hicks of Univ of Maryland

Languages for tracking information flows and in particular security metadata (e.g. CIA attributes) from Dr Marco Pistoia of IBM

Database as a Service (DAS) for secure and efficient query evaluation over encrypted databases from Dr Wendy Hui Wang of Stevens

Security as A Service models (SaaS) from Suresh Sari also from IBM Research

An other interesting papers..

May 25 is the deadline to register. The organizers also plan a nice sightseeing program with wine tasting and boating trips around the Long Island Beach area.

I plan to attend the conference also to meet Dr Radu Sion for which I had some previous paper email exchanges (Financial Cryptography Conference in Mexico last January that I did not attend) and connect with some academics in light of my future publishing endeavors (a book I intend to write on Software Security Frameworks)

Most importantly to take Suzanne (my wife) with me and celebrate together our 4th wedding anniversary with a nice visit/lunch at one of the local wineries on Saturday.

Security and Wine Tasting is really appealing...+ car racing event would be elecrifying...I refrain myself would not take the wine-car talk spin topic on this blog... Cheers :)

Success story of the OWASP Day II in Italy

I participated to OWASP Italy back in March. OWASP Italy was a success story: more than 200 attendees, 9 great speakers, 5 sponsors, 1 round table and an article (in Italian) here:
http://punto-informatico.it/2266944/PI/Commenti/La-Web-Application-Security-parla--anche--italiano/p.aspx

Here is the OWASP page of the event in English with the presentations:
http://www.owasp.org/index.php/Italy_OWASP_Day_2

It was very nice to meet Matteo Meucci, Stefano Di Paola, Giorgio Fedon and Jacob West in Rome. The organization of the conference was fantastic and good lesson for me. Wish one day I will be able to organize a similar event with my OWASP chapter here in USA. My kudos to Matteo bellissimo lavoro, bravi!! Go OWASP!

OWASP Italy:The State of the Art of the Web Application Security and the OWASP guidelines for Companies

Back in 2005 my first involvement with OWASP was to help write the OWASP testing guide. The project was successfully lead by Matteo Meucci that is founder and chair of OWASP Italy and CEO of Minded Security. Three years later Matteo invited me to participate to the sponsored event on March 31st at the Congress Center of the University of Rome La Sapienza. The topic of the one-day event is "The State of the Art of the Web Application Security and the OWASP guidelines in the Companies". The topic of my presentation is: "How to start a software security initiative within your organization: a maturity based and metrics driven approach."

As part of the event Matteo will moderate a round table talk on the following topics:

1. Which are the countermeasures that organizations adopted to mitigate new attacks?
2. Responsible information disclosure of vulnerabilities: what's the best approach?
3. How do you implement a security enhanced software development life-cycle that also provides a good Return of Security Investment (ROSI)?
4. Customers security awareness: does it provide fundamental leverage for implementing security controls?

My presentation can be found herein: http://www.owasp.org/images/a/ab/Owaspday2Morana.pdf

A detail program of the event can be found here

OWASP Top Ten and In-secure Software Root Causes



A security professionals diagnosis of vulnerabilities
is similar to a doctor diagnosis of viruses;
 there are causes and symptoms



I did a presentation last week for my OWASP local chapter on application vulnerabilities and in-secure software root causes. A little too much to cover in one hour, the next time, I will do just one session per vulnerability and be less Italian in my perception of time...

Here is the Abstract Of the Presentation:

Before to diagnose the disease and provide the cure a doctor looks at the root causes of the sickness, the risk factors and the symptoms. In case of application security the majority of the root causes of the security issues are in-secure software, the risk factors can be found in how bad the application is designed, the software is coded and the application is tested and the symptoms in how the application vulnerabilities are exposed. The presentation will articulate the problem of secure software, the costs, the software security risks and how these are typically dealt with by most organizations. Solving the problem of software security requires people, process and tools. From the information security perspective we will look at ways to enforcing software security by looking at risks that threat agents (attacks) can exploit vulnerabilities due to insecure software and the resulting impact on company assets. Implementing a set of software security requirements is the best place to start to address the root causes of web application vulnerabilities. With a categorization of web application vulnerabilities as weakness in application security controls, it is easier to describe the root cases as coding errors. A good place to start documenting software security requirements is the OWASP Top Ten, for each of these vulnerabilities we will discuss the threat, the risk factors, the software root causes of the vulnerability, how to find if you are vulnerable and if you are which countermeasures need to be implemented.

The presentation can be downloaded from OWASP site herein:

https://www.owasp.org/images/e/eb/OWASP_Top_10_And_Root_Causes_Cincy_Feb_26_08_Final.pdf

Application Security Vulnerabilities and Insecure Software Root Causes

From the information security perspective analyzing software risks means identifying vulnerabilities and implementing countermeasures as soon as they manifest in the software you build. Previous research shows that this is more cost effective then testing and fixing what is already being integrated in QA environment or catching and patching what is already being deployed in production. I wrote an article for the February 2008 edition of in-secure magazine with the intent to tell information security practitioners how to perform software risks analysis. In a nutshell software risk analysis means: identify common threats to web applications, find out the exposure to these threats caused from vulnerabilities due to insecure software and estimate the potential impacts derived by exploiting such vulnerabilities. I gave a few examples on common web application threats, how and where vulnerabilities can be identified, the root causes in insecure software and the implementation of countermeasures: http://www.net-security.org/dl/insecure/INSECURE-Mag-15.pdf

The next step after performing the software risk analysis is to document the basic software security requirements that you would like your software developers to follow when developing web applications. Both source code analysis and web application penetration testing will validate that such requirements are satisfied and that the risks posed by the vulnerabilities are mitigated before releasing the application to your customers.

2006 in Review

2006 has been a prolific year, rich on contributions among the secure software community. So what has been my part? Well, I did my little too. In a summary these are my contributions as publisher, reviewer and presenter in 2006:

• January 2006: ISSA Article Building Security Into Applications
• August 2006: Blackhat Presentation:Building Security in the SLC
• August 2006: DHS review of: Security in the Software Life Cycle
• November 2006: CSI Presentation: Secure Code Reviews
• December 2006:OWASP contribution:Testing Guide

And of course all the hours spent on consulting work for my clients on behalf of Foundstone. So here I would like to thank all, clients and attendees of my presentations. Your critical feedback helped me to improve and add more value on my work.

To you all Merry Christmas and Happy New Year 2007.

BlackHat 2006 Presentation Outline

This is the consolidated outline of my BH presentation: Building Security In the Software Development Life Cycle:

· Introductions
· How we define risk
· What is at risk, how we approach it and how we address it
· What are the costs of application security and software security?
· Data from a case study: build the business case with ROSI
· Secure Software Development Life Cycle: How do we get there?
· Secure Software Development Life Cycle: Is People, Process, Technology
· Security-Enhanced Lifecycle Process Models Compared: CLASP, MS SDL, McGraw TP, SEI TSPSM
· Security Frameworks: Mapping Activities and Software Security Best Practices
· Business Risks and Technical Risks: Review the business case and commit to it
· Summary: Take away lessons
· Resources: Foundstone Links
· Questions?

Hope to see you at my presentation, August 3rd 4.45 PM !