Application Security Guide for CISOs

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

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.

7 Security tips for secure coding your HTML 5 applications

Since the release of HTML 5 standard is expected in 2011, it is important to prepare for the potential impacts on security due the adoption of HTML 5. Currently, we can review the working draft from W3C and start looking at this standard from the secure coding perspective and specifically on how to write secure HTML 5 software. Since this blog is dedicated to software security, I thought I should try to put out a list of top security concerns that need to be addressed when coding applications in HTML 5. Herein included is my top 7 list of software security best practices that need to be addressed when coding HTML 5 applications:

1) Be careful when using cross domain messaging features

HTML 5 APIs allow to process messages from an origin that is different from the one of the application processing the message. You should check the origin of the domain of the message to validate that can be trusted such as by whitelisting the domain (accept only request from trusted domains and rejects the others). Specifically, when using HTML 5.0 APIs such as PostMessage(), check the dom-MessageEvent-origin attribute before accepting the request.

2) Always validate input and filter malicious input before using HTML 5.0 APIs.

You should validate data input before you process any messages of HTML 5.0  APIs such as the PostMessage() API. Input validation should be done at a minimum, on the server side since client side validation can be potentially bypassed with a web proxy. . If you are using client side SQL such as WebSQL (like Google gears for example) you should filter data for any SQL injection attack vectors and use prepared SQL statements. 

3) Make sure that the use of any offline-local storage is secure

Whenever possible, do not store any confidential or sensitive data in the offline-local storage, if you do, make sure you encrypt the data. If you do encrypt the data in the offline-local storage, do not store any encryption keys on the client rather, use the server to encrypt this data on demand. Make sure the encryption key is tied to the user's session and to the device that is storing it. Beware that HTML 5 offline applications are vulnerable to cache and cache poisoning hence validate the data before putting anything in offline/local storage. If should also consider to restrict the use of offline/local storage as requirement of your HTML 5.0 security coding standards is possible. Consider that right now (Jan 2011), offline-local storage is not supported by IE browsers, only by Google Chrome, Safari, Firefox and the beta of the Opera browsers.

4) Secure code review HTML 5 code and the coding of HTML 5 tags, attributes and CSS.

You should update your secure code analysis rules to include security checks for special HTML coding attributes and HTML 5.0 tags. Some of HTML 5 tags attributes for example can be potentially be injected JavaScript (JS). You should made a requirement to source code review these new HTML 5 tags for security to make sure any JS input is validated. A new version of HTML 5 CSS also might allow an attacker to control display elements via JS injection. HTML 5 source code with tags, attributes and HTML 5 CSS files should be considered in scope for source code reviews before deployment.

5) Consider to restrict or ban the use of HTLM 5.0 websocket API.

HTML 5.0 websocket API provide a network communication stack to the browser that can be used for backdoors. You should check with your security team whether the use of web sockets is allowed by your organization information security policies and application security standards.

6) Make sure your company legal approve any use of geolocation API.

Consider the impact of privacy when using geolocation APIs to make sure the use is allowed and compliant by your company legal-privacy laws/regulations. The use of geolocation might have privacy impacts, hence should be reviewed to be in compliance with privacy policies that might include notify the user when these APIs are deployed as part of your application.

7) Leverage the security of sandboxing iFrame attributes

One of the HTML 5  features is the sandboxing attribute for iFrame that enables a set of extra restrictions on any content hosted by the iFrame. When this is attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled and links are prevented from targeting other browsing contexts and plug-ins are disabled. Ian Hickson, the editor of the HTML 5 has a post on what the sandbox is good for. You should consider updating your organization's secure coding standards to cover how to code securely applications that leverage the HTML 5.0 sandbox attribute for IFrames.

Tribute to Software Security Guru Roman Hustad

Roman Hustad, OWASP chapter leader in Sacramento, CA, died suddenly on November 4th at the age of 39, the result a fatal heart rythm caused by an enlargement of his heart, the cause of which is still unknown. He collapsed after arriving in the Las Vegas airport that evening.  Roman suffered virtually no pain and was surrounded by others. 

Roman is survived by his wife of 6+ years, Tanya (Burgdorf) Hustad, and his sons Lucas (4 yrs old) and Wyatt (2 yrs old), his sister Holly (Fail) Hoeksema, and brother, Andrew James. The whole family is being supported and cared for by loving family and friends in Davis, CA at the moment.

This is also a big loss for OWASP and the appsec security community. I've known Roman as a former colleague at Foundstone and I worked with him at a four month software security gig for a financial client in Orange County, CA in 2006.

Roman was a person of high professional standards, strong integrity generosity and ethical values. Professionally, he was a top notch principal software security consultant and one of the best if not the best JAVA security trainer that I ever known. After I left Foundstone in 2007, I regret that I did not kept in touch with him. I will always remember him as one of the best software security consultants I had the pleasure to work with.

As a tribute to Roman published work I have provided some references herein.

Hacme Books vs 2.0 Strategic Secure Software Training Application http://www.foundstone.com/us/resources/whitepapers/hacmebooks_userguide2.pdf

Papers on SoftwareMag.com, such as:

 "Implementing a Software Security Training Program" http://www.softwaremag.com/L.cfm?doc=1174-10/2008

"Holistic Approach for Secure Software" http://www.softwaremag.com/L.cfm?doc=1155-8/2008

Roman also published a paper for ISSA Journal, on "How virtualization affects PCI-DSS, A review of Top 5 Issues": https://dev.issa.org/Library/Journals/2010/January/Hau-How%20Virtualization%20Affects%20PCI%20DSS.pdf

Recent Acquisitions In The Security Industry And What It Means For Software Security Professionals



The recent news of the acquisitions of McAfee by Intel and of Fortify by HP can be interpreted as a future trend for the security industry: build security into hardware and engineering processes instead of bolting security on products. Intel's acquisition of McAfee for example, can be interpreted as move by Intel to integrate application security with hardware (e.g. microchips) that Intel currently develops. Similarly, the acquisition of Fortify Software by HP can be interpreted as a move by HP to integrate software security within HP suite of tools for software testing. Moreover, the news of McAfee acquisition by Intel, can also be interpreted as that the age of companies as pure providers of Antivirus tools has come to an end. This was also predicted by John Kula in his book, Hacking Wall St attacks and countermeasures: ”By the end of 2010, conventional pattern matching anti-virus systems will be completely dead. Their effectiveness will have fallen below 50%."

To understand how signature Anti-Virus (AV) detection and eradication tools have come to age, we need to look at the evolution of security threats in the last two decades and how this affected the effectiveness of AV tools in mitigating the current threats such as cybercrime threats. This is mostly due to the fact that the security threats that consumers and businesses have to protect from today are very different from the ones that they had to protect from ten years ago. In the 90’s the main targets for viruses were users' PC, typical attack vectors included opening unknown email attachments to infect their PCs and spread to the company servers. In 2001 we witnessed the appearance of the first malicious rootkit for the Windows NT: such rootkit had the capability to sneak under the radar of the anti-virus software and evade detection. In 2003 denial of service attacks took advantage of the spreading of worms for infrastructure wide exploitation of buffer overflows such as the SQL slammer worm that caused denial of service to several ATMs at banks such as Bank of America and Washington Mutual. As new signatures were developed to detect and eradicate viruses and worms, the effectiveness of Anti-Virus tools stood on the capacity to identify viruses and worms by the unique signature of the attacks as well as in the capability to eradicate viruses and worms after the infection by patching the infected system. But in 2005, we witnessed email phishing attacks to spread Trojans programs embedded in apparent harmless files eluding anti-virus software and firewalls with the purpose of data exfiltration such as to steal passwords and sensitive data. In 2007, we had the evidence of botnet controlled trojans used as crimeware tool to rob online bank customers, spreading either through targeted phishing attacks or through drive by download infections. More recently, in 2009, Trusteer a security company providing anti-malware solutions published an advisory entitled “Measuring the in-the-wild effectiveness of Antivirus against Zeus” according to which the most popular banker malware Zeus, is successfully bypassing up-to-date antivirus software : "The effectiveness of an up to date anti virus against Zeus is thus not 100%, not 90%, not even 50% - it’s just 23% “.

It is therefore clear in my opinion, that the defenses for malware infection, being this with either viruses, trojans or worms have to be expanded to include other layers of the technology stack that are now the target for rootkits and malware attacks. These expanded layers might include for example, besides the O.S and the application also hardware, kernel and firmware that are currently below the radar of AV detection tools.

Expanding security protection to the hardware layer is beneficial not only as detection control such as for malware intrusion detection but also as security risk preventive controls such as data protection. In the case of cybercrime, malware rootkits such as ZeuS for example that seek to compromise the communication channel between the PC and the banking sites, the malware attacks the client to either hook into the kernel to do Man In The Middle (MiTM) attacks or into the browser APIs to do Man in The Browser (MiTB) attacks. In both cases of these attacks, there is a lot of security to gain at the application layer by protecting the data at the hardware layer. One way to defeat MiTM attacks for example is to secure the communication channel through 2-way mutual authentication and PKI using client identities that are protected by the so called "ID vaults" embedded in hardware chips and secured at firmware layer. Examples of this "ID vaults"are the Broadcom USH Unified Security Hub, that is included in several PCs today and is leveraged by data protection tools such as Verdasys's Digital Guardian data protection solution. You might also consider the benefit of developing application with hardware defenses such as by enforcing firmware controls by digital signing your application at the firmware layer. For the ones of you that attended the talk from Barnaby Jack about jackpotting ATMs at BlackHat this year, signing the application at the firmware layer was one of the mitigations being recommended against rootkit infections.

The other big opportunity for security companies is the integration of security of software with hardware such as in the case of applications for mobile phones. As software is built for the specific mobile O.S. (e.g. Android or iPhone O.S.) can also be build out of the box by leveraging security controls deep in the technology stack that include kernel API, firmware and hardware. In the case of being capable to detect attack vectors, having intrusion detection events that can be triggered at the different layers of the technology stack can leverage defenses at the application layer such as blocking the application to run or transferring data to the server. These are just few examples of security synergies accross layers of the technology stack.

In summary, I think Intel acquisition of McAfee could give Intel the opportunity to design hardware chips that tightly integrate security detection and prevention controls with firmware and software and provide additional layers of security to applications.

The other industry M&A news was the acquisition of Fortify’s software security company by HP: this follows a trend of big software companies such as IBM and HP to acquire security tools companies such as Watchfire and Fortify. Previously, HP grew their security assessment suite of tools through the acquisition of SpyDynamics WebInspect to integrate it in HP's software quality assurance suite of tools, QA inspect. Since IBM previously acquired application scanning tool WatchFire’s Appscan and static analysis tool provider Ounce Labs, Fortify’s static analysis tool acquisition by HP fits the scenario of HP competing head to head with IBM in the software security space. For sake of competition, the acquisition of Fortify by HP make a lot of sense, but the HP acquisition of Fortify also fits the trend in the industry of run software security either as a service or as an assessment integrated as part of the Software Development Life Cycle (SDLC) process.

For example, application and source code vulnerability scanning assessments, referred as dynamic and static testing can be performed a Software Security as a Service (SSaaS) for software development stakeholders such as application architects, developers and testers. These services can also include automation security tools that can be rolled out as part of the overall software development and testing suite of tools such as Integrated Development Environments (IDE) and Q/A testing tools. Obviously, security tool integration with IDE and Q/A testing tools is just one part of the software security equation, as besides tools you also need to roll out secure coding training and secure coding standards. The holistic need of software security that includes people process and technology, is often misunderstood by who has to manage software security initiatives for organizations as software security tools or services alone are mis-interpreted as sufficient to produce secure software.

To produce secure software with a level of software security assurance that is both risk mitigation and cost effective, organizations need to roll out, besides static and dynamic analysis tools and services also software security training for developers and software security engineering processes/methodologies such as SAMM, BSIMM, MS-SDL-Agile, Securosis SSDL, OWASP CLASP.

Obviously, the increased adoption of static and dynamic analysis tools by the enterprise follows the application and software security tool adoption trend. If you refer from a survey from errata security –Integrating Security Info the SDLC http://www.erratasec.com/ErrataSurveyResults.pdf, it is shown for example that static analysis is the most popular activity (57%) followed by manual secure code reviews (51%), manual testing (47%). The trend of adoption of application and software security tools usually follows the enterprise awareness of the application security problem as a software security problem.  At the beginning of the rolling out an application security initiative, companies start from the far right of the SDLC by rolling out application scanning tools and ethical hacking web assessments and then move toward the left of the SDLC with source code analysis. Eventually the awareness of the software security problem moves to the design stage by trying to identify security design flaws earlier in the SDLC with the Application Threat Modeling (ATM). Right now, according to the errata security survey, only 37% of organizations have adopted ATM as part of the SDLC. I believe the trend will lead to that direction of adopting ATM because of the efficiencies and the larger security coverage that ATM will provide. Probably this low ATM adoption can be explained by not enough security awareness yet onto the benefits of ATM as well as the maturity levels reached to seek adoption of ATM within the SLDC.

Software security training for developers is also a trend, 86% of the participants of the survey sent one or more members of the software development team to security training. But again according to the Errata security survey, software security is not yet part of the top list of information security management concerns as only about 1/6 of participants (16%) sends his project managers and InfoSec and AppSec directors to software security process management training.

As the static and dynamic security testing adoption grows in the industry there will be also a need of software security services such as software security training and the development of engineering processes and standards. This trend follows the integration of the organization SDLCs as well as InfoSec/AppSec and Risk management processes with formal software assurance methodologies and activities such as vulnerability assessments, secure coding reviews and secure design review/ application threat modeling.

These trends in the M&A of software security industry will also create new career opportunities. In the case of information security managers for example, there will be a need to hire managers with the right experience and skills in managing software security processes for organizations. In the case of software engineers and security consultants, it will create a need of software engineers and consultants abreast of software security formal methods, static and dynamic analysis tools as well as security assessments such as secure code reviews and application architecture risk analysis and design or application threat modeling. In the case of electrical, software or computer system engineers, the knowledge of hardware and software security could also be leveraged to become an expert in hardware-software security integration such as in the case of the design of hardware embedded application security products/solutions.

In conclusion, as software security practitioner, in your current professional role of information security manager, software security architect, software security consultant, software security trainer/instructor you might look at these industry trends to set your career goals and cultivate the necessary skills and experience that could lead you in new career opportunities being created as results of these security industry trends.

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

How a process model can help bring security into software development

Very good article about SSDLC (Security Enhanced Software Development LifeCycle). It should be mandatory reading for promoters of SSDLC initiatives within organizations. This article (third in the series on the secure software lifecycle) captures some of my previous work around the concept of the (SSF) Software Security Framework. The SSF was conceived as framework to integrate security within the (SDLC) Software Development Lifecycle as well as with existing information security and risk management processes. The idea of the SSF originated in 2005 while working with clients of Foundstone (the security consulting company that was acquired by McAfee in 2004) mostly financial institutions and telcos and presented at Blackhat USA Conference in 2006.


Software Security Framework

In general, I have to give credit to the idea of the SSF to the CISOs that I worked for back then as consultant like Mr. Denis Verdon. I also have to thank Mr. Joe Jarzombeck PMP Director Of Software Assurance at the National Cyber Security Division at the Department Of Homeland Security (DHS) for capturing my contributions in the first SSDLC DHS document as well as the SMEs such as Mrs. Karen Mercedes Goertzel at the IATAC (Information Assurance Technology Analysis Center) to document the SSF in the 2007 State of The Art Report of Software Assurance. More recently the idea of SSF evolved thanks to the work of Dr Gary McGraw CTO of Cigital in the context of software security maturity models as framework of software assurance best practices within software maturity model domains

Perceived Security vs. Real Security

M.C. Escher (1898 - 1972), Bond Of Union, 1956.

Risk mitigation is about making an assessment more or less objectively of possible circumstances and events that might determine an impact. The perception of risk is an important factor to determine how humans make decisions on how mitigate risks. Human perception of risk is biased by facts and assumptions that might prevent objective and factual judgment of risk mitigation. Some of these perception factors are not risk factors are driven by human emotion and experience.

One important factor is fear, consider for example these data as fear relates to perception of risk:...the fear of earthquakes has been reported to be more common than the fear of slipping on the bathroom floor although the latter kills many more people than the former...the fear of a flying is still widespread despite the chances of being involved in an aircraft accident are about 1 in 11 million while your chances of being killed in an automobile accident are 1 in 5000. Bruce Schneier has actually posted on his blog some other interesting examples of human perception of risk. How perception matters for security risk professionals ? Well, assume you would like to drive security decisions, then understanding of human reaction to risk is critical factor to consider in risk mitigation decision making.

Understanding cognitive science basics is very important. Consider for example security awareness. Studies show that awareness shift the perception of risk. In general you are aware of a risk that is close to you or of an event that you experienced before, this would drive risk mitigation decision and investment on security. Statistics from OWASP for example shows that organizations that have experienced a public data breach spend more on security in the development process that those that have not.

Basically a breach or an occurred event drive risk awareness and is an important factor in risk mitigation decision and security spending, the relationship of bad events to risk perception is also confirmed by cognitive science,... events that have been experienced before are easily brought to mind are imagined and judged to be more likely than events that could not easily imagined and never occurred.

Another important aspect of risk is what is referred as the appetite of risk or being risk adverse because of a potential gain. In general humans are risk adverse with respect to gains such as preferring a sure thing over gamble with a potential loss and taking a risk in the event the loss is small comparing with the potential gain. Consider for example risk perception biased by human greed. Sometimes risk decision are blind of potential losses because of lack of due diligence on what losses can be. This is what someone refer as taking the risk as being the chicken or being the hawk. Another way to think about risk vs. gain is to rationalize what is the residual risk left if an event would occur where the probability of the event can be estimated based upon real incident/events data. In essence is the what I could loose factor for the business gain of taking the risk. This require being able to visualize and articulate the risk event and simulate the losses that would occur if the event would materialize. In my day to day job for example I would use the threat scenarios and simulate the event of a loss to make the point to the business of the potential loss due to the exploit of a vulnerability.

Threat and risk modeling can be a useful way to visualize an attack, which threats an attack might materialize, the vulnerabilities that can be exploited and how these vulnerabilities can cause an impact. Nevertheless, even if the threat scenario is visualized, the decision of whether to deploy a countermeasure or not is a risk judgment decision that is biased by business factors such as usability, customer impact and even with visualized threat scenario showing the risk potential, perception could still be such as that risk would be acceptable. If the threat scenario applies directly to a real event or incident that occurred before most likely the associated risk won't be accepted as well as if the threat scenario applies to a compliance risk event that could be found by the incoming audit.

In essence, for certain organizations, previous incidents and audit findings can drive security decisions more then threat assessments such as using risk analysis and threat modeling.

Another important factor of perception of risk is whether the risk impacts an organization or an individual responsibility directly or indirectly independently from the fact that the event occurred or not. If the impact is direct such as in the case of assuming the liability for the loss of a bad event occurring risk awareness will be higher then if is indirect and happen to a third party would be considered a non-liability.

In essence to make the cased for risk you need to consider how risk can be differently perceived by the business factoring fear as related to loss and rationalize residual risk as related to business gains. If the organization is fear driven in risk decision making including data from previous incidents and fraud that the companies experienced before can help to drive security awareness as factor of risk mitigation. If the organization is audit driven use the audit findings and non-compliance liabilities and made the case for mitigation.

Ultimately the adoption of security initiatives and security spending can be driven with informed risk decisions using threat models and risk factors such as likelihood and impact but also by factoring perceived security and risk vs. actual/real security and risk.

OWASP Italy Day 4 Software Security Initiatives Conference Presentation Videos

OWASP Italy has published the videos of the conference on Software Initiatives held in Milan and Rome, Italy last November

The videos for the Milan conference can be reached at the following OWASP Day 4 Italy Page

From the OWASP page you can also download my two video webcasts (Italian language over English slides) of the related conference presentations (1) Guidance for starting software security initiatives within your organization and (2) business cases for software security initiatives

OWASP Italy

An hearth felt thank-you to the OWASP Italy organization and for putting this together, expecially to Matteo Meucci OWASP Italy Chair and Giorgio Fedon, Chief Operation Officer Minded Security.

If there is interest in having these webcasts also in English please contact me directly, thanks

Looking past the cyber threats of the last decade and the new to come



Top Cyber Security Risks

 As we pass the first decennial after 2000 we can look back at how IS threats have evolved in the last ten years such as for the complexity of the attacks and the evolution of the attacker's motives.
This is well described by Robert Vamosi on his article on PC world "Top 10 Security Nightmares of the Decade The new threats that will be facing in 2010, according to predictions from a report from McAfee Avert labs will be exploiting of application layer vulnerabilities such as Web 2.0, social networking sites, drive by download, browser vulnerabilities man in the browser,  adobe flash vulnerabilities, mobile phone vulnerabilities, and malware attacks through botnets and banking trojans (e.g. Zeus).

For security practitioners that still think old security school, network security such as secure the perimeter by deploying firewall and IDS (that I pioneered developing at ISS) mitigate threats to the PC/desktop using AV, AS this is the main lesson from the trenches: as threat evolve and rather quickly with increased sophistication, we need new defenses expecially at the application layer to mitigate these new threats. The new defenses need to look at the security of the applications and the data expecially of the transactions and the data flows (end to end from user to application) above all.

There is also a need to look at security control from risk mitigation perspective, keep measures that work (that is risk mitigation to acceptable residual risk) and discard the ones that do not work. One example of a very destructive change in the security industry would be for example to retire all MFA (Multi Factor Authentication) that were adopted in 2006 (mostly to earn a checkmark from FFIEC) and that now just add to the TCO (Tocal Cost of Ownership) since can be easily defeated by malware.

As Einstein said," let's not pretend that things will change if we keep doing the same things". In essence, we are moving to a past information age society where cybercrime threats mitigation need to be the main focus of information security. I believe that we as security practitioners we are about to reach a tipping point: organizations and governments will pay a huge price for fraud and data losses without deploying radically new countermeasures.

My wish for the 2010 is that business organizations and government will put more focus on application security and root causes of vulnerabilities such as insecure software and design. I hope we could put the effort on building new countermeasures at the application layer and use new approaches such as identification of design flaws that account for more than 50% of vulnerabilities such as by using threat modeling (that will be the book I will publish in 2010). My hope is that we recognize that we as security practitioners we are on a time race to win against cybercriminals, we need to work with businesses to roll out new security control and measures. We need to quickly adapt to the new threats and prepare to respond to the cyber threats of the next decade...

Business Cases For Software Security Initiatives, Maturity Models and Security Costs 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)security conference on the topic of software security initiatives. In my presentation , I am going to 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 management (the sponsors of the initiative), it is important to make the appropriate business cases and use the so called "drivers" for software security adoption such as 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

BSIMM SSF

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 mapped to levels 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 not software security in particular but 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 it is possible to map software security from the 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 starting from 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.

One fundamental element of any maturity model is the definition of the software security roadmap that provides the set of standard activities that bring an organization to a certain capability level in software security 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.

An organizaiton can reach 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.

At level CMM 4 (managed) organizations are capable to 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.



Software Assurance Maturity Curve And CMM Levels

At level CMM 5 (optimized), organizations have optimized 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, according to the maturity curve, 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 the cost that is required.

This costly step 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.

One of the factors most critical to the success of software security initiatives are the 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.

The essential software security metrics for a successfull software security include process and vulnerability management metrics, vulnerability root cause analysis, governance 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 such as how to justify the security budget 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 the 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 determining the benefits of security initiatives so can be justified using cost vs. benefit 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.

Optimized Software Security Costs

Some studies that use cost vs benefit analysis show that when the cost of a security investment is around an optimal value of 30-40% of the overall failure costs, the security cost can be justified.
This can be desumed by optimizing the overall costs when factoring the cost of security failures and the cost of security measures.

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.