About five years ago thinking that I was about to code an Identity Vault, my fortunes changed and responsibility of helping build an Application Security program fell in my lap. The only problem was that five years ago there were very few examples of how to do this. Some how we managed to figure it out and build one of the relatively rare dedicated Application Security teams. Along the way I learned a lot about Application Security and plan to share it with you for the greater good of all.
One of the first lessons about Application Security is that it is not like most of the other traditional Information Security disciplines like Network or Host (Server/OS) Security. AppSec is primarily about people and process, and not so much "tools". It's about equipping a developer with the knowledge and desire to write quality, secure code. Network Security has been around for many years and has a "relatively" limited number of possibilities of routers, switches, firewalls, major operating systems, etc. This allows numerous tools to be built to help secure and test the security of the network with a relatively high level of assurance. In contrast, Application Security is very dynamic, not only is there a virtually unlimited number of ways to write an application, but "business context" can make all the difference in the world. Business context is referring to the business data available in the application, the actions that may be performed on it, the business rules, and access control lists. Automated scanners have great difficultly understanding the "business context" of an application (actually I haven't found one that can yet) which seriously limits their effectiveness to largely only finding the "low hanging fruit" like basic reflective cross-site scripting. (Not trying to start any major arguments about the effectiveness of web application scanners, that is for a later post.... )
Thursday, October 1, 2009
Subscribe to:
Posts (Atom)
