James McGovern has a post up on “The Insecurity of Ruby on Rails…“. He brings up some great points:
Java has the notion of a security manager where folks can specify what types of code can be allowed to execute. Ruby currently has no such notion. While I know this is under development, one needs to ask whether using Ruby without one is a security risk?
He also notes the lack of tools like Fortify Coverity, Ouncelabs, Klocwork, etc.
So is using Ruby on Rails (RoR) a security risk?
The answer of course, is “it depends”.
Our first dependency is the probable magnitude of loss concerning whatever application we’re studying that uses RoR. Using Tracks to manage GTD is not usually going to carry the same PLM as using a Ruby based shopping cart.
Our second dependency is the probable frequency of loss events. This will come down to the popularity of the application (TEF), and any other priors we can use to create Control Strength - because I believe we can make a strong case for needing a strong TCap in our relevant Threat Community. Concerning Control Strength, there are all sorts of priors to draw from. For example, have the developers been trained in secure coding practices? Are we marrying RoR in the application with other “scary” technologies (AJAX, for example), and if so, can our implementation of these technologies pass tests? Have we had an independent code review by some outside RoR experts?
One final thought, while we’re not studying any specific implementation, the analyst studying risk surrounding RoR use should be reminded to apply “Fragile” and “Unstable” modifiers if necessary (for those who have not gone through FAIR training, risk condition can have modifiers based on the cogency of various factors). In just “gut checking” Ruby, I believe these modifiers may apply more often than not, due to the youth of the technology.
Now I’ll share RMI’s findings concerning Ruby on Rails with you. We see very little risk in deploying our application internally. Even in a large internal user population, the TEF, TCap, and PLM just isn’t there.
Tags: compliance, risk, risk management, risk assessment, risk_management, risk_assessment, risk_analysis, risk analysis, security, information_security, information security
August 31, 2007, 10:14am Comments
