360 Security

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.

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?

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

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.

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

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?

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.

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.

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