Tag Archives: security

The Time to Pay Attention to Application Security is Now


June 12, 2012 By Tim O'Brien

When we announced Insight for CI a few weeks ago, our message was simple “Get Proactive about Security with Insight”. A few months ago, when we introduced the Repository Health Check in Nexus Professional, we had a similar message about licensing, “Lead or Be Led to OSS Compliance”. For months we’ve been making the case that the time to worry about application security is now.

Another thing we’ve been saying is that it is our responsibility, as developers, to start paying attention to security vulnerabilities, and if we don’t take responsibility for application-level security, someone else will impose this requirement on us…

…and that’s exactly what’s we’re seeing both in the EU’s reform of Data Protection Laws and as the US Congress responds to the latest data breach at LinkedIn. Now, who knows what sort of regulations we’re going to see in the coming months, but one thing is sure, the fact that lawmakers feel compelled to act is proof that we’re not doing enough as an industry to address security.

The best security is a layered approach: multiple levels of network security, security policies for production resources that limit access to individuals that need it, secure password policies, and application security. Sonatype’s focused on that last item, application security, and our approach focuses on the components you assemble to create your applications. If you develop software today, you understand that much of your work is spent creating applications that sit atop frameworks like Spring and Hibernate. It isn’t enough for your own software and infrastructure to be secure. These days, you need to account for vulnerabilities in your dependencies.

And, again, this isn’t operation’s responsibility. Security is a shared responsibility across both development and operations. This is something that developers need to take ownership of. While we’ll probably never know how sites like LinkedIn, eHarmony, and Last.fm were compromised, there’s a good chance that some of these sites were compromised via known vulnerabilities in outdated components. Components like Tomcat or frameworks like Struts are among the list of artifacts that have known problems.

Don’t get hacked because you didn’t upgrade to the latest version of Tomcat or because you happened to be using some ancient version of Spring with a known vulnerability. If you are consuming artifacts from Central (and if you are a Java developer, you probably are), you need to start using Nexus Professional to keep track of your dependencies. If you are using Hudson or Jenkins, take some time to evaluate Insight for CI.

Get proactive about Security with Insight


May 25, 2012 By Tim O'Brien

There’s a shift in the way organizations are thinking about security, and This article in Infoworld “IBM: Security execs move more toward active risk management” is exactly what we’ve been talking about. Here’s the quote that stood out:

“Nearly two-thirds of security leaders say their senior executives are paying more attention to security today than they were two years ago, due in large part to media attention.” and “60 percent of the advanced organizations named security as a regular boardroom topic, compared to only 22 percent of the least advanced organizations”

Instead of simple three-tiered applications following a standard Apache -> Tomcat -> RDBMS pattern, today’s scaleable applications involve a portfolio of technologies: Redis, Hadoop, real-time BI systems, integration with 3rd party APIs, Node.js, with more and more companies adopting a portfolio of technologies. It is becoming increasingly difficult to draw a line around a particular application and evaluate security vulnerabilities in isolation.

Today, you need to have your security group sitting next to you evaluating a complex application as it evolves…. but, back to the article, it isn’t just the evolution of technology that is making security a focus for business, it is a series of high-profile, embarrassing data breaches. A CEO that wouldn’t have thought very much about security technology a few years ago, sees what happens to a Stratfor or Global Payments and they understand the risks. Data security is front and center in the news, and a data breach can be a business-ending event.

So get out in front the problem. Start tracking your application dependencies and identify known vulnerabilities with Insight.

When we launched Nexus Professional and integrated Sonatype Insight information we gave you the ability to keep track of your overall exposure to security vulnerabilities. Your IT organization gained a window into the intersection of known vulnerabilities with the artifacts you download from Central. That was a good start, but the real benefit is Insight for CI. We launched Insight for CI this week, and it’s the tool you’ll want to use to address security vulnerabilities in specific products. If it is your responsibility to keep up with security, one of the easiest ways to take a more proactive approach is to start using Insight for CI to track your application’s dependencies.

Click here to get started with Insight for CI. It works with either Hudson or Jenkins, and it covers both license and security information.

The OSS projects you depend on take security seriously. Do you?


April 6, 2012 By Tim O'Brien

When we published our executive brief on security a few of you immediately reacted wondering if we were calling OSS insecure, we are not. OSS is both secure and increasingly awesome. What we’re trying to call attention to is the disconnect between OSS security and the ways in which it is consumed. It is clear from our survey of the data that many organizations are just not paying any attention to a constant stream of critical security updates. As a result these organizations are exposed to security flaws that have already been addressed by these projects.

Important projects, projects like Apache httpd, Apache Tomcat, JBoss, or Spring all have something in common. Each of these projects has a formal security team and a process for addressing security flaws. The presence of a security team in an OSS project is a signature of how seriously a project takes vulnerabilities. If you are evaluating projects for security, you should evaluate a project not by the number of vulnerabilities you identify with a tool like Nexus 2.0, but on the process a project uses for addressing security risks.

Just because a project has a large number of vulnerabilities doesn’t mean this project is insecure. Take, for example, Tomcat.

Continue reading →

Wayne Jackson’s Presentation at RSA 2012: An Overview of Insight


April 2, 2012 By Tim O'Brien

At RSA 2012, Wayne Jackson gave a short presentation focused on the security aspects of Sonatype Insight and the newly released Repository Health Check in Nexus Professional. This five minute overview gives you a sense of the magnitude of the problem we are trying to solve.

Here are some of the highlights from Wayne’s presentation followed by the video of his talk and his slide deck:

  • “The benefits of ‘many eyeballs’ in open source does create better software but you can only leverage that if you know about it. That’s particularly troubling in the context of the fact that more than 80% of the modern software application is [comprised of] open source and the components that are used to build those applications are surprisingly complex.”
  • “That complexity is compounded by the fact that when issues arise their implications are viral and the big problem is that when those issues are resolved in the root components the solutions are not [similarly viral] . Spring Beans 2.5.6 compromised 1400 open source components and God knows how many downstream applications. When Spring Beans 2.5.6 was fixed, none of the others were fixed.”
  • “You can imagine the ripple effect of compromising open source. And the combination of things like the lack of notification infrastructure and the complexity of open source componentry is how you get situations like this. 6,982 organizations including the Dept of Homeland Security and several financial institutions are still using a 3 year old crypto library with an “as bad as it gets” Level 10 flaw that has known exploit code.”
  • “Sonatype is creating an extraordinary infrastructure for finding out everything knowable about a given component. So that when flaws are discovered, we can know and we have the ability to deliver that knowledge into the tools that developers are using every day. This family of technologies is called Insight.”
  • “Critical to that is the Central repository. Central houses hundreds of thousands of components from nearly every open source project in the world and it is used by tens of thousands of organizations.”

 

 

 

We’re a Java shop, we’re not going to get hacked…


March 27, 2012 By Tim O'Brien

This article is another in a series of articles associated with our Executive Brief. To access the executive brief, “Addressing Security Concerns in Open-Source Components,” visit www.sonatype.com/securitybrief. You can follow the conversation on Twitter using the hashtag #OSSsecurity.

I just wanted to reiterate the key point of yesterday’s security brief which is: “You and everyone else in the world are likely downloading vulnerable components.” If you don’t believe me, then take a look at this graph:

First, note the logarithmic scale – downloads over an entire year. Then, take a look at the left-side of the chart. See anything familiar? GWT, Spring, Struts, CXF, Xerces? If you use these components, you should try to identify which versions are affected by widely known CVE vulnerabilities. It’s that simple, if you use these components it would be a good idea to browse the CVE database, or to take a look at Nexus Professional’s Repository Health Check.

Really, attackers aren’t going to go to the trouble…

Developers, you might be thinking, “an insecurity in GWT or Xerces, who’s going to trouble of doing that much research? Who’s really going to hack into Megabank via some obscure AJP vulnerability in a Tomcat connector?” And if you are asking these questions as a way to shuffle this all under the rug, I understand. There’s enough work in the pipeline already and you don’t need another thing to worry about. As developers we’re not going to turn into security professionals overnight, but we can start using tools like Nexus Professional to help identify vulnerable components and isolate us from deploying known security problems to production.

It isn’t the likelihood that someone will hack GWT that is the issue, it is the idea that deploying any code with a known security vulnerability needs to be identified as a disqualifier. The idea that if you get compromised and someone realizes that it was a known vulnerability (for years): developers need to be motivated to avoid this embarrasing situation. The point I’ve tried to make on this blog is that we (developers) are not really paying attention to this problem because we just assume that it is someone else’s problem.

Ignoring Security: It isn’t a question of if you’ll get hacked, it’s when

The issue of data and systems security has repeatedly been front-page news time and time again over the past year. Groups like Anonymous and Lulzsec made a public sport in 2011 of hacking into serious organizations and making every effort to embarrass and ridicule them for lax security. The last few years have been pretty embarrassing years for a lot of security departments at large corporations and a few governments. 2012 promises to be even more active with McAfee predicting the reorganization of Anonymous, but focusing on these high-profile, news-generating events ignores the scope of the problem. It isn’t about volume, it is about your exposure to this risk.

I’ve seen some recent attacks in action. Attacks on both Java-based web architectures and PHP-based architectures. While it’s true that PHP-based applications present a much larger and more insecure surface area to attack, it has to be said that Java-based web applications and .NET present a much more lucrative target. An attacker can compromise all the two-bit Drupal instances in the world without stumbling upon anything worth intruding, or they can focus on a multi-month strategy of social engineering and direct attacks to compromise one the Global 100 financial institutions that are downloading insecure dependencies every day.

Welcome to the Security Theater

If you are banking on the fact that attacking Struts 2 or Log4J is just too esoteric for most hackers to do, you are participating in something Bruce Schneier calls Security Theater, and that’s really what I’m taking away from this study. Some of these institutions are so invested in presenting an image of trust and security that they will spend millions on Super Bowl ads and marketing efforts to purchase customer trust. But, at the end of that day they continue to download vulnerabilities. It doesn’t match up, we need a change of culture in development and security needs to be top of mind.

It’s time for developers to start taking security seriously. You could choose to be proactive about the problem and use tools like Nexus Professional to automatically correlate CVE vulnerabilities from CERT with your artifacts, or you can wait until someone replaces your company website with a funny picture and lose the ability to download artifacts from Central altogether. The choice is yours.