February 2009 Archives

My friend Wade recently posted his thoughts on how to go about building a security team. For the most part, I found his comments to be spot-on, with one major, glaring exception. At the end of his post, he starts talking about getting into planning and measurements once you have your team in place, overlooking one major area: risk management.

Now, in his defense, Wade's objective was sharing his thoughts on how to build a good security team, starting with a good security manager who actually understands things. You cannot simply put a well-connected talking head in place and expect them to be successful managing security without the necessary technical know-how to grok what is going on. That being said, choosing who to hire and when to hire them, as well as making decisions about what technologies to leverage within your security team, must be based on sound risk management principles.

When I'm talking about "risk management" here, I'm really talking from a high level, and I'm including risk assessment and measurement as part of the equation. Plain and simple, if you're charged with building a security team and managing security objectives, one of your top challenges will be prioritization of work and resources. With security, it's very easy to let oneself slip into semi-anarchic ways where you are quickly overwhelmed that all that needs to be done. In order to keep the tigers at bay you need to make use of sound decision-making practices that prioritize your workload on a few criteria.

This is a bit off the beaten path, but hey, if you can't talk about the things you like in your own blog, when can you? :)

Last Fall I started attending training sessions for Brazilian Jiu Jitsu at Capitol Jiu Jitsu (CJJ) out in Dulles. CJJ is part of the Royce Gracie Jiu Jitsu Network (Royce Grace being a legend in UFC realms). The Gracie family is often noted as the "biggest family in sports" and are the innovators of Brazilian Jiu Jitsu (BJJ).

Last night I had an opportunity to attend a seminar with Rodrigo Gracie, who is a 3rd generation BJJ/MMA pro from the Gracie family. Talk about an awesome session! His pace was very good, demonstrating each set of moves multiple times, explaining new/different details with each explanation, and providing lots of coaching along the way to help everyone out. If you're training in BJJ, I highly recommend catching one of his seminars.

As for me, well, suffice to say that after working hard for 2.5 hours (of a scheduled 2-hour class), I ache all over (in a good way!). :)

If you're in the DC metro area and have interest in Brazilian Jiu Jitsu, Muay Thai, Cross-Fit, MMA, or Women's Self Defense, then I highly recommend Capitol Jiu Jitsu. The owner, Jeremy Lafreniere, is a very up-beat, positive, patient coach and is doing a lot of good work in the area.

lulz! Pirate iz d4 b0mbz!

If you need a good chuckle, please go read my friend Pirate's blog. He has a "1337" AIM SN that draws all sorts of interesting random babble. A good way to laugh your day away. :) There is, incidentally, some security tidbits to glean from here... in particular, some first-hand observations of (weakly) attempted social engineering...

This quote reminds me of the security programs for many large orgs... :

Putt's Law: "Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand."

Security Focus has an article up, "Man-in-the-middle attack sidesteps SSL", talking about how changes in default browser behavior have resulted in a less secure posture that facilitates MITM attacks.

In an homage to resourcefulness, this reformed felon is looking to apply his high-end skills, including in security and computers, in his post-confinement life/career.

In a tribute to more shoddy Science... it turns out that the National Snow and Ice Data Center (NSIDC) has botched their measurements by using an obsoleted method in estimating Arctic ice/snow coverage... from a security perspective, this really highlights the importance of good data... look at the current financial meltdown on Wall Street... by most accounts, the crisis was largely due to very poor risk management decisions thanks to poor risk evaluations... this is very much a case of "garbage in, garbage out"... we must all learn to put a critical eye on numbers - particularly statistics...

Speaking of getting things right... it seems that the tide is turning a bit on the notion that we should live in fear of terrorists... The Bruce has a post up this week titled "Terrorism Common Sense from MI6" where a former big wig from Britain's MI6 spy agency talks about how there are far worse things to be concerned with than the random terrorist attack.

I've gotten to the point that I'm tired of continually referring back to the PCI DSS document over and over again simply to figure out what it is that still needs to be done. In order to better wrap my brain around things, then, I decided to summarize the requirements as best as possible, including specifying action items under each high-level requirement based on the detailed requirements contained therein. Since I found this to be useful, I thought others might, too. Comments extremely welcomed as improving this benefits everyone. In terms of length, this fits into a reasonably-formatted 12-page document now, as opposed to the 59 pages used in the standard.

I. Introduction

The Payment Card Industry Data Security Standard (PCI DSS, or PCI for shore) version 1.2 was released in Fall 2008. This release was the third iteration of PCI, and represents its continuing evolution. Version 1.2 is structured in the manner of the audit procedures guide of previous versions, making the standard easier to comprehend from an implementation standpoint. That being said, the standard lacks an implementation guide that sets forth action items against which an enterprise can execute. That is the goal of this document.

Scope of Requirements

Contrary to popular belief, not all requirements are limited to just the cardholder data. As such, it is imperative that the scope of requirements be carefully considered and understood when planning for remediation.

Reference
The full standard and supporting documentation is available from:
https://www.pcisecuritystandards.org/

Document Approach
The approach of this document is to list a requirement, summarize it as concisely as possible, and then list actionable requirements. All statements are derived directly from PCI DSS 1.2.

Disclaimer
The author is not a PCI Qualified Security Assessor (QSA). When in doubt, it is best to err on the side of caution. If you’re subject to external assessment by a QSA, then you should work closely with them to get questions answered suitably, especially in the case of planned compensating controls.

A few quick thoughts from recent sports news...

By now everybody has heard about Michael Phelps and the bong photo-op. What this should teach us is the importance of evaluating risks before making a decision. No matter what your personal opinions are on the legalization/demonization of weed, the bottom line here is that, today, in the US, it's illegal (except in certain states for certain medical reasons), and as such, one should look at the broad spectrum of risks involve in imbibing. For Michael Phelps, it seems clear that he overlooked a few minor details when making his risk decision... details like that he's an internationally recognizable sports star, that he's often looked at as a role model, and that getting caught could (and eventually did) mean losing millions of dollars in endorsements. Of course, after his DUI arrest a few years ago, none of this should surprise us... I do, however, find it amusing that Rosetta Stone chose him for their ads, since he doesn't seem to be the brightest bulb. He should just be glad that he's not a Japanese sumo wrestler, as the consequences for this offense would have been permanent and life-long.

The other story of interest is on American downhill phenom Lindsey Vonn, who had to get her hand stitched up after shredding it on a bottle of champagne. I'd be curious about the details, but one thing here is for sure: there should not be a global ban on champagne bottles. In contrast to the bad risk decision made by Phelps, this sounds like somewhat of a freak accident. Maybe we'll find out that Vonn was engaging in risky behavior, but I'm guessing/hoping it's pretty innocent. Nonetheless, don't be surprised if somebody somewhere institutes some sort of new rules about champagne bottles at post-event celebrations.

Ok, here's a fluff piece, but it's interesting stuff from a security perspective... and, really, it's not all fluff. :)

1) From Slashdot today, False Fact On Wikipedia Proves Itself. This is an amusing little story of circular logic where someone erroneously updated Wikipedia, which was then used as the basis of multiple stories, which were in turn used to prove the validity of the erroneous Wikipedia entry. This isn't the first time this has happened, and I'm sure it won't be the last. Still, it poses an interesting challenge and dilemma.

2) According to The Bruce, Congress wants digital cameras to always click. Apparently they think that this absurd little rule would stop voyeurism. Apparently they're unfamiliar with the concept of "moving picture shows" and the advanced alien technology contained within the "camcorder" that makes voyeurism and exploitation just as possible without any clicking. This is what happens when luddites rules the world. Thank goodness our President is more technologically savvy...

3) The MN Supreme Court apparently isn't being heeded. Steve Bellovin has an in-depth article up about getting access to breathalyzer source code. The MN SC ruled a while back that defendants should be allowed access to the code - which, incidentally, is owned by the State - to aid in their defense. It turns out that breathalyzers use a rough average for calculating what's considered an ok level for a person, not taking into account numerous variables. If you blow a .08 (the legal limit), then depending on your body make-up, this may actually be a high score, meaning it's inaccurate. Rather than codify a +/- tolerance in the readings, they're taken at face value. As such, it's worthwhile to see the source code to determine what assumptions were made and to see if they impact the defendant favorably or unfavorably. This just highlights where an approximation is treated as an absolute measurement, leading to the potential for the unfair prosecution of people.

Yes, I know, I'm way late on this, but what the heck... for the record, I tried to get a ticket for this year's conference, but they had taken the site down due to issues. By the time I got back to the site, they were sold out (this happens every year). Anyway, enough sob story.

If anybody has an extra SchmooCon ticket, or if anybody can't go and wants to pawn theirs off, please let me know ASAP. Thank you! :)