Blog

A client recently had a stream of attacks on several of their online applications. Thanks to excellent monitoring, solid architecture and nice, clean installations, the attacks were easily rebuffed. Cheers to all involved. Just the same, the attacks gave me some insights on what a typical attack vector looks like to an online intruder. There were certainly some patterns in the commands directed at each server or application. As I said, the client faired very well. However, the incident gave us an excellent opportunity to review our monitoring efforts and even more interesting, our security. Open source software poses a unique set of circumstances when considering security. The actual source code of these projects is freely available for anyone to review for potential angles to exploit. Of course, to the open source community, that same statement is the reason they feel open source software is inherently more secure than closed, licensed software. That is, anyone in the community is free to look things over and report bugs and security concerns. Voila, the world's largest quality assurance team! The adoption of open source software such as WordPress, Drupal and LifeRay has increased a great deal in the past few years, especially in Enterprise clientele. I've been involved with at least a half dozen open source projects in the last two years alone, all but two of which were for one of several government agencies. I thought this a great opportunity to review my standards in a couple of common open source solutions. It wasn't a great surprise that a pattern emerged here as well. Quite a few of the steps I perform in hardening a site are done not matter which system I've installed, migrated or upgraded. I've split the patterns I found into a few categories: Change the Defaults! As many as humanly possible or fiscally feasible. In descending order of importance, here are a few common defaults that should be changed in any installed system if possible:

• username - There should be no admin accounts in your systems. By leaving the default user in place, you are giving away one half of the key to your system. So easy to change, so much to gain. Talk about ROI!
• db prefix - This is usually most easily accomplished before you install your system but it's not always impossible to change after the fact. A migration can be a great chance to apply this security update. The concept is the same as for the default user; the database schema for open source systems is freely available. Your database prefix, should you choose to use one, obfuscates all of that.

Users are the Enemy Strong words, I know. Software exists to serve the end users, right? Trust me, it's like Tron all over again in there, users versus system. Intentionally or not, the end user is the greatest potential threat to your system simply because you are forced to give them some kind of access into the system. So do your best to enforce best practices around end user security.

tron_catimg.jpg

Don't give them a choice, code measures in if you have to, for example:

• Solid but reasonable password policies. Password policies that are too extreme cause end users to break security protocols that you cannot control. That is, expect to see text documents and/or stick notes with passwords all over. A great compromise my team has been using lately is Pass Pack, an online password management system. Awesome layers of security to be seen there.
• Session timeouts. Don't let your users go to lunch and come back to a breached system. Even if they lock their systems, an external intruder that networks into their machine will be happy to see all those open web sessions.
• Limit login attempts. It may add a little work at the admin layer, helping locked users for example, but you can stop an automated attack in it's tracks if you limit login attempts by both username and IP address.

Apply Updates Immediately A caveat here. I know no one runs updates indiscriminately. You have to review the update, see what else could be impacted and then make the call. That being said, a lot of these updates are released for security reasons. Check your status reports regularly and don't hesitate to get these updates out there unless you have a very good reason not to. As always, back up your systems first, but you did that already I'm sure. Plugins have their own Security  Or add-ins, snap-ons, modules, what have you. Anything that is not core code, anything that is installed after the fact needs to be maintained as if it was a separate system. That means checking regularly for updates, patches and new releases. Another big thing to watch out for is the development status of any externally maintained code. Add-ins that have become a core part of your systems' workflows is not guaranteed to be around forever. Check for end of life notices on a regular schedule and be aware that some add-ins just fade away without any announcement at all. Have alternatives at the ready or be prepared to be held back in the future because of one little unmaintained module. Utilize Your Dev Environment Everything is an emergency. You're in software, get over it. That's no excuse to break best practices and just update one little thing in your production environment, bypassing development and/or staging and quality assurance. Thank goodness, it's been some time since I've worked with an organization without separate environments but the time I spent without them was anxiety-ridden, I assure you. Go Run a Backup, NOW! Depending on how often you update content, schedule your backups. Seriously, go set it up right now. Backup your database and files off server, and often. The good luck you've had so far may not hold out forever and lost content is gone with a capital G. Or at least so gone as to not be worth recovering, whatever, are you running a backup yet? Stop reading, go.