Writing Secure Code
I was in WA last week and met up with my buddy Akhil who works for Microsoft. It was great to drop down you guard and be nerds once again. Due to the nature of the product I am working to create here in RI, security in code interests me a great deal. Akhil told me about how folks in Microsoft are religiously [my words, not his] looking at their codebase, fixing a lot of potential security loopholes. Then as I was leaving, he gave me a copy of the book "Writing Secure Code" by Michael Howard and David LeBlanc. "It's a useful book", said Akhil, in a classic understatement that doesn't come naturally to my friend. I am half way through it now and can't put it down.
I have always believed this myself, but never put in print before: the common mistake we as developers make is to architect, design, develop, test and deliver code that that has no palpable security features. We add security technologies into our applications more to be "buzzword compliant" than to truly make it secure. We have disdain for the good folks from the Information Security group. They are seen as academic; what do they know about the real world of coding and deadlines and not to mention changing requirements? [Nobody loves me!] Security is usually an afterthought, added into the code several iterations down the line [when there's time for these pesky things]. Does this stem from naivete? I think not. Security is seen to bear little financial benefits with customers. It gets in the way! Too much time, money and resources are needed for features that are for all practical purposes "invisible". Besides, how many developers have security skills in their resumes? These are the reasons I have frequently heard given.
Expensive security tools and gizmos can provide one with a false sense of comfort but sadly they do not suffice. Incorrect handling of arrays, buffers and memory copying logic have been liberally exploited by virus writers and hackers alike. Howard and LeBlanc demonstrate with examples, how black-hat hackers attack vulnerabilities in code. They provide tips on how code can be secured as well how to convince decision-makers about the importance of security. Some of their examples made me go back and look at code I'd written to verify I wasn't making the same mistakes. There's a lot more to be written on this. There's even more to be learnt.
I have always believed this myself, but never put in print before: the common mistake we as developers make is to architect, design, develop, test and deliver code that that has no palpable security features. We add security technologies into our applications more to be "buzzword compliant" than to truly make it secure. We have disdain for the good folks from the Information Security group. They are seen as academic; what do they know about the real world of coding and deadlines and not to mention changing requirements? [Nobody loves me!] Security is usually an afterthought, added into the code several iterations down the line [when there's time for these pesky things]. Does this stem from naivete? I think not. Security is seen to bear little financial benefits with customers. It gets in the way! Too much time, money and resources are needed for features that are for all practical purposes "invisible". Besides, how many developers have security skills in their resumes? These are the reasons I have frequently heard given.
Expensive security tools and gizmos can provide one with a false sense of comfort but sadly they do not suffice. Incorrect handling of arrays, buffers and memory copying logic have been liberally exploited by virus writers and hackers alike. Howard and LeBlanc demonstrate with examples, how black-hat hackers attack vulnerabilities in code. They provide tips on how code can be secured as well how to convince decision-makers about the importance of security. Some of their examples made me go back and look at code I'd written to verify I wasn't making the same mistakes. There's a lot more to be written on this. There's even more to be learnt.
0 Comments:
Post a Comment | Home | Inference: my personal blog