Following up on my overall 2019 predictions for Windows and Office 365 professionals, here is the first in a series of blogs that will explore each individual prophecy. In this series, I’ll explore the likelihood of your only PowerShell person leaving, why it’s likely in 2019 as well as my recommendations on how to head this off or react when it does happen.

When I look into my crystal ball, the first thing I see is your PowerShell person — yeah, the one you have on staff — will leave, or at least change roles. That means you’ll be in a world of hurt when you need to change any one of your user provisioning, group management or attribute population scripts, or simply create and manage your Linux or Windows VMs in Microsoft Azure.

This is a straight up prediction based on the odds. The average person spends less than five years in each job, and the tenure for IT jobs is even shorter given the rapid pace of change in technology and the monumental digital transformation happening right now. In the 15+ years I’ve spent supporting the Microsoft ecosystem (I’ll throw in the year plus when I snuck away to the world of Red Hat Enterprise Linux), the command line has gained significant ground when it comes to managing and securing Microsoft on-prem and cloud environments.

The demand is up for PowerShell skills

In a funny twist, while commercial Linux server vendors add more management GUIs (e.g., SUSE Manager and Red Hat Enterprise Linux Cockpit), Microsoft is relying more heavily on PowerShell for Windows Server and Azure administration operations, like in Azure Active Directory (AD), Azure ElasticDB and Azure Information protection.

For folks with PowerShell experience, demand is high for projects that:

  • Build out DevOps practice with Microsoft Azure and Windows containers
  • Integrate those same environments to their on premise infrastructure
  • Automate everyday admin tasks for Microsoft Office 365
  • Manage the server that hosts your Oracle or Microsoft SQL databases
  • Enforce desired state configurations (DSC) across dev, test and production environments

And because PowerShell is so integral to administering your Microsoft ecosystem (there are 900 PowerShell cmdlets alone for managing AD), it’s also an essential tool in your cybersecurity practice. With a near three million cybersecurity professionals shortage around the globe, organizations are building their own security talent by finding candidates with transferable skills like network operations, database administration and application development. A PowerShell expert certainly has an adaptable skillset to fill one of those cybersecurity roles.

But you only have one person who can do this

Pulling on my years talking to customers, I also know most organizations have just one person who took the time to hone their PowerShell skills. Maybe they were a former Linux admin who appreciates the control of the command line or they just wanted to stay on top of their game. It’s not a skillset spread across the team; there’s always just one guy/gal who does the scripting. And that’s because the rest of the team has been dealing with AD for years, rising up the management ranks and handling many IT projects outside of Windows.

So the question you need to ask yourself is: What do you do when your PowerShell person leaves? Who will modify those scripts? Who even knows which scripts are running?

Scripting adds complexity to your environment, and left unchecked can breed micro-developing and unknown dependencies along with security misconfigurations. When you have one person writing scripts, oftentimes the rest of the organization has no idea what scripts are running in their environment, punching holes through walls where they shouldn’t or bypassing security protocols (wittingly or unwittingly). A change in one system or script could break a vital DSC script.

Our recommendation for 2019

  • You need more than one person with this skillset. PowerShell needs to be a basic skill for any system administrator or cybersecurity professional. Period.
  • You also need to put in place policies that dictate when a script makes sense and when it is adding complexity to an environment. For configuring Office 365 and provisioning SharePoint Online sites or other such tasks, PowerShell scripts are great. But when you’re dealing with enterprise requirements for audit logs, error handling and security features, PowerShell can quickly become impractical because of the amount of scripts required.
  • Simplify the complexity of the IT estate by looking for commercial-off-the-shelf (COTS) solutions that handle the big enterprise features you need, such as auditing, threat detection and group management. You should then look for robot process automation solutions (like Puppet or Ansible) that help orchestrate and manage your everyday PowerShell scripts.
  • Finally, with any scripting, it only takes one error to compromise an entire system. So one PowerShell-experienced hacker using living-off-the-land techniques to exfiltrate your data can do some serious damage. You’ll want to constantly audit PowerShell scripts in your environment for security violations and have a plan in place for remediation.

To learn more about how to monitor PowerShell, check out this e-book: Top 3 Workstation Logs to Monitor — Improve Endpoint Security with Sysmon, PowerShell and Security Logs.

Read the e-book today

Related Content