And so begins everyone's claim for Cloud Compliance

Today's blog entry at Mosso Blog

Cloud Sites, Mosso|The Rackspace Cloud’s Flagship offering, is officially the very first cloud hosting solution to enable an Internet merchant to pass PCI Compliance scans for both McAfee’s PCI scans and McAfee Secure Site scans.

While I am all about helping companies meet compliance with whatever technology they are trying to implement there are some facts that seem a little skewed here.

1) They only passed the ASV scan. A scan of the external facing ip addresses as required by requirement 11.2.b. This is great but it's not PCI DSS compliance - it is in fact only one very small piece.

11.2.b Verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, by inspecting output from the four most recent quarters of external vulnerability scans to verify that: Four quarterly scans occurred in the most recent 12-month period; and The results of each scan satisfy the PCI Security Scanning Procedures (for example, no urgent, critical, or high vulnerabilities); The scans were completed by an Approved Scanning Vendor (ASV) qualified by PCI SSC.

2) They aren't processing credit cards - they call an Authorize.net API (SSL wrapper and encryption) and let credit cards flow through to someone else's non-cloud network. Their marketing material shows the API. It sure is neat but again we are still only talking about a piece of the PCI DSS compliance. I am happy that you are not storing credit cards.

3) I don't believe they would be able to PASS an onsite assessment for a RoC but since it looks like they are only a L3 merchant - a SAQ is all they need to fill out.

So why don't I believe they could pass?

Until someone can present a clear picture of the demarc point between the application, virtualization and the physical layers and the controls offering protection between those layers; no QSA will be able to say they are compliant. I have discussions just about the idea of a demarc point between the Dom0/DomU. We haven't even begun to drill into the other layers.

So in this case the merchant's argument might be that they are using a shared hosting provider: (language borrowed from multiple posts in SPSP forum)

A shared hosting refers to a hosting service where many hosted servers reside in a date center connected to the Internet. In shared hosting, the provider is generally responsible for managing servers, installing server software, security updates, technical support, and other aspects of the service.

PCI compliance is the responsibility of the organization who owns the data. In a shared hosting environment where it is truly shared hosting and the client can upload whatever they want, then the client is responsible for ensuring they are using a hosting provider that meets their needs. Simply having merchants that house data in a hosting environment does not impose the requirements upon the hosting provider. There are two basic paths here. 1) the merchants need to ensure they are using a hosting provider that complies with the PCI DSS or 2) the merchants need to ensure they can manage their own systems in accordance with PCI DSS.

I haven't met a Shared Hosting provider yet who is willing to accept the liability of PCI DSS compliance in the cloud - this isn't to say that they aren't all working towards it. So this leaves the merchant responsible for managing their own system - and we fall back to my Dom0/DomU comment and the current problems with providing enough evidence of compliance.

Most QSA's are struggling with the idea of virtualization in general - they either get stuck on the 1 service per server or their view of virtualization is based on their use of VMware or Parallels. QSAs are going to have to either take deep dives into Architecture or they are going to fail companies all over the place.

Finally as I said at CloudCamp last weekend - want to be compliant in the cloud today, treat all information that is stored in the cloud with the highest level of encryption, then it only becomes random bits and it doesn't matter if you suffer a breach.

Me - diving into the deep end and drowning

So this post all got started because I had a hard time with comments someone made about the Kindle. As I type this I see where the term "fanboy" came from. I was reading a post by the Hoff about the Kindle and his Security Thoughts.
To some degree I agreed that the device was missing stuff. I then proceeded to read the comments that followed the post and I took offense. I still don't know why - if I figure it out I will share the news.
I took 4 pages to write this or as Hoff pointed out to me "Um, you know nobody will read that much...that's my point, I think you're going off the deep end... ;0"

So here's what follows...

After some debate with Hoff on twitter - I figured I should bring my comments here. I was moaning about FUD (Fear Uncertainty & Doubt) with regards to the comments made about the Kindle.

I feel like his comments are FUD because with a little research he could very easily have discovered that the holes he decided were there had mitigations or were misguided because they needed some research to see how things really worked.

Both Hoff and Roland support the idea that “security versus convenience trade-offs are getting more slippery these days.” This is a valid argument for dozens of consumer devices – iPhone, iTouch, U3 USB Keys all come to mind immediately.

I feel that Hoff highlights security flaws that are inherent to the device’s individual operational specs. The device doesn’t lock, you can’t control content, etc. Roland chooses to argue that the device is insecure because of the device’s operation on the network. In Roland’s case I had some trouble swallowing them:

1. Amazon now have a copy of any document you convert. Who knows who can see it, if it's been stored somewhere it can be accessed, etc.?

Amazon only has a copy of your documents if you opt to go with the method of sending them docs via email. It costs money. Amazon as well as multiple articles all within a google search show how easy it is to use mobi pocket creator to convert word, and pdf files over – and then with a easy drag and drop right into the kindle. BTW most pdfs just don’t look that goood – it’s a problem with the standard that Amazon chose.

Your response might be that’s too hard, who is going to do the research – if you are actively using the Kindle as a doc repository for docs that shouldn’t be out of your sight then you deserve what you get.

2. Everything on the Kindle apparently runs as root; the device itself is accssible via USB/serial console during boot, and the filesystems are mountable via plugging the device into a computer via USB. Very easy to trojan (or even bot!) someone's Kindle.

I can’t really argue this. I don’t understand it. I don’t know why they did it that way. Seems foolish for multiple reasons.

Now I will debate the statement Easy to Trojan (or even bot!) – hmm well I would not say easy – the preferred vector here would actually be to send you a doc through kindle email and attack that way. But then you need to know my kindle email for that - again with research I am sure you would have me. So now we are relying on Amazon to protect me – well since they have to open the doc/pdf to convert it – you are more likely to compromise them – doubtful first.

3. If you use the Whispernet MVNO service carried across Sprint's EVDO network, note that when you browse the Internet using the Kindle browser, all of your traffic is apparently proxied via Amazon proxy servers (which is totally unnecessary, as EVDO uses routable IP addresses, unlike GSM 3G networks). So, Amazon are MITMing you

Hmm Amazon MITMing me – I like that. Oh wait I am buying their product on their network and reading it on their device (I own it yes but the device is only for Amazon content – much to my dismay). Were I to hazard a guess the only time I ever leave the Amazon network is when I launch the web browser. So yes they are proxying my traffic – they are seeing all my google reader traffic.

4. People can see what you're reading, or planning on reading. People can plant potentially damaging documents/images/audio on the device in order to frame you, given that there's no security when the device is mounted via USB

Hunh, I don’t really understand this. Look at my desk, you can see what I am reading – although you won’t find that I have a small place in my heart for teenage sci-fi fantasy novels – I didn’t get enough as a teen so I still read them now.

5. You've no idea if the Kindle 'phones home' via EVDO if you're reading with the EVDO enabled, or stores up behavioral information and then sends it home when you turn on EVDO or enter an EVDO service area. It's hard to investigate this without specialized equipment or investing the time to root the Kindle, since it uses EVDO exclusively, no WiFi capability.

Of course it phones home – Amazon wants your marketing information just like everybody else. I actually don’t know this to be fact. I would worry more about the fact that the Kindle has GPS (not really but sorta GPS) where oh where has my poor cheating SO gone with her Kindle so I can come and keel her secret lover….
As noted by Amazon:

“The Device Software will provide Amazon with data about your Device and its interaction with the Service (such as available memory, up-time, log files and signal strength) and information related to the content on your Device and your use of it (such as automatic bookmarking of the last page read and content deletions from the Device). Annotations, bookmarks, notes, highlights, or similar markings you make in your Device are backed up through the Service. Information we receive is subject to the Amazon.com Privacy Notice.”

6. The Kindle obvious has the ability to store and trasmit such behavioral information, given that now multiple Kindles on the same account can keep in sync with one another in terms of content on your Kindle, your current location inside a given book, etc. Amazon plan to extend this capability, along with the base ereader functionality, to other types of devices, over time.

Is this information encrypted in any way? If so, is it real encryption, or is it ROT13? Is it encypted only in flight, but at rest, as well?
See my answer to question 5. The real value here is what are your preferences so that they can sell more stuff to you. Why should it be encrypted – it’s a series of numbers identifying your kindle & your accounts token – nothing of value here – well other than the fact that I just ordered a subscription to the Atlantic and the New York Times and I need my Kindle updated.

7. If the Kindle is phoning home, are Amazon selling your behavioral data to advertisers? Even if they're not, are they mining it (in addition to the data you already consciously and voluntarily give them), and is it stored securely (for some value of 'secure')?

I am going to defer to Amazon on this one:

“Information about our customers is an important part of our business, and we are not in the business of selling it to others….Protection of Amazon.com and Others: We release account and other personal information when we believe release is appropriate to comply with the law; enforce or apply our Conditions of Use and other agreements; or protect the rights, property, or safety of Amazon.com, our users, or others….With Your Consent: Other than as set out above, you will receive notice when information about you might go to third parties, and you will have an opportunity to choose not to share the information.”

And finally

“How Secure Is Information About Me?
We work to protect the security of your information during transmission by using Secure Sockets Layer (SSL) software, which encrypts information you input.
We reveal only the last five digits of your credit card numbers when confirming an order. Of course, we transmit the entire credit card number to the appropriate credit card company during order processing.”

8. The Kindle allows you to highlight chunks of books/documents, annotate them with notes, and store them on the device. Are they DRMmed to your particular device, or are they just unencrypted text files, which can be accessed and downloaded via the USB mounting facility (I know which way I'd bet, heh).

Your clippings are .txt files that you can pull right off the Kindle when in USB mode. Why would you DRM to a particular Kindle?

9. I've never used the Kindle Web browser; does it let you store usernames/passwords/cookies for Web sites you access? If so, then they're sitting there on the flash, waiting to be downloaded via USB by anyone who can get hold of the device

The Kindle browser blows. There is no way to say anything good about it. The little configuration it does allow is choosing basic versus advanced mode.
• Set Default View Mode - lets you choose between Advanced and Basic View Modes.
• Clear Cache: Delete temporary Internet files from Kindle browser's cache.
• Clear History: Delete Internet address entries from Kindle browser.
• Clear Cookies: Delete cookies from the Kindle's browser.
• Enable Javascript: In Advanced Mode you can enable execution of Javascript on the pages you visit. Choosing to enable Javascript will probably slow down your browsing speed.
• Show Images: Lets images on pages appear - again, slows down browsing.
In all fairness to Amazon – to get to the browser you have to choose Experimental. I am not sure how security works for everyone but common sense 2.0 tells me that when I find stuff under experimental I shouldn’t trust it with my super secret stuff.
As a side I can’t find password on mine – maybe I will do a deeper dive with some other tools.

Black Hat Europe 2008 wrap up...

So I spent the last week in Amsterdam at Black Hat Amsterdam. I was there for a couple of different reasons.

The first reason involved me taking a class on Reverse Engineering: Application in Malicious Code Analysis. I have been interested in Reverse Engineering over most of my career but never really had any instruction in the art of disassembling something that often doesn't want to be taken apart. Well after this class I am going to be spending some of those late nights in hotels unravelling pieces of malware. Yes, I realize this is an open confession that I am a geek.

The class was taught by Pedram Amini (blog) and Ero Carrera (blog) (twitter).

...Commercial Break...

Quick little story about Ero: Dacort and I have just taken seats in class when Dacort laughs. I look over and ask him what he was laughing at. He pointed to his iPhone and explained that he was tracking #blackhat and #amsterdam. It seems that one of our instructors had just posted to twitter. I laughed now and asked Ero - if he was a Twit. He smiled and said he was. How did you know? We told him about tracking #blackhat and #amsterdam.

Want to know who got him on Twitter - the "Goddess of Security Twit Herding" Mediaphyter. You can find her illustrious list of Security Twits right here.

...Back to the class...

The instructors were great. If you have the opportunity to take the class and are interested in getting a solid basis for Reverse Engineering I highly recommend trying to get into the class at Black Hat: Las Vegas. Ero has already said he his going to try to incorporate some of our thoughts into the next class.

The course outline looks something like this: (note: I am leaving some areas out. This are the areas we concentrated on. The book provided by the class has a lot of great material for later reference.)

Introduction: They queried the class to determine where the general level set was. In our case most everyone was already familiar with IDA Pro but hadn't used OllyDBG as much. I don't believe anyone in the class had ever used IDAPython either.

VM's and Live Analysis: The first day more than half the class was running Windows PCs. The second day more than half the class had broken out there Macbook Pros. Note: The instructors were using Macs as were Dacort and myself. I was using an XP image on Parallels. Turns out that some of the newer malware running around out there has some checks to determine whether it is infecting a VM versus a real live machine.

PE File Format: The Portable Executable (PE) format is a file format for executables, object code, and DLLs, used in 32-bit and 64-bit versions of Windows operating systems. The term "portable" refers to the format's versatility in numerous environments of operating system software architecture. The PE format is basically a data structure that encapsulates the information necessary for the Windows OS loader to manage the wrapped executable code. This includes dynamic library references for linking, API export and import tables, resource management data and thread-local storage (TLS) data. On NT operating systems, the PE format is used for EXE, DLL, OBJ, SYS (device driver), and other file types. The Extensible Firmware Interface specification states that PE is the standard executable format in EFI environments.

PE is a modified version of the Unix COFF file format. PE/COFF is an alternative term in Windows development.

Thanks Wikipedia.

There overview was a really good start to understanding what we were going to be looking at and the bits and pieces that are included in our analysis. There were lots of good graphics to help understand Directories, NT Headers, Section headers, Optional headers, and so on.

Overview of Analysis Tools: This section was where the real fun began. We got to learn about the arsenal of tools to examine malicious malware code. We discussed Debuggers, Disassemblers, Decompilers, and Python.

(Dis)Assembly: The instructors called this a crash course. I thought they did a pretty solid job of getting everyone on the same page about what was going on in the assembler.

IDA Pro: This section alone could be a class. I believe both instructors even mentioned this. They provide a solid overview of what the tool is, and then they took the class through customizing the tool for use. I had never thought about how hard it would be to teach a class that requires that we all use a very complex tool doing complex work and the necessity to have everyone looking at the same screens. Again the instructors were the stars.

note:The included CD for the class is a valuable resource. The instructors have provided code examples, solutions, and software. There are configurations, extra plugins, and so much more.

OllyDBG: the "Cracker Friendly" tool. If you have ever considered RE, read about RE or talked to an RE practitioner - the all recommend this tool. Best part of this tool - Free as in beer. There are countless features, the instructor mentioned that he is still finding new ones and super documentation. I won't talk anymore about this section - the class covers the tool extremely well.

Executable (Un)Packing: I loved this section. During the class you review a piece of malware that utilizes ROT13 to hide some of the nastiness. This section of class discusses how this works, how to pack and unpack your own code, how to use statistics to examine packed code, how to unpack traces. The instructors also provide some statistical analysis of common packers in use and what they are seeing as the future. This was one of my favorite sections of class.

As I mentioned earlier - the class/book/cd has a much more material. There are several more sections we covered, resources we were directed to, and questions answered. Again I highly recommend taking this class if you are interested in Reverse Engineering.

The other reason that I was present for Black Hat Amsterdam was to demonstrate that Director part of my title now. I helped in our booth to answer questions about the services that we offer, and our perspective on security. Ask anyone in the biz today and they have a perspective on security.

Some how along the way I ended up being interviewed for Global Security Mag. It's a french magazine about Security. The interview can be found here. I had a rough translation I had done of the interview but some how I have misplaced it on the HD. One friend's comment on the interview was, "You sound so much smarter in french." Thanks. My father offered to send the article along to my old French professor.

I was also caught on camera in a quick - alright I can ramble on if given the chance - video for Help Net Security on PCI. I am a little scared about this interview. I managed to jot a few notes down before walking in to sit in front of the camera but now in retrospect I might have been garbling all kinds of things together. We will have to wait and see what the final cut looks like. The video guy told me that this was the first time he was actually interested in what was being said about PCI. I will take that compliment and run.

So the show wrapped - managed to visit a party, hit a club, and have some amazing italian food (check out the Carpaccio al parmigiano and the Pasta Parmigiano- it's got whiskey fire, and glorious cheese.)

All it takes is time...

Here's the situation: Henryk and Karsten are sitting around drinking beer and one turns to the other and says, "hey since we aren't doing anything let's take a powerful microscope and take apart the MiFare RFID chip." (this is complete fiction - well the beer drinking part - I wasn't there they could have been drinking wine for all I know.)

Compterworld has an article discussing the MiFare RFID tag hack. A RFID tag used by "Millions upon millions of MiFare Classic chips are used worldwide in contexts such as payment cards for public transportation networks throughout Asia, Europe and the U.S. and in building-access passes."

Hypothesis: "Hmm wonder how these MiFare RFID things work?"
Process: Take them apart
New Hypothesis: "You think there are any vulnerabilities in this thing?"
Process: Holy crap these things are as secure as my credit card data at the grocery store.

What I really want to point out here is that given time it can be broken. I have heard on multiple times from Vednors, Programmers, Engineers - our "insert name" can't be hacked, broken or abused for nefarious purposes.

Well boys and girls (equal opportunity) you are wrong!

Lesson to take away from this. Don't rest on your laurels (I am in Athens, Greece - seemed like a good phrase). Keep innovating - while today it looks like it can't be broken, tomorrow some kid might try to put it in the microwave.

Introducing: Were I taking this seriously...

So in an effort to separate the wheat from the chaff I decided to spin off my InfoSec thoughts from my wanderings and exploration of the world.

My initial plan for this little corner of writing will be for me to discuss things about Information Security that crop up on a daily basis. Let's say this is going to be about "iron sharpening iron."

I am also planning on using this space to dump bits and pieces of wisdom I might learn along the way to being the best InfoSec manager in the world (this is humor - I am sure I will provide more than enough reasons to flame as this goes along. Please learn to see my sarcasm before we get to far into things.)

I am not a super h@x0r - I have never claimed to be. I am not a Bruce Schiener or a Richard Bejtlich, or even a Dan Kaminsky (although I do work with him).

I am a former network engineer who always had a belief that security should be included in everything you built. I blame this on my own misspent youth. My father watched me blow my eyebrows off more than once doing stupid things. After awhile of doing destructive things that might hurt you, suddenly security (protection of self) became important.

I started college as a Sociology Major (people are interesting) - then changed to Mechanical Engineering (I am going to build robots) - a quick stint in Biology: Marine Biology (I read Lilly - one of his pals was Timothy Leary). I had a car accident and things changed - I ended up in Computer Science and did well. I had a computer from the age of 9 on so it made some sense (thanks to mom and dad on that one).

I enjoyed computers - introduced some neat ideas to the use of computers and biology at my university (if I had known that there would be a field to spring up years later called BioInformatics I might have stayed in that) and then bounced to Colorado to be a ski bum.

My diverse course of study has provided me with different ways of looking at things. Those in the security industry realize that having alternate viewpoints will help you figure out where the next bad thing is coming from.

As a side, there was a post in the last month about the way InfoSec people think. Is it learned or is it innate knowledge? See Bruce's thoughts at link. You can see one rebuttal at link.

Sorry Bruce - I am going to lean towards the learned ability. Proper scientific method at use here:

1) Define the question (how would i break this web application? steal this car? compromise this RFID tag?)
2) Gather information and resources (Google, Secunia, milw0rm, RFID)
3) Form Hypothesis (hmm if I add a ' there will things go awry?)
4) Perform experiment and collect data (well look at that - the database just dumped)
5) Analyze data (oh looks like someone has been keeping credit card data)
6) Interpret data and draw conclusions that serve as starting point for next hypothesis (does everyone using Joomla have Remote File Inclusion Vulnerabilities?)
7) Publish results (Google, Secunia, milw0rm, RFID)
8) Retest (here come the script kiddies)

So while I might agree that InfoSec people are a little different (if you don't agree you have missed oh every Defcon since the dawn of time) - I am not going to agree that they go at things differently than the next guy. InfoSec professionals just come up with better hypothesis to test.

Well that's enough for a solid introduction. I will be adding more as I go along. Here's a brief snippit of where I will be over the next couple of weeks:

"Next I am in Amsterdam all week for Blackhat Europe. The first couple of days I will be in class learning Reverse Engineering: Application in Malicious Code Analysis. I am really looking forward to the class. It should be interesting and allow me to be more successful in my on reverse engineering assignments. I wrap that up and zip back to the States on the 29th.

I will be in Seattle for a week (time to practice being a manager) then I am off to San Francisco for RSA. There I will get to practice my new Director skills as I begin the process of moving IOActive forward in their information security offerings (glamorous words for me being a sales guy for a week). I will also be there as a technical resource to help the real sales people discuss what we can do as a resource for an organization. I am really excited about this. I have begun to make some new contacts and I am really looking forward to increasing the range of discussions and add my own input to the security community.

After that long week I will be back in Seattle reviewing what I learned at RSA and preparing for a trip back to Germany. If you don't follow me on Dopplr let me know and I will add you. My travel schedule is crazy...."

Hope to meet you and see your comments in the future.