RSA 2006: Secure Software is up to Business
One of the themes discussed at RSA 2006 was Secure Software. Secure software is up to businesses and most businesses are not doing enough to build and buy securely written software, according to a panel of corporate security executives, academics and professional software developers speaking at the RSA Security Conference 2006 yesterday.
Here are a couple articles on what was discussed at RSA 2006:
https://www.computerworld.com/securitytopics/security/story/0,10801,108716,00.html
https://www.securesoftwareforum.com/assets/documents/SPISSFWhitePaper.pdf
One panel member agreed that education helps, but developers also need tools that flag potential flaws as the code is being written and that can fix them automatically. However, I only partly agree with the one panelist's comments as code scanning tools alone are not the answers. I particularly liked the way Michael Howard describes his thought --which I summed up in points below --about using source code scanning tools alone:
If Developer do now know how to write Secure Code
If Designer do not know how to design secure systems
If Tester do know how to test Security-posture of a system
Then
Tools will provide very little help
Code analysis tools have to keep the number of false positive low
Because of this high bar, many tools will miss real bugs
Design bug will not be found by a source code analysis tool
Therefore
Tools are used to force policies or “just in time learning”
OR
"Not-so-knowledgeable-developer" + great tools == marginally more secure code
Therefore, we can not look for quick fixes for Security as it is too important and too complex. Now I am not saying make all developers security specialist as that is not feasible. But what is wrong with training developers so they understand the major vulnerabilities that exist and how to program against them?. Then have an IT Sec Pro team that consists of not just Infrastructure people but also a small core group of developers who are highly trained in Security. This team would then be involved in conducting Security code reviews and penetration testing of Applications during the Application Software Development Lifecycle.
This is too complex of a problem to leave up to a tool alone but rather one in which Architects, Developers, Testers and Business have to work together to solve.