The difference between pentesting and an application development security process Part I

Many times when we’re speaking with a customer or reviewing material from security vendors, the inclination we’ve seen is to rely on penetration testing or code analysis/scanning tools and other solutions to make up for the fact that there is no comprehensive security process in place during development. Microsoft IT runs thousands of applications in our data centers and we’ve realized over the years that even if you spend large amounts of resources (both time and dollars) on penetration testing or automated scanning tools or other activities touted by some security vendors in a vacuum, you will never get the results you need. This is simply because you’re addressing a symptom and not the root cause of the issue. The root cause, of course, being that developers are writing code and deploying applications without following a standardized security process that enforces industry best practices when it comes to security code quality. What we’ve also learned is that developing and maintaining a solid application development security process is hard to do: it takes time, effort, support from senior leadership and a constant willingness to test assumptions and continuously improve what we’re doing. Cost is also a significant factor, something I intend to blog about in some more depth separately. 

So what kind of security process do you need? It used to be that a lot of the security processes organizations developed and followed were based on their specific vertical or budgetary constraints, so for example the banking industry tended to do the same thing or the retail industry might do things in a certain way. What’s happened over the last several years however, and no doubt this has been significantly impacted by nearly everyone doing some kind of business online, is that processes, needs and requirements have started to merge. To a significant degree, it no longer makes any difference if you’re in banking or retail, you still need to protect consumer data from exposure just as much. 

More to come in part II.