Writing Secure Software

PASTA Process for Attack Simulation and threat analysis (PASTA) Risk-centric Threat Modeling

2012-09-15T13:54:00.001-04:00

Castle under siege
(Source Wikipedia)

Information security is about protecting digital assets from threats, software security is about designing and implementing software that is not vulnerable to threat agents seeking to exploit design flaws and bugs to compromise digital assets. Traditionally software security has been driven by the need to identify vulnerabilities with specific tests such as static source code analysis and fix them prior to release software products in production. Today this traditional defensive approach toward software security security cannot cope with increasing level of sophistication and impact of cyber-threats such as financial fraud and massive compromises of confidential data. I therefore advocate we need a new approach in software security that considers the attacker perspective while designing and implementing software. Let's start this new approach by considering threats and attacks while designing and implementing security controls such as setting security requirements. Let' s design, implement and security test new countermeasures so that the software is both threat resilient and attack proof. This blog is about educating people on how to write secure software and to manage the different risks of insecure software. Security engineering and risk management are part of the solution of secure software and these are not only responsibility of software developers but the software organization as a whole that includes application architects, information security officers, chief technology officers, risk managers and least and not last business owners. Software security requires collaboration between engineering and security teams. It requires business and risk managers to together seeking to improve engineering processes and minimize risks. Software security is not the end goal but a process that allows to reduce risks to a level that the business is willing to accept. Software security is more journey than a destination, it is an on going mission and an opportunity to reduce risks to the business through continuous process improvements. Indeed we made improvements in software security. For example, the average software developed today has fewer number of vulnerabilities than had in the past, say six, ten years ago. This is due to the availability of better tools for testing software vulnerabilities and to the effort of security vendors and organizations whose mission has been improving the security of web applications like OWASP. Nevertheless, despite the progress made in software security, we are far from writing and building software that can be considered resilient to today's threats and attacks. There is still a lot of work to do in software security. To know how much work, think about software security as a metaphor of car safety. In automobile industry metaphorical terms, the state of the art of countermeasures built in today's software are like air bags that inflate after a car crash accident had occurred. Consider for example that it takes months on the average for a company to detect a data breach incident (based upon Verizon data breach reports) since the time the security accident had occurred. Most of data breaches today are detected after the data has been lost, similarly to air bags that detect car crashes and explode after the passengers are either already dead or injured. Unfortunately, there is no air bag equivalent security measure in software today and there is not car crash test equivalent to test security measures.

Car Air Bag
(Source http://www.airbagecu.com/)

Also consider the inherent risks due to the high value of the data assets and the critical business functions that software stores and process today such as software that runs critical industrial systems like SCADA and runs oil, gas, water and electric utilities, that control manufacturing, traffic controls and mission critical systems for the military. In the financial industry, this is the critical software that handles payments,allows to trade stocks and bonds seldom for million of dollars per transaction. A little bit closer to our every day experience as consumers, consider software for online purchases and that processes and stores credit cards data. Software that is critical for business functions and for the operation of critical business services is today under the focus of persistent attackers and need adequate countermeasures. Let me try to use the car analogy for highly sought targets from attackers. This would be like the limousine car carrying the president of the United States for a state visit trip. Because of the threats that the presidential car might face, it would need at least high grade security built into the car like bullet proof glass and doors. Other cars with secret service agents would escort the presidential car as well to provide a layered defense. The presidential car is not built with the protection of an average car and is not given average security protection. This is because the president is an highly value asset and needs extra level of protection. Similarly, business critical software is an high value asset that needs a level of security that is higher than commercial off the shelf software. For example, business critical software need at minimum additional layers of preventive and detective security. Yet business critical software today is engineered by following more or less the same design of countermeasures of average software that is 20 years behind today car safety standard technology such as air bags. So I hope you got my point with the car metaphor. Today's software security is not adequate because is not resilient enough to cope with the new threat landscape. Today software applications that protect critical company and government digital assets are under the siege of motivated threat agents and persistent attacks. In today threat landscape, business critical software would need the equivalent security of a tank or a bullet proof car. So how we can catch up with the threats ? We need to work toward more resilient and attack proof software. We need to design and implement countermeasures that make more costly for attackers to bypass. We need preventive and detective controls to evolve to effectively detect fraud and prevent fraud and identity theft. We need to move on from infrastructure and perimeter security as network firewalls and intrusion detection systems were good security measures to protect from the cyber attacks of the late 90s and not adequate to protect from today's threats. Because of this, today's cybercrime is an industry that strives with profits of several millions of dollars for cyber criminals by selling malware that is designed to hack into the consumers bank accounts and steal credit card data. Today cybercrime tool vendors offer a money back guarantee to a fraudster in case a cybercrime tools won't provide the financial gain that was sought (e.g. stealing money from bank accounts). Yes, in the mean time we worked to build more secure software, the cybercrime industry did not waste time and our effort of securing software today is not catching up with the threats we face. Not to underscore the progress we made in software security, if you read the the 2006 DHS Security in the SDLC (S-SDLC) guidelines, we can say that after 6 years, most of software organizations conduct penetration tests and some even have deployed static source code analysis tools that automate the process to identify vulnerabilities in source code. This means there are fewer number of vulnerabilities available to exploit by the attackers. We also have software security maturity models like BSIMM that help software development organizations to compare their software security practices among peers and focus their security efforts in the security domains and activities that need the most effort. This is all good but not enough because the threat landscape has changed and the exposure of software to cyber threats has increased dramatically. Consider the widespread use of software for mobile applications and the millions of people storing personal data on social networking sites. Consider the corporate data stored and processed by software in the cloud and the software that processes and stores personal identifiable information such as voice fingerprints for authentication and user's images for a person identification. Today, there is a disconnect between the escalation of cyber threats, the increased exposure of software to cyber threats and the effectiveness of the countermeasures for protecting and detecting cyber threats. Today software security need to evolve and bake in new countermeasures that need to work like a car air bag. Since Microsoft released a threat modeling methodology ten years ago, we had a software centric based approach to design secure software that considered threats against software components including data assets. This methodology is based on a simplified view of threats such as STRIDE (Spoofing Tampering Repudiation, Information Disclosure, Denial of Service and Elevation of Privileges). This type of threat modeling today is not adequate for designing secure software because threats and attacks have evolved from the basic threats. Consider the example of an attacker using an interface that takes credit card information not to steal credit card data but to enumerate which credit card numbers are valid so can be used for online purchases or counterfeit credit cards. This is a type of threat that STRIDE does not categorizes because is tied to business impact not technical impact. Today attacks against application's software not only seek to compromise the data assets but also to abuse the critical application functionality. In a today threat model, the analysis of use and abuse cases and of business impacts caused by vulnerability exploits are essential to identify countermeasures and mitigating business risks. The attack surface of today's applications has also become wider including all the available application interfaces and channels that are exposed to a potential attacker. In enterprise wide software and applications the targets are not just one software component or library but the whole services provided to customers and partners. An attacker will seek to compromise different channels that lead to the data assets such as online, mobile and B2B channels and in the cloud where data is either stored or processed.

Tony UV Gives a talk on P.A.S.T.A. Threat Modeling
ATL BSides Conference in Atlanta, 2011

A comprehensive threat model today need to analyze the abuse of software and application functionality by an attacker to determine the possible business impacts. Today's software need to be tested with the equivalent of car crash tests to probe the security measures in place assuming that a compromise of one measure won't result on a catastrophic loss of the assets such as data and critical business functions. As I saw the need of a new way to look at threats, vulnerabilities and attacks, I embarked with my friend Tony Ucedavelez CEO of Versprite in a passionate effort to develop a new process for the analysis of cyber threats by focusing on business impacts and with the ultimate objective of protecting the company digital assets such as data and critical business functions. This is not a stand alone threat model for software developers but a risk framework that can be used by organizations to analyze the impacts to the assets and critical business functions assuming these can be attacked and compromised. This means to consider the attack as a mean to the attacker goals. The foundation of this application threat modeling methodology is a new risk framework and process. This threat modeling process consists on the "Process for Attack Simulation and Threat Analysis" (P.A.S.T.A). Pasta is a food metaphor for threat and attacks and it is used to educate security people to threat and attack analysis. Using the food metaphor, pasta is taught as the basic ingredient for cooking quality meals as threat modeling is the basic ingredient to build secure applications. Since an attack describes how a threat is realized, this methodology outlines the steps for analyzing threats and attacks and build countermeasures as a recipe for cooking good pasta. The modeling threats and attacks, threat modeling drives the design of protective and detective measures to minimize business impacts. For example, the correlation of attacks to possible exploits of vulnerabilities can be used to design preventive and detective measures. Since we need tools to conduct this process and the correlation between threats, attacks and vulnerabilities, we convinced the company, myAppSecurity Inc to develop the threat modeling tool to support this process. The tool threatModeler (TM) helps software developers in conducting the steps of the methodology and produce threat models of the applications. In the mean time, Tony UV and I started giving talks about threat modeling by attending several security conferences (e.g. Universities, OWASP, BSides). We spent the last three years learning what works and what does not work. Education of software engineers and software security professionals in threat modeling is key for success. Also in most of software development organizations today, threat modeling is misunderstood as software security methodology. For this reason, it is either missing as S-SDLC activity or it is considered as complimentary of other consulting security engagements such as pen testing and secure code reviews. Instead threat modeling is central to the application security risk mitigation strategy since allows to map threats to attacks and attacks to vulnerabilities and to highlight the exposure to threats of the data and critical business functions. Threat modeling allows the business to understand the risks of the exposure of data assets by vulnerabilities and the determine the effectiveness of security measures in place. Threat modeling allows to perform a defense in depth analysis by determining how defenses can be bypassed by an attacker and identify where layered controls need to be implemented. Threat modeling allows to model the abuse cases of critical business functions so these can be used to crash test security measures and to determine how effective these are for protecting and detecting from the attacks. Ultimately, application threat modeling allow the business to decide which security measures are the most effective in mitigating risks of attacks and implement the security measures that minimize the risks and minimize the costs of implementing them. While security, engineering and business teams work together and follow the steps of P.A.S.T.A., they learn how to develop resilient software and translate software security into business value so that the business can make informed risk decisions. Finally, on the topic of application threat modeling, we have a book coming up where we collected our ideas and experiences in eight monumental chapters. The intent is to help others with our experience in the field and to educate the new generation of security professionals on how to design and implement resilient and attack proof application software for today's and future cyber threats. So be prepared soon to reboot your security program as well and start a new journey leading to a destination where software and applications are resilient and attack proof like a cars are safe in accidents because are designed to use air bags and probed with crash tests.

Application Security Guide for CISOs

2011-08-05T01:49:00.016-04:00

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

2011-06-19T09:27:00.024-04:00

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

2011-02-06T19:08:00.014-05:00

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

2010-11-15T23:21:00.010-05:00

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

2010-09-10T09:32:00.029-04:00

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

2010-07-26T20:53:00.023-04:00

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

2010-03-21T18:28:00.028-04:00

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

2010-03-19T20:56:00.014-04:00

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

2010-01-24T14:09:00.017-05:00

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

2009-12-31T17:12:00.022-05:00

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

2009-11-01T19:27:00.062-05:00

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:

Compliance with information security standards (e.g. PCI DSS);
Education and awareness on root causes of vulnerabilities in applications/software;
Software security engineering benchmarking using a software security maturity model;
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:

Software Risk Analysis & Management
Software Security Engineering
Security Assessment Processes and Tools
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.

IMI Security Summit in Northern Kentucky: awesome security conference

2009-10-30T20:31:00.028-04:00

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

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

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

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

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

Two Weights-Two Measures

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

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

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

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

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

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

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

2009-10-03T10:05:00.074-04:00

I recently had the opportunity to give prezos for OWASP in Los Angele s and Orange Co unty 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)

There is a strong and compelling case, based upon vulnerability data alone, that compliance do not buy security for your organization but a minimum level of information security assurance: in the context of mitigating vulnerabilities for compliance sake for example such as to fill a compliance requirement (e.g. vulnerability assessment), based upon the data from MITRE, at their best the organization 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 compliance security assessments. These threat analysis techniques for example 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.

The threat mitigation 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 proactive risk 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 such as to protect credit card data.

Fraudsters also know that ogrnaizations implemented multi-factor authentication and fraud detection, in compliance with FFIEC guidelines for authentication.

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:

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.

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.

Business Cases For Your Software Security Initiative

2009-07-05T09:30:00.062-04:00

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

2009-03-31T07:47:00.006-04:00

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

2009-03-28T10:20:00.022-04:00

An example of C/Q
setup for on-line banking

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

2009-02-28T22:36:00.018-05:00

Example of god action: lightning

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.

Human factors is the
fundamental risk "element"

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

Co-risk for financial institutions

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.

Credit Default Swap:
Source:Invest2success blog

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 Cassandra told all the people in Troy to watch out for the Trojan Horse, but nobody paid any attention.. 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.

December 1941 Dec,
Japanese attack US Navy at Pearl Harbor:
A small boat rescues a seaman from
the 31,800 ton USS West Virginia
burning in the foreground.

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

2009-01-17T18:04:00.011-05:00

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

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!

2008-12-16T18:57:00.010-05:00

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

2008-11-06T00:37:00.019-05:00

Open Source and Free Software Wars: Source
dwheeler.com

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

The following themes were stimulated during the round table:

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

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

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

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

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

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

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

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

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

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

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

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

References:

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

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

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

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

[5] Charles Hill: Thoughts on FOSS security

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

New phishing attacks require adoption of different countermeasures

2008-11-02T17:56:00.016-05:00

Phishign warning source:
Cyberpunk blog

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

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

2008-10-09T19:34:00.034-04:00

If your are an information security officer managing risk and incident response processes, I strongly recommend watching the movie Jaws as a case study for learning how human and business factors play in dealing with bad, non expected and non foreseeable negative events, such as in this case, shark attacks, and how risk mitigation decisions are affected by human psychology. The move is a en example on how the human psyche responds to negative events through stages such as: (1) denial, (2) awareness, (3) responsibility, (4) action. I am not a psychologist but this is my interpretation by just applying common sense: Denial comes from the fact that till we (as people or as business) are not impacted directly by the consequences of a negative event, we most likely minimize risks. Awareness, is driven by the fact that we had experienced a negative impact such as a damage or a financial/asset loss before and so we raised our level of attention as a response to feelings (fear). Responsibility, comes from a feeling of duty or role to deal with the risk and the negative consequences of it, for example, as humans, we might feel responsible to react to protect business, family, friends that depend upon us, our actions and our role in society. The last stage of incident/risk response process is the call for Action. This it is either triggered by need to prevent further sure loss and damage or because someone else told us to do so. If you watch the movie from this perspective, as a case study for managing the risk of security incidents such as data losses and fraud, you can see clearly all these elements and learn some lessons for dealing with security incidents:

Lesson #1: The first approach toward risk, when not impacting directly a business or an individual, is to either ignore it or minimize it. For example, the movie is about the risk of being killed by a shark attack. In the opening scene of the movie, a shark is seen wandering in the ocean and killing a girl during a skin-dipping swim after a college party. The police, that responded to the incident, 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 of the incident is advised to minimize the incident for fear that reporting the incident would have scared off the tourists to come to the town beaches on vacation. How this lesson applies to IS risk? A company had a security incident and customer data was compromised as a result. The attack indicates that an attacker got customer data by breaking into the database through one of the company web sites. The business together with security and fraud decides to file a security incident report that the web site application database that stores customer information has been compromised but minimizes the potential impact since no customer PII (Personal Identifiable Information) has been compromised. The decision is to investigate this further till more information is gathered.

Lesson #2: When the causes of the incident are not found and the fix does not address the root cause, more incidents most likely will occur and get noticed. Since the shark is still alive, it attacks again and makes another victim. At this point, the incident cannot be ignored since it happens in complete daylight with a lot of witnesses. In the mean time, another shark (but not the killer one) is being caught and shown to the public as proof that now the shark responsible for the attacks has been caught and beaches are no-longer at risk. How this applies to IS risk? The company did not found the cause of the exploit/data breach so they had another cyber-attack that exposed customers data to public. Since now the information about the data loss and the vulnerability is public, the company needs to do something to deal with the damaged reputation. The company then decides to release information to the public that no compromise of personal identifiable information was result of the incident and publicly disclosed that the vulnerability has now been fixed and there is no risk for the customers.

Lesson #3: When new, internally adopted measures do not mitigate the risk of further incidents, you most likely ask for help from the 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 on dealing with the shark killing threats. The researcher comes to the town and starts his investigation, he soon realizes that this is a case of a giant tiger type of a shark attack and that the shark that was believed to be the killing one (the shown to public as trophy) is not possible to be the one that made such killings since the teeth of the jaw of the shark and the teeth marks in the scares of the victims did not match. The researcher explains the results of his analysis to the police and the town officials and recommends a call for action for killing the tiger shark. After meeting with the policemen and the major it still decided not to. How applies to IS risk? The company internal security team has identified some security vulnerabilities like SQL injection that possibly were the cause of the breach, these were fixed but the attacks continued to occur so a security consulting company is asked to analyze this further. Security researchers did some security tests (e.g pen tests, vulnerability scans) and concluded that even if some of the identified vulnerabilities can be exploited for the type of the attacks seen like SQL injection, other potential critical security flaws (e.g. weak authorization controls, weak input validation) can be exploitable too but these security flaws might actually require to do a design review to be identified and eventually require to re-engineer the application security controls. The business is still undecided to whether pursuit these recommendations since require more explanation of risk and impact to justify very expensive design changes to the application.

Lesson #4: When the impacts of incidents gets bigger and get notified to senior officials, can be ignored no more 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 police hears the people complains at a public hearing, they decide to finance a mission to kill the tiger shark. How applies to IS risk? Fraudsters break again to the site and this time the financial and reputation losses can no longer be ignored including senior management at the company that now decides to prioritize the effort to mitigate this risk and put resources and spend money to identify the root causes of these attacks and provide risk mitigation solutions.

Lesson #5: The first approach to deal with attacks takes the defensive perspective to detect the negative events and pinpoint the threat sources. The policemen, the shark hunters/fisherman and the Oceanic Society Shark researcher devise different techniques to locate the shark attacks such as by hooking floating detection devices to the fisherman boat, these "sensors" seem to work, for a moment, the killing shark is located and traced and seems to be within reach for a shot. How applies to IS risk? The company installs new Security Incident Event Monitoring (SIEM) and starts to closely monitor the attacks looking at logs and incident events. Once an alert from the SIEM is triggered, it is decided to block the IP address of the most likely source.

Lesson #6: If your deal only with the symptoms instead of the root causes of an incident, the countermeasures can be bypassed by the attacker and the risk is still not mitigated. Despite all the effort put forth to detect the killing shark attacks, the shark outsmarts the fishermen, the oceanographer and the policeman by breaking the hooks where the floating devices where attached and attacks the boat unnoticed. The shark now attacks the boat directly, breaks it and causing it to sink. How this applies to IS incidents? The fraudster learned that incident-event evasion techniques can be used against the application, a SIEM event that pinpoints the source of the IP address to block the traffic, it does not stop the attack since the attacker uses proxies and fast-flux botnet techniques where the source IP is dynamically changed in real time.

Lesson #7: By tackling the causes of the incidents and the sources of the attacks finally the risk of further attacks is mitigated. The fishermen are now actively engaged in fighting back the shark attacks, during a dramatic wrestling with the shark, the policemen throws the boat gas tank on the shark jaw and then aim to it with a rifle causing the gas tank to explode. How applies to IS risk? After an analysis of the attack scenarios several most probable attack patterns are simulated, the attack surface of the application is identified as well as the possible data entry points for intrusion. The data entry point that is most likely used by the attacker is a web form to initiate a database query transactions to gather customer's demographic information, access to this data entry form and the transaction are temporarily disabled by configuration changes and this prevents the attack to occur. The application logs collected during the attacks are provided to law enforcement. These along with other information collected by the law enforcement, such as the attacker's toolkit/scripts used in the attack, provide enough information to pin point the attacker, take down the IP address and eventually catch the fraudster with a sting operation. Further security design review of the application identified flaws in the implementation of the transaction for query demographic customer data such as elevation of user privilege through changes of query parameters that were unvalidated by the server. Application design changes are implemented to prevent further attacks such as to strictly enforce role base access controls on the server side with new policy rules, changes to the web form not pass role/permissions parameters in the query. These fixes were implemented with a new patch and access to these transactions was re-enabled for the customers. Finally a disclaimer, the examples mentioned herein are not factual..

Application Security Conferences/Events (July-November)

2008-07-13T08:33:00.009-04:00

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

2008-06-25T21:59:00.003-04:00

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.