About this time last year I took on the role of Security Manager, an area I had been informally doing for a while up to that point. The past 12 months has flown by and I thought it might be of interest to the community to do a bit of analysis and see how I and the rest of the dotnetnuke security team has performed in this area since it was formalised, and see where we can improve for 2008 and beyond. I've pasted my original planned tasks below, and added notes in italics below the items to give an update.
1. Regularly review the code for any potential issues introduced, or any that surface due to new/popular attack vectors
I only managed one full-scale audit of the core code during 2007, along with a series of smaller reviews on particular areas,but I expect to do an indepth review of the core as the new Cambrian items will introduce a lot of change.
2.Act as 'point-man' for security related issues i.e.any mails directed to security@dotnetnuke.com. The emails we receive typically fall into a few categories
Reports of suspected hacks - from time to time people email in when their site has been hacked to see if the problem was dotnetnuke related. Typically I examine the exploit payload/vandalised pages, site contents and IIS logs and see if the issue was in the core or other 3rd party modules (note: almost without exception the hacks are not dotnetnuke related, typically they are server related usually due to missing windows patches)
Validate vulnerability assemements/penetration reports - sometimes we receive these when a site owner employs a 3rd party to assess their site. I read these, and validate whether the issues are genuine, if they have mitigating factors, and whether they can be fixed. In some cases genunine issues do turn up, at which point we fix the issue and release a bulletin as usual.Users wanting answers to security related questions that they/clients require
We received over 280 emails and sent out almost 200, mostly dealing with queries about security and reported hacks. As usual almost all of these hacks turned out to be missed patches, default configurations or 3rd party modules. However, we also received 2 major audits, as well as half a dozen smaller audits/reported issues in core code or modules. To date all issues have been resolved. Note: in 2007 we had 1 issue rated as low, 2 medium and 1 critical.
In some cases we also received requests for security enhancements, a number of which ended up in core code, with some still on the table to be added in future releases.
3. Add to and maintain our security documentation (latest versions are available here)
The documentation is overdue an update. I have a number of errata and addition's (in many cases suggested by the community or other core team members)that I will be adding shortly, ideally by end of Q1 2008. I did also get the opportunity to deliver sessions on DotNetNuke security at both SDN and Devconnections. The slides I used there as well as demo script steps will be released once I get a chance to tidy them up.
4. Perform security audits of any projects added to the project tracker. This has worked well, with a number of issues being caught before release already.
This has turned out to be the most time consuming task, with a few dozen audits being performed in 2007. As the project teams have gained experience in this area, the number of failures has dropped, but it continues to be a key area as web vulnerabilities evolve.
5. Plan out security related enhancements. This year I'd like to look at a few areas including :
- adding page level SSL support
- enhancing security options in the core
- breaking out our InputFilters into a provider, so that admins can plug in updates/alternatives easily (diversity is always a plus in the security world)
- now we've moved to a pure asp.net 2.0 codebase, theres a number of 2.0 specific enhancements that will be added in the next releases.
- adding an application level filter that can block user access based on selected criteria such as user agent or IP.
Despite being a developer in my day job, I probably spent less time coding than any other task, though I did add a few enhancements (checks for default username/password combinations, additional filtering , enhanced XSS checks). Happily a number of these areas were addressed (SSL and application level filtering) by other team members. I'll be submitting a few items as part of our scope planning for Camrian, so hopefully we'll continue to enhance this area.