As we all know, there are two main components to risk: 1) the chance that something will happen, and 2) how bad it would be if it did--or, probability and impact. For the last 20 years we've been focused almost exclusively on probability, i.e. trying to make sure bad things don't happen.

The problem is that we’ve reached Peak Prevention. Like Peak Oil, Peak Prevention is a wall of diminishing return, and we've hit it. We can multiply our prevention efforts many times over and get very little reduction in risk (and perhaps even an increase due to ever-advancing threats). 10 years ago we were at around 50% prevention maturity, and now we’re at roughly 90%. If we spend another 10 years and 10 trillion we can maybe get to 95%. But all that effort would provide only a small fraction of the risk reduction we could achieve by making successful compromises less costly.

...

We are very pleased to announce the release of the HP 2012 Cyber Security Risk Report. Originally started several years ago by HP DVLabs, it has grown to encompass data, analysis and content from a wide range of HP groups and truly serves as a not only a representation of our unique view into the threat landscape, but also as a testament to the strength of our integrations and outlook.

Keep reading to learn more about the report's findings.

Next week, we are publishing the HP 2012 Cyber Risk Report. This is an  annual collaboration among groups within HP Enterprise Security Products including  HP Security Research (spanning HP DVLabs, HP Fortify Software Security Research, and the HP Zero Day Initiative), HP TippingPoint, and HP Fortify on Demand. While you'll have to wait until next week to read the full report, there are some key stats I can share with you now that illustrate the ugly nature of the security beast.  Cross-site scripting has been around a long, long time.  In fact, one of my first security jobs (all the way back in 2002) involved working on a white paper on that very subject. Apparently, it didn't solve the problem. We tested thousands of applications across multiple sample sets and the results were clear -  cross-site scripting remains a pervasive web application security problem. Numbers ranged from 44% to 48% across our various applications sets and included results from both dynamic and static testing, helping to underscore our findings.  Further corroborating our results, cross-site scripting remained the number one Zero Day Initiative submission for 2012, accounting for 15% of all vulnerabilities.

So what does all this mean? Well, for one thing, that developers and organizations alike aren't correcting long standing and well known security issues (more on that in the full report). For another, that the prevalence of susceptibility to this vulnerability coupled with constant research into new methods of exploitation should give any enterprise sufficient reason to test for cross-site scripting.

I would be remiss if I didn't mention that one thing we offer via Fortify on Demand are free initial scans for cross-site scripting vulnerabilities. If you need a place to get started figuring out if your applications are vulnerable, it's hard to beat free.  You can find more info on our free offer at https://www.fortifymyapp.com/freemium/pricing.aspx.

Here at Fortify On Demand our engineers assess countless mobile apps. Being on both sides of the fence (static analysis and blackbox pentesting) we like to think we have a very holistic view of mobile vulnerabilities. This series is an educational resource for mobile app developers and testers exploring the newly minted OWASP Mobile Top 10 project, its categories, and how these vulnerabilities manifest themselves. We will explore the threats surrounding these vulnerabilities and in some cases look at insecure code and testing methods associated with them as well.

The Open Web Application Security Project (OWASP) has been categorizing, evangelizing, and publishing remediation information for web application security for 12 years. In 2007 OWASP released a project to categorize the 10 most prevalent web application vulnerabilities in order to educate developers and testers as to their manifestations and risks. The end goal being that they could be identified and reduced in web applications all over the world. The “OWASP Top Ten” project was a huge success.

In early 2012 OWASP realized that the application landscape had shifted. They enlisted the help of researchers to draft a Top Ten list for mobile applications. Fortify On Demand researchers lead and contribute to this project. Below we will be exploring the third category in the OWASP Mobile Top 10; Insufficient Transport Layer Protection.

Fortify On Demand has been helping out the OWASP Mobile Project recently by contributing content and fleshing out the descriptions for the Mobile Top Ten. While doing this I thought up a list that provides more… anecdotal value.

It's important to remember that these are mostly just roadblocks, in fact I’ve blogged here on the FoD blog about how to bypass some of these protections but... they sure made those specific applications harder to crack. That and they took a bit of time to figure out. Defense in depth is my motto!

The Top Ten Ways to Thwart a (iOS) Mobile Application Hacker:

1) Certificate Pinning

2) Jailbreak Detection

3) Protecting Everything with Proper Data Protection API Designations

4) Enabling Binary Protections (PIE and Stack Cookies)

5) Encrypting Local SQLite databases (SQLCipher)

6) Defending against Runtime attacks via memory address checks

7) Writing custom functions (securely) in C vs C++

8) Clearing memory after every function

9) Use Anti-debugging techniques (no attach or check for kernel state of debugging)

10) Harden your web-service (especially in the areas of session management, authorizations, input validation, etc)

I’ll expand on these more in the future, just random thoughts!

- Happy Hacking!

Few topics in the infosec world create as much heat as the classic "vulnerability assessment vs. penetration test" debate, and it's no different in the web application security space. Sadly, the discussion isn't usually around which is better. That would actually be an improvement. Instead the debate is usually semantic in nature, i.e. the flustered participants are usually disagreeing on what the terms actually mean. Step 1: agree on terms.

So, I'll be ambitious here and will tackle both subcomponents of the debate here: 1) what the terms actually mean, and 2) which is better for organizations to pursue.

Web Vulnerability Assessment vs. Web Penetration Test

It's worth stating explicitly that these two types of security test are in fact quite different. Many make the mistake of thinking that a penetration test is simply a vulnerability assessment with exploitation, or that a vulnerability assessment is a penetration test without exploitation. This is incorrect. If that were the case then we'd simply have one term that we'd qualify with "with or without exploitation".

A web application vulnerability assessment is fundamentally different from a penetration because its focus is on creating a list of as many findings as possible for a given web application. A penetration test, on the other hand, has a completely different purpose. Rather than yield a list of problems, a penetration test's focus is the achievement of a specific goal set by the customer, e.g. "dump the customer database", or "become an administrative user within the application". Also important to note is the fact that a penetration test is successful if and when the goal is acheived--not when a massive list of vulnerabilities is produced. That's what a vulnerability assessment is for.

Some are tempted to say that this is a goal-based penetration test. My question to them is simple: "As opposed to what other type?" Penetration testing is goal-based. That's its entire purpose. Even a customer direction as nebulous as "see what you can do" is absolutely a goal. It's an implicit goal of getting as far as you can given whatever constraints are in place.

The question of exploitation is another obstacle to clarity on this topic. Many have a simple binary switch for using the terms: "If there's exploitation it's a penetration test and if not it's a vulnerability assessment." Again, the key difference here is list-based vs. goal-based--not exploitation. It's possible do do (or not do) exploitation in both types of test. You can have a web vulnerability assessment where you are to exploit anything you find, and you can have a penetration test where you are asked to confirm that you can do something but not do it. Exploitation is an independent attribute that can be attached to either type of test.

When to Use One vs. the Other

Now that we see a distinction between terms, the next question is, "Which one is best?" Which should we be offering customers? As you may expect, the answer is that it depends on the customer and the project, but in my experience the answer will usually end up being a vulnerability assessment. Why? Because vulnerability assessments (getting a list of everything that needs fixing) is usually where most customers are in terms of maturity.

To tightly summarize:

For questions or comments I can be reached at daniel.miessler@hp.com and on Twitter at @danielmiessler. ::

The Open Web Application Security Project OWASP is well known for its Top 10 list, and perhaps for its testing methodology as well, but comparitively few people are aware of its Application Security Verification Standard (ASVS) Project

The ASVS, as the name alludes to, is a standard for verifying the security of applications as opposed to a methodology for testing them. This is not a distinction without a difference, but rather a key piece missing from many appsec efforts...

This article outlines using runtime hacking to dump classes of iOS applications even if the application is still encrypted.

All security services are not created equal. In the application testing field you will find a common theme among security professionals is that you can never automate everything. Here at Fortify on Demand we take that to heart. Look below to see how we leverage both industry standard tools and world class engineers in our application assessments via Fortify On Demand.

This blog is a cursory breakdown of defeating less advanced jailbreak detection code. There are several ways to employ jailbreak detection in a security conscious mobile  application. Many of the easier-to-defeat methods involve checking the iOS file system to see if any jailbreak relevant files exist. If we need test an application that employs this type of protection, we need to figure out a way to defeat it, so we can still use our jailbroken testing device.

For the longest time a big struggle with doing mobile application assessments on iOS has been monitoring applications as they drop files to the file system. There were definitely ways to do this but they involved taking snapshots of the application directory with tools like macrobber. This is less than adequate because some of these apps drop unencrypted files with sensitive data but later delete them as part of a functions cleanup. A realtime solution was needed.

There is no question that mobile computing is growing at an exponential rate. This rapid transformation has seen security concerns outpaced by the ease of use, flexibility, and productivity of mobile devices. When vulnerabilities are
exploited, the security of mission-critical data becomes a serious concern. Here we take a look at three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.

In this white paper, we explore and discuss the following:

• How mobile applications are just as prone to security vulnerabilities as their web counterparts.
•  Why insecure use of mobile APIs, data exposure in transit and at rest, and other serious threats make this shift to mobile computing a top concern for businesses today. 
• The top three mobile application security threats from out data set. 
• Recommendations on how to mitigate the risk from mobile computing security vulnerabilities.

The entire white paper can be accessed at the following link:

http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA4-4446enw.pdf

Here at Fortify On Demand our engineers assess countless mobile apps. Being on both sides of the fence (static analysis and blackbox pentesting) we like to think we have a very holistic view of mobile vulnerabilities. This series is an educational resource for mobile app developers and testers exploring the newly minted OWASP Mobile Top 10 project, its categories, and how these vulnerabilities manifest themselves. We will explore the threats surrounding these vulnerabilities and in some cases look at insecure code and testing methods associated with them as well.

Welcome to the HP Fortify On Demand blog! In our first inaugural article we will introduce the latest offering from HP Fortify On Demand at www.FortifyMyApp.com.