You can now integrate Risk I/O with the Veracode static analysis tool

Following our recent integration with Portswigger’s Burp web scanner, our development team has added another vulnerability assessment tool to Risk I/O. Integration with Veracode static analysis is now available!

If you use Veracode to scan your applications for security flaws, you’ll be happy to learn that you can now plug it into Risk I/O to manage and monitor the vulnerabilities that Veracode identifies. You can also use Risk I/O to pull in scan data from other vulnerability assessment tools, and generate reports with intelligent remediation right within Risk I/O without juggling multiple tool interfaces. To add the new Veracode connector to your account, simply go to the Connectors page within your instance of Risk I/O. You’ll be seeing Veracode scan data in your account within minutes!

Are you a Veracode customer but haven’t given Risk I/O a spin? Head over to our website and create a free account to start managing and monitoring your vulnerabilities!

We’ve been hard at work making sure Risk I/O is a flexible and fast platform for managing vulnerabilities and defects for our customers. One of the most used features has always been bulk editing of assets. By prioritizing and tagging assets in large quantities, our customers are able to quickly create meta data describing their environment. This results in very customized prioritization, views and reporting of their vulnerabilities.

With our latest production build, our customers can now apply this mass amount of meta data to their vulnerabilities as well. With a quick search and select, you’re able to edit hundreds of vulnerabilities in a matter of seconds. There are more use cases for this than we could pretend to imagine. Rather than try to spell them all out here, we decided to post a short video of one example below. Take a look and then login and try it for yourself.

Of course if you don’t have an account, you can always sign up for free. We’d love to hear how you are using custom fields and meta data to manage your vulnerabilities. Leave us a comment or send us an email at hello@risk.io to fill us in.

Just a quick fun post. Happened to catch this episode of Arthur this morning during the kids breakfast and it sadly reminded me of our industry. One of the big problems in justifying security is proving a negative. In other words, we weren’t hacked so the controls I’ve implemented must be the right ones.

Apparently ‘bad luck’ has the same challenge.

Last week I had the pleasure of delivering a keynote presentation at the IANS Twin Cities Security Forum. Having been involved and participated in IANS events in the past I knew what to expect. They always do a great job with their Security Forums with a very unique format. Probably what I like the most about these forums is the amount of candid information sharing that goes with them – something I’m a big advocate of and what a lot of my presentation was about.

I posted the slides on Slideshare and embedded them below, however; due to the format of the talk there’s not a lot of content within the slides themselves. To give you more context as well as summarize the topics even better than I could, I’m posting a number of references to concepts I spoke about within the keynote. Some of the concepts are simple and easy to grasp while others border more on specific use cases and are a bit more abstract.

Happy Reading!

References & Credits – GO READ THESE

• A good series of blog posts by Scott Crawford of EMA on Data Driven Security
• Post from Josh Corman on HD Moore’s Law
• Our own post on Traffic Signal rankings and the subsequent comment thread on vulnerability prediction
• CVSS and the Base Rate Fallacy by Jeff Lowder on the SIRA blog
• Security Trend Analysis with CVE Topic Models
• Gunnar Peterson‘s Information Security Debt Clock
• The New School of Information Security – a must read and topic primer
• Ted Talk – Doctors Make Mistakes, Can We Talk About That?

Hot on the heels of launching role-based access control which allows you to control who has access to what in Risk I/O (all the way down to the vulnerability level), we have added integration with a new vulnerability assessment tool. (Drum roll please…) We are happy to announce that integration with the Burp Scanner is now available in Risk I/O! For those not familiar with Burp, it was recently voted #1 in the web scanner category on SecTools.

PortSwigger Web Security's Burp web scanner has become the latest vulnerability assessment integration available in Risk I/O.

With this integration, you can pull in all your latest web application vulnerability scan data directly from Burp and aggregate, correlate and rank them across your security vulnerabilities and defects. Combine this with our bug tracking and trouble ticketing tool integration, asset tagging, custom fields, scoring, data mining and metrics such as benchmarks, and Risk I/O is now the only vulnerability management needed to identify, prioritize and remediate your security vulnerabilities.

If you currently use Burp to test your web applications, then head to your Connectors tab to integrate your Burp Scanner with your Risk I/O account. Not a Risk I/O user yet? You can sign up for a free, complete version on our website.

We’ll be adding additional integrations to our list in the near future, and we welcome your feedback on this and other functionality you’d like to see added to Risk I/O.

Red, Yellow, Ugh…

I have been frustrated by the state of prioritization in security for several years. I recently wrote about how a data-driven approach can help prioritize remediation when there are a large amount of issues to contend with. It seems that much of the industry got together years ago and decided we could drop millions of issues into buckets of red, yellow and green. Simple. Now all I have to do is start with all the red issues and fix those right away, after all they are RED! The problem with this approach when you dig into the issues is that prioritization can be complex and include a lot of different factors. Adding to the complexity, those factors are often different from organization to organization. I am all for breaking things down to their simplest parts but doing so by obfuscating the complex factors that go into this, NOT eliminating them.

Information Security Needs a Decisioning System

Lets start with a seemingly simple example from a world I know well.

What factors should we know about a defect or vulnerability to help guide how we prioritize remediation? Here are a few things directly off the top of my head…

• Exploitability
• How easy is it to exploit this vulnerability?
• Are there publicly available exploits through Metasploit, Core, ExploitDB?
• What is the access vector? Does it require a multi-vector attack? Is it behind authentication or an additional control thus reducing the attack surface?
• Asset Affected
• How do we value this particular asset?
• What type of data is stored or processed by this asset?
• Is the asset part of a larger system (see Business Process Affected)?
• Are there specific confidentiality, impact or availability requirements tied to this asset?
• Are there compliance requirements or additional SLA’s for this asset?
• Network Location
• Is the vulnerability/asset publicly available?
• Does it sit within a DMZ or core network?
• What additional assets or systems can a threat agent access from here (see Multi-Vector Attacks)
• Business Processes Affected
• Is the asset above part of an important business process?
• Does exploiting this vulnerability interrupt or compromise this process? (CIA)
• Number of Users Affected
• How many users are affected by an exploit of this vulnerability?
• Is the attack directly against users of the application?
• Discoverability
• How easy is it to discover this vulnerability? (through automated tools, specialized skills, etc)

There are likely several more including some unique to your company but lets use this quick list for brevity sake.

A Simple Example

So lets apply this criteria to a single example.

Vulnerability: Persistent XSS on public web site www.foo.com

• Cross Site Scripting issues can vary quite a bit but we’ll call this one trivial to exploit. While there isn’t a publicly available exploit as this is a custom web application, it can be exploited with a small amount of skill and a browser.
• www.foo.com is our public facing web site. It doesn’t process much data and mostly serves as informational. It’s important for our sales, marketing and public relations.
• Our public site is available directly and not behind authentication. There are several systems within the DMZ that can be accessed from www.foo.com. Some of these systems include processors of “confidential” but not “sensitive” information.
• The primary business processes associated with the site is public relations and marketing.
• Our public site receives millions of unique visits per month and the exploit of this vulnerability can directly attack these visitors. The payloads can vary but assume the worst.
• Discovering this cross site scripting issue is trivial and can be done through automated tools or manually via a web browser.

In this simple example we start to get a feel for how serious or not this vulnerability is. Just by running through this off the cuff list of decisioning factors I can see how this can result in an attack against a large amount of our users and the likelihood is fairly high based on the lack of skills needed to both discover and exploit this defect.

We Can Be More Quant Than This

Have I over simplified this? You bet. There are likely several other factors that drive prioritization here, including competing with other priorities (opportunity costs). I’ve also simplified this down to a qualitative decision but there’s no reason why this can’t be more quantitative. My point here is even a short, simple off the cuff list can bring a lot more relevant factors to my remediation priorities than red, yellow and green.

I’ve just returned from RSA, BSides and Metricon and thought I would pen a few of my thoughts while they’re still fresh in my mind.

On Monday I had the privilege of participating in a panel on Data Driven Security at Metricon 6.5. Scott Crawford moderated and has a great blog series on data driven security. It was an interesting group of backgrounds between myself, Mark Clancy, Chris Eng, Micha Govshteyn and Martin McKeay. Some of the participants were further along in their analysis of the data they were collecting while some had a volume of data (Akamai) most of us could only dream of. While I don’t think there was anything too surprising that transformed from the panel, the final question from Russell Thomas was the exception. Russell asked, and I’m paraphrasing, if we had one new open job req we could hire for right now, how many of us would hire someone dedicated to this topic. What surprised me the most wasn’t the question but roughly half the panel including myself answered yes.

We are very dedicated to data-driven security and have very specific use cases that we are building into our product. I went in to Metricon worried that security intelligence would be more talking about SIEM or the various ‘State of the Industry’ reports published by several security vendors. While I don’t have an issue with those solutions and actually appreciate several of the published reports, utilizing big data in security can and should go well beyond these. One useful way we see to use this data as part of a decisioning system is through prioritization.

For example: if I have one million identified security risks, realistically I have little chance of remediating everything. How do I decide what’s most important? As a service provider that has visibility across many organizations, we can take into account a lot of different factors to help determine when someone becomes a ‘target of opportunity’ including postures across these issues as well as threat data across both public and private networks. This, of course, is one of MANY examples on how you can feed security and operational data into a system that helps make smarter security decisions.

While I was pleasantly surprised to not be talking about SIEM at Metricon, walking the show floor at RSA brought all my fears back and then some. Big Data was a huge topic at RSA but as mentioned by the guys at Securosis, there was a lot of repurposing of existing products like SIEM. As I mentioned to a coworker as we walked the floor, “it’s like Vegas minus the fun.”

RSA aside, there are plenty of examples out there of using large amounts of data in the real world to aid decisioning systems. One shining example is what Preston Wood and the team over at Zions Bancorporation are doing. They have taken security intelligence way beyond SIEM. Imagine taking these capabilities and setting them atop data that Akamai or other large service providers may house. Additionally, if you haven’t seen the post by Ben Sapiro yet, go check it out. While it’s not focused on big data in security, he talks a lot about analytics and at the end of the post lists a LOT of real world metrics anyone can start with to improve their program.

A lot of Risk I/O users rely on bug tracking and trouble ticketing to track their remediation workflow including status, ownership and due dates. We built Risk I/O to integrate directly into these solutions so our customers would never have to leave while tracking to close. That’s all well and good, but we have others who prefer not to use bug trackers or trouble ticketing or simply don’t have all of those resources in-house. Well I’m happy to show how this can be done now all within Risk I/O.

For awhile now we have had both custom asset tagging and custom fields. These are often used to collect data for tracking remediation such as status, ownership, expected remediation dates, SLA’s, etc. Last week we launched role-based access that allows you to control who has access to what down to the vulnerability level. In addition to our Standard and Admin roles, you can now create “tag-based” roles to control access within your Risk I/O instance.

Here’s a simple example:

We have several development teams each that own different applications and the bugs and vulnerabilities associated with them. We can tag each of those applications in the assets tab with these development teams. From there I can create a new role allowing for read-only or read-plus-write access to any assets and vulnerabilities that have that tag. I can also now create new users and give them the appropriate role, allowing them to work directly within Risk I/O to help manage remediation workflow.

We have focused relentlessly on simplicity and flexibility. With our new access control features I think we’ve found a great balance to allow you to keep it all within Risk I/O or use the remediation management tools you already have deployed in your environment.

…and since a picture is worth a thousand words, a short how-to video must be worth even more.

Secure. I don’t think it means what you think it means.

Back in my days as a CISO or even previous to that in various practitioner roles, there were two frequently asked questions by executives and management.

1. Are we secure?
2. How do we compare to $x?

Let’s start with the first question. Security is not binary. That is, it’s not a state of on or off. Security in it’s entirety should be viewed more like 256 shades of grey. It’s not a question of whether or not you are secure but rather how secure or insecure you may be. There are a lot of controls and decisions that go into that state, each of them pushing your state to more secure or less. Each of those controls and decisions have a lot of trade-offs.

What I’m really getting at, is that it’s a bogus question. But you can’t really respond that way so you take it with a grain of context and politely answer.

Now on to the second question, one that I find more interesting and more meaningful. A common concern amongst management is how they line up with the competition. If your security falls behind that of your competition they worry they will be burned by this and look bad. On the other hand, if they are way ahead of the competition, why? Sure it gives some level of comfort but are they spending too much on security? Could those dollars be better spent elsewhere? Ahh trade-offs again.

There may be many reasons why you need or should be ahead of your competition in securing applications and infrastructure. Perhaps you’re working in an infosec lagging vertical where “keeping up with the competition” means you’re a target of opportunity on the Internet. Being a target of opportunity can come down to how you stand up against a particular vulnerability versus those of your neighbors on the Internet or Google’s search index. Regardless of reason, you’re going to need data to back you up.

Measuring what’s important to your organization, industry and management is the best way to answer these questions. Include not only metrics around these but also benchmarks to compare how you are doing versus your vertical, the broader industry and internally. Pick and choose your metrics carefully and make sure they pass the “so what” test. You can benchmark in an automated manner in some cases as well as loosely through industry organizations such as the ISACs and other areas where your industry gathers.

You can now pick and choose which vulnerability attributes are displayed and which are hidden.

Just a quick post to give you an update on one of our newest features. A few months back we wrote about custom fields in Risk I/O and how to add your own data and metadata to your vulnerabilities and assets. Today I’m writing about taking this customization to the next step.

We recognize different people within your company are going to need to see different views of your data, so why not give them what they need? With our latest release of Risk I/O vulnerability management not only can you create custom attributes and meta data, but also create completely custom views of this data within the interface and reports. By simply checking a box, you can choose what data is displayed and what data is hidden within your vulnerabilities.

Combine these custom data views with your custom attributes, asset tags, and our faceted search and you have a very personalized and dynamic view into your security data.

For our current customers, check out this new capability within the vulnerabilities tab. Don’t have an account? Sign up for a free version!