Here’s the thing about security – you can’t just “do it” then move on. What I mean by this is that it’s a continuous process and thinking that you only need to just implement some secure coding standards or scan the website once before go live leaves a great big hole in your process.
For example, the other day I wrote about how insecurity is easy where I talked about how Black and Decker had exposed ELMAH logs. This is the tiniest of security misconfigurations which can easily happen at any time but it meant that they ended up with the credentials from a significant portion of their customer base publicly accessible – ouch! Ok, this also involved storing plain text passwords in cookies in order to facilitate the “remember me” function (no, really), but the point is in how easy it was to make a simple change that blew a massive hole in the side of their security profile.
This brings me to the point of the post: security misconfiguration happens and you need to start looking for it bang after you publish the site. Exposed ELMAH logs is one thing but simple security misconfiguration changes you can screw up on release of an ASP.NET website go well beyond that; custom errors, tracing, request validation and the way your cookies are configured to name but a few. Each of these can be configured to leave a site vulnerable in literally just a few seconds.
For the last couple of years I’ve provided a service to detect these problems in a live site – ASafaWeb. The value proposition of ASafaWeb has always been that on demand, you can scan your live ASP.NET website and it will report on these security misconfigurations. Now I’m very happy to share how ASafaWeb has been integrated into OnCheckin (the brainchild of Doug Rathbone) to provide continuous deployment for ASP.NET websites as a cloud-based service.