Download our in-depth report: The Ultimate Guide to IT Security VendorsWeve all suffered from software that was clearly not built with security in mind. Quite often, features meant to help us have ended up hurting us. After all, who would have ever thought a spreadsheet could present an attacker with a means of breaking into a computer halfway around the world, by simply crafting an email message? Ill tell you who its we security folks.
Case in point: I vividly recall when Microsoft Word gained its Visual Basic based macro scripting language feature. The anti-virus community screamed, begged, and pleaded for that feature to be omitted (or at least significantly hobbled in its capabilities) so it couldnt be used against us. We now know, of course, they lost that battle and weve seen many examples of exactly the sort of attack they foresaw.
Now those of you who know me know my #1 rule of information security: Dont impede business. Its not highly likely those anti-virus folks could have thwarted disaster even if theyd been in the meeting room when the macro scripting discussions first took place. However, they would have had a much better chance than by sniping at the products after theyre developed, announced, advertised, and released.
Defensive Developmenthttps://o1.qnsr.com/log/p.gif?;n=203;c=204650394;s=9477;x=7936;f=201801171506010;u=j;z=TIMESTAMP;a=20392931;e=iMany of you know Im a huge advocate of software security. If youre not familiar with this term, you should be. Think of it as defensive software development techniques. Sometimes that means adding some security features like encryption; other times it means handling user data input as though it was some deadly toxin.
Sounds good, but software security is not likely to succeed without some value-added input from the security folks who have been out there in the trenches fighting off attacks. Were the ones who have studied and analyzed these attacks in detail. Its been my experience that this awareness and technical knowledge base is sorely lacking among our software developers. Although theyre more often than not brilliant people who do excellent work, studying and learning from attacks has never even been on their radar screens.
Further, software security can only succeed with careful and appropriate input from the security folks. We need to be active participants in the software development process, not the post facto reviewers of their work. The latter is how things are done all too often, and it is downright counter-productive. It leads to adversarial relationships between developers and security people when what we need to be building is collaborative relationships striving toward the common goal of producing sufficiently secure software to meet our users needs.
This concept has been one of my many soapboxes lately. I passionately believe were missing opportunities for doing things much better. So, to that end, here are a few suggestions you might want to consider trying with your software development folks:
Now, I certainly realize this is a lot of stuff and Ive just barely scratched the surface here. This list is the basis of the software security touchpoints defined by Gary McGraw et al in his Software Security: Building Security In book, so consider looking there for more detail and tips on how to implement this stuff. You can also turn to the U.S. Department of Homeland Security site, Build Security In, for more detail on each of these things.
And dont even consider trying to do all of this at once. Take an iterative approach to adopting the practices above one small step at a time. Most importantly, do everything you can to eliminate the adversarial relationship with your developers. We all suffer in the long run from that.