Sunday, March 04, 2007
Thoughts on Secure Coding
I am a savage believer in Secure Coding Practices and am keenly interested in evaluating tools from such vendors as OunceLabs, Fortify, Coverity, SPI Dynamics and LogLogic. I have asked myself, are these tools enough or does the problem space I am attempting to solve reside elsewhere...
I have in my travels ran across many enterprises that use tools in hopes of making software development more secure. However, it still feels as if security is somewhat ad hoc. One truth is that the vast majority of tools tend to address things later in the software development lifecycle where it is more expensive than addressing earlier. I believe that even putting tools into the hands of software developers when it comes to security is too late in order to be useful.
So, I guess I am concluding that the security community at large needs to start talking about how to discuss security requirements as specified by business analysts. Something in which I cannot find evidence that it exists. How come application security requirements aren't on par with functional requirements? Would security within enterprises get better if architects weren't the first folks to noodle security and our business analyst counterparts took the lead? What would happen if business analysts started including in all requirements documents that the application shouldn't behave in a way that does not reveal confidential information or allow unauthorized actions?
I believe that if business analysts specify it then folks downstream such as quality assurance would need to then start testing for it. Us security types are always advocating that security is not the job of a single individual or department yet our behaviors demonstrate the exact opposite.
Another thing that I have been noodling is that many folks have gotten it twisted when it comes to methodology. In order for security to make meaningful progress, we have to educate the process weenies to understand the subtle distinction between a project management methodology and a software development methodology. These two words are incorrectly used within most enterprises in an interchangable way.
I wonder what it would take for security bloggers to stop talking about coding, XML specifications such as SAML or XACML and to start talking about how both business analysts and project managers can help make software more secure? It would be interesting if industry analysts started covering this aspect of security. Maybe I should call up Dan Blum of the Burton Group to see if his folks have any plans to research this important topic...
| | View blog reactionsI have in my travels ran across many enterprises that use tools in hopes of making software development more secure. However, it still feels as if security is somewhat ad hoc. One truth is that the vast majority of tools tend to address things later in the software development lifecycle where it is more expensive than addressing earlier. I believe that even putting tools into the hands of software developers when it comes to security is too late in order to be useful.
So, I guess I am concluding that the security community at large needs to start talking about how to discuss security requirements as specified by business analysts. Something in which I cannot find evidence that it exists. How come application security requirements aren't on par with functional requirements? Would security within enterprises get better if architects weren't the first folks to noodle security and our business analyst counterparts took the lead? What would happen if business analysts started including in all requirements documents that the application shouldn't behave in a way that does not reveal confidential information or allow unauthorized actions?
I believe that if business analysts specify it then folks downstream such as quality assurance would need to then start testing for it. Us security types are always advocating that security is not the job of a single individual or department yet our behaviors demonstrate the exact opposite.
Another thing that I have been noodling is that many folks have gotten it twisted when it comes to methodology. In order for security to make meaningful progress, we have to educate the process weenies to understand the subtle distinction between a project management methodology and a software development methodology. These two words are incorrectly used within most enterprises in an interchangable way.
I wonder what it would take for security bloggers to stop talking about coding, XML specifications such as SAML or XACML and to start talking about how both business analysts and project managers can help make software more secure? It would be interesting if industry analysts started covering this aspect of security. Maybe I should call up Dan Blum of the Burton Group to see if his folks have any plans to research this important topic...
