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.
Here’s how it works: Firstly, you plug it into source control:
Then you configure the deployment:
Then finally you review everything and tick the box to run the ASafaWeb scan after every deployment:
That’s it – job done! Now each time the scan runs there’ll be a little ASafaWeb tab and a nice report on how the scan went:
What I really like about this is the continuous nature of the process. Every time that build runs, the site is going to get scanned and so long as you’re keeping an eye on the results you shouldn’t have sneaky security misconfigurations making their way through to production. Well at least not for very long!
The other thing about this integration is that it’s another step towards publicly releasing the ASafaWeb API. Yes, there’s an API and in fact it’s been used extensively as the magic behind the ASafaWeb Scheduler which gives you the ability to scan your sites on a regular basis (I mentioned it’s free, right?!). The intention has always been to open the API up for anyone to consume I reckon including it into the continuous integration cycle is a fantastic use-case.
To that effect, if you’re involved in a similar project and would like to integrate ASafaWeb then I’d love to hear from you. I’m happy to open it up to beta testers who want to contribute feedback and I know there are a ton of good ideas out there for how it might be used.