In the last year, I've had a number of friends not renew their CISSP certification. At RSA, I got one of those badge flags saying "ISC2 Member". More than a few people asked "How did you get that?" Then before I could answer they would retort in a disgruntled tone "Oh you must have put your CISSP number in at registration. The CISSP doesn't matter anymore anyway". Shrugging shoulders; Well, OK, thanks for your kind words, I guess?

The CISSP doesn't matter anymore.

I hear this comment a lot. Where did this data originate? Personally, I think it stems from the CPE process and requirements. Those who value the certificate will put in the work to obtain and record the CPEs. Those who don't probably couldn't care much about the certificate anyway. They were probably "incentived" by their employer to go take the test. While they may have seen value in it at one time, the motive wasn't personally driven. I remember attending college right out of high school. I found school boring, but always noticed how the 30+ something's in class really enjoyed it. They were there to learn, to fill that personal drive. I, on the other hand, just wanted to get this part of life over with.

CPEs for Free

When I obtained the CISSP, I made a personal goal. I shall obtain all CPEs each cycle for free. That means no mega payments for online webinars and classes. It also means that I haven't joined any associations requiring yearly dues. So just how have I obtained CPEs for free? Here are some ideas:

• Submit ideas for speaking engagements. I attended RSA 2007 for free as a speaker and was proud to both be an attendee learning and an active contributor.
• Get a paper published. I did and it meant I also got to tick off a personal life goal.
• Read books.
• Vendor presentations. Almost all of the SANS WebCasts qualify.
• Seek out associations without membership dues. I'm an Infragard member.
• Volunteer. Offer to provide a free seminar at your local chamber of commerce regarding PCI.

I believe the CPE process to be a self-weeding mechanism. Those who value and desire the certification will continue. Those who don't can happily exit. There will be no shame and no throwing of stones. I respect your choice, but next year at RSA when you see my ISC2 flag, please don't turn the topic to one of belittling my achievements.

Reported by USA Today, both Hooters and Ruby Tuesday announced new tighter credit card handling procedures. Ruby Tuesday is touting an "Ultra-secure credit card process" which will apparently leave no credit card information at the restaurant. Hooters says they are in a pilot program which allows you to pay with a credit card from your table.

Just exactly what is an "ultra-security credit card process"? This makes me feel like I'm watching QVC. Everything is "ultra" this and "HD" that at an unremarkable value for a limited time. Would you like some bowie knives and a saber with that?

The pay at your table concept will be interesting. No doubt it will be a wireless device. I'd like to see the first analysis of that RF traffic. Another thing, too many people already fail to check my signature or ID. Paying at the table will undoubtedly ensure that the merchant will verify not a single transaction.

According to MarketWatch, Intel may have lost some email with respect to an ongoing litigation regarding an antitrust lawsuit with AMD. The story in itself isn't really all that interesting. What caught my eye were the plethora of failed communication and user training anecdotes. Here are few great snippets from the article:

Intel said a "fail-safe plan" to prepare back-up tapes missed some employees, while some workers didn't properly follow document retention policies. It further admitted some workers weren't given timely notice to retain materials.

In other cases, Intel said some employees may not have moved all the e-mails to their hard drives, while a few employees thought the company's information technology department was automatically saving their e-mails.

He said Intel is taking steps to correct the problems, including implementing a new email archiving system using software from EMC Inc., among other measures.

I'm no SOX expert, but I do know a thing or two about data retention policies. Isn't there a SOX requirement regarding data retention with respect to contracts and financial documents including email? It's my experience that companies affected by data retention policies in regards to regulatory compliance, generally install a technical means to automatically retain all data BEFORE going public. There seems to be a larger problem if your retention policy relies on employees copying data from their mailbox to their hard drive. Exactly how long has Intel been public?
Maybe someone who has first hand knowledge with respect to data retention of email and SOX could help shed some light?

You know when this new DST change has gone too far when your building management sends out a memo reminding you to upgrade your systems and patch your applications.

I came across an interesting paper this evening. Found at the bottom on this site http://www.energy.ca.gov/daylightsaving.html

Dr. Adrienne Kandal, with the California Energy Commission's Demand Analysis Office, has written a paper titled Electricity Savings From Early Daylight Saving Time, Commission publication # CEC-200-2007-001. She concluded that, "There is no clear evidence that electricity will be saved from the earlier start to daylight saving time on March 11, 2007..."

Check out the entire report.

According to AP reports, Sourcefire has set their initial price at $15 per share. Previously, the expected range was set at $12 to $14.

Since the onslaught of SOX, there has been a significant decrease in IPO activity. The new conventional wisdom says that you need at least $100M in revenue to go public. That combined with a minimum of $2M a year to stay compliant has many companies looking for alternative ways to raise capital. These forces are just one reason for the increasing consolidating in many markets. Given that Sourcefire's annual revenue is only about half of the $100M thought to be needed, all of us private companies will be watching and learning.

Product Information

	Name:	OCTAVE
	Website:	http://www.cert.org/octave/
	Category:	Methodology
	Date:	15-Mar-07

(This is part of a regular series where I discuss free information security products, tools, methodologies, hardware, etc. For a description of this column and to read other Free Lunch menus, check out the category archive)

No, I'm not talking about the musical term or the GNU language for solving numerical computations. Operationally Critical Threat, Asset, and Vulnerability Evaluation is a self-directed assessment methodology for security risk management. Isn't that a mouth-full? I can hear someone yelling Bingo! right now based on all the key jargon words that sentence contained.

First developed back around 2003, the work to develop OCTAVE was sponsored by the DOD and took place at Carnegie Mellon University. As best as I can tell we owe this body of work to Christopher Alberts, Audree Dorofee, James Stevens and Carol Woody.

What's special about OCTAVE is that its entirely self-directed and is not technology dependent. The method assumes that those persons internal to the organization are much better apt to perform a risk assessment than a third party. Today we still see many organizations outsourcing their risk assessments, but compared to 2003 today's numbers are much less. OCTAVE is intended to focus on strategy and process and less on technical tools. Where other evaluations focus on technology, OCTAVE focuses on security practices.

This is starting to sound all too familiar. Today it's a common theme to focus on best practices and common configurations than how do vendor x, y or z score my webservers. This might be why not too many people know of or use OCTAVE. Those who read about the approach took important lessons back to the office. They used the key learnings to implement their own self-directed methodologies and metrics. Unfortunately, very few technical risk management vendors partnered with these methodologies. OCTAVE never really had a large following or a developing community. Nonetheless it's fair to say that its core components are still very important and live on today.

This leads me to the difficulty of placing a score on OCTAVE. As usual I try to apply a rating in terms of Features, Ease of Use, Documentation and Community. OCTAVE is funny tool in that it just doesn't fit well into these categories, but giving it a low rating would be an injustice. I've learned a lot about risk assessments from OCTAVE and I encourage others to read and learn.

OCTAVE is a registered trademark and use of the documents are each subject to their own restrictions. None of the restrictions should avoid you from using the tools provided, but saying its open source like that of the GPL would be misleading.

Enjoy the Free Lunch.

Kevin Finisterre on the FD mailing list has provided us with two good posts regarding apparent Xbox live accounts being stolen. So far, I haven't found any compelling evidence either way that this has or hasn't happened. Likewise nobody seems to have posted a proof of concept or really taken credit. Seems that we are in limbo. Lets hope that MS isn't covering this up. If so, we can probably all expect the "we are _really_ sorry" speech.

While we are on this topic, I'd like to remind you all about one of my 2007 predictions where I call for the need of stronger identity mechanisms for online gaming. Not only are we paying money for these online games, but they also make many people money. The service these company's like Microsoft, Sony and Linden provide are a market and need to be treated as such.

College, Computer Science major. The tool of choice - an expensive HP calculator. The first thing I did was engrave my name and drivers license number on the back. Certainly, that would thwart off the threat of theft. Fast forward a few months to summer break where I was returning to contract work with TK (of course we didn't call him TK back then). On day one of my return to the software company, I trudged into work with that calculator safely tucked away in my backpack. My plan? To show it off to TK. He'd be so enthralled, so interested to see such a cool gadget. With corners of mouth pointing to the sky,

"Hey dude, check out this calculator I've been using at college."
TK: "Wow, this thing is nuts". After a few minutes of key pressing, he flips it over. "Um, hey dude, nice disclosure of privacy there."
"What are you talking about?" I inquire.
TK points out my flaw, "You've posted your name and drivers license number for all the world to see. Not to mention, I kind of doubt that this will thwart off a theft or even help you recover it if it were stolen."

I guess he was right. What a dork. Not only did I knowingly disclose my own information, but also I managed to deface my cool calculator in the process. So much for trying to resell it later.

Back in October, I posted an intentionally humorous question about how each of you protects your own privacy. Truth be told, these are part of my own list of personal privacy security measures. (No I don't wear tin foil undergarments). I learned an important lesson in those days working for TK. One might say he unintentionally molded my into a "security nut". I became a new person, or rather changed into just a phantom. You would have been hard pressed to find me at all.

I enjoy reading Jaron Lanier. He is one of those scientists and authors who make sense by stating the obvious. Or rather it may not have been obvious to you until you read it. In his ongoing line of writings regarding groupthink and the Internet, he comments on anonymity and how it affects collective communities like Wikipedia, YouTube and MySpace. "Beware the online collective" is his recent publication from December 2006. I read the piece and quietly said my typical response, "Well Duh". This short essay managed to get stuck in my head since December. It was not until now that I know why.

Like many people, I have profiles on many of the popular community sites. On all but one of these accounts I use a pseudonym. I'm probably not unlike many other people who either don't trust the company running the site, or simply would like to participate, but in private. A lurker of sorts. I haven't changed my identity, nor am I anonymous. I'm just sitting there like a span port.

Amy Bruckman is another one of my valued researchers and authors. A long time ago, I used to help run a MOO. She became famous to me at that time as she was using the online community of MOOs to understand human psyche in the online world. One of her findings, poorly paraphrased, is that persons with online identities eventually become themselves again online. As hard as we try to build a different persona, or even change gender online, we eventually return to our true selves.

Well, as it turns out, Jaron and Amy are correct. I'm one of those anonymous persons participating in the mass groupthink revolution. And yes, you'll discover I have a different identity. Not even my best friends know my MySpace profile name. Times have changed, however.

Today is a different day. You might say I exist again. There is my picture on our blog and it's not so difficult to find me in Google. Being a real person again online is refreshing. I learned that you if you want to enact change, you can't do so from behind the curtain. More importantly, if you buy an expensive calculator, don't engrave your drivers license number on it.

I still own that calculator.

Handheld mobility devices, the security and functionality of said devices never seem to dull. Of recent, we have two references you may want to read more about. First is a writeup from ComputerWorld, the second is announcement from PayPal.

Jon Espenschied has a nice writeup in ComputerWorld, titled "Ten dangerous claims about smart phone security". This is an excellent primer for anyone who thinks his or her smartphone is safe. His 10 claims are as follows:

1. It's just a phone with cool features, right?
2. It's stable, just like any other purpose-built appliance.
3. Communications are encrypted from end to end.
4. The connection's secure unless I use Wi-Fi in a cafe.
5. E-mails and messages are secure from prying eyes.
6. Using a mobile phone constitutes out-of-band communication.
7. I trust the integrity of data and applications on a smart phone.
8. Information deleted from a smart phone is gone, right?
9. Spying on my smart phone is hard.
10. Abuse is minimal because the network and phones are constrained.

In other news, PayPal is gearing up to deploy a mobile payment service. According to CNET and the WSJ, PayPal will launch a service this year, enabling users to pay for transactions using a smartphone. More specifically, person with web-enabled handhelds will have a specific application allowing them to pay for transactions using their PayPal account.

Back at RSA, when I participated on the SmartPhone Insecurity panel, it came to my attention that people really do use their phone to surf and purchase items. I was amazed to see more than half of the audience had purchased something from the Internet using their handheld in the last month. Personally I find the form factor and medium of a handheld too annoying to do any serious shopping.

Tim Erlin started us off on a popular topic - Is brand damage a myth. In other words, can we draw conclusive evidence to show that a company's financial value becomes altered by an external brand-damaging event? He takes case in point of 4 stocks - TJX, AMP, CPS and ADP. Nick Owens follows up with more data and now Adam promises us simple experiment.

Whatever the answer may be (if we ever can draw a reliable conclusion), today we have new data from Audit Integrity. Listed on Forbes are the America's Most Trustworthy Companies. The data provided are the results of their independent study on corporate governance best practices. In short, they have delivered a risk metric.

For quite some time now, I've been banging my head on a unification method by which we use financial risk models to represent information security risk. Lets face it; the financial sector has been going at it a lot longer than IT and certainly longer than information security. There are tried and relied upon inputs, metrics and statistical models. Out of these equations emerge basic risk metrics. We can answer the question, "Does the risk for which I'm about to take outweigh the potential reward?"

The problem I struggle with when joining these IT risk and financial risk models is they are flipped. We don't speak of risk/reward, we only deal with risk. The reward for patching my system isn't reward, its just less risk. Or in some cases, we find that patching a system may actually deliver a new or higher risk. How one quantifies the change in information risk is no easy calculation. I'd go as far as saying that there is no single model, which accounts for the diversity in each company or situation. Historically, from the financial world, when this quandary appears, it's tackled by adding more data inputs, changing metrics or statistical models. Unfortunately, IT risk seems to be lacking a well-defined set of all three.

I'm reading the new Cisco vulns released today regarding Cisco Unified Call Manager. Apparently one can cause a DoS by sending an ICMP flood.

* ICMP Echo Request Flood Denial of Service

By sending a large amount of ICMP Echo Requests (Ping) to a CUCM or CUPS system, it may be possible to cause various CUCM / CUPS services to crash resulting in a denial of service affecting voice services. CUCM versions 3.x and 4.x are not affected by this vulnerability, only CUCM version 5.0 is affected. The CUCM issue is documented in Cisco Bug ID CSCsf12698. The CUPS issue is documented in Cisco Bug ID CSCsg60930.

I interpret this as the classic "ping of death" we used to enjoy in early versions of Windows. One would think this would have been solved already.

Anybody try it yet?

I asked around, "what's a patch compared to an upgrade?"

The upgrade is generally considered more invasive, larger and comes at a higher risk. It may or may not have a big reward. The reason for the upgrade may be external, internal, and feature-centric or security related. Operationally, an upgrade requires greater amount of testing, planning and more complete change control planning procedures.

Patching is viewed as a smaller change. Only one or a few very specific variables are altered. The risk is generally considered low, but with a high reward, as the problem at hand will be quickly fixed. Patches are generally installed with less testing and often are implemented during a normal change window.

Don't both a patch and an upgrade represent the same operational risk?

The perception is seemingly clear. Call something a patch and it will get rolled out quicker than an upgrade. Case in point here at nCircle. Our internal Information Technology Patch Tuesday SLA is 8 hours. The IT team has agreed to test and ready for deployment "patches" within 8 hours of their release. In general, the acceptance and installation of said patches throughout the organization is less than 24 hours later. The net is that within 24 hours of patch Tuesday, we have nearly 100% of all end points patched. Now compare Patch Tuesday with the end of life for FreeBSD 4.11. FreeBSD 4.11 was our IT sanctioned Unix server common operating environment. Version 4.11 went end of life on January 31st 2007. Even with more than 6 months of notices and hands-on help, we still have business units who haven't been able to fully migrate.

Sure the "upgrade" from 4.11 to 6.x is much more complicated and complex than a "patch", but there is more at hand. There is a hesitancy and procrastination. For most, the upgrade of FreeBSD is perceived at painful and with little reward. Meanwhile, installing a few Microsoft patches is easy and comes with a big security reward.

Change == Risk

One would think that any change at all represents risk. Patch or upgrade, both introduce change. It's not our job to be risk adverse, but to be risk managers. Are we doing our users a disservice by calling anything a patch? What if we called it "Change Tuesday", I guess that's better than "Time to introduce risk to your computer in hopes of being able to better manage risk at some unknown point in the future so I don't loose my job".