Eric Friese

I recently read an article quoting some “cyber security experts” discussing off-shoring and cyber security. Part of the article says that the government should not regulate software security because this will increase the cost of software and push more development over seas. There is some logic to this argument, but it’s the same excuses I hear from software developers who don’t want to fix their code. The argument being made is “I can give you crappy software at a price that is competative with off shored labor, or we can give you good code for a price that’s so large it will make you be okay with off shoring”. 

I’m not a fan of government regulation, but something has to give. For decades the general public has been acting as beta testers while software vendors work the kinks out of their software. The obvious downside is weekly security updates from Microsoft, malware that can take over a computer in a single click, and the building of zombie computer armies. While we are seeing some companies get better about writie secure code, it’s not industry wide. Security remains as a obstacle to getting to market quickly and an afterthought once in the market. This mentality will continue until something changes.

The Payment Card Industry Data Security Standard (PCI DSS) is a great example of self regulation. PCI DSS is not perfect by any means, ask Heartland Payment System, but it forced some companies to make security a priority. Even if the priority is just to pass an audit, this is still possitive yardage for their customers. The private and public sectors need something like PCI DSS. 

The answer could be self regulation. A consortium of software vendors agreeing to a security standard and then being able to put the groups logo on their software. Will this happen? Probably not. Humans usually don’t change until there is a large enough event to make the change happen. I would rather not wait around for that event, so government regulation (or the threat of government regulation) is the next best thing. 

A part of whatever regulation that comes about should include stipulations for supply chain risk management. Code coming from off shored development shops is sub par functionally speaking and even worse for security. If we are going to make software secure, it has to start at the requirements and be a part of design, coding, testing, and production. Who writes the code or where it is written should not matter. Developing software without security is writing crappy code plain and simple.

If this makes the cost of software rise, so be it. I would much rather pay more for software and not have to worry about clicking a link that will take over my computer, steal my bank password, and then make me spend hours on the phone trying to get my money back.

Eric Software

I’ve noticed my blog has been getting a lot of traffic lately regarding false positives and custom rules for Fortify. Full disclosure: I am a Fortify consultant. The number one complaint I hear about Fortify’s static analysis product (Fortify SCA) is that it produces too many false positives. To understand why this happens, some context is needed on Fortify’s design and purpose.

When the cavemen wrote code, they would use manual code review to look for bugs and security holes. There is a place for manual code review, but its costly and the effectiveness depends on the security education level of the reviewers. Manual code review usually leads to a high false negative rate, especially in complex applications. To make sure everyone is on the same page here, a false positive is where an issue is found that is really not an issue. A false negative is where an issue is missed, leaving a vulnerability in the code.

Fortify SCA was created to help automate the manual code review process. SCA looks through your source code and finds possible vulnerabilities…emphasis on possible. SCA errs on the side of reducing false negatives. The corollary to that is we produce more false positives. We do that because we would rather produce some false positives to avoid missing real issues. We do our best to understand the application, but let’s face it: static analysis is just one algorithm scanning another. There’s no way for ANY static analysis software to not produce false positives.

I also encounter many developers calling real vulnerabilities false positives because they don’t fully understand the finding. I recently received an email from a developer saying SCA found hundreds of persistent cross site scripting issues and that they were all false positives. He was convinced that since they do input validation, trusting the database was not a problem. We talked some about why the database is not a trusted source and he got the big picture.

For the most part, SCA does a decent job of reducing false positives. Many times the reviewers don’t understand the vulnerability or SCA’s criticality is too high for the given scenario. When it comes down to it, SCA is just a way of identifying potential issues. Its up to the reviewers to decide how they want to handle the output.

If you’re having problems with Fortify, send an email to support@fortify.com. Our support group is fantastic, so give that a go first. If you need help integrating Fortify into your SDLC, contact your Fortify rep to get a consultant on site.

Eric Software caveman, false positive, Fortify

I bought a T-Mobile Vibrant (Samsun Galaxy S) in July and I’ve been really happy with it. The only down side was that it had Android 2.1 (Éclair), I was hoping for 2.2 (Froyo). Today, I read an article saying that Samsung was pressuring T-Mobile to not upgrade Vibrants over the air with Froyo so that people will upgrade to other Samsung phones. Oh, I don’t think so. I spent a lot of money on this phone and I will not let some no-talent-ass-clowns at Samsung/T-Mobile keep me from the Froyo goodness.

So, I rooted my phone and installed the Eugene Ginger Clone 2.2 ROM. It’s Froyo with a Ginger look and feel. Very, very, very nice. This was my first attempt at rooting my phone or using a ROM. Here’s how I did it:

1. Root the phone. I spent some time working with the SuperOneClick app from XDA, but couldn’t get it to work. For the Vibrant it would involve toggling USB Debugging multiple times and sacrificing a chicken. I found this post that worked like a champ…much easier. When the phone finished booting, I had the SuperUser app and everything worked great.

2. Backed Up Phone. Now that I had root, I used Titanium Backup from the Google Market to make a back up of the phone. This came in helpful for after I installed the ROM. I had to reinstall of my apps.

3. Install ROM Manager. To install a new ROM, you need to do a few things. First, download the ROM Manager app from the Market. After installing, install the Clockwork Recovery. Before doing this, make sure you have deleted the update.zip file from step one. If you don’t, then Clockwork Recovery will not be installed.

4. Download a ROM. At this point, you can use any ROM you want. I chose the Eugene Ginger Clone R2 ROM because I wanted Froyo and I thought the Ginter interface looked cool. You can download the ROM here. After downloading, connect your phone to a computer and transfer the ROM zip on to the internal storage.

5. Install the ROM. Open ROM Manager, and then choose install ROM from SD. Choosing the ROM you want to install, and then click go. It will automatically reboot your phone and the new ROM will install. Voila!

It took me a few hours to do this, but it would have been much quicker had I not bothered with the SuperOneClick app. Happy rooting! Oh, and I’m not responsible if you brick your phone…

Eric Software android vibrant root froyo ginger

I laughed my head off when I read this post on Slashdot this morning:

"My current boss asked me what I thought of asking all employees to work 10-11 hour days until the company is profitable. He read something from Joel Spolsky that said the best way to get new customers is to add new features. Anyways, we are a startup with almost a year live. None of the employees have ownership/stock and all are salary. Salaries are at normal industry rates. What should I say to him when we talk about this again?"

My first question would be, has this manager ever developed software? In my experience, developers write code in spurts. When writing code, I’m usually not going at it for 8 hours straight. Usually after my second cup of coffee I throw on the headphones and plow through some code. More coffee and some reflection about more important things (Auburn winning the National Championship for example), then plow through some more code. Honestly, I write more code when I don’t feel like I have to be writing code. There have been plenty of times I would be in bed, awake because I’ve got some implementation problem stuck in my head. I would get up, grab the laptop, and work when I didn’t have to because it was fun. That’s why we write code: it’s fun.

Making people sit at a desk for 10-11 hours straight just because the boss says so is not fun. If you want more out of your developers, find out what motivates them. Stock options, better perks at work, an Xbox in one of the spare cubes. If you create an atmosphere where people are happy and creative, then you can get good results out of them. It works for Google…

Usually the next argument is something like how much money Google has and that they can afford to let their employees prance around. There is some truth to this, but only some. If you’re going to drive your developers like slaves, give them some stock options. Make them feel like their work will pay off. If this guy wants to stick to just salary, then you will need to find other ways to motivate the developers.

Eric Software code, developers, stupid bosses

If so, you can be absolved of your sins by buying bad code offsets! I’m not sure whether I should laugh at such a stupid idea or be envious because I didn’t think of it first. This is a phenomenal example of a stupid tax.

Here’s the group’s vision:

We envision a world where software runs cleanly and correctly as it simplifies, enhances and enriches our day to day work and home lives. Mitigating the scope and negative impact of bad code on our jobs, our lives and our world is our all–consuming passion. We foresee a time when bad coding practices and their rotten fruits have been eliminated from this earth and its server farms thereby heralding a new age of software brilliance and efficacy.

Nettlesome bugs and poorly written code have been constant impediments towards realizing our full potential as programmers and engineers. Bad Code Offsets provides the vehicle for balancing the scales of poor past practice while freeing us to pursue current excellence in code development. Until the dawn of the worldwide, bug free code base, each of us can take steps towards reducing our bad code footprint and remediate the bad code that we have each individually and collectively left behind on the desktops, servers and mainframes at school, at work and at home.

As much as I would like to think that we are progressing towards a time where software will ship bug free, reality says that it’s impossible. The best programmers in the world occasionally right bad code. We’ve all done it at some time in our lives. I recently opened some PHP code I wrote 5 years ago and was appalled.

I once worked with a group that was CMM-I level 5 certified. This group worked at least 2 years on a single project. Management dropped the project when they found out the group had written zero lines of code. They had a magnificent requirements document though! Moral of the story: bad code is a reality of life, get used to it.

To top the joke off, the group behind these offsets are donating the money to open source foundations who are  “carrying the fight against bad code on a daily basis.” The key word there is fight, and it’s not just the FOSS groups that are fighting it…we all are. If these groups write such good code, why do we hear about buffer overflow vulnerabilities in Apache HTTP Server or cross-site scripting in Drupal (both on the donor list)? Yeah they fix them when they are notified, but so do most other developers.

If developers feel so bad, let’s donate to something that will actually benefit someone other than the people running the scam. For every $400 that’s donated, I’ll sponsor a poor child’s food, clothes, toys, and education for a year. Clothing a kid for a year sounds much more appealing to me than pouring money into FreeBSD. In return, I’ll email you a certificate saying your coding sins are absolved and the world’s now a better place.

Eric Funny, Software