Category Archives: Security

Good Hygiene Should be a Foundation of Application Security


June 19, 2013 By Ryan Berg

Over the past week, there have been several articles, blog posts and security institutes discussing the latest release of the OWASP top 10 and now I think the time’s right to join the discussion.

All this chatter doesn’t come as a surprise to me (and likely others) who have been actively involved in the application security business for the past decade. I would argue that the relative constant nature of the top 10 (or at least the top 5), can be interpreted 2 ways. It can be as much of an indicator to poor secure development practices as it can be interpreted that we’ve gotten better at finding the top 5 security issues in the first place. Depending on which day you ask me, I can fall on either side of the line.

For me, one of the more interesting aspects of the latest top 10 is what’s changed. In this case, one of this biggest (and depending on your involvement with the top 10 the most controversial) is the introduction of A9, using components with known vulnerabilities. On the surface, this seems to be a no brainer, some may argue whether something so basic even belongs on this list since it seems so obvious. But the reality is most people simply don’t even know they are using components with known vulnerabilities. . This basic security blocking and tackling is missing from many secure development initiatives (trust me I’ve seen my fare share and this has never been a focus).

All of this discussion surrounding basic security blocking and tackling reminds me of some guidance my son’s teacher gave him and his classmates at graduation day. As you can imagine (and maybe you have heard the same), my youngest child just recently moved from grade school to middle school and his grade school teacher spoke to all the parents on graduation day and reminded the kids (then mostly 10/11 year olds) how important good hygiene is when children are maturing. He reminded us of the obvious but yet a thought that can be so easily forgotten. Reminding us that peers and teachers appreciate a diligent approach to hygiene basics. This approach is like OWASP adding A9 to a security threat list. It’s easy to take these basic principles for granted, but sometimes we just need to be reminded.

Much like you don’t want to start your day without the basic elements of hygiene; you shouldn’t start your application’s journey based on a bad foundation Which is why I’m happy to see that something that on the surface seems so basic is getting the needed attention. Recognizing not to use components with known vulnerabilities starts the right security discussion. I am glad OWASP recognizes the need for basic hygiene.

It may seem ironic that arguably one of the most well-known security lists for web-based vulnerabilities in the world includes language to not use components that are vulnerable.  I would argue (and I welcome the argument) this is one of the most important points on the list and one everyone should be aware of. I consider this one of the foundational elements of any secure application development initiative.

Having spent the last decade focused on application security, I can share many lessons learned but one of the biggest lessons I’ve learned is how security professionals can have the greatest influence on development. It’s not as difficult as one may think.  It starts by delivering solutions that fit the “practice of the practitioner”. What does this mean? It means not only delivering tools that work within the existing developer ecosystem, almost all would argue they do, but it also means delivering the functionality most useful to that group scaled by their capacity to effectively use it in the first place. I would argue most do not fill this last piece.

One of the benefits of working with Sonatype now, an organization that understands modern software development, is that we aren’t just another security company building security tools for security people. We are an organization with a passion for both security and development and a mindset geared towards helping organizations make sure they don’t leave the house without at least brushing their teeth. A security company that absolutely understands the importance of A9 and good hygiene. Do you?

 

OWASP Recognizes Component Security


May 1, 2013 By Mark Troester

The tide is turning. OWASP A9 is more recognition that modern applications are constructed primarily of components. In our recent survey of 3500 developers, managers and architects that use open source, 86% of participants noted applications built today are at least 80% open source. OWASP A9 highlights the potential problems associated with the widespread use of open-source components with known security vulnerabilities in modern-day application development.

Jeff Williams, CEO of Aspect Security and a long-time member of OWASP puts a fine point on the challenge…

  • “The performance, time and cost advantages of agile, open-source development comes at a price – you have to ensure the components you use are up-to-date and secure.”
  • “Unfortunately, it’s not trivial to figure out what components your applications are using, and even harder to figure out which vulnerabilities apply to those components.”
  • “The new OWASP Top Ten has detailed recommendations for locking down your software supply chain, and Sonatype’s tools make them much easier.”

So why should managing and securing components be a priority? Simply put, components have become a rich attack vector because of their pervasive reuse. Reuse that makes it easy for hackers to propagate their attack across multiple applications and organizations.

OWASP provides a set of best practice recommendations, including:

  1. Identify the components and their versions you are using, including all dependencies.
  2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.
  3. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable license.

Sonatype CLM goes beyond these recommendations and is designed to manage the entire component lifecycle. The CLM integrates security, licensing and quality information about the components directly in the tools that developers use (repository manager, IDE, build/CI environment), provides early and quick remediation capabilities, and continuously monitors your production applications.

For more information on recommended best practices, check out the 7 steps to Good Component Practice section (it’s at the end) of the 2013 Sonatype Survey results.

You can also check out the press release announcing OWASP A9.

Improving Software Quality Using Component Lifecycle Management with Jenkins


October 24, 2012 By Emily Blades

A few weeks ago, a few of us joined the Jenkins community at the Jenkins User Conference 2012 in San Francisco. Our presentation “Improving Software Quality Using Component Lifecycle Management with Jenkins” given by Manfred Moser, was very well attended and there seemed to be a lot of interest. A video of our presentation has now been posted here and you can download the slides as well.

Have Jenkins (or Hudson) up and running, and want to give Insight for CI plugin a try? The plugin is available in the plugin center and easy to install and configure. — Just add a post build step and configure it to scan (e.g. your build output war file). Get the plugin.

Summary and component results are completely free and will give you a very good indication of the security and license issues (or better their absence) of your software. We’ve even got you covered for manual scans – have a try with Insight App Health Check.

That’s Billion with a B: Is Java Having an “Outlook” Moment?


September 26, 2012 By Tim O'Brien

I’m a broken record, I know, but every month that goes by we get more and more news that suggests that Java developers (and the companies that support Java) are slow to wake up to these threats.

You remember Outlook, maybe some of you are unlucky enough to still use Outlook, but for Microsoft, Outlook was a multi-year security embarrasment. From 1999 to around 2005 it felt like Outlook was having a security vulnerability every other minute. Back then, there were so many that, in technical circles, Outlook became something of a joke to anyone who valued security. In fact, you could make a compelling argument that Outlook’s multi-year security challenges were the weak point in the armor that provided an opening to Google’s GMail (and once you’ve decoupled from Outlook, why not try that Macbook Pro you’ve been eyeing).

If this trend in Java doesn’t stop – if we don’t stop experiencing billion-user, level 10 CVSS security exploits every other week in Java – all the inertia in the world won’t stop a shift to another language or another platform. Check out this news that just crossed the wire yesterday from Softpedia:

Continue reading →

Remember when Hackers Ignored Java? Those days are over… FBI Hacked via AtomicReferenceArray


September 4, 2012 By Tim O'Brien

Earlier this year, I wrote a piece about how it was only a matter of time until Java became a popular vector for attacks. The response to that particular article was a lot of fun for me. Let’s just say a number of high-profile, open source Java folks jumped up and down and shouted FUD. My conclusion: just talking about security to developers earns an almost immediate negative reaction. They don’t want to think about it.

I guess this makes sense, developers generally don’t want to have to deal with security, and me bringing up the fact that many of the systems you are working on may be vulnerable to attack isn’t something you want to think about. I understand, you have enough to worry about: looming deadlines, that junior programmer you just hired who isn’t pulling his weight, a continuing fight with operations over who “owns” the deployment process. Work is hard, there are certainly not enough hours in the day, and if you can ignore security, why not? I mean, it’s Java. Who’s going to attack Java?

AntiSec, that’s who. They aren’t just going to compromise your machines because you failed to update Java, they are going to grab your data, parade it around the world for all to see, and then make a few political statements at your expense. And, I’ll bet the FBI wishes that they had installed this February 2012 security patch from Oracle. If they had done so, they’d probably be having a much better day today.

“During the second week of March 2012, a Dell Vostro notebook, used by Supervisor Special Agent Christopher K. Stangl from FBI Regional Cyber Action Team and New York FBI Office Evidence Response Team was breached using the AtomicReferenceArray vulnerability on Java, during the shell session some files were downloaded from his Desktop folder one of them with the name of “NCFTA_iOS_devices_intel.csv” turned to be a list of 12,367,232 Apple iOS devices including Unique Device Identifiers (UDID), user names, name of device, type of device, Apple Push Notification Service tokens, zipcodes, cellphone numbers, addresses, etc. the personal details fields referring to people appears many times empty leaving the whole list incompleted on many parts. no other file on the same folder makes mention about this list or its purpose.”

This is from the AntiSEC statement regarding this breach (inappropriate language).

So what do you think is happening to the person responsible for security right now? Do you think he’s able to say, “you didn’t tell me that security was a priority?” or “It wasn’t my responsibility to check for JVM updates from Oracle?”. No, he’s likely being replaced, if not immediately then his management team is leading him on until they can identify someone who isn’t going to generate front page security failure.

What’s next? Well, the JVM is now front-and-center as far as security vulnerabilities go these days. Just last week you were all asked to turn off Java 7 until a suitable patch was issued (which is a ridiculous request BTW, that’s like asking us to stop working for a few days). I predict that as Java continues to develop as an attack vector – libraries are the next fun vulnerability. I know many of you don’t want to hear this, but it’s true. Your web frameworks are next, prepare yourself with Sonatype Insight, or start coming up with excuses when your systems are the reason for front page security fail.