It's that time of year again--RSA is just around the corner. When the conference folks put up the speaker list this year I was pleased to see a little red star next to my name, which I learned means I'm a "Top Rated Speaker" from past years. Yay, me :P

This year I'll be speaking with Jeremiah Grossman from WhiteHat Security on Correlating Static and Dynamic Security Results. This is a topic we've both been interested in for years (along with half the security community, it seems), but this is the first time we both feel like we have some significant contributions to share. In particular, we're excited to talk about real-world examples of correlation we've seen in the context of Fortify on Demand.

If you just can't wait until March, Jeremiah and I recorded a podcast with RSAConference.com Editor-in-Chief Jeanne Friedman where we preview the session.

Some manufacturers of secure USB memory sticks have forgotten to encrypt the contents using the user-supplied password. Instead, they use a hardcoded password to decrypt the contents. They use the user-supplied password as an authorization check. Upon successful authorization, the stick uses its hardcoded password to decrypt the contents.

If you know the hardcoded password and you can bypass the authorization check, you can decrypt the contents without knowing the user's password.

The folks at the security firm SySS have done just that... check it out here.

Technorati Tags: data security memory stick encryption authorization authorisation USB

Speaking from personal experience, having Tsipenyuk as a last name can be inconvenient due to pronunciation and spelling errors, but the last name O'Neil can cost you an identity. I came to realize this when I got married and, being convinced by many around me, exchanged my complicated scary-looking Ukrainian last name for this simple and straightforward Irish one. Turns out, my problems were just beginning.

I will skip over describing the pain and frustration of filling out millions of request forms asking to change the last name on millions of the accounts from one to another, and making millions of photocopies of the marriage certificate to send along with the forms as a proof. I won't start a discussion on why changing your last name on a credit card account is significantly less painful than doing the same for an airline frequent miles account. I will proceed straight to the really good stuff.

• The Social Security office simply dropped the single quote from my last name even though my request form clearly contained one. When I inquired about it, the response was that their system automatically does this and treats O'Neil and ONeil the same.
• TD Ameritrade and Wells Fargo sites (as well as many others) don't allow single quotes in their passwords.
• The zenTrack project management and bug tracking software escapes single quotes, but does so incorrectly, leaving backslashes for display.

The list goes on--these are just a few examples of what I keep running into. I am sure some of you see what I'm getting at. Clearly, all of the mentioned inconveniences are caused by the fact that single quote is a special character that needs to be correctly handled by software behind all these institutions. Some institutions choose to deal with the problem by simply not allowing special characters, others attempt to escape them. Still others--remain vulnerable. It boggles my mind that this one character causes so much pain and makes it necessary for me to remember what version of my last name I should use at which point. Why is there still no standard way of dealing with this problem? Why is everyone still doing their own thing?

It shouldn't be a surprise to you that my advice to the software developers writing code for these institutions is to create standards that allow them to be consistent and correct in their handling of names as "special" as O'Neil. I still hope that one day the standard everyone adheres to will exist, and then I will be an O'Neil at all times. Until then we'll keep running into problems similar to this one.

Apparently there were more people listening than we realized. President Obama has named Howard the new Chief of Cybersecurity. Congratulations Howard!

Today we are officially launching Fortify on Demand. You can upload your compiled code, and we'll generate a vulnerability analysis report. Give us the source code too, and we'll include information about the offending lines of code. Give us a URL where the code is running, and we'll create an integrated static/dynamic analysis report, with the dynamic results courtesy of our friends at WhiteHat Security. (Press release here.)

I got started on static analysis in order to help programmers write better code, but I've learned there's a lot to be said for simply creating a code assessment. Non-programmers deserve answer questions like "Did I get what I paid for?" But non-programmers aren't usually in a position to make static analysis fly. And even if they are, the norm is a static analysis report that says things one way and a dynamic analysis report that says them another. Our early adopters (thanks guys!) are big on the ease-of-use factor. Multiple assessment techniques coming together in one report without any fussing around with code. What could be better?

If you want a closer look at what we've built, sign up for the webinar Jacob West and Jeremiah Grossman are giving on Jan 14. Register here.

- Python (new language)

- Microsoft SharePoint

- Adobe Blaze DS (Server-Side Flex API)

- Spring Annotations

- Apache Commons FileUpload API

A successful con of this magnitude requires a victim who desperately wants something and who's willing to depart from rational thought in order to believe they can have it. Software security assurance is ripe for snake oil salesmen because measuring security is hard and major loss events are relatively rare. But what are software security practitioners so desperate for that they'll buy even though the product doesn't work? I'll outline two ideas below. Any resemblance to actual commercial offerings is purely coincidental.

The Silver Bullet
This vulnerability detector uses a patented counter-interpolation analysis to apply a vulnerability database derived from the scariest hax0rs around. There are never any false positives. False negatives? We don't even know what that means. Good for analyzing source code, binaries, web sites, services on the network, networks you have only heard about, and iPhone apps. Merely analyzing your software|hardware|network once guarantees a seal of approval from OWASP/SANS/PCI/FISMA/NRA.

The Responsibility Shifter
Buying this product allows you to sit back and relax. Your job as a security professional will now be taken care of by all of the non-security people in your organization. You drop the software off on their desks, they immediately understand how important security has become in the past few years, and they stop doing their jobs in favor of doing yours instead. If anything goes wrong, the software will explain to management that getting security right requires a team effort, and you really can't be held accountable.

Have more product ideas? Post them here or send me email, and I'll do a roundup in a few weeks.

A lot has been said about the Payment Card Industry Data Security Standard (PCI DSS) established in 2004. Actually, let me correct myself: a lot has been said about what is going on with regards to PCI DSS here in the US. But have you ever wondered what is going on with the standard in other parts of the world? Well, I have. In fact, I do travel to Russia once in a while, and I do use my credit cards there since rate of currency exchange is best when you use a credit card. Plus credit cards are convenient since you don't have to carry cash around and worry about thieves. But perhaps instead of worrying about physical thieves, I should really worry about virtual ones?

To answer my questions, I did some "yandexing" (google equivalent) and found some interesting information. The good news is that PCI DSS assessment is now a requirement, even though before September 2006 it was not. Unfortunately, according to this article written by Anton Karpov, a Qualified Security Assessor (QSA) working for Digital Security, PCI compliance is still optional. You will be fined if you don't get an assessment, but nothing will happen if you don't pass it. This state of affairs leads to many companies getting an assessment just so that they don't get charged any fines, and going on with their lives no matter what the outcome of the assessment is. Moreover, I found several articles and blog posts (for example, this one) cautioning the companies to be careful when choosing their auditors because some of them incorrectly interpret the standard and others give a passing mark even when the requirements of the standard are not met. The amusing thing is that the blog post seems to be written by Anton Karpov's boss, but when I looked the auditor up via QSA employee lookup, it turned out that Anton's QSA certificate has expired. I hope he gets it renewed before doing any more audits.

PCI DSS is not the only accepted standard. ISO 27001 and ISO 17799 and their Russian equivalents ГОСТ 17799 and ГОСТ 27001, as well as СТО БР ИББС-1.0 are also accepted. However, even assessments of compliance with either of these are not mandatory -- they are only recommended. So, looks like PCI DSS is still a little bit ahead of the others. Sadly, all of the above seems to imply that it's gonna take Russia a little while before it catches up with the US in terms of Software Security Assurance (SSA). But who knows, perhaps I'm wrong.

Technorati Tags: pci dss compliance