IT security staffing shortage? Nonsense.

From Codas to Coding

Many years ago I was a kid living in the Raleigh area and I met a music teacher who was leaving her job to go work for IBM as a programmer. I asked whether she had any programming background and she said no — but IBM was going to train her. She said IBM was recruiting new talent into the software field and wanted folks that could handle some math and logic, and to their thinking, music majors fit the bill for them. They were going to provide months of training and bring this music educator up to speed with new skills and then use her to create software for IBM.

That’s how you solve a lack of skills in your industry: you find people that are smart and trainable, and you train them.

The So-Called Security Skills Crunch

These days you can’t swing a dead cat around without hitting a hand-wringing or cheer-leading security industry article talking about:

Well that sounds good to me! I’ve been doing IT security work for years as part of my various IT infrastructure, project, and management jobs. I work with firewalls, VPNs, networks, servers, directories and so forth all the time. I’ve been a HIPAA Security Officer in the healthcare sector. I’m gonna be rich!

So… where’s my big fat check?

Reality of Corporate Attitudes Toward Security

The truth is corporations really don’t like security and they aren’t hiring nearly as much as the salary surveys and feel-good security industry articles would have you believe. To most corporate leaders, IT security feels extravagant and wasteful: “Why would I hire even more people to not produce anything marketable?” Even worse, more security slows productivity for those that actually are generating marketable goods and services. And to guys in the C-suite, it’s painfully boring to boot — whether it’s endless policy discussions or technical reviews, it ain’t sexy or fun.

The data breach explosion and the corresponding breach fatigue come from these corporate attitudes: that security is boring, too expensive, and anti-productive. Corporations that get “hacked” — like Target, Home Depot, the USPS, your local hospital chain — aren’t getting taken by brilliant mastermind super-villains with supercomputers. They’re getting their data splattered across the Internet because they’re lazy and cheap.

It’s Not Good to be the King

king

All that said, I feel for these corporate leaders. They’re living through a Catch-22 situation. Since they haven’t yet spent any attention or money (to speak of) on security, their only internal line of defense is a socially-inept neckbeard who’s answer to every threat — no matter the real risk — is “lock it down” and scold everyone for being so foolish. When that proves fruitless and frustrating they turn to outside security consultants, who cost them a fortune, but who cannot — no matter how much you pay them — force your company to develop and follow better policies or allocate capital or operating budgets to really, truly solve the most pressing security problems.

If you’re a CEO or COO or even if you’re the CIO, most likely you’re better at politics than policy, and you simply don’t know how much to spend in cash or attention to solve enough of your security problems to be helpful without spinning off into infinite expenses.

Security, at the policy and prioritization level, is damn hard. Someone needs to be smart enough on the tech and the business, but have enough political pull to guide changes in daily behaviors throughout the organization. That’s a really rare combination of skills and political powers.

So About That Hiring Problem…

Yep, the situation stinks for the CEOs, CIOs, and other leaders. But the fact remains that they need good security techs and security policy wonks, and they need to keep them moored to the reality of the business and market while also funding their work to a sufficient level.

Given the Breach-a-palooza we’re living through, clearly there’s not enough hiring going on for security-minded people, and security is not part of most companies’ core cultures. But let’s assume that changes. Let’s assume businesses want to get rolling with security-minded hiring. How do they find the talent?

Create it.

Because the Catch-22 that’s stopping businesses from hiring also creates a Catch-22 for potential candidates. Companies that do start hiring security people slap on all kinds of prior-experience and certification requirements. If you’re a candidate with limited or even tangential-but-relevant experience… too bad, chump. You’re not a CISSP? HR’s resume-scanning software will kick out your resume before you even talk to anyone. You haven’t been doing IT security work in a dedicated security role for the last 10 years? Don’t bother applying.

Welcome to the Catch-44

catch22

I’ve seen this before:

  • the software company that wants to hire coders with 10 years of Java experience when the language was only 7 years old
  • the marketing group that wants 5 years of social media experience only 3 years after Facebook opened to the public
  • the certification group that wants you to prove you have industry experience before you sit for the test, but you can’t get the experience without the cert.

This is what I call the Catch-44: companies that can’t hire for security because they’ve never hired for security and are scared to start, and candidates that can’t get security jobs because they haven’t done security work in the past. Employer Catch-22 + Candidate Catch-22 = Catch-44.

Someone has to make the first move here.

Investments Are Made by the Guys with the Capital

So here’s the deal. Companies are the ones with something to lose. They’re the ones traded on the touchy risk-averse stock market. They’re the ones with the deep pockets, funded by tax breaks and 10+ years of depressed employee wages. It’s their responsibility to foot the bill and break this Catch-44 logjam (to mix metaphors).

Follow IBM’s lead… from the late 80s. Hire the music teacher with the raw skills and train them. Only this time you can actually hire experienced IT folks who’s jobs are being outsourced and automated anyway. Move them “up the stack” into security work.

The training is out there, ready to be absorbed. The policy frameworks are out there. Start making the investments.

And until we see real investments in the field by the incumbent businesses, I don’t want to see another “security staffing shortage” article, mmmkay?

When it comes to Google Apps, I’m certifiable

Back in mid-2007 I deployed my first instance of Google Apps, replacing a Microsoft Exchange 2003 server. It was a controversial choice back then — Google Apps was still pretty new and it wasn’t yet clear whether Google was going to stick with the platform and build it out. But there were several deciding factors that pushed me to an Apps deployment:

  • I was working at a nonprofit, so Google Apps was free for us; worst case I could always fall back to the in-house system
  • Our Microsoft Exchange 2003 server was constantly running out of space and was a pain to backup
  • We lived under a monstrous waterfall of spam that required a special appliance outside the Exchange box that worked well but was costly
  • Our Internet connection was relatively slow and outrageously expensive, so handling all the mail traffic in-house was painful, especially when the in-house web site was what we really wanted to share with the world, not our email system
  • Our users wanted to send and receive larger and larger files via email, which only strained all of the above factors further

We made the switch, I uploaded a bunch of mail using Google’s then-primitive migration tools,  and I put everyone onto the web-based interface — no Outlook allowed. We did trainings and I spent a lot of time helping users get acclimated to the new way of doing things. This was before drag-and-drop email attachments in Gmail. It was before full compatibility with external calendar invitations. It was before Chrome.

And I was immediately hooked.

Why Go Google?

From an IT perspective, this Google Apps thing was awesome. There were no servers to own, nothing to back up, nothing to manage — aside from creating and deleting accounts. The users had far more space than they’d ever had (7GB at the time) and far more space than I could have ever offered locally at a reasonable price. The system was accessible everywhere, and no matter where you got your mail or looked at your calendar, it functioned the same way. And, as a nonprofit, it was all free! We even started using Google Docs right away, sharing selected spreadsheet data with remote workers and volunteers, allowing for real-time collaboration that at the time was mind-blowingly simple yet powerful.

Since then the Google Apps platform has matured with better features, a more homogenized interface in the apps, better administration tools, more reporting, more granular controls, and great (paid) add-ons for email archiving and spam control. And since then I’ve deployed Google Apps 4 more times, not to mention personal use. My most recent migration was last year, again dropping Microsoft Exchange 2003 and Outlook to go all-cloud all the time.

And then there was this past weekend.

Getting Certified

After managing and evangelizing Google Apps all these years, I stumbled across a certification program for Google Apps nerds like me: the Google Apps Certified Deployment Specialist. So I dug through the Study Guide, re-read a lot of stuff I knew, learned a few new tricks Google has developed in the last couple of years, and paid my testing fee.

The weird part was the testing method. Rather than send you to a local testing center — where you might sit for Microsoft or Citrix or VMware or other vendor exams — this one is done at home or in your office. You can take the test anywhere you have a live Internet connection, a Windows or Mac machine, and a special USB webcam they make you buy. Total cost is about the same as those other exams, but you can schedule it on weekends in evenings and take it at home. They proctor the exam through the webcam and special software.

It worked great. The only thing I was “corrected” on during the exam was the fact that I started to read some of the questions out loud, to puzzle them out audibly. That’s verboten, probably because they fear you’d read the questions out loud so you could either record the questions (and give them away to others wanting to take the exam) or ask someone else nearby to provide an answer. It’s too bad, because I like to “talk out” technical solutions. Oh, well.

61 questions after starting, I had passed the exam, so now I’m certified! It’s the first major cert I’ve picked up since the “good old days” of Windows NT 4 and Lotus Notes and Domino. And it’s fun to have a Google certification, perhaps because it’s so rare. My certificate was numbered “1298”, which suggests there were less than 1,300 people certified when I took the exam. That’s cool — I’m in a group smaller than my high school census (except we’re all certified Google Apps pros!).

Can you use Google Apps in a healthcare environment?

I may need to address this further in a future post, but the short answer is yes. People freak out about HIPAA (as they well should) but the key thing to consider is how you use your email system. Bottom line: If you don’t store or share PHI (protected health information) in your email system, then HIPAA rules don’t apply. And for those that are using email systems (of any kind) to share or transmit patient data, I have a question: Are you out of your mind? Email is a promiscuous platform by design — it’ll “sleep” with anyone and it’s 1 degree away from every email account worldwide — so why would you ever push patient information through it? If it helps, I’ve actually addressed the Apps/HIPAA discussion elsewhere before.

Sidebar: I may also have to write a post someday (really a rant) about email footers with lots of legal language in them — a silly practice that has no force of law behind it. If you want to put in a “please don’t share this” message down there, that’s cool, but stop trying to create unilateral contracts with your footers — that’s not a thing.

All that said, I do think Google needs to rethink their stance on signing HIPAA Business Associate Agreements (they won’t sign them). They either need to start signing or they need to post a definitive position paper on HIPAA issues related to Google Apps. Microsoft has shown a willingness to sign BAAs for Office 365 services, which makes their service more attractive, despite their downtime problems. Google has done a good job addressing the overall security of Google Apps, but they need to go a step further, to assuage the fears of healthcare executives and Boards that don’t understand technology very well.

What’s next?

For now I’m a happy Google Apps administrator, still learning, still sharing tips with users new to the platform. Oh, and I’m a Certified Deployment Specialist, of course! So if you’ve got questions about going Google in your healthcare environment (or any business, really) just let me know. I can answer some questions in the comments or we can take the conversation offline.