Security begins with proper awareness & planning and is implemented through continued managed policy execution. The reality is that DNN (or any platform) will always be susceptible to attack left unchecked, or in many cases, even monitored. Unfortunately most smaller sites are spooled up and left alone to fend for themselves and the only time anyone knows something went wrong is when the site is down or the content's changed, you get your domain blacklisted for relayed spam or your hard drive is full because you just became a new warz server.  This is especially true if your hosting without a net...meaning your host provides pipe and ping and will rack or allocate a box for you...but draws the line at the most basic network and OS server layer.

A security policy should cover every later of the stack not just the [DNN] app and yes should include the often overlooked and already pointed out "human" layer.

Making sure your networking, firewalls, traffic monitoring, attack signatures, operating system, database, application and user and admin policies are all kept up to date, are managed and monitored proactively can be a daunting task - but will improve your awareness of attacks and vulnerabilities. Once you know what's happening or "could" happen you can work to mitigate the vulnerabilities at the most appropriate layer (block an IP, add CAPTCHA, turn off China, etc).

In many organizations this represents entire teams and lots and lots of gear in others you can outsource this to your provider or a company like white hat. In all cases however you need to think about security as a lifestyle, pay as much if not more attention to it as you do SEO and content and establish a plan to constantly evaluate and mitigate vulnerabilities.

---

Steven Webster
Manager, Community Platform
F5 Networks, DevCentral

I'm wondering if there are any financial institutions that use DotNetNuke as a platform in which financial transactions are taking place.

In addition, are there any techniques documented for DotNetNuke that provide a physically separate container separate from DotNetNuke that provide a higher level of security, or at least isolation. This would be to ease regulators and security teams minds about security because the financial transactional modules within DotNetNuke would actually be executing within a separate and more secure container than the DotNetNuke.

I'm not implying that DotNetNuke is not secure, but my little bit of security experience says that security folk are more at ease when financial modules are isolate from a public website.

Bottom line is how do you ease the minds of financial services security personnel that DotNetNuke is secure. My 1st thought is the above by allowing a financial institution to execute their financial transaction modules in their own container that they know is secure while embedding those financial modules in a DotNetNuke platform to be able to take advantage of all the great features, themes, modules, extensions of DotNetNuke.