The Lens

Are You Scanning Often Enough?

Mon, 27 Jun 2011 19:34:04 -0800

One of the metrics collected and shared in the Vulnerability Management Benchmark is Average Days Since Last Scan, otherwise known as scan frequency. It's available for free as part of the Basic package. This metric was a fairly surprising one for me to watch develop in the Benchmark community. Over about a decade of working with customers on VM programs, I can't help but have developed my own impression of how often organizations run vulnerability assessment scans in their environments. Most organizations have a monthly scan cadence; some work towards weekly or even daily, and a few outliers work on a quarterly schedule. Based on this anecdotal evidence, I had assumed that average scan frequency would end up being around 30 days. I was definitely wrong. Here's the Average Days Since Last Scan scorecard for the last six weeks:

You can see that the line has been hovering between 53 and 70 days, ending up at 67. I suspect there are two things happening here that have pushed the average up.

The Best Intentions

We all know how our best intentions sometimes don't work out. Well, the same can be true of an organization. It may be that the Vulnerability Management program specifies monthly scans, but delays happen, outages occur, and assets don't get scanned. It may very well be that what we're seeing in this Benchmark metric is the reality of life in the enterprise. A plan for 30 days comes out with an average of 60. It might be that planning for a 15 day turn around would come out closer to 30.

Outside Influence

In the Basic Benchmark package, we're rolling up everything contributed. This data set includes, and doesn't distinguish between, external and internal scans. It may be that we're seeing the influence of an externally mandated cadence being expressed in this metric. PCI requires quarterly scans by an Approved Scanning Vendor , and that distribution of ASV scan schedules may drive a schedule of 'preparatory' scans, which in turn drive the average up (more scans occurring, but less frequently). This trend, however, is really only evident over a longer period of time. Finally, there' s a general push towards more continuous monitoring, driven in part by the Federal government. As this trend continues, we'll likely see more frequent scans across the board.

Of course, you should be wondering how your organization compares to the Benchmark. If you want to find out, join the Vulnerability Management community. Remember, the community isn't just nCircle customers. If you're using a different vulnerability scanning tool, it's still completely free to see your metrics compared to the Benchmark. When you want to drill further into the details, compare and slice in different ways, then the Benchmark Premium package is available as a simple upgrade.

I haven't talked much about the other Benchmark Communities, but they're available as well. It might be interesting to join the Configuration Auditing and Vulnerability Management communities to compare change rate in your environment to trends for average risk, but that's a completely different blog post.

Remember, keep in touch with the VM Benchmark on Twitter: @BenchmarkVM

The Crowd is Dead, Long Live the Crowd

Tue, 07 Jun 2011 11:50:00 -0800

Until now, the information security community has relied on rumors, conversations and sparse breach reports to develop some kind of consensus on what vulnerability management metrics should look like. The metrics themselves haven't been hard to come by, but how do you know if you're doing well or not? How can an organization truly assess the performance of their vulnerability management program without an industry standard benchmark that provides a comparative metric for the rest of the world?

At the RSA show in February we introduced nCircle Benchmark, giving the security community the first product that actually allows you to compare your metrics to those of your peers. Since then, we've added new Metrics Packs, new capabilities and most importantly hundreds of new community members. Those of you who have already joined a benchmark community know what the combined benchmark results look like. For those of you who haven't joined yet, I'm going to give you a preview of the Vulnerability Management Benchmark right now. This is the last six weeks of average host risk scores for the Benchmark community.

For this Benchmark metric we're using the industry standard Common Vulnerability Scoring System (CVSS) base score. We've calculated the average of the aggregate CVSS Base scores for each contributed asset and trended that data over six weeks. There are hundreds of thousands of assets included in this benchmark, and it's growing with every new community member.

If you're wondering how your risk scores compare to those of the Benchmark, you can join the community and see this scorecard with your data included for comparison for free as part of the Basic package. There is no other way to compare your risk score to your peers, and there's no reason, budget or otherwise, that you shouldn't be able to speak authoritatively to your peers, management, and board about how your Vulnerability Management program is performing. This data is only available from nCircle Benchmark. You don't even have to be an nCircle IP360 user to join and contribute. If you're using Qualysguard or Rapid7, you can still join the Vulnerability Management Benchmark community (and lots of you already have).

The Basic package includes scorecards for average risk score, average scan frequency, vulnerability distribution by platform and vulnerability distribution by severity. You'll see more of the Vulnerability Management Benchmark here in the future, but you can see it for yourself today, including the comparison of your metrics, by joining the community.

Welcome to a world in which you know where you stand.

Don't forget that Benchmark isn't just for Vulnerability Management. There are communities for configuration auditing, endpoint security, anti-virus, identity and access management and more. Each of these has a Basic package that's available free of charge as well. If you like what you see there and want to drill into the details or create your own scorecards, there are Standard and Premium packages too. And you can keep up with the VM Benchmark community on this blog and on twitter @benchmarkVM.

CCM 5.10 and Cyber-Ark Integration

Thu, 26 May 2011 14:27:21 -0800

We're thrilled to announce that Configuration Compliance Manager version 5.10 is available now. While there are a whole bunch of useful features in this release, the integration with Cyber-Ark's Application Identity Manager, part of their Privileged Identity Management Suite, is especially interesting. This new feature allows joint nCircle/Cyber-Ark customers to leverage their existing secure credentials management infrastructure for configuration auditing and policy compliance with CCM. The configuration is simple and quickly facilitates more comprehensive scanning. Here’s a little bit about how it works.

One of the tasks we undertook in CCM 5.10 was to review the scan credentials management screens for usability improvements. We've updated these screens to make adding simple credentials as easy as possible, but support the complexity required by our enterprise customers as well. One of the credential types you can select is now Cyber-Ark.

When you've configured the Cyber-Ark SDK on CCM's Management Server, CCM can retrieve scan credentials from Cyber-Ark at scan time. CCM will also check for and validate the presence of the SDK, so you know it's set up correctly. We also included a test button so that you can actually test the credential retrieval before running scans.

Once you’ve entered the required information and saved the credential, you can use it just like any other credential within a scan task. CCM will dynamically request the credentials from Cyber-Ark as required and will update the credentials if they change in Cyber-Ark. The credentials aren’t stored to disk in CCM at all, providing the maximum security for your credentials possible.

All of this is intended to make the process of obtaining credentialed access to assets in your environment as easy as possible. The owners of those credentials retain complete control over them through Cyber-Ark and CCM gets the access required for the most comprehensive, agentless assessment possible.

Security Through Obscurity and the TSA

Wed, 09 Dec 2009 08:11:15 -0800

ABC news reports today that the TSA screening manual was accidentally posted online with formerly redacted information included.

"This is an appalling and astounding breach of security that terrorists could easily exploit," said Clark Kent Ervin, the former inspector general at the Department of Homeland Security.

It's not hard to conceive of why this is considered a breach, but it really should be. As [information] security professionals it should be extremely hard to understand why the TSA would create a screening process that relies on maintaining the secrecy of the process itself to be effective. First of all, it's very nature (a process that all screeners must follow) means that it's not a secret: all of the screeners know the process by definition. I'm willing to bet that this public disclosure isn't the first disclosure. Somewhere out there is a screener who made a tidy profit selling this very document. And the TSA should have expected that. All that this incident does is level the playing field between the bad guys (who already knew all of this) and Joe Businessman who doesn't want to miss his flight.

In fact, the TSA should have published the process in its entirety publicly to begin with.

One of the points in this article is that the data leaked included instructions for identifying CIA, ATF, and members of congress for alternate screening or no screening at all. First, if I'm a capable terrorist, you've got to assume I can reasonably (visually) replicate these credentials already. Until you have some cryptographically secure ID for these individuals, it's just a given. Secondly, a screening process that has a loophole better ensure that the identification to use that loophole is well secured. But let's give the TSA a little more credit than ABC news does. In fact, if you dig into the document, you'll find that armed Law Enforcement Officers (LEOs) are required to pre-authenticate via a secure network: "they will now obtain a unique identifier code from the TSA via a secure law enforcement network." You can't just walk up to the checkpoint, present an ID and board a flight while armed.

The article also points out that this manual contains a list of items that do not need to be screened, i.e. where to hide things from the TSA. This is a list that could be reasonably assembled by just about anyone who travels frequently. It's a list that can be obtained through observation, and as such it's already not a secret.

I think we all know that the existing airport screenings are minimally effective. Bruce Schneier has some nice pieces on how we might improve them. In the end, the only shocking thing about this breach is that it might have any effect on actual security whatsoever.

The TSA Screening Manual

Images of Credentials

Vulnerability Management Panel Discussion

Mon, 27 Jul 2009 07:13:46 -0800

WhitehatWorld organized this vulnerability management thought leaders panel discussion. I was lucky enough to participate as a panelist. You can listen to the recording here.

Mild mannered company by day ...

Thu, 23 Apr 2009 07:37:24 -0800

... superheros by night, or trade show at least. These guys were close enough to our booth that I managed a snapshot. I'm sure I wasn't the only one, given how proficient they were at striking this pose. I wonder what their super powers are.

Web Applications: The Biggest Risk to the Enterprise

Tue, 21 Apr 2009 20:34:31 -0800

(This post is a taste of my presentation at the nCircle booth at RSA. Come by and see it if this is interesting).

Web application risk is a hot topic these days, but there's something missing from the discussion. Vendors seem to be focused on addressing web application risk in a vacuum. They limit their marketing and products to custom web applications and ignore two things: vendor supplied web applications and what I'll call the dependency risk of web applications.

When you choose to deploy a web application, you're deploying much more than just that web app. There is, of course, the web application itself.

Whether it's custom built or vendor supplied, the web application can be vulnerable to things like cross-site scripting, SQL injection or cross-site request forgery. Think about all the products you've deployed that are managed via a web interface. They're all potential sources of web application risk. But the risk doesn't stop there. That web application has to run on some kind of HTTP server.

The web server itself can be vulnerable to buffer overflows, directory traversal, cross-site scripting (again) and other conditions. But wait, there's more. That web server has to run on some platform, whether hardware or virtual, you've got an execution space that can also be vulnerable. There are a near infinite number of vulnerabilities that might exist on the OS or other applications running the web server itself.

Finally, there's likely a database somewhere on the back-end. It may have sensitive data or may be vulnerable itself or may run on yet another vulnerable platform.

The point here is that scanning just your customer-built web applications or scanning them with a completely separate tool just doesn't cover the whole problem. You can't make good risk mitigation decisions without a clear view of the entire risk context.

Hello Old Friend Moscone

Tue, 21 Apr 2009 07:15:14 -0800

I'm lucky enough to get to San Francisco more than once a year, but for many folks the RSA conference is an annual trek. There are probably a few missing out this year because of restricted travel budgets as well. I walked around about half the show floor last night and didn't see anything outstanding, but there's time yet. I have to say, RSA is the most fun when there are big announcements. Somehow I don't think this is the year for big announcements, but I could be wrong. Heck, continued growth and profitability aren't to be sneezed at these days. In fact, they're downright awesome.

Whether you're a customer, colleague, partner or prospect, stop by the booth and say hello this week.

PCI and Politics

Fri, 13 Mar 2009 08:54:18 -0800

Did you donate to Norm Coleman? Well, your credit card and donor information has been floating around the dark side of the internet. Wikileaks has published evidence of the data breach. The Minneapolis Star-Tribune has a piece on how Coleman may have violated the law by not notifying donors who were compromised.

But this article misses an important point, or rather only touches on it in a single paragraph. Seth Peter, CTO at NetSPI, points out that "[t]he same rigor that a financial institution or big box retailer puts into their credit card collection needs to be replicated on a smaller scale."

How should/does PCI handle 'retailers' who aren't permanent? We don't know for sure how the Coleman campaign processed transactions, but we do know that they were storing card data that PCI requires you not store (security codes). It's not just PCI that makes this requirement, however, but Minnesota state law (H.F. 1758).

In other words, the Coleman campaign possibly violated the law by not notifying donors of compromised data, may be in violation of PCI (with fines?) by storing the data insecurely, and likely violated the law by storing the data for more than 48 hours after the transaction.

That being said, and left to law enforcement, we're left with a question of how PCI deals with transient retailers. The Coleman campaign (though existing longer than most) isn't a permanent retailer, so the PCI lifecycle can't really apply. What does it mean to get an annual audit if you don't exist for the whole year? What would the 2009 QSA audit for Coleman's campaign look like if it's conducted in December? What about ASV scans?

Yet, at the same time that risk might be reduced by the limited duration of the 'retailer,' entities like political campaigns present a higher risk of compromise. Here are a few things that PCI could do to deal with these situations:

1. Define a merchant tier for ephemeral entities

2. Require that they get audited by a QSA prior to starting processing or that they *completely* outsource the processing operations.

3. Require that they get an ASV scan prior to and during their operating period.

These three things can bring them into compliance and reduce risk using existing PCI mechanisms on a tighter time scale.

Next Step for Data Breach Laws

Sun, 08 Mar 2009 17:53:22 -0800

California pioneered laws around data breach disclosure with SB-1386, requiring that companies inform consumers when their data has been compromised. Now, state senator Joe Simitian wants to update the law with SB-20. The primary change is greater specificity around what information must be included in the notifications, and a requirement that breaches of a certain size generate notification to the state attorney general. While these are largely good changes, I still think the law misses the one question that most consumers really want answered when their data has been compromised: What should I do about it? Of course, that's a hard question to answer, so it's not surprising that it hasn't been adequately tackled.

Study finds you have a problem our product solves!

Tue, 03 Mar 2009 16:25:26 -0800

You have to love a study run by a vendor where the results clearly demonstrate a problem that very vendor solves. What a pleasant surprise!

Sarcasm aside, Damballa concluded that anti-virus misses a whole bunch of malware. We've seen this conclusion before. Their opinion is that they can protect you from your own compromised machines with their product.

When I read about these sorts of reactive technologies, I have a mixed response. Responding to the fire *is* important, but preventing the fire is always more important. I'm surprised that the industry continues to come up with new reactive technologies.

Web application security isn't just about web applications

Fri, 27 Feb 2009 13:11:32 -0800

More Than 500,000 Websites Hit By New Form Of SQL Injection In '08

It's new because it's automated and run from botnets. I'm not sure that really counts as a "new form of SQL injection," but I won't quibble. This paragraph isn't about SQL injection, but is noteworthy:

"While the initial attack vector was SQL Injection, the overall attack more closely resembles a Cross-Site Scripting methodology as the end goal of the attack was to have malicious JavaScript execute within victims' browsers," the WHID reports says. "The JavaScript calls up remote malicious code that attempts to exploit various known browser flaws to install Trojans and Keyloggers in order to steal login credentials to other web applications."

The point that's interesting here is that browser vulnerabilities are the real target. We may be talking about the rise in web application attacks, but they're actually targeted at the users of those web applications. We may all scoff a little at Microsoft's monthly IE roll-up bulletin, but perhaps we should scoff just a little less next month.

PCI Compliance Podcast at Practical eCommerce

Thu, 26 Feb 2009 07:04:55 -0800

There's a short interview I did on PCI compliance over at Practical eCommerce. It's about fees that merchant account providers are charging their merchants. Although not part of the interview, these fees are clearly part of the distributive nature of a regulation like PCI. In the end, the liability that the card brands previously held in its entirety is being distributed all the way down to the merchants themselves.

iPhone 2.0 is Less Secure

Tue, 10 Jun 2008 13:13:31 -0800

There's nothing quite as effective for illustrating a point than a top n list. Here are the top 4 reasons that the new iPhone is less secure than the previous version.

4. The Price

How could the price make the product less secure? Very simply, the more ubiquitous a platform, the more attractive a target it is. By lowering the price in order to increase market-share, Apple is creating a more attractive base of targets.

3. The SDK

Complexity breeds insecurity. The addition of third party code creates an avenue for exploit. Apple can work to minimize that, but there's a choice of functionality over security here. After all, not shipping the product at all would be very secure.

2. MS Office Compatibility

Do you remember MS08-026? How about MS07-044? Well, welcome to the world of remote code execution via MS Office Documents, little iPhone.

1. Enterprise-Ready

If the price of the iPhone increases its attractiveness as a target due to volume, then being enterprise-ready increases its attractiveness due to value. All the things about other enterprise computing devices that attackers love will now be present in the iPhone. Along with that comes a whole new world of exciting hackability. Who wouldn't want to break into it and see what juicy data the CEO is storing there?

A Virtual Advantage

Wed, 28 May 2008 10:24:25 -0800

First, the article.

Second, the salient quote so that you don't really have to read said article:

"If you are getting any benefit from Microsoft's software, you need to have a license, whether that benefit is for physical machines or virtual machines," Voce said in a session titled "Microsoft Licensing in a Virtual World." "You cannot engineer your way around licensing requirements. You can't use the technology as a way to cut corners around licensing."

The question I find myself asking is whether virtualization diminishes the perceived value of the operating system. As I deploy more virtual servers to do more specialized tasks, along with the very useful MTTR benefits of full VM snapshots, the relative value of the OS in that asset decreases. In fact, if I could have a purpose built OS that's completely built around executing the application function I require. Wouldn't that be far better than loading up a full, bloated, operating environment? In this equation, the value of that virtual appliance model far outweighs the value of the separate OS+Application model of the past. In fact, you might even be willing to pay more for the cost of ownership benefits of the virtual appliance (more for less, so to speak).

That's all well and good to think about, but what's the security angle (I hear you saying). Well, ubiquity breeds risk. A larger pool of targets is more attractive. 100,000 Windows based VMs is just as attractive a target as 100,000 physical servers. Purpose built virtual appliances, however, would increase the diversity of the target population. Further, they're purpose built, and we all know that increased complexity results in more bugs (aka, vulnerabilities). What I'm suggesting here, I suppose, is that the open-source community should figure this out before Microsoft because right now there's a clear financial advantage to using a free (as in beer) OS for your multitude of virtual images.