OWASP Italy Presentations: Business Cases For Software Security Initiatives: Maturity Models, Metrics & Measurements and Security Cost Analysis

On November 4, I am going to present at Italy's OWASP Day E-Gov 09 OWASP (Open web Security Project) and CONSIP (a company of the Italian Department of Economy and Finance) sponsored security conference on the topic of software security initiatives. In my presentation , I address first the pre-requisites for the software security initiative:

1. Compliance with information security standards (e.g. PCI DSS);
2. Education and awareness on root causes of vulnerabilities in applications/software;
3. Software security engineering benchmarking using a software security maturity model;
4. Business cases to justify budget and investments in software security.

Since the initial cases for software security initiatives are often made for the senior managemen (the sponsors of the initiative), it is important to make the appropriate business cases by citing executive level reports from Gartner, Forrester as well as public research on software security from NIST, SEI, DHS. Examples of good resources include NIST research on the causes of vulnerabilities and on the economics of in-secure software and Gartner press releases on economic impact of software security.

The next step is to assess the organization's secure software engineering processes and capabilities using a standard such as a Software Security Maturity Model (SSMM): the objective is to make the sponsors of the initiative aware of the organization's capabilities in secure software engineering, risk management, governance and training

The recently (2009) published Build Security In Maturity Model (BSIMM) from Dr. Gary McGraw and the Software Assurance Maturity Model (SAMM) from Mr. Pravir Chandra can help organizations in the assessment, planning and implementation of software security initiatives. These models are explictly designed for software security assurance and are based upon real data (surveys) from companies that actually had enacted and implemented software security initiatives. The models are organized along similar domains (e.g. governance, intelligence, SSDL touchpoints, deployment for BSIMM and governance, construction, verification, deployment for SAMM) each domain has three best practices and three levels of maturity. BSIMM's 12 best practices have a total of 110 sofwtare security activities and maturity levels that can be achieved by assigning goals and objectives to each activity.

A traditional maturity model such as the Capability Maturity Model (CMM) can also be used to assess a level of software assurance even if is primarly designed to assess maturity for software quality assurance, engineering and other organization domains. More specifically for the security domain, the System Security Engineering Capability Maturity Model (SSE-CMM) addresses maturity of security systems as a whole and can be used for software security as well.

Based upon my previous professional experience on the System Security Engineering-Capability Maturity Model (SSE-CMM), it is possible to map software security activities to CMM maturity levels and provide a roadmap for software security maturity. For example from initial (level 1) to optimized (level 5) via repeatable (level 2), defined (level 3) and managed (level 4) levels of software security assurance. The mapping of software security activities for each level need to include main security domains such as:

1. Software Risk Analysis & Management
2. Software Security Engineering
3. Security Assessment Processes and Tools
4. Security Training & Awareness.

In my presentation, I provide the mapping of CMM maturity levels to software security processes such as security testing (in BSIMM this domain is referred as SSDL touchpoints domain and in SAMM as verification business function) since for most organizations the evolution toward software security starts from application security assessments such as web application pen testing and then evolves to secure code analysis, threat modeling as well as other supporting best practices such as metrics and measurements, risks management, software security training and awareness.

In my opinion, the most important element of any maturity model is the definition of the software security roadmap that provides a set of standard activities that allow an organization to reach capability levels that can measured both qualitatively and quantitatively.

For example an organization can start at CMM Level 1 (Initial) with a catch and patch approach, move to CMM Level 2 (repeteable but reactive) by ethical hacking existing applications, move to CMM Level 3(defined and proactive) by defining a security testing process such as vulnerability assessment as part of the SDLC that is adopted for security assessing vulnerabilities for each web application project at the organization level, move to a level CMM 4 (managed) by risk manage projects with checkpoints in all the SDLC phases (e.g. asserting security by design, development and deployment) and by using vulnerability metrics to make informed risk management decision at each checkpoint and finally to level CMM 5 (optimized) by optimizing software security processes for increased return of security investment, security cost savings and improved risk mitigation/reduction.

One essential factor for achieving maturity is understanding the concept of the maturity curve: this is similar to the learning curve to mature in knowledge and skills: a maturity curve shows that time is needed to acquire maturity. Since the maturity level curve provides the time frame for reaching software security maturity, it helps planning and set up the right expectations to management and also factor the costs.

For example, the effort required to an organization for passing from CMM level 3.5 to 4 is the highest hence only few large organization can afford it: this coincides from proactively define a software security process and manage it thought the SDLC for each product at organization wide level. From the time perspective for example software security processes are not acquired and assimilated overnight but over the course of several years especially when the sofwtare security initiative impacts several business units with several different SDLCs as well as hundreds of web applications to risk manage.

The most critical element of a software security initiative are metrics and measurements: only by the definition of what we should measure, where and how it will be possible to manage software security risks and assess the organization maturity in acquisition and assimilation of software security best practices. In my opinion, the essential software security metrics for software security include process and vulnerability management metrics in support of vulnerability root cause analysis, governance gap analysis and the risk analysis.

On November 5, I will be in Milan to present at Italy OWASP Day 4 on the business cases to justify investments on software security initiatives such as the spending in software security: the goal of this presentation is help security managers in answering questions from senior management to justify the spending such as why we should spend money for software security, how much we should spend and where.

In a nutshell this means quantify the business case for software security in terms of security costs such as cost vs. benefit analysis, assumption costs vs. failure costs, quantitative risk analysis and Return of Security Investments (ROSI).

The key in this analysis is to be able to estimate the software security failure costs such as the ones due to business impact deriving from a data breach or fraud. For most organizations this is a daunting task because these data are not available, hence I am suggesting an approach that uses public sources to estimate such costs such as reported data breaches from FTC (Federal Trade Commission), data loss incident data from datalossdb.org and correlation of incidents to vulnerabilities from the Web Hacking Incident Database (WHID).

Quantifying failure costs is essential for a cost of security initiatives vs. benefit of the initiative analysis. In the presentation I show how assumption costs (cost that your organization assume for software security initiatives) correlate to failure costs (costs that the organization incur because of insecure software) to an increased level of software security assurance: the objective is to justify an investment in software security by monetize the security costs. Some studies show that when the cost of such investment is around an optimal value around 30-40% of the overall failure costs the cost can be justified.

Another method for justifying software security costs consists on using quantitative risk analysis. Quantitative risk analysis allows to estimate the annualized impact of loss such as the one due to a cause of insecure software such as SQL injection. For example it is possible to calculate a rough estimate of ALE (Annual Loss Expectancy) for a SQL Injection attack by calculating the probability of such attack occurring based upon data of the reported incidents. As data loss from FTC (US Federal Trade Commission) show that the probability of a company incurring in a data loss of PII is about 4.5% the probability of a data loss due to web channel and because of SQL injection is about 2.5%. The business impact can be quantified in terms of FTC estimate for each record of a data loss to be about 655 $/per lost record and multiplied by the number of records that can be potentially be lost to estimate the overall asset value that can be lost. This value can be multiplied by the probability of the loss to calculate the liabitility for the company. According to FTC data, in the case of a generic data loss for example (e.g. probability of 4.5%) the liability for a company of each PII record loss is about 35 $/record.

Another security cost analysis method is to evaluate the cost savings to the company by the introduction of the software security initiative by calculating the ROSI (Return Of Security Investment) of software security. I will refer to previous studies (Soo Hoo IBM study) that use ROSI to justify investment for software security activities as well as to use a standard ROSI formula (SonnenBerg) and previously computed ALE (Annualized Loss Expectancy) to determine the ROSI. According to Soo Hoo study it is shown that comparing software security assessments such as threat modeling, source code analysis and pen test, threat modeling provides the highest return of the investment since is done earlier in the SDLC: is you spend $ 100 K in a software security initiative, 21% will be saved if you adopt threat modeling for example.

Finally, I will cover the dashboard metrics can be used in support the business cases to different shareholders in an organization. As the business case is initially made with estimated engineering and security data, it needs to be supported with measurements on the fields. This dashboard metrics need to show management that the software security initiative provides value to the shareholders and that is aligned with other company goals and values such as financial value for the company, value for the company customers, value for the internal business processes and value for learning and growth.

IMI Security Summit in Northern Kentucky: awesome security conference

I presented today at IMI Security Summit on the topic of "Threat Analysis as methodology for deriving risk-based security tests of web application software". The conference gave me the opportunity to evangelize for OWASP and thanks to Dr James Walden that teaches Software Security at Northern Kentucky University. This is the second time that I give the talk at IMI security conference and I really love the organization of this conference and the quality of the speakers, Patrick Gray, Principal Security Strategist of CISCO ex co-ISSer (all great security folks come from ISS since we invented the first IDS, ditto: Gunther Ollmann, David LeBlanc, Chris Klaus founder, Tom Noonan CEO and me S/W lead engineer #? at the lucky IPO). Patrick is an awesome speaker and it is was worth going to the conference just for his talk: he can communicate the right message for wide audience of security folks with sense of humor and law enforcement insights: it is 100% right in my opinion that the main challenge we are facing today as security professionals, besides organized crime, is the increased imporance of the human factor (he refers is as the human firewall) as a way to mitigate social engineering attacks: with 300 million facebook users, the new generation Y proned to twitter-like private data sharing: we are facing a security challenge to scale that we as security industry and practitioners we need to respond with increased education/awareness and by developing better security technology controls .

During luncheon I loved the presentation from Dr Kevin Gallenger on his survey about information security:"State of IT Security 2009". The data shown matches previous surveys I have seen such as from Ponemon Institute, CSI-FBI and Verizon. For example it is shown that less then 60 % of organizations conduct a formal IT audit, hackers and employees are equally problematic (27%). Finally some good data, take as reference recent Ponemon-Imperva institute research that show that 71% of companies do not think compliance is strategic to security even if after experiencing at least one data breach. And also finally suspend the vendor bias belief that most of the attacks come from internal source when is at max 20-30 %. The part that I liked the most of the survey was the difference between "acquisition" of security and "adoption" of security in particular as related to policies/compliance. Most companies acquire security tools enact policies and even processed 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 in implementation mostly driven by compliance. The survey touches the problem of information security at the core: 44% of respondents indicated that they were unwilling to disclose the types of breaches. This is the main problem we face in security today. The lack of data on losses, fraud and incidents affecting business sectors so we can identify needs and opportunities to improve and make business case for security investments. In essence is like a mafia problem for security, "we all know but we do not say and keep within the family business in " cosa nostra" style... Nice we have SB (Senate Bill) 1386 enforced also in several US States to force companies affected by data breaches to public disclose and data loss event of customer's PII: in this cases, thanks to SB 1386, we can still factor business impact of a data breach such as for example: 100 million records of PII stolen at 25 $/piece (estimated at the cost to buy that PII on the black market) equals 2.5 billion $ impact. This is the data we need, to take the metrics to the next level of maturity, we need to correlate data breaches to business impact and fraud and monetize losses so we can make business like informed risk mitigation decisions. The other part of the conference I loved was to talk to Dr. Frank Braun (like Von Braun but his name is Frank..). I had a talk over a nice glass of Merlot wine and
Camembert cheese, nicely sponsored by Apple Inc on the business cases for information security. This is a topic I will be presenting at a security conference in Italy next week so I was very puzzled that Frank research covered already a lot of my research on business cases for software security such as ROSI, cost/benefit analysis and quantitative risk analysis as factors for making business cases.
I loved the conversation with Dr. Frank, later on, we shared some thoughts about business risk analysis, human factors in risk decision making and general bias, unbars decision making. Really loved the conversation at very high level, it was like when minds connect and elaborate for common good. What we elaborated was #1: business security is the most important factor to security #2 we need data that prove the point about business value of security #3 we need to approach security for the business taking into consideration of the context and culture of the "security decision makers". Most of security decision making by senior and executive management now days follows what "Gartner says" or what vendor days or what my competitor does. This is not rational thinking backed by quantitative data, it is something that is either purely qualitative, speculative or at best follow the herd mentality... So we need to get members onboard the new thought process for security management and recruit member of this new School Of Information Security, cost and fraud data driven approach, unbiased from Gartner and security vendor companies and their agendas. If you do would like to know more on what I mean for New School Of IS, I recommend reading Adam Shostack book.

My presentation (refer to our local OWASP chapter web page for further info) on risk based security testing was nicely received. I was glad to have the audience asking me a lot of questions after my talk: that to me means I raised enough interest on the issue: not doing good enough security testing as we should do. Hope people will go download the OWASP Testing guide (according to Software security "Illuminati" Gary McGraw, the best piece of IP from OWASP, even if comes from "communist" Italians...but I am not represented there by party affiliation..)

Cybercrime risk mitigation: a critical view of compliance from threat analysis perspective

I recently had the opportunity to give prezos for OWASP in Los Angeles and Orange County together with the Application Threat Modeling book co-author, Tony Ucedavelez. Both Tony and I believe that application threat modeling can help organizations understand cyber-threats and identify countermeasures to mitigate them proactively. We also think that compliance with security standards is not a guarantee for "immunity" of becoming a target and victim of cybercrime and fraud hence the topic of our presentation, intentionally provocative: "The rise of threat analysis and the fall of compliance in mitigating cyber-crime risks". We take a critical view of compliance especially PCI-DSS and we advocate putting compliance in perspective of business risks mitigation. To support our view, we start looking at how PCI-DSS security standard drives application security with compliance to highlight the fact the two largest data breaches of credit card data ever reported occurred to companies that were compliant with the security standard PCI-DSS. We also analyze these data breaches for the business impact that caused and we compare the cost of non-being compliant with the cost of the business impact caused by the breach: based upon public disclosed data (2007 TJX data breach) we find out that overall the cost of non-compliance is one factor less of magnitude comparing with how much will cost to an organization to cover the overall business impact of the data breach incident (e.g. millions for non compliance comparing with billions for business impact)

We make the case that compliance do not buy security for your organization but a minimum level of information security assurance: in the context of mitigating vulnerabilities with tools to fit a compliance requirement (e.g. vulnerability assessment) for example, based upon the data from MITRE, at their best tools will mitigate 45% of all known vulnerabilities (e.g. 600 included in CWE MITRE in the study). We use this data to advocate that the remaining 55% of ways to exploit known issues can be assessed by adopting a threat analysis and risk mitigation techniques that cover a larger attack space then tools. These threat analysis techniques include (1) gathering cyber-intelligence from attacks from public sources such as law enforcement (e.g. FBI, Secret Service), (2) learning about attacks scenarios and likely targets with attack tree analysis, (3) determine the possible abuses of the applications business logic using use and abuse cases, (4) identify the attack vectors used against web sites so applications defenses can be tested and (5) finally by developing application countermeasures at the application layer with threat modeling/architecture risk analysis. Our mantras are: (1) you can only mitigate for threat you know of. ( 2) Know your enemy so you can build your defenses. Being threat aware means being threat intelligent. To know your enemy means awareness: as organizations defending from cyber-attacks we need to be aware that cyber-criminals already assume your have been compliant with PCI-DSS to mitigate known vulnerabilities to protect credit card data and implemented multi-factor authentication and fraud detection, in compliance with FFIEC guidelines for authentication for example.

We basically need to be aware of the new bigger cybercrime threat and how might affect us. For example, cyber criminals can buy or lease sophisticated automated attack tools called botnets to do fraud. These botnets can direct attacks against banking customers by exploiting browser vulnerabilities as well as against on-line banking sites bypassing strong authentication and data filtering controls. Cyber-crimes include fraud (e.g. wire transfer to money mule accounts) as well as stealing credit card and confidential data for reselling it in the underground economy or to fake credit and debit cards. Understanding how these threats scenarios might affect your organization in terms of threat analysis means: 1) Is possibly my organization a target 2) what is the data asset that most likely an attacker/fraudster will go after 3) the attack vectors) that he will use 4) the potential vulnerabilities that can be exploited and where 5) which are the countermeasures that I can design and deploy at the application layer.

Threat analysis of security controls must be the driver for design of countermeasures: by using threat tree analysis for example it is possible to analyze the effectiveness of security controls such as MFA to mitigate threats such as man in the middle attacks to find out that most of them are ineffective. By identifying the targets of attacks with attack trees we also find that browser vulnerabilities facilitate drive by download, man-in-the-middle and man-in-the-browser attacks and that these vulnerabilities represent the weakest security link. Only after cyber-crime targets are analyzed and visualized with attack trees it is possible to understand the different avenues of attacks methods used by the fraudsters. By associating a cost for achieving each step of the attack tree it is possible to walk through the attack methods that cost the least to an attacker to succeed.

To test defensive controls at the application layer, we need to identify the attacks vectors (both manual and automated) and use them against the authenticated and non authenticated entry points of our application, validate the authorization levels required and walk-through the data flows (from client to back end) to test for potential vulnerabilities. The aim of this data flow threat analysis is to localize and identify countermeasures can be designed and deployed at each layer and component of the architecture (client, server processes and data).

We emphasize that for security compliance to be security effective, needs to enforce actionable threat assessments. We advocate a new risk mitigation strategy that looks at compliance with a positive security approach rather then negative security approach. The positive security approach consists on proving the positive effect of defenses on mitigating threats, the negative security approach consists on proving the gaps in applying standards and security controls. Positive security is driven by threat analysis as a positive factor for building better security controls against new threats, negative security is driven by compliance as a way to prove the negative that is your organization failed in applying standards and policies.

We conclude that even if there is still a value in compliance for security as validation against a minimum level of security requirements, the approach that most organization use toward compliance does not help security and derails the organization effort from focusing on effective threat risk mitigation. To improve security organizations need to re-consider compliance; being compliant will not warrant protection of your core business assets against cyber-crime threats. Compliance is just a piece of the risk mitigation strategy , compliance security assessments can be effective mitigation against cyber-crime threats only when are driven by cyber-crime intelligence and application threat modeling techniques.

An abstract of the presentation is included herein: On August 5 of 2009, Federal prosecutors charged Albert Gonzales with the largest case of credit and debit card data theft ever occurred in the United States: 130 million credit cards numbers by hacking into Heartland Payment Systems, Hannaford Brothers, 7-Eleven and two unnamed national retailers. Both Heartland and Hannaford were security compliant with PCI-DSS standard at the time they were compromised: that let question the validity of regulatory compliance frameworks, and specifically compliance with PCI-DSS standards as an effective method to reduce data breaches, identity theft, and the proliferation of credit card fraud. This presentation will further analyze the cost of the data breaches by monetizing the losses as being reported in quarterly earning reports (e.g. TJX) as well as impact on stock price (e.g. HPY) at the time of public disclosure of these data breaches. Monetizing data breaches helps to frame non-compliance risks as a factor of business impact and dispelling further the myth that being compliant equals being secure.

Traditional compliance-driven security assessments efforts such as penetration testing, static code analysis and standard compliance gap analysis will be compared to threat analysis techniques in order to demonstrate how cybercrime risks can be mitigated by understanding threat scenarios through cyber-intelligence: cases of reported cybercrime attacks will be presented as a way to determine the threat landscape and the attack scenarios. Attacker motives and means to achieve them will be analyzed by using attack tree analysis: attack trees allow to study cyber attacks against web applications, breaches of credit card data as well as ATM fraud. Use and misuse cases will be used to evaluate the strength of security controls such as multi-factor authentication against known cyber-attacks such as MiTM as well as a way to elicit requirements for security controls (e.g. secure logins). Examples of attack vectors for testing applications against code injection attacks as well as for cybercrime attacks (e.g. HTML-IFRAME Injection Attack Vectors and drive by download) will be provided using attack vector analysis. Data Flow Diagrams (DFD) Analysis and Architecture Risk Analysis examples will be presented to provide a viable, consistent methodology to identify the entry points for attack vectors, identify user access levels, enumerate threats as well as to determine threats, attack, vulnerabilities and countermeasures. Security by deployment and security by design principles will be elaborated as strategic countermeasures with reference to three tier architectures and security by design architecture principles. Finally, risk mitigation strategies against cybercrime attacks will be discussed starting by self-awareness questions. The presentation re-affirms that compliance risks need to be approached by organizations as a factor of business risk and advocate threat risk modeling and application threat modeling as a actionable processes for mitigating cybercrime risks to web applications.

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.

OWASP Releases World’s First Security Code Review Guide for Free

The OWASP Foundation, March 30, 2009 – The Open Web Application Security Project (OWASP) today announced the official release of the free OWASP Security Code Review Guide v1.1. The Code Review Guide provides details on how to review code for all sorts of application vulnerabilities. Together with the OWASP Security Developer Guide and OWASP Security Testing Guide, OWASP has created a powerful suite of books that covers most of what people need to know about application security. The 216 page book can be downloaded from the OWASP website or a bound copy can be ordered for the cost of printing.

The Code Review Project is led by long time OWASP participant Eoin Keary from Dublin, Ireland. Like all OWASP projects, the work is performed by Eoin’s team in a free and open manner, and coordinated via the OWASP wiki and project mailing list. Everyone is welcome to download the guide and benefit from OWASP’s research. You can also join the project and contribute to making the guide even better.

“Despite the many claims that code review is too expensive or time consuming, there is no question that it is the fastest and most accurate way to find and diagnose many security problems. There are also dozens of serious security problems that simply can't be found any other way.” said OWASP Chair Jeff Williams. “Still, code review is no panacea. Static tools, dynamic tools, and manual testing all have an important role to play in verifying the security of an application.”

There is overwhelming evidence that the vast majority of web applications contain security holes that are increasingly putting people and organizations at serious risk. Our Code Review Guide is one part of OWASP’s strategy to make application security visible and enable the market to support the development of secure application software.

OWASP is a free and open community that focuses on improving application security. Join the thousands of organizations that are using OWASP guidance to run a responsible application security program. Anyone can join our community and use our free tools and documents, attend our free conferences and local chapter meetings, and join projects to make the world’s software safe for the Internet.

About OWASP -The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas. We can be found at http://www.owasp.org.

Insecure Implementations Of Challenge Question Answers (CQA) For Password Resets

Challenge Questions Answer (CQA)are widely used in web sites as a form to validate the user during un-authenticated transactions such as password resets, user name resets as well as extra authentication factor besides passwords during logins. The problem with CQA is the degree of freedom given to the implementation leaves a lot of room to deliver in-secure validation. Some of you might be familiar for example with the Gov. Sarah Palin's yahoo email hack via yahoo email password reset. It was due because yahoo email reset validate users with questions that can be easily guessed from public profiles such as birthday, country of residence and postal code. This is from implementation. Gov Palin as any user of yahoo email is allowed to select easy questions among a list, such as "Where did you first meet your spouse". This, again is implementation problem, for a public person like she is (but this applies also to users of Facebook and social sites) the answer to that question could be easily guessed (Wasilla high). The other control on yahoo email reset is to validate a secondary email address associated with the account for which hints are given. Apparently this was not set up. The attack that was highly publicized that time simply highlights that even companies like yahoo still do not get how to get email password reset securely implemented.

This example underlines a problem of 1) user awareness on which CQA to choose, 2) Force user to choose CQA that are not easy to guess, for example asking DOB (date of birth) besides being considered Personal Identifiable Information is a bad question where asking a user to choose a date that is memorable may be better. The concept that CQA need to learn also is the one of entropy that is not easily guessable with different means, besides by public profile searches is also by the length of the question that at minimum has to be of a certain number of characters. In this context if my favorite town is New Your City, NYC cannot be entered because three letter city names are not allowed.

In the case of financial web applications, good secret questions are the ones that require specific shared knowledge between the user and the authenticator such as shared knowledge of events (e.g. the last time you make a payment) or specific knowledge of data (e.g. the exact amount of customer's monthly mortgage payment).
To improve entropy of the shared secret, you can prompt the user to answer different shared secrets by randomly choosing them from a previously set of pre-registered answer/questions.

The mortgage question that is not usually deducted from public records (obviously does not include dumpster diving) is better than a question such as most favorite movie or soccer team, or the high school where you dated your husband/wife. But also this is not immune from attacks a typical Monday morning dumpster dive may reveal the others or a simple call to the mark with a refinance question to capture in your example the "monthly" mortgage payment.

The emphasis I am making is that the CQA have to be shared secrets between the authenticator and the authenticatee. An example can be to validate time and information data that is shared secret between the user and the Bank such as when you visited the ATM and how much money you withdrew. Of course these requires query data sources and are not easy to implement.

Ideally web site architects that implement this controls they need to be guided on how to implement CQA securely in the application uses cases of password and userID reset as well as a form of "extra" factor of authentication besides passwords. The concept of what constitutes a good non-guessable CQA should be covered as well as how to implement the password reset security.

A good guideline for implementation of CQA is OWASP Using Secret Questions Page

You can also test if you password reset is done security by looking at the password reset section of the OWASP testing guide.

For example once you had the password rest after CQA validation, a good practice is to deliver the one time temporary password out of band to the user with a different channel such as SMS. This will allow for identification of the user via a call back and also another layer of defense against someone attacking the email channel during the outbound password delivery such as in the case of Man In The Middle Attacks.

In the case when CQA are not pre-registred such as in the case of validation of question based upon demographic information that is known about a user from Knowledge Based Authentication system, ideally you want to consider this only to validate low risk application function since the degree of security of these questions is one notch lower then CAQ based upon shared secrets and two notch lower than passwords. This is to consider also in user validations that fall back to KBA from failing to validate a password at login as security expert Bruce Schneider points out in The Curse of the Secret Question . It would be ok if I am falling back from low risk authentication control such as one that uses IP for authentication to another low risk control such as KBA.

The best use case for using KBA CQA is in the case of a user applying for an on-line account for which no previous information is known about the user. It is better than validate the user with information that is sensitive and can be phished to attack other channels such as for example validating the user with ATM PINs or with PII such as SSN. A KBA with a rich set of CQA such as group of 20-25 questions selected ramndonly is also more difficult to phish than a set of 2,3 CQA (provides better entropy)

Financial Markets Meltdown: Risk Management Lessons

I just finished reading the book "Against The Gods, The Remarkable Story Of Risk, Peter L. Bernstein". This is part of my current study of financial risks and relationship with information security risks. The book is written by an economist, Peter Bernstein and provides, in my opinion very good insight on how risk analysis evolved as discipline to respond to human needs. Along the course of history, risk management has evolved as discipline to help humans in calculating risks for decision making in different aspects of human condition such as nation's and individual wealth, human health, engineering, warfare etc.

As a technical discipline, risk management also evolved as part of the progress made by mathematicians in predicting risk. Most of us now associate the likelihood factor of risk to a calculation of a probability such as the likelihood that the occurrence of significant events might have impact in our human lives. Risk analysis had a shift in the course of human history with the mathematical discovery of probability theory that originated back in 1,600 Century, thanks mostly to the works of mathematical geniuses such as Pascal and Fermat. These mathematicians were the first to devise a mathematical method to forecast the Pacioli’s puzzle game. From a way to predict the outcomes of games and help gamblers, probability theory evolved in the 1700 century to respond business needs such as by helping the English government to predict life expectancies so they could help the finances with the sale of life annuities. This event marked the start of the Insurance Business. Later Bernoulli and Leibniz invented methods of statistical sampling that are used today in scientific methods for asserting quality, health of populations, demographic and political studies etc etc. We had the discovery of the normal distribution that is used for statistical analysis: events could predicted when the number of observations of the sample increased. In 1800 Century we had the chaos theory and the discovery of critical concepts in statistical analysis such as"the regression from the mean" that explains that events are affected by a random variance so that a market can be expected to fall after going up and viceversa. In the 1900 financial risk theories also demonstrated mathematically that putting all eggs in one basket is unacceptable risk strategy for buying stocks.

In modern times, risk models got help from information technology and computerized risk modeling. These risk models are used to predict financial trends and support decision making. Nevertheless these models also fail. Being risk calculation a complex, multi-variable and non-linear problem to solve, the accuracy of these models is always in question. For example,these computerized models clearly failed to predict the house mortgage risks and the impact on the financial markets. In my opinion this is because risk in essence ties fundamentally to the human element and irrational decision making. It also ties to unpredictable events that we did not include in the analysis of the mathematical model. At the root of the meaning of risk we have to dare, as Bernstein points out, the orgin word for risk (sounds like I am paraphrasing the movie, the fat greek wedding :) from the Italian (risicare) that means act, to dare. There is actually a say for it that is a proverb for the one of who that know Italian Language “chi risica non rosica” it means who does not risk do not gain for it…

The point I want to make here is that human factors determine how we react to risk. From this perspective, learning about human history as a factor to make risk decisions is the key for effective risk management

One interesting lesson that can be learn is the "attitude" or the "appetite" for risk was obviously not calculated and lead the financial markets to the current meltdown. During the so called "housing price bubble" era of the last 5-7 years we had people buying houses by borrowing money with mortgages that were at high risk of not being repaid. The home buyers and the financial institutions allowed this party to happen, home owners happy to own houses that according to risk should not have afforded and the financial institutions taking high risks for pure financial gains along with speculators inflating the home values by buying and selling property for their quick profit.

Then things started to change for the worst, rumors spread that some banks were running out of cash and that big institutional investors pulled out from the market. Acting upon "rumors" investors start selling financial stocks. This despite CEOs of such financial institutions are still trying to reassure investors. Rumors eventually become reality, the big investors pull out from the market and all the sudden, financial institutions need to raise capital to keep them afloat. At last resort the government comes to help to contain the impact to the overall economic system.

One lesson that you can learn it that this is a case of systemic risk. Systemic risk are the most dangerous risks because scale up to different entities all interconnected and might end up impacting the all financial system. For example the US financial meltdown started with the failing of financial institutions that depended on each other because they shared the risk: from Bear Sterns to Lehman Brothers, from Merry Lynch to AIG and then to Bank Of America and Citigroup. Most recently, the US Government acted to contain the systemic risk with extraordinary measures and very timely, bailing out financial institutions with enormous amount of money.

From the perspective of information security we might also have similar systemic risks. An example of systemic risk is the impact that a critical information system such as the one that serves as backbone to all infrastructure and operations one day might fail. This can be for example attacks to bring down the internet such as with denial of service attacks to the root domain servers that serve the DNS protocol. Another example of systemic risk is the one posed by botnet driven distributed denial of service attacks toward financial transaction systems as well as the financial infrastructure. Attacks that potentially pose a systemic risk to the information infrastructure of a country or a company need to be taken very seriously and analyzed using attack trees and threat modeling.

Another lesson that you can learn from the financial market meltdown are the gaps in laws and regulations to control risk. Take for example the unregulated Credit Default Swaps used by banks to make million of dollars with a form of insurance based upon spreading the risk. A CDS meant that you could get insurance on a bond that you owned on the assumption that if the bond did not go “belly up”: you just had to pay the insurance installment and you only needed to repay the all amount of the bond if the bond were going down. This is basically an instrument for risk transfer and risk avoidance that also contributed to increase the systemic risk.

The analogy in information security would be that while your operations expand to new data centers as well as in the value of the data assets you manage, you do not step up in the security controls by investing in security technology, processes as well as people. You might also decide to transfer the risk to another entity and have you services managed by them. In some cases a certification from auditors still lacks clear oversight on the security risks you are facing.

Once you face the impacts of systemic risk you need to act with extraordinary measures to contain the risk and still it takes a lot of time to recover to normal.

Another lesson you can learn from human attitude toward risk is that there is always a Cassandra that is someone that prophetically had made his risk assessment as negative against the common thinking being positive. As humans we doubt of "doomers" especially when everybody else is partying..

Unfortunately, one of the greatest lessons from the learning of human perception of risk is that is humans do not usually make decisions based upon previous generation mistakes. For this reason, risk education is fundamental. Risk managers had to learn human sciences and understand human attitude toward risk, the perception of events, which risk indicators are critical and which facts are relevant.

From the perspective of computational models, we should have expected this financial meltdown to happen sooner or later because of a drop of the home prices of 10-20% and other factors could have been built into the model. Besides some indicators of systemic risk such as CDSs could have issued a warning from distribution of risk and business impact perspective:the financial institution inter-dependency and reliance on risk transfer with unregulated transactions should have raised some economist eyebrows.. did risk model factor these elements in their risk model? This questions are still open in my mind.

From the information security perspective, we do not have such sophisticated risk models, rather risk assessment is still mostly done as qualitative assessment by risk analysts that understand the business impact of system vulnerabilities. Nevertheless, the equivalent of a meltdown of the Internet cannot be excluded. Some referred to this threat as the digital Pearl Harbor referring to the Pearl Harbor Japanese attack in WWII. We had recently incidents that seems to indicate that such attacks might be possible in the future. We had for example a distributed denial of service attack to the information infrastructure of an entire country such as Estonia, allegedly caused by the Russian Business Network. We proved that cyber attacks to the SCADA power grid are possible as well as distributed denial of service attacks via botnets directed toward financial institutions. Recent examples include coordinated attacks toward ATMs with cloned cards causing RBS 9 ML $ of fraud in one day. The recent credit card information leak involves credit card account information for 100 million users and involves 500+ institutions(Heartland Data Breach).

These kind of systemic attacks require governments and financial institutions to work together to build defenses for preventing potential large scale information systemic risks. There is a need for threat analysis of cybercrime attacks and a reconsideration of what is system critical and what is acceptable risk. Risk mitigation provisions need to be the topic of research and new information security technologies need to be developed to mitigate these kind of attacks. Information security managers need to learn the lessons that the financial risks meltdown posed to the financial markets, how could have been predicted and find the analogies with information risks so a similar systemic risk to the information infrastructure can be prevented.

Java Security: Why Not To Use String Objects For Storing Secrets

I participated to an OWASP email thread regarding the security of storing passwords in a JAVA string object vs. a char array.

The initial assumption is that since java String objects are handled by the garbage collection differently than other objects such as for example a char array, storing such passwords in string objects might represent a risk.

The threat scenario is potentially of information disclosure since additional instances of secrets stored with JAVA Strings such as for example passwords, even when are zeroed programmately they might allow the original values recovered from a memory dump.

Therefore when choosing between two method calls:
public Connection createConnection(String userName, String password) throw JMSException
or
public Connection createConnection(String userName, char[] password) throws
JMSException

The latter passes the password as a char array and is more secure then the first that uses a string object. I'll articulate why herein:

Let’s analyze the assumption first and point out the main differences when using char[] vs. using Strings. I would like to cover here first some background (for the non-java experts, I do not consider one myself too so bear with me) and terminology

According to the JAVA both specification all data types, char and String included are objects and the instances in memory of such objects are handled by the JVM and the garbage collector outside the control of the coding logic (different from C/C++ where memory instances can be handled by the programmers)

There are differences thought, in what a programmer can do with JAVA Strings. For example the value of a JAVA String object cannot be changed after has been initialized. If you would like to change a value to a string you need to use StringBuffer. This property of JAVA Strings is loosely defined as Strings being "immutable"

I say, loosely defined because refers to value hold by the object not the instance in memory. I stumbled on this definition myself (thanks Rogan Dawes to fail my assumption and shed the light). I assumed this relates to change the value in memory (that in JAVA is never the case). Indeed there are different flavors of immutability best described by the article herein:

So let's assume immutability in the "strong" sense, that means locking down a piece of data in perpetuity, such as creating an immutable object instance that cannot be changed by any code.

A char array, comparing with a String is mutable because the value assigned to the element can be changed.

For example, in the case of a char array,

char[] str = {‘a’,’b’,’c’};

the following will change the values to 0

for ( int i=0; i< str.length; i++) {
str[i] = 0;
}

In the case of a JAVA String since is immutable, the value cannot be changed. For example, when a new instance is created when changing from uppercase to lower case the contents of the object:

String str = “ABC”;
str.toLowerCase();

Another example, illustrates the difference when assigning a new value:

String str = “Hello”;
str=”Goodbye”;

The first creates an instance of "Hello" when the second one creates another instance (invoking the constructor of the class) and therefore assigning an object reference to be stored in str. The same will happen when concatenating strings with the + operators such as:

String str=”Hello”;
str = str + “Dolly”;

There is also an additional consideration….(thanks to Rogan Dawes again..)

When using String objects get internalized (saved in an internal cache), which means
that even when you set the variable to null, the actual String object
may never be garbage collected.

Now back to the CreateConnection API examples, passing a password as char array to the API is better because, values of the passwords can be zeroed after used (same for keys and other shared secrets or confidential information) and no extra instances of passwords are left in memory to be garbage collected or cached.

This is also what JAVA recommends such as when using password based encryption:
http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide.html#PBEEx

Therefore, if you need to store passwords, a good reference on how to do it securely using char array instead of Strings it is shown herein;

On the issue about clearing password contents and using char[] instead of strings there is also a thread from Sun Inc herein

Indeed, the use of char[] instead of String is a good idea for security to prevent information disclosure of passwords via memory data access such as in the case of an attack toward information stored in memory such as memory dump caused by a denial of service attack. When handling encryption keys, the requirement to zeroes them is also driven by key management compliance such as FIPS140.

Now, I am still puzzled about this because immutability of Strings was devised by Sun as part of the JAVA security model. In 2001 J Gosling the inventor of JAVA had to say this: (ref http://www.artima.com/intv/gosling313.html)

“One of the things that forced Strings to be immutable was security. You have a file open method. You pass a String to it. And then it's doing all kind of authentication checks before it gets around to doing the OS call. If you manage to do something that effectively mutated the String, after the security check and before the OS call, then boom, you're in. But Strings are immutable, so that kind of attack doesn't work. That precise example is what really demanded that Strings be immutable.”

But there are problems and assumptions. Even in this case the immutability of Strings does not offer security value 100%. See another thread herein
It is actually shown that char[] can be used as a way to write the contents of a String when untrusted code is allowed via the JVM. This is possible by using reflection and by depending on the results of SecurityManager. Because of this, someone also even argued that because of this Strings are not really immutable

Indeed in the summary, please do not use JAVA Strings and use char array instead when storing confidential data, credentials (e.g passwords) and secrets such as encryption keys…

OWASP Security Testing Guide Vs 3 Officially Released!

The OWASP testing guide version 3 has been officially released.
This project is part of the OWASP 2008 Summer of Code that started on April 2008. The guide resulted in a 349 page book and is the contribution of a team of 21 authors, 4 reviewers and 6 months of hard and great team work.

You Can Download the Guide Now Here:
http://www.owasp.org/index.php/OWASP_Testing_Project
http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf

I contributed to the guide vs 2 by writing section 5.1: How To Value Real Risk authored the introduction part of the version 3, security requirement test derivation (pages 24-39).

I welcome any comments that can help improving the guide by asking you to join the mailing list herein:
http://lists.owasp.org/mailman/listinfo/owasp-testing

If you are interested, presentations can be arranged too by inqurying OWASP.
Some presentation material is also available herein:
http://www.owasp.org/images/2/2c/OWASP_EU_Summit_2008_OWASP_Testing_Guide_v3.ppt

Security of open source, proprietary software and interoperability

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

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 serviceson 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.

7 Information Security Lessons You Can Learn By Watching The Movie JAWS

If your are a security practitioner involved in risk analysis and incident response processes I strongly recommend watching the movie Jaws since this movie has all the elements to learn how human and business factors play in information security risk management and incident response decision making. One thing you soon realize is that risk awareness never comes first. We are humans and as humans we respond to risk in stages such as: (1) denial, (2) awareness, (3) responsibility, (4) action. Risk denial probably comes from the fact that till we (as people or as business) are not impacted directly, we most likely minimize risks. Awareness is probably driven by the fact that we had experienced a loss before and raised our level of attention to new and incoming risks. Responsibility comes as response to feelings (fear) or duty (role). As human we might feel responsible to react to protect our assets such as people, business, family that depend on us for example. The call for action is either triggered by need to prevent further sure loss and damage or because someone else told us so. If you watch the movie from the perspective of risk management you can see clearly all these elements. I dared to extrapolate some information security lessons that I think we can be learn from this movie:
Lesson #1: The first approach toward risk is to either ignore it or minimize it. For example, the movie is about the risk of being killed by a shark attack. So the opening scene of the movie is that there is a shark out there in the ocean and has already made a victim (a girl student during a skin-dipping swim after a college party). The police finds the remains of the body and needs to file a report. The human remains are a clear indication of a shark attack but the policeman filing the report on the incident is advised to not report about the shark as the cause of the incident for not scaring off coming tourists to the town beaches. How this lesson applies to IS risk? A company had a security incident and corporate customer data was compromised as a result. The attack indicates that an attacker got customer data by breaking into the database through the company web site. The business decides to file a defect report that the web site application has some functional defects that need to be fixed. Lesson #2: When security vulnerabilities are found and fixed you also gain a false sense of security.The shark attacks again and makes another victim. The incident cannot be ignored since it happens in complete daylight with a lot of witnesses. In the mean time a shark is being caught by the town fishermen. Such shark is shown to the public as proof that the shark responsible for the attacks has been caught and beaches are no-longer at risk of such shark attacks. How this applies to IS risk? The company did not fix the web application vulnerability that is the cause of the exploit so they had another attack. Since now the information about the vulnerability is public, the company needs to do something. The company releases information to the public that the publicly disclosed vulnerability has been fixed and customers can use the site securely for business as usual.
Lesson #3: When internal security solutions do not mitigate the risks, you most likely ask for help from outside such as by a security matter expert/consulting company. The policeman of the city where the shark attack takes place asks a researcher of the US Oceanic Institute for help. The researcher comes to town and starts his investigation about the shark attack. He soon realizes that this is a case of a giant shark attack. The shark that was believed to be the one doing the killing and shown to public is identified not to be the one that made such killings. This is based upon the fact that there were different teeth marks between the jaw of the shark and the scares in the victims body. The researcher explains the results of his analysis to the policemen and recommends an action for fishing the killer tiger shark. After meeting with the policemen and the major it still decided not to. How applies to IS risk? The company declares that knows what the security holes are, a security consulting company is asked to identify the web application vulnerabilities and run some security tests. Security researchers look at the web application scan reports and results of the security tests and conclude that even if some of the identified vulnerabilities can be exploited for the attacks, other potential security flaws can be exploitable too. Fixing these security flaws might actually require to re-engineer the application. The business is still undecided whether to pursuit this recommendations since require very expensive changes.
Lesson #4: When the security problem gets bigger and noticed by senior management it cannot be ignored and it is decided to act The shark attacks again and this time even more deadly, the people are now scared and demand prompt action to the major of the city and the policeman to kill the shark. After the major of the city and the policemen hear complains at a public hearing, they decide to finance a mission to kill the shark. How applies to IS risk? Fraudsters break again to the site and this time the losses get noticed by seniot management. The company now decides to put resources and spend money to identify the root cause of these attacks and ask engineering to provide proved risk mitigation solutions.
Lesson #5: The first approach to deal with information security attacks from the defensive perspective is to detect the intrusions and pinpoint the threat sources. The policemen, the shark hunter and the researcher use different techniques to locate the shark such as by hooking it with floating devices. For a moment the shark is located and traced and is within reach for being killed. How applies to IS risk? The company installs intrusion detection systems and intrusion prevention systems. Once an alert from the IDS is triggered, it is decided to block the IP address of the source.
Lesson #6: If your deal only with the symptoms instead of the root causes the risk is not mitigated.The shark outsmarts the fisherman, the oceanographer and the policeman by breaking the hooks where the floating devices where attached and attacking the boat unnoticed. The shark attacks the boat directly causing it to sink. How applies to IS risk? The fraudster bypasses the IDS with signature evasion techniques and continues the attack undetected, a device that pinpoints the IP address for blocking it does not stop the attack since the attacker uses fast-flux botnet techniques where the source IP is dynamically changed in real time.
Lesson #7: By tackling the attack root causes finally the risk is mitigated During the wrestling with the shark, the policemen is able to throw a gas tank on the shark jaw and by shooting it with a rifle finally causes the tank to explode and kills the shark. How applies to IS risk? Finally is is decided to go after the root causes of the attack identified with an attack tree analysis where all probable attack patterns are simulated. By threat modeling the application, the attack surface of the application is identified as well as the entry points. The entry point that is most likely used by fraudster is blocked access and the possible transactions that can be performed through this entry point are disabled. Web application logging and tracing are enabled to detect and trace and correlate possible threat events. These web application changes finally prevents the attack to occur. The logs collected during the attacks are provided to law enforcement. These logs provide enough information to catch the fraudster.

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.

Threat Modeling Article

I co-authored with Tony Ucedavelez (Managing Director for Versprite) an article on threat modeling. It is published on the June edition of In-secure magazine.
The intent was to give an holistic view on threat modeling as security activity that can be performed by security practioners in different role and speciality. Threat modeling (TM) is not limited to just modeling threats in applications and the usage is not limited to architects that need to design secure applications. The result of the TM activity can be used by security testers to perform risk based tests as well by information security officers for technical risk analysis. This is because beside modeling threats with the logical, physical and use/misuse case views of the application, TM allows for the identification of vulnerabilities (security flaws) and the countermeasures to mitigate the risk posed by such vulnerabilities. The article also tries to strike the balance from the strategic view of threat modeling with a more tactical one such as way to perform a security assessment on existing applications. We covered the most popular TM methodologies and TM tools available today. We also tried to give best practices on how to use TM as part of the SDLC to build security into the applications independently from the TM methodology being adopted.