I finished a great training session today.  Everyone in the class really enjoyed the entertainment and several people described me as “animated” and “high energy”.  I hope that’s a good thing and I didn’t overdo it on the coffee.  One of the participants offered me a complimentary PayPal Security Key.  These are basically Verisign key fobs used for two-factory authentication.  These retail for about $15-20 but PayPal sells them at cost for about $5.

Being the security geek I am, I immediately enrolled it with my PayPal account.  I know nothing changed really, but I somehow felt more secure about my account (which I never use.)  I told Chipmonkey who immediately asked, “What if you loose the token?”  “Uhm… then I can’t log in… or have to jump through several hoops to log in w/o it.”

I think the mass market adoption of any two-factor technology will ultimately be in the form of cell phone payments.  Either your phone can be loaded with a “soft” token, or you simply get an SMS message with an authorization code you can enter into a POS.  Whatever the future holds, it’s nice to feel a little more secure in the present.

Popularity: 11% [?]

I’ve spoken with several vendors at RSA and some are better than others at positioning their product within a specific market.  This year, everyone is talking about two things at RSA: risk and regulatory compliance.  Of those, what I really care about is PCI and specifically the payment services space.  I’ve learned some of the good and bad ways that vendors market their materials.

The following are a list of several common pitfalls of vendor marketing:

1. Promising the world - Every product seems to address PCI compliance… and GLBA, HIPAA, SOX, and if asked I’m sure the vendors would say they address XYZ LMNOP compliance.  The problem with this is that of over committing and under delivering.  Vendors can tell their VC firms their product will save the world, but never tell potential customers - unless you plan on delivering in a big way.
2. PCI DSS Mapping - The next step up from spelling PCI is to perform a 1-to-1 mapping of every single PCI DSS requirement to your product.  Again, this is an error of promising too much and never really delivering on any.  Companies that read the detailed PCI DSS requirements want to address as many of them as possible so they find ways that their products can meet their custom interpretation of each requirement.  Many marketing people consider this to be understanding their client’s needs, when in all reality there is no one product that meets every single PCI DSS requirement.
3. Being agnostic to the data - In an effort to be everything to everyone, many vendors say their product is agnostic of the data.  We can protect it all!  The problem again is that you become a generalist and do not show anyone that you understand the specific needs of their data.  Sometimes it’s good when your product can protect all data, regardless of type, but how do you communicate to each customer that you understand their needs?

When entering the Payment Services space it is paramount that vendors understand the specific business needs of the market.  Vendors need to understand the top problems companies have in addressing compliance and how their product eases those problems.  Without a solid understanding of the data and the market’s business needs a company may struggle communicating with their prospective customers.

Also, companies want their vendors to educate them.  I’ve written about this before, but it’s paramount that vendors understand their clients market better than their clients do.  A potential customer wants to visit a vendor website and be educated about the current business needs and other roadblocks they have not yet encountered.  If a vendor can accomplish this they can reach the coveted position of being a market leader - and more importantly, someone their customers can trust and respect.

For more information on entering the Payment Services market space, please check out our service offering.

Popularity: 25% [?]

Over the past few weeks I have received hundreds of emails from vendors asking for a meeting at RSA.  As most media flacks, I’ve ignored these for the most part, but replied to any that mentioned “PCI” in their product description.

I’ll be attending and blogging at RSA 2008 and would like to interview as many product vendors as I can as they relate to the Payment Card Industry.  If you have a product positioned towards PCI compliance or the Payments Industry, I would like to meet with you.

Please email me or call direct (number on the blog as always.)

Popularity: 31% [?]

It has come to my attention that software vendors do not fully understand their responsibilities regarding Payment Application Best Practices (PABP) compliance and their customers’ PCI Data Security Standard (DSS) compliance. PABP compliance does not automatically imply PCI DSS compliance and visa versa. What follows is a recent real-life example of how a major vendor handled this situation and how it adversely impacted their customer.

One of my clients is implementing a new point-of-sale (POS) system in one of their operations so that this operation will be PCI DSS compliant. This POS vendor is not only providing the software solution but is also providing remote management and support of the solution.

The first problem my client ran into was their demand that the contract with the vendor contain language to ensure that the vendor’s services being provided were PCI DSS compliant. The vendor explained that their software was PABP compliant and that they were therefore PCI DSS compliant. We explained that the software was only part of the equation because the vendor would be remotely administering the system and that those services needed to be PCI DSS compliant. The vendor continued to argue that their PABP compliance was all that was needed but finally relented to the PCI DSS compliance provision.

We are now assessing the implementation of the vendor’s software for revising their PCI Report On Compliance (ROC). While the software is definitely PABP compliant, we have consistently had difficulty getting information out of the vendor regarding how to assess my client’s implementation of the solution. They have finally, and very reluctantly, admitted that cardholder data (CHD) is stored encrypted on the server at each location. In very tense discussions, they have also finally relented and released the process for managing the encryption keys to my client for their management. My client was relying on the fact that since the software was PABP compliant, they would not have to worry about additional controls. However, my client now has to rapidly make implementation changes to make sure that they meet the PCI DSS requirements for data center monitoring and controls because the new solution stores CHD locally on each server.

All through this process, the vendor has been arrogant and indignant. They have repeatedly stated that as they understood the process, PABP compliance was all they needed to be compliant with all PCI processes.

This has been meant to give software vendors a relevant example of why it is so important for them to be forthcoming with all information regarding their solutions with their customers. There is important information regarding the solution that the customer needs to know so that their implementation will be PCI DSS compliant. PABP compliance means that an application properly protects, manages and controls CHD. It does not mean that your customers will not have to implement their own management procedures and controls at their end to ensure their PCI DSS compliance.

If a vendor is providing management or other services to their customers that are covered by the PCI DSS, vendors need to understand that those services are not covered by any PABP compliance process and that these services need to comply with the PCI DSS.

And this situation will not change with the introduction of the PA-DSS.

Popularity: 47% [?]

(This is republished from our December 2007 newsletter. To read them all as they are released be sure to subscribe or check it out online.)

In 2007, compliance was the name of the game and every other vendor claimed their product would comply with just about everything, including the building codes for installing a kitchen sink. As 2008 approaches we find the term “GRC” popping up as companies try to tie together Governance-Risk-Compliance for a trifecta of sales terms. Instead of branding and marketing, a movement is growing that calls for product vendors to educate their customers about their product and the specific issues that merchants or service providers may be facing. Here’s a short wish list for product vendors in 2008.

1. Educate me! Having a logo that says your product makes me compliant is nice but it’s no longer a differentiating factor. I need to choose between 10 vendors that all claim the same thing. I also need to make sure I’m choosing a product that will solve our problem and not get me fired for implementing. What I want as a consumer is for my vendor to know more about my compliance issues than I do. I want their web site and marketing materials to educate me about the issues I know and those I am yet to encounter.
2. Never over commit and under deliver! I don’t care if your product cannot bake me bread in the morning, I just want to know what it’s true capabilities are so I can make educated comparisons. Maybe your product compliments another I already have, but I won’t know that if you tell me it solves all the world’s problems. I would home vendors in 2008 have a crystal clear message about specifically what their product can and cannot do. This lends itself to my vendor understanding the compliance and risk areas first (see above.)
3. Define the space you support! Nothing makes me feel better about choosing a vendor and knowing they will be around than seeing them define the space they support. I want my vendors to be the movers and shakers who define the standard and explore uncharted waters. I want my vendor to own the conversation surrounding their product space and talk to me about it.
4. Be connected! It is especially important with new vendors that I know they are connected and supported by people I know and trust. Word of mouth is stronger now more than ever, and I will make decisions based on the words and recommendations of those I know and trust. I want my vendor to connect and collaborate with others I know, so my decision grounded and secure.

Popularity: 24% [?]

Much like other professions, end-of-quarter is always an interesting time for anyone who works in the PCI space. Working for an ASV allows me purview into a flurry of activity, as a significant number of merchants invariably wait until the last minute to run their compliance scans; not bothering to allow enough time for things like…oh, I don’t know…remediation.

Understandably, the stress-levels run high when merchant X runs their scan, only to find a vulnerability that is particularly complicated to fix (e.g., XSS — well, for most merchants anyway). The natural thing to do? Contest it of course! Never mind the fact that there are more pragmatic and productive options available. I’ve dealt with several individuals who’ve insisted on contesting vulnerabilities for the simple reason that they “just want a clean report“. The most recent of which was when I took an escalation from a large pharmaceutical company.

The problem: The merchant had 2 web-servers that failed to respond consistently to our HTTP tests. This prevented us from accurately/completely evaluating their vulnerability status.

Our contention: As PCI is a compliance standard, failure to effectively evaluate the servers meant that we couldn’t say whether or not the systems were vulnerable. We therefore were unable to certify the servers as being PCI compliant.

Their contention: There were several actually; the most compelling of which was something to the effect of Your scanner can’t find anything wrong with our system!.

The real headache started when I refused to clear them. We needed to find out why the web-servers were inconsistent in their responses so we could get a clean scan. Part of the problem was that they didn’t know why; the other part was that they seemed to lack the technical expertise to investigate the issue. Their solution? Bullying.

They started by becoming rude, they accused me of “intentionally making this more difficult than it is“, they called my intelligence into question (not that my wife doesn’t on occasion, but at least she’s nice about it), they threatened not to renew their license and they demanded to speak with my management. My point isn’t to rant about this particular merchant or complain about the mean people out there in the cold, harsh world. None of this should come as a shock to anyone. It’s simply to point out that some merchants have engaged in this type of behavior, will continue to do so as long as it remains effective, and have doubtlessly succeeded at one time or another, in browbeating some poor support-rep into providing an exception when it wasn’t warranted.

It’s a truism in the infosec space that security is a people problem, and any reasonably robust security policy will address this kind of social engineering. So what will PCI do about it?

Popularity: 34% [?]

That’s right, Hackistan! In a viral marketing effort to bring attention to the problem of application security, Fortify Software has developed the website Discover Hackistan and all the hoopla that goes with it. They have a blog, news from Hackistan (the ticker is hex encoded), and the HIT (Hackistan Institute of Technology).

If you want to become a citizen, you can. All you need to provide is your: name/handle, SSN, bank PIN, and favorite password. =)

Popularity: 30% [?]

A few weeks back I was invited to the Qualys annual conference in San Francisco. Their theme was Software as a Service (SaaS). No sooner had I returned than CIO Magazine has Software as a Service as their cover article. I think they are on to something here, that is bigger than just security or software.

While at the event I had a chance to speak with many on the Qualys team (some of whom I had met just days before in Tokyo.) One of the most interesting characters was Philippe Courtot, the Chairman and CEO. He is a consistent entrepreneur who, aside from being well connected, is well informed about the industry. He is French, a physicist in his prior life, and enjoys extreme skiing as a sport.

He purports that software is moving to a service (or subscription) based economy. For example, take Google with their online service based suite of office tools (word processor, spreadsheet, email, calendar, etc.) We made a bet on Windows Vista being the last operating system that Microsoft makes, with his argument being that all software will move to a service based offering. (Bill, please release another operating system or I loose the bet.)

Qualys has put their company where their mouth is by releasing QualysGuard. One thing you may not know is that Qualys is the approved scan vendor (ASV) of choice for most merchants. Why is this? Because the majority of companies listed on the ASV list actually resell Qualys. This means that Qualys scans a large percentage of all PCI compliant merchants.  This new service offering of theirs delivers another type of SaaS — the Security as a Service.

I’m now wondering how many other companies will follow suit and offer Security as a Service and what other products can be delivered via this method. We already offer this (partially) via managed service companies. These would be your remotely managed IDS and audit log review providers. But managed services are still only partially on-demand security.

The question is: what, when, and how will the security industry move to a service based offering? Is this something we want, need, or could use?

Popularity: 49% [?]

As we move into year 2 and 3 of PCI compliance for many companies the question I’m left with is, “how does one stay compliant?” Several QSAs have related stories to me of happily helping their clients get compliant in year 1, but frustrated when they show up 12 months later to find out the company was not maintaining that compliance.

Sometimes people focus too much on the event of compliance and miss the fact that they need to maintain that secure state over the period of 12 months. What does a QSA do if they audit a company over and over only to find out they are only compliant and secure around the time of the audit itself?

One of my (and many others’) frustrations is that companies are focusing on the point-in-time compliance instead of continuous security throughout the year. We have already had the conversation about compliance vs. security, but when is compliance/security going to become a continuous event?

Popularity: 30% [?]

I just returned from attending InfoSec Institute’s AEH course. Given the relevance of penetration testing to PCI, I thought that it would be worthwhile to post a review for anyone who’s considering attending.

Vendor:
InfoSec Institute
I hadn’t heard much about InfoSec Institute previous to doing research into pen-testing training. What ultimately helped to make my decision was my familiarity with The Shellcoder’s Handbook and that it’s lead author was going to be teaching the particular session that I was considering attending.
Course:
Advanced Ethical Hacking: Expert Penetration Testing
The course is styled for those who have an interest in moving beyond simply launching exploits at a target, as the meat of the course is in vulnerability discovery and exploitation. This is a 5-day/40-hour training session.
Prerequisites:
In addition to the prerequisites noted on the webpage, the instructor stated that some knowledge of C/C++, knowledge of basic assembly/memory management, and familiarity with the first five chapters of The Shellcoder’s Handbook were required to get the most out of the course.
Instructor:
Jack Koziol
Jack was certainly one of the most knowledgeable instructors that I’ve had. The great part about him was his ability manifest that knowledge in the form of a concise and self-assured teaching style. Not only did he readily provide clarification with regard to the course material, but he had plenty of real-world information and anecdotes from his various pen-testing engagements.
Course Materials:
I found the course materials to be very good overall. Each student received a copy of The Shellcoder’s Handbook, a high-quality lab manual, a CD containing PDF copies of the instructor’s PowerPoint slides and a CD containing a number of “ethical hacking” tools. The book and lab manual were the best resources by-far; the CDs were lacking however. The slides were merely provided speaking points for the instructor, and so were void of much in the way of detailed information. The hacking tools — while useful — were certainly outdated (e.g. nmap 3.75, circa 2004).
Certification:
Certified Expert Penetration Tester (CEPT). I’ve been known to assert that certifications that don’t include practical exams are worthless. I’m quite happy to report that the CEPT has gone from a simple 100-question multiple-choice exam to a 50-question multiple-choice exam with a practical. I found the multiple-choice portion to be not unlike other certifications — exceedingly easy. Though we had 2 hours allotted to us, I was able to finish within 15 minutes with a 98%. However, a passing grade on the multiple-choice means that the student receives an e-mail within a week that contains instructions for the practical exam. According to the instructor, the practical consists of finding vulnerabilities in 2 binaries, writing exploits for them, and reverse-engineering a 3rd binary.
Daily summary:
Day 1: The first day was somewhat disappointing, as it was much more tool-centric than I had anticipated. We looked at “advanced” recon and stealth techniques such as idle scanning, moon-bouncing, IDS blinding, and so forth. I’m not — by trade — a pen-tester, but nothing presented here was very novel or surprising. Still, going through the lab exercises and actually using the tools was a nice confidence builder. The day ended with a capture-the-flag exercise that was somewhat glitch-prone (network/target stability issues), so it wasn’t all that fun.
Days 2-3: Days 2-3 blended together somewhat and were definitely the core of the course. Topics included buffer overflows, fuzzing for vulnerabilities, writing exploits with Metasploit, writing shellcode, and format string bugs. Jack was able to simplify these complex ideas and — at least on a basic level — make them accessible to the class. The capture-the-flag exercises on each day went much more smoothly than the first day; both centering around finding vulnerabilities and writing exploits for them. Whee!
Day 4: Though I learned a great deal from the day 4 modules, the material was only tangentially related to penetration testing. Cracking binaries, CDROM protections, cracking with SoftICE, cracking with IDAPro and detecting debuggers/disassemblers. The capture-the-flag exercise involved cracking a couple crackmes.
Day 5: This was the short day, as the goal was to end the class by 3pm. Unfortunately, trying to stick to this time-table meant that the quality of the course suffered a bit. We were supposed to study web application penetration testing — SQL Injection, proxy poisoning, and the like — but were only able to get through 2 of the 5 modules.
Critiques:
Slides: As previously mentioned, the slides lacked detailed content. I would have preferred either better slides or supplementary MP3s.
Tools: The free toolkit seriously needs updating.
Thoroughness: Due to the amount and depth of material that we needed to cover, several modules were glossed over or skipped altogether. IMHO, InfoSec needs to either re-focus on the core (days 2 and 3) material or extend the course to 7-days. It should also be noted that the course — minus the capture-the-flag exercises — was supposed to be 40-hours in length, but the shortened final day meant that we only went through 3-hours of material vs. 8-hours in previous days.
Content: The web-app modules were obviously an after-thought and their presence didn’t make as much sense as the other modules. Again, there needs to be a re-focus on the core material.
Prerequisites: Unfortunately, there were a few people in the class who not only lacked the extended prerequisites mentioned above, but the base prerequisites mentioned on the website. This meant that the instructor was tied up with basic/mundane questions, rather than spending more time with questions on the course content. Somewhat along these lines, several students — myself included — had their copies of The Shellcoder’s Handbook shipped to them late (distributor error). InfoSec’s operations manager stated that “it will not hurt you in any way with the progression of class“, which was in direct contradiction to the instructors assertions.
Class size: The InfoSec website states “Guaranteed small class size (less than 10-16 Students)“; I counted at least 22 students in my class. While not a deal breaker, I believe that we could have gotten though more content had there been fewer students.
Conclusion:
My expectation wasn’t to become an expert vulnerability researcher, but simply to further my knowledge a bit. Despite my critiques, I was quite happy with the course overall, as well as the support that I got from the sales team. I wouldn’t hesitate to recommend the AEH course to anyone with a technical bent who is interested in progressing beyond point-and-click pen-testing.

Update - 2007.07.31:
Based on the critiques of the course, I am attempting to take advantage of their free re-sit policy. On 05.08, I was “confirmed” for a re-sit of the August class in Las Vegas and was told that the details (e.g., times, location, etc) would be forwarded on. After no contact for a month, I e-mailed again on 07.08, 07.13 and again today…still no response.

Update - 2007.08.02:
After CC’ing another InfoSec Institute employee and posting an update to this blog, I finally received a response to my 07.31 e-mail. It looks like I’ll be at the Las Vegas class later this month. I’ll continue to post updates and any critiques of the class.

Update - 2007.09.27:
Unfortunately, my re-sit was pushed back by my employer (too busy). I’ll add another update if/when I eventually do the re-sit. On the positive side, I was contacted by InfoSec and was told that I had passed the practical portion of my CEPT. One odd thing about it — when I completed the multiple-choice test, the screen clearly stated that I passed with a 98%. When I got my CEPT certification — which included a breakdown of grades — it stated that I had received an 86% on the multiple-choice portion. I didn’t address it with anyone however; a pass is a pass, and I don’t care enough to pursue it.

Popularity: 22% [?]