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

A colleague noted that my posts tend to be “angry old man rants” of the “get off my lawn” (for the record, it is a nice lawn) ilk. I’m not sure if this was a slight against my age, but I do occasionally see the brighter side of our software development world and I’d like to highlight something that recently made me smile.

After several years of users pleading with (and the security wonks groaning at) the Rails development group to escape HTML by default, they’ve finally listened and the latest “Edge” version of Rails will escape output by default and developers will have to explicitly mark a string as “safe” to output unencoded HTML. Why is this such a big deal? Because as the BSIMM project has pointed out, secure-by-default frameworks are a much better approach towards long-term application security than bolt-on security.

John Steven at Cigital posted a few months back expounding upon the value of a secure-by-default framework. I’d like to draw attention to two of the bullet points that I feel are most important to get adoption from a development group:

• Maintains transparency, as best as possible – Those securing the framework can place implementation ‘under the hood’ allowing developers to call functions as normal;
• Moves security ‘lower in the stack’

My previous complaint with Rails (and apparently others had the same frustration) was that the Rails developers had the foresight to include the option for html escaping, but developers had to explicitly invoke it (‘<%= h’ to escape versus ‘<%=’). This made it *very* easy for developers to miss. This behavior was in direct conflict to the “Convention vs Configuration” mantra that Rails has adopted with regard to API design and usage.

That’s enough history for now though. Rails, welcome to the club with the other frameworks that are already doing the right thing:

• Grails -- The Grails gang has been incorporating security into their design since the beginning. The following is the default Grails behavior:

  • All standard database access via GORM domain objects is automatically SQL escaped to prevent SQL injection attacks
  • The default scaffolding templates HTML escape all data fields when displayed
  • Grails link creating tags (g:link, g:form, g:createLink g:createLinkTo and others) all use appropriate escaping mechanisms to prevent code injection
  • Grails provides codecs to allow you to trivially escape data when rendered as HTML, JavaScript and URLs to prevent injection attacks here.

  They have a web page that gives developers a highlight of common web vulnerabilities and how they can address these issues with Grails.
• Django -- As of Django 1.0, HTML escaping is on by default in the Django templates via the autoescape behavior. Unless the developer explicitly turns off escaping or the variable has had the “safe” filter applied, variables are HTML escaped before rendering the output.

If you know of any frameworks that also “Do The Right Thing”, let us know in the comments!

Technorati Tags: ruby on rails software security secure by default fortify

Users who have upgraded to Apple's recently released 10.6 update to OS X, codenamed Snow Leopard, have reported a seemingly rare bug that results in their entire user account, including settings and data, being lost inadvertently. The bug apparently rears its head when a user logs in, either intentionally or unintentionally, to the 'guest' account on their machine. When the user logs out and logs back into their regular user account they receive the nasty surprise that it has been fully reset to the default state for a new account and their data has been lost.

If this bug turns out to be as easy to trigger as it sounds, then the security implications are pretty serious since they effectively translate a short window of physical access to a machine into the ability to do irreparable damage in fairly subtle way. Although reports of the bug appear to have surfaced within days of Snow Leopard's release, Apple has only just now acknowledged the problem.

Until Apple addresses this problem properly, a good first-step defense is to disable the 'guest' account.