[Guest Blogger] Dana Epp on Security Myth: Only Large Teams Can Write Secure Code
[Guest Bloggers] Security Myth: Only Large Teams Can Write Secure Code
If you ask me, one of the biggest fallacies of writing secure code is that you can only accomplish it when you work in large teams and have bigger budgets. There is a disconnect between the theory of secure programming, and the practice as smaller ISVs believe they simply don’t have the resources to meet the objectives required for safer software.
What is interesting is that a lot of businesses are put at more risk because of this. Many buy tools from these small ISVs, since the ISV typically focuses on small verticals the big boys aren’t after. But if the same defensive coding strategies aren’t applied, the business is at more potential risk, and typically doesn’t even know it.
Recently I was brought into an environment to audit some code in business workflow that caused a major failure in a manufacturing facility by exposed privileged information publicly and shutting down a key system. They had built a web service to expose status and engineering change orders of just-in-time manufacturing for their customers. I can’t really go into much more detail, but to state that poor coding practices in how to handle failure code paths resulted in private information to get plastered on the public facing website and an exception thrown that wasn’t caught properly, causing the whole thing to tumble down. The problem was pinpointed to a 3rd party library that simply wasn’t written properly to handle tainted input from an untrusted source, which in this case was completely accidental.
After discussing this with the ISV and making suggestions on how to fix it, I was presented with the argument that they can’t afford the time or tools to do this. They said they didn’t have the resources needed, and that ticked me off. I felt it was a cop out. So I decided I would do something about it.
I knew I had a project coming up that I wanted to do, and felt it would be the perfect time to highlight how some front loading of design decisions and the selection of the proper tools could go a long way for a small ISV in building better software. From mindmapping features to threat modeling functionality, I wanted to show the end to end process of building software. Well, at least how we do it around here. Every software company will have their own methods to do this.
So last month I did just that. In 30 days I went from the idea of a product to the reality in 30 days. With just ONE person…. aka me. Now this wasn’t to impress anyone with my ability to write code. It was to impress upon the readers that it was indeed possible to do it with a small team. Can’t get any smaller than one guy. And I blogged and screencasted the process as I went along.
If you are interested in sharing in my experience, feel free to check out the Project Anvil blog at http://www.scorpionsoft.com/anvil/. I highly recommend you read it from the first post at the end of July and read along as I built Anvil. It was quite an experience. And the product is now being dogfooded in house in a set of betas we hope to open to the public next month.
So don’t let the excuse of limited time and budgets dissuade you from writing secure code. It is possible. But like anything, you need to think objectively before hand and build it into your development process from the get go. Not sure how to do that? May I recommend that you pick up the book “The Security Development Lifecycle” written by Michael Howard and Steve Lipner (ISBN: 0735622140)? It will go a long way to show how Microsoft does it, and will allow you to adopt what you think makes sense in your own dev process.
Dana Epp
Microsoft Security MVP
 |
|
Dana Epp, Scorpion Software Corp’s founder and CEO, researches software security and sets the vision in the convergence of information security principles and practices with digital information asset protection for small business. As a computer security software architect, Mr. Epp has spent the last 15 years focusing on computer programming with a particular emphasis on security engineering to offer a safer computing environment for business. His latest research has been on risk-based authentication, focusing on strong two-factor authentication (2FA) for small business. |
