nCircle.com >> 360 Security >> Sync

Web Poll

March 11, 2010

The Cadence of Microsoft Security Patches

Every month, like clockwork, Microsoft releases security bulletins and every month people ask me if it's small or a big release. While the exact details of the patches are generally treated as news, the expected workload each month really shouldn't be a guessing game because Microsoft's patch releases are predictably cyclical.

I don't have any special inside knowledge, and I can't speak for Microsoft, but when I look at the publicly available information it's pretty clear to me how the cycle works.

60 Day QA Cycle

A 30 to 60 day QA cycle on a Microsoft patch is typical, and it's actually pretty easy to tell how many days a patch was probably in QA. If you are curious, download the patch manually and take a look at the date the file was digitally signed. This isn't an absolutely accurate date because a patch could drop in and out of the QA process several times, but it's a reasonable approximation.

Using this method I calculated the average dates for the Dec 2009 patches at 54 days, November 2009 patches at 36 days, and October 2009 at 45 days. It's not too hard to jump from those numbers to an average 60 day cycle.


Roller Coaster Months

The security teams in charge of acquiring, testing and installing patches can feel like they are on a roller coaster with Microsoft patches. In just the first three months of 2010 we've already had wild swings in the number of CVEs and bulletins. January saw 2 bulletins, followed by huge February with 13, and then this week we saw just 2 again.

If we plot the number of bulletins along side the number of CVEs patched each month, there is a distinct pattern. Most Microsoft patches are obviously on a two month push. The first graph plots Microsoft release trends from January 2006 to March 2010. The second graph shows just the last two years, 2008 and 2009, where the wild up and down pattern is more obvious.

chart1.png

chart2.png


Lessons Learned

We'll never be able to predict the exact patch details for any month, but security teams can use these data points to help with planning. We all know that resources are short, but the risks and threats continue to grow, so better utilization of resources has never been more important.

There are no shortage of vendor patches. Luckily, Microsoft not only releases their patches on a predefined schedule, they are also fairly predictable in size. Since March was a pretty light Patch Tuesday, we can expect that the bulletin count for April will jump back up into double digits.

If you are the resource manager for a team of people in charge of your company's patching methodology, just knowing that can help you plan. This month is your chance to catch up from January. Thinking ahead to April, it makes sense to anticipate a large release from Microsoft so plan to have all hands on deck.

Not really much of a mystery after all is it?


February 25, 2010

RSA Conference Twitter Badge Mod

Again this year, the folks at the nCircle booth will be providing customized RSA badge mods with your twitter handle.
twitter_badge_small.jpg

We've made things really simple to request your own:

Follow @ncircletweets
Send us a DM that you'd like one for yourself.
Come by the booth (#1023) at RSA for pickup.

February 23, 2010

nCircle Announces Patch Priority Index

Each time a vendor releases patches; I always answer the same questions about prioritization. Which new patch is the most important? How is enterprise IT going to be tackling this new work?

At nCircle, we know from customers and other publicly available sources that most companies need at least 60 days to complete a patch deployment cycle. Every day a new deluge of patches are released. Every group of new patches kicks off a new cycle of patch management steps. Each patch must be evaluated, prioritized and scheduled. Information security managers are continually juggling decisions regarding risk, prioritization and resource allocation and the variables change every time a vendor releases a new set of patches

Today, nCircle announced the Patch Priority Index, a monthly ranking of the top 10 highest risk vulnerabilities from key vendors such as Microsoft and Adobe that adjusts to reflect how vulnerability's risk changes over time. The Patch Priority Index (PPI) helps prioritize risk reduction decisions by evaluating new patches within the context of the bigger security picture and acknowledges that all patches may not be deployed before the next group of patches are released.

The idea for this index grew out of community discussions with customers, partners and vendors. Our Patch Priority Index is a free and publicly available service that nCircle is providing as a service to the information security community.

We hope that the service will provide a repeatable, consistent and complimentary metric that IT security teams can use to effectively prioritize the most critical vulnerabilities.

Patch Priority Index rankings are based on key elements of nCircle's Risk Score and includes a critical time component that is unique among scoring systems. This time component prioritizes new patches within the context of all patches previously released by a vendor within the preceding twelve months.

Patch Priority Index debuts for Microsoft vulnerabilities in March and other key
vendors will follow.

The most recent Patch Priority Index may be found here

For information on the nCircle risk score algorithm, please check out our
whitepaper

February 22, 2010

How does a consumer report PCI non-compliance?

This past Saturday my son and I were having a "boys day". My wife was out having
fun all day and the boys were left to be boys. Dinnertime rolled around and we were
having too much fun playing LEGO India Jones to even consider making food. So I
treated him to a stereotypical boys dinner - video games and pizza. This was when
the fun turned into fear.

Moments after ordering pizza online from our favorite local pizzeria, the phone
rang.

Caller: "This is Joe from the local pizza place, calling to confirm your order".
The order and delivery location was confirmed.

Caller: "And how do want to pay for this?"

Me: "Um, well I just entered all my credit card info into your website like I usually
do".

Caller: "oh". A moment of pause. "Oh I see your credit card info now in the email."

Me, with a definite tone of anger: "My credit card was sent to you in email?!"

Caller: "um, I'll get that pizza delivered ASAP."
Click


The pizza delivery guy arrived. As it turns out it was the owner delivering the pizza.
He explained to me that he had recently bought the local franchise and had no idea
that the online orders were emailed to him along with all the customer information.
As an attempt at a good-hearted gesture, he gave me some free breadsticks along
with the printed email containing my entire credit card and address information.


I was now bent out of shape. Five minutes of Google searches turned up no methods
for a consumer to report this obvious PCI non-compliance. Asking friends on
Twitter and Facebook ended up with equally non-specific information. Some friends
offered up email addresses of people at Visa, others stated quite assuredly that a
consumer has no means to turn in violators. Realize of course that nCircle (my
employer) is a certified PCI scan vendor and my online friends are all very much
entrenched in information security. That is to say that you would think someone
like me could ask around and quickly find a way to report this merchant to the PCI
council for review.

The next step was to call my bank and issue a fraud alert. The bank customer
support person took my information, listened well and followed her procedural
steps exactly as instructed. All my information was confirmed, past orders were confirmed
and a new card was issued. I requested directions on how to report this merchant
for obvious non-compliance. Furthermore, I felt the merchant was in violation of a
number of laws by printing out my entire credit card number. The bank customer
support person offered the number of the Better Business Bureau.


Think about this. The PCI standards council has worked hard to ensure compliance
of all their merchants. An entire industry has sprung up around the PCI Data
Security Standards. Yet, the standard provideds no means for consumers to flag
merchants for non-compliance. Even the issuing bank seems to have no means to do
so.

Aside from naming names here in my public soap box, how are consumers suppose
to help due their part to ensure security and privacy of the credit card industry?


January 29, 2010

BofA Website Outage - A Giant PR Mistake

For a lot of Americans, today is both a payday and the last business day to pay those bills online due this month. So it goes without saying that many people have noticed that Bank of America's website has been unavailable for most of the day.

A quick search on twitter shows many Americans complaining about the site being down. Yet, so far only a few news organizations are covering the outage. The only official word from the company has come from its twitter account ( http://twitter.com/BofA_help ). Apparently, they feel that the outage is only affecting a few people by issuing a statement, " We are aware some customers are experiencing access issues. Our tech team is working to resolve as soon as possible." Those news organizations covering the outage all report no word back from the company.

Meanwhile, speculation is on the rise that the company is in the midst of a cyber attack. This is turning into a giant PR mistake by Bank Of America. For a company that took billions of federal assistance, this would also seem like something our new Cyber Czar should be looking into. We must not forget that at the very least, one tenet of information security is availability.


January 16, 2010

Is Google to blame for the IE 0-Day Hype?

The sudden hypersensitivity regarding a new Microsoft IE 0-day, traces its roots to this weeks Google's overhyped breach. On Tuesday, Google went public with an admission of its own compromise. This was no ordinary breach, but one of global proportions that claimed they and 20+ other companies were all victims of state sponsored cyber thiefdom. Everyone suddenly became aware of China's cyber terror potential.

Queue the Beethoven.

While most everyone assumed the public Adobe PDF flaw was the attack vector, we should have more correctly assumed not one but many attack vectors were at play. Come Friday, in an unexpected turn of events, Microsoft was taking the brunt of the blame in a newly announced IE vulnerability. Microsoft is getting a bum deal here and has much of it to blame on Google's overhype.

What if we replayed this week's events with a different set of goggles?

Suppose that Google had not raised its own compromise to the level of state sponsored cyber terror, while threatening its own retaliation by ceasing censorship of search data. Furthermore, Google didn't need to announce that some 20+ other companies were also victims. At this point, the other companies have very little reason not to come forward. They can safely join the ranks of the others affected and cleanly play the victim role of being attacked by a state sponsored cyber terror. Yet, very few have come forward despite all having been notified.

It would seem to me this was an obvious calculated overhype. The event provided the perfect set of excuses for Google to combat Chinese censorship while giving them an alternative reason to pull out of China. It's a win-win for Google - fight Chinese censorship, support Chinese human rights activists and cleanly exit a failing business venture.

With any good attention diversionary plan an unexpected victim arises.


Take the facts of the IE vulnerability independent of all external events. What we have today is a bug in all versions of Internet Explorer, but so far only weaponized for IE version 6 on Windows XP. As usual, DEP and ASLR are providing significant mitigation with IE8, Vista and Windows7. The net of these findings is that today's attacks are only successful on Windows XP with IE6. Jonathan Ness of the MSRC engineering team spelled out these important facts in a blog post Friday evening. In an ordinary humdrum month, the vulnerability would be worrisome, but not epic.

Zero day attacks happen every day. Even the most secure organizations get compromised. Everyone is a target, everyone will be a victim. Take a few deep breaths.

August 6, 2009

Twitter is down, twitter is down! I don't know what to do.

On this momentous occasion of a twitter outage apparently caused by a big DDoS attack, let us celebrate by naming 5 things we used to do before twitter.

1. Work more
2. Email the person directly
3. Pick up the phone
4. Make a decision by yourself
5. Watch the evening news and not find it old news


August 3, 2009

How to react when big leaguers get hacked

An old boss told me once, "You play in the big leagues, and you will eventually fall like a big leaguer." The fact is many people have their computer security compromised daily, and this is also true for many corporations. But how are we supposed to react when the "big leaguers" in our industry fall victim too?

Over the last week some of the security industry's heavy hitters were victims of widely publicized security breaches. Dan Kaminksy, Matasano Security and Kevin Mitnick all had their websites breached. Some events were little more than defacements; in Dan's case some of his personal information was publicized. We, the BlackHat attendees, are the ones entrusted by individuals, large corporations and government entities to protect networks against precisely these types of attacks. What do high profiles breaches like these mean for our reputations and for our industry?

The truth is that data breaches are so common that most of us aren't even alarmed anymore. Privacyrights.org tracks the millions of private records that are compromised each year. The Conficker worm was said to have compromised millions of computers. We have become so used to reading about these stories and shrugging our mental shoulders that some people say our industry has become laize faire. We work towards compliance; we fight for budget and reducing our risk metrics. But are we really living and breathing what we preach?

This is not to say that Kaminksy, Matasano or Mitnick aren't intelligent, creative thought leaders who honestly work hard each and every day. It does mean that even the best of us are vulnerable to the same threats as everyone else. It also means that every company, even the ones we work so diligently to protect, is susceptible to some sort of data breach. No one is beyond the law of statistics.

So what does it really mean when even the security gurus at Blackhat get breached? It means there is always room to improve, and it means that there is no such thing as complete security, no matter how much money you spend or how smart you are.

This sobering reality is a reminder to us all about the value of vigilance. It's also a reminder that every breach offers a lesson. Dan Kaminksy handled this very public data breach by congratulating his attackers and offering them two of his grandma's famous cookies.

Dan will definitely step us his security, will you?

Apple Needs to Get Serious About iPhone Security

Two years ago I took some hard hits from my peers for calling the iPhone "a security nightmare". Two years later, I can't find a single person who doesn't agree that the iPhone is the number one mobile target of security researchers. Fast forward to today -- is the iPhone still a security nightmare or have those problems been relegated to annoyance status?

Last night at one of the BlackHat evening events, I went out of my way to personally thank Charlie Miller for his creative and diligent work finding new and ever more alarming bugs in the iPhone. Charlie needs very few introductions these days due to the notoriety driven by his iPhone security hole discoveries and his history at the Pwn2Own contest. But Charlie is not alone when it comes to iPhone security research. Apple security updates for the iPhone OS now recognize a rapidly expanding list of bug reporters.

The iPhone is now on its' third full OS version and Apple has added many new enterprise and security related features. In spite of Apple's attempts to keep the iPhone a closed system, more known about its inner workings than any other mobile platform (except possibly the open source development of Android). iPhone popularity isn't limited to consumers, it is a favorite with security researchers.

One security maxim says that risk increases in proportion to the target landscape. If this is true then, the iPhone represents a significant security risks simply because of its market penetration. The same thing can be leveled at Microsoft Windows. It's easy to say that because the iPhone is getting the high level of security attention it represents the greater threat than other popular mobile platforms such as Windows Mobile or Blackberry. This kind of thinking is short sighted.

The reason why the iPhone continues to represent a significant threat to the enterprise is not because of its operating system design or the dozens of security bugs it contains. The iPhone risk continues to escalate because of the way Apple prioritizes and operationalizes security. Apple continues to prioritize usability and features ahead of security. Apple just recently added on board data encryption to the new 3GS model. Only days later after its release iPhone encryption was shown to be easily subverted. And enterprise security teams operating with limited resources still don't have a centralized management console for pushing out updates, and the updates themselves are released on Apple's timing with no advance clues as to timing or content. Enterprises that allow iPhones on their networks must live without vendor-supplied intelligence routinely provided by other vendors.

Today'the iPhone might not qualify as a security nightmare but it's still a pain in the side both IT security and operational teams. We would like very much to support and deliver the best tools to our users, and that includes the iPhone. The problem is that Apple's enterprise management tools just don't measure up to what is available from Microsoft and Blackberry. And even when we get in a bind with security issues from other vendors, at least they communicate and lend us a hand with detailed information and risk mitigation steps. It's time for Apple to get serious about security if they want to grow in the enterprise.

May 20, 2009

Adobe Responds To Criticisms About Its SDLC

Adobe had a turbulent start this year and in response to cries from it's disgruntled users, Adobe security has announced several strategic moves. This blog post from Adobe describes the three much-needed things Adobe will be doing to improve security for their popular Reader and Acrobat products.

First, Adobe's existing secure product development standards will now also be used against their existing/legacy code base. Second, Adobe now promises quicker and more in-depth security incident response mechanisms. Finally, Adobe will be moving to a regular patch release cycle.

The three initiatives essentially mirror what we have come to know and appreciate about Microsoft's security processes. About a decade ago, hit by bad press and poor industry reputation, Microsoft embarked on a similar but grander vision. The result of that effort is that today Microsoft is the leader when it comes to managing the enterprise security development lifecycle.

These initiatives are a great start for Adobe to begin rehabilitating their image. These initiatives go a long way, but they are still missing a few important components.

First, Adobe needs to learn how to reign in the bug finders. Both critical security incidents with Adobe so far in 2009 have involved situations where proof-of-concept code was made public before Adobe could repair the bug. Letting bug exploits out into the wild set Adobe back on their heels and left IT security groups in a reactionary mode trying to cover their security assets without much help from Adobe

Second, enterprise IT shops could benefit greatly from centralized tools that allow for product policy changes. If Adobe published means and methods to disable product functionality using active directory group policies, then IT would be in a better position to respond and implement policy-setting changes.

Finally, JavaScript bugs riddled Adobe products in 2008 and in 2009. It would behoove them to consider disabling JavaScript by default.

The long string of critical bugs in Adobe products has disappointed me, among many others. The bugs, coupled with poor company communications and difficult to deploy mitigation steps have made the last six months ever more trying in our security team. Going forward there will be 2 key metrics of Adobe's successful implementation of their new security program. First will the obvious - fewer security holes. The second indicator will be when Adobe has successfully convinced the bug finders to disclose holes to them instead of publishing them online.

The bottom line is that the changes announced today by Adobe are welcome and we all hope that Adobe sees immediate improvement across their install base.