Here are just a few highlights of some of our speaking opps this year…

RSA 2011
In the talk “Intelligence on the Intractable Problem of Insecure Software” Veracode’s Sam King, vice president of strategy and product marketing, and Chris Wysopal shed light on application security debt and the real cost of insecure software that threaten the integrity and performance of software in the software supply chain.

United States Congress
Yes, we (or more specifically Chris Wysopal) were invited to Capitol Hill to present to members of Congress on the criticality of insecure software and the role it plays in the landscape of cyber security threats.

BlackHat
Senior Security Researcher, Tyler Shields, played host and moderator to a panel of top mobile security experts in the world to debate which attack models would potentially pose the greatest risk to enterprise across the mobile security stack.

OWASP App Sec USA & Europe
The Veracode research team was in full force at OWASP on both sides of the pond, presenting on everything from mobile security trends to critical analysis of information security stats available in the marketplace today.

AnDevCon
Tyler Shields cautioned developers on “Avoiding the Pandora Pitfall”. With a different threat landscape and new, mobile-specific, privacy concerns, secure mobile development is a unique concept. Tyler discussed the new imperative to understand what common mobile security flaws look like and how they differ from traditional programming vulnerabilities if we are to avoid repeating our failures of the past.

Other Little Known but Equally Fun Speaking opps from Veracoders:

DEFCON Kids
Chris Lytle of the Veracode Research team is training the next generation of security superstars! In this session at DefconKids he introduced budding cryptographers to the art and science of making and breaking secret codes and ciphers.

MIT
This fall the ivory tower elites at MIT got schooled on security by Veracode’s Co-Founder and Chief Scientist, Christien Rioux, when he presented a lecture to MIT associates and students on the topic of “Lessons of Static Binary Analysis”.

Of course with the year coming to a close the tradeshow/conference season begins to settle into the lull of the winter doldrums. But if you really have a hankering to see the Veracode team live, then why not switch gears from the conference circuit and check our performances…

Don’t miss Tim Jarrett, Director of Product Management, as he sings with the Boston Symphony Orchestra in the Holiday Pops performances on 12/21 and 12/23.

And if you need to amp-up your year-end, join resident rocker (and Inside Sales Representative), Andy Reed, as he performs live with his band, The BlueWaves, in some of metro Boston’s local venues — Brighton Beer Garden on 1/20 and Copperfields (Boston) on 2/4! ROCK ON VERACODE!

In this post Fergal asks if developer code quality is seasonal? Fergal used the State of Software Security data set to analyze applications in early stages of the development life cycle. He examined application size and a roll-up of the total quantity of flaws per application to determine what he calls “flaw density”.

The results are interesting, January through September has a relatively flat flaw density. Then, there is a big bump in flaw density in October and November. Why is this? Maybe the build up to Thanksgiving has developers distracted? Are developers adjusting after the Summer break when “the living is easy” and the roads are quiet? Fall brings the extra pressure to produce a high volume of code to meet end of year deadlines and releases.

Read the full post here – http://threatpost.com/en_us/blogs/quality-coding-takes-break-holidays-why-122011

For a few days after the 2011.6 Release, Veracode’s Development & Research teams hosted our first ever Hackathon. It’s been a productive year for us at Veracode, and after six product releases and a record number of applications scanned, we felt like it was a great opportunity for us to see what creative ideas our team could come up with if they had a few days of free reign to code anything that excited them (you know, without us Product Managers telling them what to do).
There’s only one major rule: you can work on anything that interests you as long as you can demo it to everyone at the end.

For the few weeks leading up to the Hackathon, we put up boards throughout the office where people could jot down their ideas. We filled up over 10 boards & over 65 ideas were posted!

Last Friday morning, we kicked off the Hackathon with a brainstorming session. People presented ideas that had been percolating for awhile and solicited feedback from the other participants. Projects, teams, and code started taking shape and we were off. We had some conference rooms set aside for group work spaces, but aside from that we tried to keep the formality to a minimum.

Three days later (well, five if you count the people who kept working through the weekend), we were rewarded with an amazing demo day. Almost half of the company was in attendance and we saw demos from over 20 project teams.

Despite our Marketing team’s wishes, the details of most of what was worked on are top secret – but we definitely saw projects that stretched our collective imaginations and used an incredible spectrum of different technologies. Projects fell into a few different categories:

1) Customer & Internal product improvements (which will keep our product team busy for a while): These included a simple upload tool that leverages our APIs to drag and drop apps from the desktop to the Veracode service, and a new bulk processing feature to enable preparing hundreds of applications for upload at the click of a button. We liked these so much that they’ll be shipping soon.

2) Engineering exploration and skill building: things like Google maps mashups, data visualizations, or this script that adds beats per minute values to your iTunes library: http://bit.ly/sOi6pd

3) General technology exploration: for example, we learned that someone’s driveway is not the ideal place to make your first printed circuit board.

On the Product Team, we’re actively looking at the projects to determine where the best features and improvements will fit in our product plan. It was absolutely amazing see how bright our team is and what they’re capable of producing in just a few days!

We finished up with some good natured awards given for categories like Best Mashup, Most Dangerous, Most Usefully Repulsive (hint: it involved Perl), Best Laid Plan, Best Already Shipped Feature, Biggest Win for Veracode, & Biggest Team; to name a few. As we planned the event, we had high expectations for what our team could put together, and we left amazed that those expectations were far exceeded. The energy, enthusiasm, and ingenuity that everyone put into their projects were off the charts. Folks left already asking about when the next Veracode Hackathon will be, thinking about their next project, and talking about what we could do better next time – so I guess we’re going to have to make a habit of this…

You recently heard our CTO, Chris Wysopal discuss in his blog post the warnings issued by ICS-CERT on backdoors in a standard network module for control systems. The type of equipment was the Schneider Electric Quantum Ethernet Module. You can read more about the full warning here. Chris went on to discuss how this warning was consistent with what we observed in our recently released State of Software Security report where we found that backdoors were present in 3% of software vendor developed code (Schnieder’s module being an example of this type of commercial code).

However, the vulnerability categories that we observed in the Top 10 for commercial software and not other types of software (e.g. internally developed) don’t just stop at backdoors. We also saw a higher presence of remote code execution vulnerabilities in commercial software than other types of software we analyzed.

So, what is a remote code execution vulnerability? Before I elaborate on that let me ask you – do you remember ‘Operation Aurora’ that caused a breach at Google and several other prominent US companies? Well, that attack exploited a remote code execution vulnerability in Microsoft IE 6. So, a remote code execution vulnerability is one that is really bad to have in your software. More specifically we characterize vulnerabilities such as buffer management errors, buffer overflows, and integer overflows as classes of remote code execution vulnerabilities due to the potential for an attacker to exploit them to gain command over the target system and execute

arbitrary code on it. It was interesting to observe that these made it to the Top 10 for commercial software but not other software types (4% of vulnerabilities in commercial software were buffer management errors and 3% were buffer overflows). We think that the reason for this is that internal software development continues to shift to managed code languages and scripting languages which don’t fall victim to many of these serious vulnerability types. However, commercial software continues to make use of non-typesafe languages (such as compiled C/C++ and Objective C) where it is easy to get sizes of buffers mixed up and end up with these problems. In fact, we reported in State of Software Security report that 15% of commercial applications made use of C/C++ as compared to only 4% for internally developed.

So, what’s to be done? There is a role to be played by both the software producers creating the commercial code and software purchasers that are buying it for deployment in their organizations. Software producers should provide training to their development teams on how to prevent and fix these types of issues and test for their presence before shipping their code. Software purchasers should make sure that their security due diligence on commercial vendors includes a detection capability for these types of serious vulnerabilities.

My next post in this series will be after the New Year, so until then – have a happy and safe holiday season!

For those of you interested I put together a sampling of other Veracode appearances on local and national news: http://www.veracode.com/tv

Backdoors in industrial control systems

These backdoor revelations in industrial control equipment are becoming frequent. Earlier this year Dillion Beresford found similar backdoor vulnerabilities in Siemens equipment.

We find these types vulnerabilities fairly often when we scan vendor code on behalf of our customers at Veracode. Our recent State of Software Security Report vol. 4 detailed the findings. We didn’t find these backdoors in internally developed, outsourced, or open source applications. We did find backdoors in 3% of software vendor developed code.

This chart above is the result of our static and dynamic analysis of thousands of different applications over the preceding 18 month period.

Vendors add this backdoor code because it lowers their support costs. Unfortunately it is at the expense of the customer’s risk. It is easier for a vendor support technician to remotely diagnose a problem if they know a “support” password to your system or if there is a debugging interface exposed to the network. No need to fly on site or communicate time consuming “remote hands” commands to a local IT employee.

We have seen an uptick in customers performing 3rd party scans on the software they are purchasing. A few years ago it was only our financial services customers that were concerned about backdoors and vulnerabilities in the code they were purchasing. Now we are seeing a much broader range of industry verticals.

The chart above shows we have 8 different industry types including: aerospace & defense and oil & gas, scanning 3rd party code. We are still not seeing industrial control equipment but with the news this year I think it is only a matter of time. 3rd party analysis will grow as operators of code continue the trend to hold vendors accountable.

Backdoor testing should always include static code scanning. How can you find a static password or cryptography key without it? Ideally this is done on the product binary. Vendors are loath to give up source code, even to a 3rd party, and even if they do they might not give you the exact source code or all of the source code. Binary scanning and backdoor testing go hand in hand so Veracode has done research on the subject of backdoor and implemented as much as was practical in our binary static analysis. For further reading on testing apps for backdoors see our “Static Detection of Application Backdoors” paper which was presented at Black Hat Las Vegas.

I’ve recently joined Veracode as a product marketing manager. One of my responsibilities to respond to customer questions about Veracode, what we do and why we do it. So I thought it would be a good idea to blog about some of the common and/or recent questions I’ve been getting. So here goes the first one:

Why are false positives a costly headache for enterprises?

The short answer is: because the development team has to spend time, expensive time that they can’t afford to waste, figuring out that they don’t need to fix those flaws. Long answer takes some explaining. For those of you confused as to what a false positive is – it is something that looks like a security flaw to an automated testing solution but may not be. Some false positives are flaws that have already been mitigated by the application design or the operating environment. For example, the application may utilize custom validation routines, intrusion detection processes or restricted file access that mitigate the application risk of a flaw. Some false positives are the automated tests running across something new it doesn’t know what to do with. Some are patterns that look very similar to a flaw but aren’t a flaw.

So if your tool has false positive rate around 35% – it means that 35% of the flaws listed in the testing reports are not real flaws for one reason or another. Which means your developer or team of developers has to spend time analyzing a lot of flaws just to figure out that they are not really flaws (I think of this as rework). So you can imagine the impact on developer productivity – and more importantly your time to market. What’s worse is that the developers who get really good at doing this are aggressively pursued by security consulting firms – yes, recruiters will find your people and woo them away with sweet promises of more money and flexible hours.

Now, I’ll put on my ‘bragging hat’ and tell you that Veracode customers have minimal developer rework (and churn) because our platform and customer success team does the identification work for you. As a cloud provider we analyze many hundreds of apps a month which helps us achieve low our false positive rates. This is good news, especially for Java apps, because it’s being reported that Microsoft detected some 27.5 million attempted Java exploits since the third quarter of 2010. So we’re seeing it all and then some – which we use to create more accurate automated testing.

Also for customers that want to drive those rates even lower, the Veracode customer success team works with their developers to identify other false positives and categorize flaws that have already been mitigated. This means when our final report says ‘these are the flaws’ – those really are the real flaws. Since we only report valid flaws to our customers, there is much less developer rework (and churn), and that is why developers love us – well – maybe I’m exaggerating a bit there – let me rephrase – that is why developers adopt and use Veracode solutions on a regular basis. Anyway, don’t just take my word for it – check out our demo and see for yourself.

Application security performance declines steeply when current threat landscape is taken into account in the evaluation criteria.

Put more simply – it’s really bad out there!

We at Veracode are a pragmatic bunch. We have never promulgated a theory that every instance of every vulnerability we find must be fixed. That’s too absolutist, impractical and frankly not necessary. This philosophy underpinned our rating system such that we would pass an application with a few instances of certain classes of vulnerabilities like SQL Injection and Cross-site Scripting as long as these were not present in large numbers. How many instances were okay to have or not depended on the business criticality of the application. However, we started to see an increasing number of breaches take advantage of these vulnerabilities (e.g. Sony). The Web Hacking Incident Database reveals that 20% of reported incidents were caused by SQL Injection issues. At the same time, we started to hear from our customers that they simply want to say NO to these vulnerabilities in the software they are building and buying. So, early this year we rolled out a new Veracode policy intended to be more resilient against prevalent threats. This new policy makes the acceptability threshold more stringent, particularly for higher criticality applications. For example, it adopts a zero-tolerance policy towards frequently exploited vulnerabilities such as Cross-site Scripting (XSS) and SQL Injection. Even a single instance of these types of vulnerabilities causes applications of higher criticalities to be deemed unacceptable. The result of this new policy on application performance was drastic.

Before we went to the zero-tolerance policy below is what the picture looked like:

Overall, 58% of applications failed to pass an acceptable level of security when we first tested them.

Here is what happened when we went to the stricter zero-tolerance policy:

and the picture now looks like:

Overall, 84% of applications fail to pass an acceptable level of security when first tested! As you can see, the result of the new policy is nothing short of a staggering nose dive.

What this tells us is that we have a lot of work to do to defend against the vulnerabilities that attackers are exploiting most frequently. SQL Injection and XSS were two of the top three vulnerabilities used by Lulzsec in their 50-day hacking spree. Because it only takes one instance of these vulnerabilities in one application to cause a breach, it is important that organizations ensure that there aren’t any instances of these vulnerabilities in any application.

So, what should be done? Our recommendation is to implement a program that allows for the rapid discovery and timely remediation of such vulnerability types. Leverage automated static and dynamic analysis to scale your program to your entire application inventory quickly. Also, don’t forget the importance of training and education, the subject of another key finding in this report. But, more about that in a future blog….

First, some introductions are in order, since this is the PM team’s first time posting on the Veracode blog. The Veracode product management team is responsible for the roadmap and user experience of the services that Veracode provides to its customers through the Veracode platform. The platform is the SaaS portal our customers use to interact with all of the services we provide. This is much broader than just static binary scanning – though that is certainly what we’re best known for – and also includes dynamic scanning, developer education, and reporting and analytics.

Veracode takes advantage of being a SaaS service to update frequently with a goal toward having the most actionable results turned around most quickly for our customers, and making it as easy as possible to use every aspect of the service, from requesting scans and viewing results to setting policy and running an application security program. Ease of use isn’t just a nice to have for us, it’s mission critical, as you’ll see below.

So what’s in this week’s release? The list is long but includes a redesigned platform administration interface; data export capabilities to provide customers better access to data about their application security program; adds support for the Apache Xerces J2EE framework; adds new flaw categories for Android applications; and adds a host of improvements in results quality, API based results access, and other areas. I’ll dig into three of these items in a little more detail in the rest of this post.

Android: A year or so ago Veracode introduced the Mobile Top 10, and earlier this year we rolled out our initial support for Android. As we’ve reviewed more and more Android apps, we identified some priorities for expanding our support for scanning some of the items on the mobile top 10, including looking at cases where Android apps attempt to modify proxy settings, create inbound SMS listeners, or create data files or permissions settings in ways that allow other apps to read or change them.

Xerces: One of the benefits of running a scanning service in the cloud is that we can learn a lot in an anonymous, aggregated way about the applications we scan. For instance, we have started to track the frequency with which we see frameworks in the applications that are uploaded, and are mining that data for prioritization purposes as we continually seek to improve the quality of our results. One outcome of this effort was learning–somewhat to our surprise–that Xerces was the fifth most common Java framework or technology that we saw, after JSPs, Spring MVC, and Struts 1.x. (We believe that we have the only top ten list of Java framework prevalence, which we’ll share soon.) But at the end of the day, the benefit to our customers is better coverage of their application leading to more accurate results.

User administration: To secure an enterprise, it’s not enough to scan a few applications or educate a few users–you need to roll out wide, scan everything, educate everyone. You need, in short, to scale. Veracode is probably better at this than anyone in the industry – we have multiple customers who have scanned 100 applications in the first 30 days of their subscription, and others who have successfully rolled out 1000+ user developer education programs. As more of our customers are scaling to this milestone or growing their Veracode user base from hundreds to thousands of users, we have recognized a need to enhance our user administration features. So this release adds features for sorting, filtering, and taking quick action on user lists, easy team membership management, and getting on-platform access to detailed user activity logs for tracking and investigating user activity. And we’ve made sure that it all scales to tens of thousands of users per customer.

So that’s just a few of the dozens of enhancements we made in this release—a great way to close out 2011. I’m looking forward to keeping you up to date as we go into the new year!