March 2009 Archives

RSA Is Right Around the Corner

Greetings! RSA is coming up quickly - less than a month away, now. Are you going? Want to get together? Drop me a note and I'll see what we can work out.

Need a reason to go? How about this: The MythBusters (Adam & Jaime) are keynote speakers this year! WOOHOO! :)

Unable to pay for a delegate pass this year? Fear not! RSA is offering a scholarship this year to 25 luck recipients. Here are some of the requirements:
   * Must be an information security professional (practitioner, security architect or similar role);
   * Must have attended the 2007 or 2008 RSA Conference as a full conference delegate;
   * Complete a 1000 character explanation on “Why I need to attend RSA Conference 2009”; and
   * Complete a 750 character biography

Deadline is April 2nd!!! See the following for more info:

RSA Conference is also having a Six Word Memoirs "contest" in which people describe their life in security in six words. The memoirs will be posted throughout the conference. If you'd like to participate, go here:

Facebook Passes the Buck

If you're a user of Facebook, then you probably got a bazillion PicDoodle notifications early last week. In fact, if you clicked on a link, you probably generated part of those notifications. According to Facebook, it was just a broken app and not spam. Frankly, I don't care how you explain it away, it was bad. So, I sent a spam notification to Facebook saying "this app is killing us - please kill it". Now, the proper response here would have been to route it to the right people and fix the problem. However, here's the response I got from Facebook instead:

Hi Benjamin,

Thank you for reporting this potential abuse. Your issue relates to an application that was not built by Facebook. Unfortunately, Facebook cannot provide service for applications built by third parties, so you will need to contact the developer of the application directly. To do this, please visit the application's About page and use the "Report Application" link at the bottom of the page. Be sure to give a detailed, accurate description of the problem and include links (URLs) to the relevant pages.

Facebook is not responsible for the support provided by this developer. If you continue to have problems, please note that you can remove and restrict applications by clicking on the Applications menu in the bottom left corner of any Facebook page and selecting the "Edit All" link.


User Operations

Obviously this is a dumb form letter response. However, it seems to me that it's also wrong. The problem absolutely was Facebook's. They obviously had bad code that allowed this problem to occur. And, it's their responsibility to keep app developers in line. Oh, well... I guess it's just easier to pass the buck sometimes...

Overwhelming Flood

This is a personal note. You've undoubtedly heard about the flooding in Fargo, ND. We're talking water levels of unprecedented proportions, blowing through the previous record (from 1997) last night. They've raised the crest estimate numerous times, with it now in the 42-43' range. If you live anywhere near ND or MN and can get away, I urge you to do so - folks need help.

If you can't make the trip, but would like to help another way, please visit the web site for the Minn-Kota Red Cross

My parents were under mandatory evacuation last night. If the river reaches 42' (previously thought nearly impossible), the water will reach the main level of their house. With the evacuation, they're not able to monitor their basement, so if the power goes out, they're sunk (water table will rise and flood the basement), or if their sump pump dies, their sunk. Not good.

Track current river levels on the NDSU Fargo Flood page.

For news, road closures, and general coverage of the event, see the Valley Flood Watch site, or visit the local newspaper, the Fargo Forum.

A live web cam is available from the Forum at - be advised, however, that it has been up and down a lot.

I wish that I could be there to help out. Unfortunately, I'm on the verge of a cross-country move, with the movers coming Mon/Tues next week. It's very frustrating not being able to do anything to help my own parents!

Dragon Door Cuts Kettlebell Prices

If you've been looking for a high-quality Dragon Door kettlebell, but been hesitating due to the price (expensive!), guess what? They've cut the prices significantly as they're dumping US-based production. Remaining US-produced kettlebells:

10lb - 77
14lb - 121
18lb - 110
24kg - 23
28kg - 263
32kg - 267
36kg - 317
40kg - 63
48kg - 49

Save up to 30% on Dragon Door's classic Kettelbells

Are you familiar with the classic South Park episode "The Underpants Business"? For some strange reason it reminded me of PCI compliance today...

Phase 1: Publish PCI DSS
Phase 2: ???
Phase 3: Security!

Security in the Comics...

I always enjoy it when security-related topics make it into the comics... the more mainstream fundamental security concepts get, the better hope I have that we might some day make real progress... ;)

(Click-through to see them in their entirety)


OASIS EKMI Coup D'état

First, some quick acronym definitions before I go acronym crazy...
OASIS - Organization for the Advancement of Structured Information Standards
EKMI - Encryption Key Management Infrastructure
KMIP - Key Management Interoperability Protocol
TC - Technical Committe

Quick background: The EKMI TC was formed in 2007 to create standards around the topic of Encryption Key Management Infrastructure, or EKMI for short. EKMI is the combined management of PKI and Symmetric Key Management Systems. The notion is that both types of systems deal with encryption keys (asymmetric and symmetric), and thus should be fully interoperable and managed jointly. Contrary to some reports, EKMI is not just an XML protocol. The goal of the EKMI TC was nothing short of developing a standard for securely managing any type of encryption key.

The controversy: In February 2009, several major vendors, including IBM, HP, and RSA, announced that they were chartering a new OASIS TC - KMIP. Ironically, some of the people chartering this new TC had been members (though not regular participants) in the EKMI TC as well as the (dysfunctional) IEEE P1619.3 standards committee. By all appearances, the KMIP charter has significant overlap with the EKMI charter, and it is not clear at all why the TC was allowed to go forward, except that under OASIS charter rules due diligence is not required. In essence, a group of vendors can get together and launch their own charter without determining whether or not there is overlap or congruence with existing OASIS TCs. The OASIS argument is that competition is good, but this seems to fly in the face of the OASIS mission, which is to drive "the development, convergence and adoption of open standards for the global information society."

Stupidity at

Just a quick quip on an interesting interaction with support. I received a called from "Restricted" on which I was advised by someone purporting to be from that my back-ordered purchase was not successfully receiving a credit card authorization. It turns out that re-authorizes the credit card transaction every 5 days. When an item is back-ordered for a long time, this eventually results in the issuing bank blocking further transactions. support then called me to request that I call my card issuing bank and ask them to approve the authorization. SERIOUSLY?!? Quite literally, by following a stupid practice that they know causes problems, they've chosen to make it the customer's problem rather than fix their process.

What I find interesting here is that, really, there should only ever be 2 transactions. At the time of purchase there should be an authorization check, and then nothing further should happen until the product is ready to ship. At the ship time, the card should be run and charged, and if that fails, then and only then should support be triggered to call the person. And, at that, a phone call shouldn't even be necessary. A simple "We're ready to ship, but your credit card declined." email would be more than adequate. Provide a contact number if more information is needed, but that's about it.

Of course, in either case there's a significant fraud risk. My example reads like a possible phish. *sigh* But the phone call wasn't much better. And, what's really weird is that they asked me to call my bank. Imagine running a scam where you're trying to make a false charge and it's being blocked. Just call the consumer and ask them to unblock it? Really? *sigh* Maybe it would be better simply to cancel the order if the credit card fails, requiring the user to go purchase it again? I'm sure business would love to hear that solution... of course, I wonder how much money they're spending on these phone calls asking people to unblock their repetitive authorization charge?

Oppose Merit-Based Pay for Teachers

Pardon the political rant... this is an issue near and dear to me. Please join me in openly opposing merit-based pay for teachers. This is the dumbest idea in education reform since Bush's No Child Left Behind (or educated or funded). That Obama has proposed such a plan makes me even more annoyed with the president I helped elect (this is not change I can believe in!). For more on his push, see here and here.

So, to keep this short and to the point... the problem with merit-based pay is that there's no reasonable, rational, consistent way to measure performance... teaching is more art than science. Every student is different, with a unique perspective, background, learning style, and, more importantly, pace of development. To penalize a teacher for having a group of students who develop more slowly than others is absurd. No matter how good the teacher is, there's no way to force a child to develope faster than they're capable of doing.

One might then respond by pointing at standardized tests. Surely those could be used, right? The problem, of course, is that when you put all the emphasis on standardized tests (as has been done the last several years thanks to Bush and NCLB), then the teacher is only incentivized to teach to the test. Instead of education and learning, you get rote memorization. Rote memorization is NOT education. Teaching to the test, and the resultant rote memorization technique, means that students are graduating without the ability to think for themselves (no critical thinking skills). Regurgitating facts is an almost completely useless ability if you don't know what to do with the facts. Just because you can recall constants and equations does not mean you know when and how to use them. This is a major problem.

And before you get off on the tangent about how our poor US students just don't compare with students in China or India, let's bear in mind some basic statistics... if you look at the top 10% of China and India (total populations of 1.3B and 1B), you're looking at 130m and 100m people, respectively. According to the US Census Bureau, the current US population is only 305,979,379. So, let's compare, then... the top 10% of China and India is approximately 230 million people, which is about 75% of the total US population... now consider that the best and the brightest are the ones who typically get to take standardized tests in those countries... while all students in the US take those tests... this is not, then, an apples to apples comparison, right? So, don't get off on those misleading reports about how the US is lagging behind... if you want to know the real cause of the US decline in education, it's the combination of requiring a focus on standardized tests (rote memorization instead of critical thinking) and the development of an entitlement generation that thinks everything should come easily to them with little or no effort (since mommy and daddy have always provided).

Review: CISSP in 21 Days


Cissp_80.jpgFollowing is my review of the recent release CISSP in 21 Days. A sample chapter can be retrieved from here.

CISSP in 21 Days by M. L. Srinivasan is a CISSP exam prep book. By its own admission, it is not a comprehensive, end-all-be-all book for preparing for the CISSP. What it does claim is the ability to take you through a well-reasoned progression over the course of 21 days to hit on the key concepts and topics of the CISSP, with the last day focused on taking a 250-question sample test. Overall, I think the book accomplishes its goal and could be a useful study guide.

There is no shortage of CISSP prep books today. Shon Harris alone accounts for a lion's share of the market, and one should also not overlook the Tipton and Krause anthology Information Security Management Handbook. In the face of these books, one might wonder why Srinivasan would even bother with an attempt. However, if there's one thing that is clear from most CISSP prep books, it's that they've taken the "quantity over quality" approach, oftentimes burying the reader in hundreds of pages of oftentimes duplicated and sometimes error-ridden work.

In this instance, the book covers all major topics in 225 pages, broken up into 20 days of study, where each of the 10 CBK topics is covered at 2 days each. The layout is clean, lightweight, and concise, hitting the important points. One should not feel overwhelmed by the amount of materials presented, though one might also be left wondering if this is really all there is (it isn't - there's more). However, the book never claims to be a complete, comprehensive training guide - merely a guide for reviewing topics. Specially, the book points out that it "assumes that the candidate already has sufficient knowledge in all 10 domains of the CISSP CBK..."

   * Concise: The book is very brief and to the point. It does not waste ink or pages on unnecessary explanations.
   * Logical: A reasonably logical approach is taken to the topics, starting with security and risk management and expanding from there.
   * Straightforward: The explanations provided are very straightforward and clear.
   * Clean Layout: The book is laid out in a manner that is easily read and followed. Ample room is left in the margins for notes.

   * Thin: This is not a comprehensive prep guide, but rather a review guide. The book is not aimed at beginners.
   * Few References: In the "Introduction" the book mentions that there will be a reference section at the end. It turns out this Reference section has 9 entries, including Wikipedia. Not complete or particularly useful. One of the links is for the ISO organization, but it incorrectly uses a TLD of .ch instead of .org.
   * Rigid Language: The language is fairly rigid in its construct. This is fine, but it can be off-putting for some readers.
   * Some Grammar Issues: The author is an Indian National, and thus there are the occasional grammar flubs. The errors are not terribly serious, but they may be distracting or off-putting to some readers, particularly speakers of American English.
   * Slightly Pricey: The eBook (PDF) lists for $22.39 and the print+eBook lists for $40.79. Given that this is just a review guide and not a comprehensive prep guide, I feel that anything over $20 is asking too much.

So, the magic question: Would I recommend this book? My answer is a qualified "yes", though perhaps not at the current listed price point. This book could be useful for an experienced IT professional who already understands security, but has never looked at taking the CISSP before. From this standpoint, it would be very useful to quickly bone-up on what the requirements and expectations are.

That being said, this book will only be once piece in the overall puzzle, and it's lack of useful references means that the aspiring student will still need to go research other references.

This book is definitely not for the inexperienced IT professional. If you cannot speak knowledgeably to risk and security management, network security, system security, or physical security, then you will not find this book to be very useful. On the other hand, if you know these topics inside-out, then you may think this book isn't terribly useful.

If you're not familiar with the CISSP, but have the skills, this book can provide a useful starting point. If you don't have the skills, then don't start here.

Good Quote to Ponder

From the recently departed creator of Gracie Jiu-Jitsu:

"It is only with a lot of training and dedication that we can achieve something. A brave man, a real fighter is not measured by how many times he fall, but how many times he stand up. Always be ready to fight, to win and to forgive when necessary. Good luck."
Grand Master Helio Gracie (1913 - 2009)

Ummm... Squeeze Me?

Alright, time for a snarky request for public intervention... :) If anybody out there knows anybody in the State of Colorado's Office of Technology, you might want to perform your public service act of kindness of the month and go kindly inform them that, no, IE6 (!!!) is not more secure than Mozilla Firefox. As noted on Slashdot, making such assertions to the contrary (that IE6 is, like, the most securest-est browser ever, man) really undermines the credibility of the agency.

Source: Slashdot: "State of Colorado Calls Firefox Insecure, IE6 Safe"

Two unrelated items, but I thought they were worth highlighting in case you hadn't heard the news...

First up, The Bruce has a post on "More European Chip and Pin Insecurity" talking about how the current implement of Chip and PIN capabilities in UK credit cards is so shoddy that it's hackable. Oh, sigh... it's hard to harp on the card brands here in the US to move to chip and PIN when the implementations aren't working very well. I'm personally of the opinion that we need smartchips with an RSA-token-like 1-time code displayed on the card itself to use with each transaction. Combine that with the CVV2 value, zip code, etc, and you hopefully would have enough factors to start getting a handle on credit card fraud... maybe... sort of... :)

Second up, if you've not heard, Microsoft is suing TomTom over some sort of wonky patent infringement blah-de-blah... *yawn* Ok, but anyway... it's starting to look, however, like Microsoft is really trying to attack Linux through this attack... Slashdot has a post on it here that's worth scanning... let's hope that MS is no more successful here than they were backing SCO... and, moreover, let's hope for the day when MS learns to embrace their competition, rather than resort to underhanded legal attacks... it's kind of an old, tired meme, don't you think? ;)

James McGovern has an excellent post recently on how agile development has grown to become the antithesis to security (see "Agile is the antithesis to security..."). He argues, quite correctly, that agile development is really just short-hand for "really crappy coding practices". As Telic Thoughts discusses, security has to be built-in via quality software engineering principles - the very thing that is missing from agile dev practices. Unfortunately, these days there is very little "engineering" involved in software development. To me, this seems to be a side-effect of the evolution of the Internet. Most "applications" are web-based, written in some sort of scripting language, rarely compiled, and almost never optimized.

These practices, or lack thereof, contribute to a state of insecurity that plagues the enterprise. However, none of this should surprise us because there's little incentive for businesses to implement secure practices (see Bruce Schneier's post "Perverse Security Incentives"). Business is incentivized to do what the business ideally does best: make money. Anything that gets in the way of that purpose - including security - is often seen as a negative detractor; something to be ignored. Oftentimes we in the security industry make it very easy for this attitude to pervade the enterprise, putting us at a disadvantage.

When you get down to it, the trick here is in finding a way to position security as an enabler; as a way to optimize the business. As Schneier notes in his post, Legal departments have been successfully making this case for years. After all, if you reduce liability exposure, you're reducing the risk of a significant financial loss. For security - and, really we should say IT security - we need to accomplish the same task within our different genre. Reducing risk resulting from poor IT security practices should be seen as a way of reducing the likelihood of financial loss. In fact, this is the exact goal that regulations like the Payment Card Industry Data Security Standard (PCI DSS) are hoping to accomplish (leaving aside who is making the changes and whose risk is being reduced).

About this Archive

This page is an archive of entries from March 2009 listed from newest to oldest.

February 2009 is the previous archive.

April 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives


  • about
Powered by Movable Type 6.3.7