It has been an impressively brutal month in terms of security breaches, and across a whole range of fronts. The "Cablegate" leaks, courtesy of Wikileaks, appear to be in a league of their own. The "Operation Payback" DDoS attacks against PayPal, MasterCard and Visa (not to mention the less successful attack against Amazon) are equally impressive. Even more recently, the Gawker Media Network was subjected to a relatively sophisticated hack attack by Gnosis, with the hackers gaining access to some 1.3 million passwords and usernames, as well as internal credentials of Gawker employees, and a big block of users & staff email addresses. Pretty spectacular stuff.

While DDoS attacks and truly skilled hacks are difficult (though not impossible) to defend against, information leaks should theoretically be under better control. It's hard to predict what's going to be thrown at you from the Lions and Tigers and Bears of the internet, but much more within our power to control information flows and potential leaks within our own domains. Not necessarily easy, but much more manageable.

The confidential information recently exposed by Wikileaks was, with a few notable caveats, handled in much the same way as the average Enterprise might manage large amounts of communications data - with PST files. While the scale of the breach is impressive, the methodology is more mundane, and something we're all potentially at risk from. All of a sudden, Brien Posey's horror stories pale into insignificance!

Ultimately, security is always your domain, regardless of whether your server environments are on-premises or in the cloud. Uptime is an obvious concern, and while your PaaS is probably in a better position than you to weather a storm, but it's also more of a target. There's the question of whether you're willing to trust your private data to a 3^rd party, but that's evidently a problem you need to address closer to home as well.

The fundamental nature of security challenges remain the same wherever your environments are hosted; it's only the fine details that change. Just because you're using a big PaaS provider (Amazon being the case in point), that doesn't mean you'll be immune from digital damage. You'll just find it easier to point the finger of blame.

"Systems Administrators, I come in peace. You have nothing to fear from me"
- Office 365

Microsoft Business Productivity Online Suite recently absorbed a few other services and has been rebranded as Office 365, which is currently in private Beta and NDA-d up to the eyeballs. As Microsoft's (slightly delayed) answer to Google Apps Premier Edition, it shows a lot of promise; MS has technical expertise, market penetration, and financial capital all going for it. On the other hand, Google has its fair share of brainpower, and is built from the ground up with network uptime in mind. That is, after all, what their business completely relies on.

Office 365 is also an implicit brand promise (backed up by an explicit 99.9% uptime SLA), and it's already looking like Microsoft might have to work a little harder to honor that promise. Unsurprisingly, I've seen it argued that even 99% is still pretty darned good, and that plenty of enterprises with in-house IT support suffer much worse than 90 minutes of downtime in 2 months. This is all true.

It also doesn't take into account a few points:

• With in-house IT, downtime doesn't mean users can't work, it just means they can't work online. If you're using the full Office 365 suite (i.e. with hosted versions of Office itself), then you've potentially got a bigger problem.
• It's damaging to the Microsoft brand if they can't honor this promise. They're presumably trying to sell this SaaS suite to managers and executives, and in that arena, confidence is king.

Speaking of confidence, their support for SME's seems to be of the "moderated community-based" variety. So, forums and twitter, then. This suite is designed to appeal to smaller businesses who are likely to not have the in-house expertise to recognize bad advice - that's why they're going down the cloud route. It's designed to put them on an equal software footing with larger enterprises, except when things go wrong, apparently.

To add fuel to that particular fire (and it's a fire that you should draw warmth from), given that they're supporting IE6 (oh, the humanity!), one assumes that they're hoping to attract users who are firmly near the bottom of the IT knowledge histogram.

Do SysAdmins need to worry about their jobs? I doubt it. Particularly as this opens up new opportunities to specialize in network administration, or to rebrand yourself as a Downtime Troubleshooter. Either way, I suspect there will be plenty of call for your expertise in the near future.

Whilst we at Simple-Talk naturally support PowerShell’s use as a scripting medium, and agree with Microsoft’s policy of encouraging its use as a scripting language, it’s a little unsettling when encouragement turns into compulsion. Powershell is potent magic for the PowerShell priesthood, but mumbo-jumbo for ordinary mortals and, unlike VBA, makes no compromises with the user.

VBA in Microsoft Office was originally introduced as the scripting language that anyone could use, but even this hasn’t been adopted as hoped. Technologies such as the macro-recorder would, you’d have thought, made VBA the logical scripting medium for all of us. Yet I can still count on one hand the number of people I know who are even remotely inclined to script their own macros. There’s definitely an audience for this sort of thing, but that audience isn’t everyone.

I’ll be the last person to suggest that PowerShell isn’t useful, but the time it takes to learn is a non-trivial barrier to entry, and not everyone likes to script. Unless you’re already a PowerShell guru, there’s often a certain amount of pain involved in scripting an operation, as James Allison demonstrated when it took him, literally, days to set up, debug, and perform a PST Import into Exchange Server 2010. The (debatably) braver system administrator with no PowerShell knowledge might download a script from the internet *gulp* and hit ‘run’, but the rest of us will opt for the safer option of a 3^rd party tool to solve the problem in a fraction of the time it would take to tinker with scripts.