So by now NIST SP 800-37 R1 has made the rounds.  I want to take a couple of minutes to go over my theory on this update.

Summary of changes:

• Certification is gone.  Accreditation has now changed to “Authorization”.  This is interesting to me because it removes certification which I’ve always equated with compliance.
• There is more focus on continuous monitoring.
• NIST has made it more obvious that the process in 800-37 is the security aspects of a SDLC.
• There is much more more emphasis on enterprise-level controls.

So those of you out there who have been succeeding with the NIST Risk Management Framework  have been doing this all along, and it’s actually why you’ve succeeded.  For the rest of you, if you have to change your existing process, you’ve been doing it wrong.

Now for what’s missing and where you need to fill in the gaps:

• Prioritization of controls.  If everything is important, nothing is important.  You have to be able to determine which controls you need to succeed 100% of the time and which controls only need 75% reliability.  Hey, I even give credit to the SANS 20 Critical Security Controls, as flawed as they are, for this.
• Delineation of controls into shared/common, hybrid, and system-specific.  This is by design, it’s up to the departments and agencies to figure this out.  If you do this correctly, you save a ton of time and effort.  I remember the day my certifier told me that we didn’t recognize shared controls and that it was on me to provide evidence of controls that were provided at the enterprise–it still baffles me how you really expect one person on a project team to have the resources of the entire IT security staff.
• Continuous monitoring is up to you.  Along with prioritization, you have to determine which controls you need to monitor and a plan on how to do that.  Protip: these are usually technical controls that you can automate and should do so because it’s the only way to get the job done.
• Tailor, tailor, tailor.  It is not enough to use generic 800-53 controls.  It definitely is sub-par to use untailored 800-53A test procedures as your test plan.  These all depend on the implementation and need to be tailored to fit.

And finally, a shout-out to Dan Philpott at FISMAPedia.org.  Dan literally consumes new legislation, regulation, guidelines, and standards as they come out and annotates them with a wealth of analysis.

800-37 WordCloud by ME! Thanks to wordle.net for the tool to make it.

• SP 800-53A Now Finally Final
• NIST Cloud Conference Recap
• Special Publication 800-53 Revision 3 Workshop
• How to Not Let FISMA Become a Paperwork Exercise
• Some Comments on SP 800-39

OK, so now for some news about me if you haven’t seen it on twitter (You’re a security geek not on twitter?  Check out the Cool Kids Club and get involved).  Earlier this month I changed jobs and am now the Security Evangelist for Akamai–basically telling the story of our security team and the platform and what we do right.  I’m still doing some Federal business but I’ve also picked up responsibility for commercial customers.  And yes, I’ve slowed down on the antics a bit to let the dust settle.

In other news, My Favorite Govie and I are back to teaching our Public Policy and Information Security class for CMU.  Much has changed in the time since we started the class a year and a half ago:

• The 60-Day Review was completed and finally released.  Thanks to Melissa Hathaway for the hours she put into this, now let’s get the calls-to-action done.
• The President actually had a press conference about IT security.  Now how to convert that attitude to something actionable.
• We finally have a Cybersecurity Coordinator.  Go Howard!  I think the biggest thing that he will accomplish is to scope his job and build his authority.
• Verizon released their newer, badder, and stronger Data Breach Investigation Report.  Like it or not, they’re still the only people releasing data.

And then some things have stayed the same:

• We’re still wasting half of the Government’s security spending, we just can’t figure out which half.
• The Government’s InfoSec metrics still suck.
• FISMA hasn’t died.
• SANS still reminds us that FISMA is failing.  =)

• In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security
• In Other News, I’m Saying “Nyet” on S.3474
• Could the Titanic have changed course?
• The Spanish Civil War and the Rise of Cyberwar
• Massively Scaled Security Solutions for Massively Scaled IT

Andrew Hay, aside from being an all-around handsome guy, talked on Tuesday at B-Sides San Francisco about his life on the Information Security D-List.  Bill Brenner picked it up for CSO-Online and now it’s preserved for posterity.  Andrew’s been interviewing D-Listers and blogging the interviews.  They’re awesome inspiration if you’re one of the unsung heroes who go to work, grapple with the compliance hydra or the security operations tarpit all day, and go home to some conference videos so you can learn new skills and move on to the next project.  Yeah, I’m a D-Lister just like you folks, and I have tons of love and respect for all of you.

• LOLCATS: Defending our Cyber-Turf
• Lolcats take on Laws, Sausage, Cyberwhatzits, and PCI
• A Stable InfoSec Program?
• Shmoocon: Less Moose, More LOLCATS
• IKANHAZFIZMA and Transparency

OK, so I lied unintentionally all those months ago when I said I wouldn’t write any more PCI-DSS posts.

My impetus for this blog post is a PCI-DSS panel at ShmooCon that several of my friends (Jack Daniel, Anton Chuvakin, Mike Dahn, and Josh Corman, in no particular order) were on.  I know I’m probably the pot calling the kettle black, but the panel (as you would expect for any PCI-DSS discussion in the near future) rapidly disolved into chaos.  So as I’m sitting in the audience watching @Myrcurial’s head pop off, I came to the realization that this is really 4 different conversations disguised into one topic:

1. The Cost-Benefit Assessment of replacing credit card # and CVV2 with something else–maybe chip and pin, maybe something entirely different–and what responsibility does Visa and Mastercard have towards protecting their business.  This calls for something more like an ROI approach because it’s infrastructure projects.  Maybe this CBA has already been done but guess what–nobody has said anything about the result of that analysis.
2. Merchants’ responsibility to protect their customers, their business, and each other.  This is the usual PCI-DSS spiel.  The public policy equivalent here is overfishing: everybody knows that if they come back with full nets and by-catch, they’re going to ruin the fishery long-term for themselves and their peers, but they can’t stop the destruction of the fishery by themselves, they need everybody in the community to do their part.  In the same way, merchants not protecting card data mess over each other in this weird shared risk pool.
3. Processor and bank responsibility.  Typically this is the Tier-1 and Tier-2 guys.  The issue here is that these guys are most of the processing infrastructure.  What works in PCI-DSS for small merchants doesn’t scale up to match these guys, and that’s the story here: how do you make a framework that scales?  I think it’s there (IE, the tiers and assurance levels in PCI-DSS) but it’s not communicated effectively.
4. Since this is all a shared risk pool, at what places does it make sense to address particular risks?  IE, what is the division of roles and responsibilities inside the “community”?  Then how do you make a community standard that is at least reasonably fair to all the parties on this spectrum, Visa and MasterCard included?

PCI-DSS Tag Cloud photo by purpleslog.

There are a bunch of tangential questions, but they almost always circle
back to the 4 that I’ve mentioned above:

• Regulatory capture and service providers
• The pitfalls of designing a framework by committee
• Self-regulation v/s legislation and Government oversight
• Levels of hypocrisy in managing the “community”
• Effectiveness of specific controls

Now the problem as I see it is that each of these conversations points to a different conversation as a solution and in doing so, they become thought-terminating cliches.  What this means is that when you do a panel, you’re bound to bounce between these 4 different themes without coming to any real resolution.  Add to this the fact that it’s a completely irrational audience who only understand their 1 piece of the topic, and you have complete chaos when doing a panel or debate.

Folks, I know this is hard to hear, but as an industry, we need to get over being crybabies and pointing fingers when it comes PCI-DSS.  The standard (or a future version of it anyway) and self-regulation is here to stay because even if we fix the core problems of payment, we’ll still have security problems because payment schemes are where the money is.  The world as I see it is that the standards process needs to be more transparent and the people governed by the standard need a seat at the table with their rational, adult, and constructive arguments on what works and what doesn’t work to help them do their job to help themselves.

• Why We Need PCI-DSS to Survive
• Preliminary Findings on Cybersecurity Review Now Out
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 5
• Where For Art Thou, 60-Day Review
• Blow-By-Blow on S.773–The Cybersecurity Act of 2009–Part 3

First, it was thundersnow.  Then a couple of weeks later, we have snowmageddon V2.0 and 3.0 right in the middle of ShmooCon.  Now maybe on Monday we’ll get even more.  How could IKANHAZFIZMA refuse this as a lolcat topic?

• IKANHAZFIZMA and Transparency
• Cyber-FEMA LOLCATS Prepare for Cyber-Katrina
• Happy New Year
• Exhaustive Security Testing is Bad For You
• LOLCATS: Defending our Cyber-Turf

So it started with an idea.  How cool would it be to get everybody to install a QR code reader and read temporary tattoos off each other?  Anyway, at Shmoocon I walked around with a bag of QR temporary tattoos much to the delight and chagrin of the hackers assembled therein.

The howto:
#1 Get a barcode generator. I use zint, it’s my favorite tool for generation.  For those of you on Ubuntu or Debian, I have packages built for you.  And give the zint guys some money while you’re at it, they use the funds to buy standards and make zint work with every symbology known to mankind.

#2 Get a layout program. I use Inkscape.  Key here is that it has to be able to import .svg files and be able to flip images horizontally.

#3 Get printable temporary tattoo paper. It’s not really cheap, but I found kits on tattoofun.com.  The kit consists of waterslide temporary tattoo paper, adhesive sheets, and an instruction sheet.

#4 Make .svg Barcodes! I load up zint and toss some text at it, then use the QR symbology.  Some examples:

• sms:7035551234 body:Greetz from teh Internetz
• MATMSG: TO:shredder@guerilla-ciso.com; SUB:Test; BODY:This is a test. Please reply if received.;;
• MECARD:N:Wizzleteague, Stinky;ADR:1234 Main St, Arlington, VA 22202;TEL:+17035551234;EMAIL:shredder@guerilla-ciso.com;;
• Hi, I’m Quine. I haz a RAGE! https://twitter.com/quine
• I went to Shmoo and all I got was the flu
• BTW, if you want to pay me to make QR tattoos for promotion events, drop me an email.

#4.5 Add in QR error correction. The more error correction you use, the more data in the barcode so the smaller the blocks are.  However, some error correction compensates for distortion and glare.  IIUC, Zint automagically adds in 20% error correction.  I’m not sure what the magic number here is because it depends on the size of the printed barcodes.

#5 Export barcode from zint. SVG is awesome to save as because you can scale the barcodes up as much as you want and they won’t get all pixelated-looking.  You can grab a ton of the barcodes I made here.

#6 Import barcode into inkscape.  File=>Import then select the .svg file you want.  Since the barcodes are svg, you can scale them awesomely.  For mine, I set up guidelines so I could lay out rows proportionately.  Be sure to lock the object proportions or you’ll get hideously warped QR monstrosities that nothing can read.  You can grab my sheet of barcodes here.

#7 Make “The Big Flip” and print.  Inkscape-specific: Edit=>Select All   followed by   Object=>Flip Horizontal.  Then print the page on the glossy side of the slide water paper.

#8 Add the sticky.  It’s a bit like laminating a map only the adhesive is way more forgiving.  Poke some pin-holes in the adhesive sheet and smooth out all the bubbles.

#9 Cut, peel, stick, wet, pull, read, lol.  You can get a reader here, but the important bits: iTunes Store: Barcodes.  Android: Barcode Scanner.

Lessons Learned:

Laser barcode scanners don’t work because the film is reflective.  Photo-based barcode scanners (ie, most mobile scanners) work pretty well.

You have to make the barcodes bigger than I did.  Mine were .75x.75 inches and due to the glare on the paper and some distortion due to putting them on skin, they were hard to read.  I think maybe 2×2 inches are optimum.

Hackers don’t like informational urls in their tattoos: “I got an add for ZXing, this sucks”.  I think random goofy phrases and skin pwnage would work better than informational urls.

Some people (Quine) weren’t happy with a grab-bag random url and needed their own custom witty saying.  I felt the rage, it has now been fixed.

You can’t read the barcodes until they’re on the skin because of the horizontal flip.  Before you do the flip, print out the barcodes on regular paper.  You can read these easily enough.  Then flip the finished barcode sheet over after you’ve printed it and you can match up the barcode with the non-flipped sheet.  Even better if you use your computer monitor as a lightbox.

• Micro Digital Signatures Howto
• Turning Routers into Firewalls
• Barcode Hacking
• Barcode Hacking Process
• Because Life Isn’t Random Enough