Sales +1-855-261-3391 Chat Blog Partner Support Status  |  Download

Networking Unplugged

Perspectives on cloud networking and software-defined WANs

Posted August 06, 2013
Comments 0 Comments

Pointing Fingers at IT: When CYA Becomes CYPA

This article originally appeared in Spiceworks, an online community of 2.5 million IT pros.  

Everyone is pretty familiar with the old “CYA” policy. It’s not specific to IT. It’s also a policy that no one signs up for willingly. Usually, I like to start doing things with the assumption that I don’t have to cover my proverbial hind parts. I try to do good work, and I hope that others will do good work and everyone will take responsibility for their actions — positive or not.

But at some point it goes awry, and someone starts finger-pointing, and we all know how that goes. The buck stops at the “network.” But since the finger-pointer typically doesn’t even know how to spell TCP, the buck stops at the network owner. You know, the person who runs the thing, and that’s us.

(Interestingly, during the most heated stages of finger-pointing, the finger-pointer usually operates more like UDP than TCP. If you have ever been in this state, and you try to respond to the pointer, you’ll know what I mean. But I digress…)

CYA means that we must do a little extra — something more than simply make sure everything works. We add monitoring, alerts, make a runbook, or publish uptime stats… you know the drill. That’s because managing a network isn’t about just keeping it running — it’s about making sure that all the participants know that it’s running from end to end, no matter what services they need. CYA is all about making sure that when the finger points your way, you can stand tall and know it isn’t about you.

My old CIO, we’ll call her Cindy, had another policy — kind of an extension to CYA — and it is one I will never forget.

Cindy was fine with CYA. In fact, for her, CYA was job No. 1. On the team, we all knew that if she looked good, we were safe. Our jobs were significantly less at risk if her “A” was C’ed. We also knew, quite clearly, that the inverse was always true. If an executive walked into her office and the hollering began, one of us on the team was likely to bear the brunt of the finger-pointing.

Cindy took CYA to a new level, which we called “CYPA.” (I’ll explain that acronym in the story below.) Instead of just making sure we did our jobs, documented our networks, received alerts from stranded machines, and did as much regular testing and maintenance as we could, Cindy often started the finger-pointing. She’d head off possible attacks on IT by proactively attacking other teams.

I’ll be honest: it was super weird.

CYPA stemmed from our IT newsletter. Every month, I was asked to write something that showcased uptime stats, new services, best practices — you know, the kind of thing that never gets read and takes a lot of time to create. I was skeptical; I thought it would be a waste of time, but Cindy was adamant.

In the first issue, she mandated that we establish a regular column called, “Tips for Travelers.” We wanted to proactively solve IT-related issues for our travelling employees. (We didn’t know to call them “mobile” yet.) Travelers represented only a small section of our total workers, but they made up a pretty large portion of the helpdesk tickets we dealt with. It was partly because local folks could walk on over and ask us questions without a ticket, but mainly it was because our internal switched network was fast and reliable.

I had all of our services onsite — in the same building that 70 percent of our employees worked in every day. Mail, files, Oracle, Seibel, backup, web services — everything in a powerfully air-conditioned, glass-walled, very professional data center built (and then left behind) by the previous tenants in the building. Sweet!

Local folks got to take advantage of Gigabit speeds inside the building, and near zero latency. To paraphrase, “This LAN was my LAN, this LAN was made… by ME.” I overbuilt it to be so fast and scalable that I would never end up on the wrong end of the CYA finger-pointing. It was very good, and I was very lucky to have received the budget for it.

However, the travelers had more of a hodge-podge of a network. All kinds of IPsec clients and small concentrators lived across my user base, as if we were “testing” before we made a commitment to any single vendor. And, since I only had the one datacenter at HQ, a person’s experience suffered dramatically as they went further and further from the office. The ramifications of distance and the speed of light can be hard to avoid.

But the main problem that broke my network experience for travelers was my coworker over the cube wall who managed Active Directory. He set the password rules, and they were rough.

Every 60 days, each employee had to reset their password. It had to be unique, not include any previous combinations, be a half-a-million characters long, include 14 special characters, and be precisely 34 percent uppercase — you know the deal.

If someone ignored all the AD warnings and emails and let their domain password expire, they were done. No more network access. No way to reset their password without a call to the helpdesk. No way to email the helpdesk either, since they were booted off of all systems.

Our CIO was none too pleased. She liked the CYA aspect of frequent password rotation, and loved the complexity of rules. But she hated the finger-pointing that came after travelers were locked out of the network, forced to find a phone, figure out the helpdesk external number, and then try to get their password reset.

Cindy wanted employees to change their password before they left to travel, or at least before they expired, and she wanted them to feel responsible for doing so. So in each month’s newsletter, at the top, was the same thing: Cindy’s proactive strike at travelling users who got locked off the network. CYPA stood for “Change your password, a******.” Yup. Cindy didn’t mess around.

Of course, my column never said specifically that. It did in fact say, “Change your password before it expires, or you risk getting locked off the network.”

This simple column allowed Cindy to push the responsibility for difficult password recovery process off of IT, and onto the users themselves. It basically implied: “Stuck without access? Can’t get to IT quickly? That’s your fault, jerk! You got the emails, and you ignored them. You got the newsletter with the big scary article, and you ignored it! You’re a clown!”

CYPA was, frankly, accurate. Getting locked off the network was the user’s fault. But, IT is not just about IT services — it’s also about customer service. I believe our role is not just to build the best tools and services we can, but also to support the people who use those tools (who, unfortunately, are often clowns).

We all know those people can be the worst part of IT when they turn to finger-pointers, but CYPA meant that I was forced to be that finger-pointer as well. No good.

CYPA-type policies can escalate unintentionally, to a point where some level of IT responsibility ends up being pushed out to end users. When this happens, it can impact end user experience and IT service level. What we really need are systems and processes that ensure business operations (and offer enough CYA to keep things safe), without burdening the end users with increasing responsibilities.

It’s only when I was able to implement systems and processes that enable end users to get things done simply, while still protecting the organization, that I ever felt like I had really done the right thing. I think that’s why CYPA never really felt good to me.

IT is a balance. Here’s hoping the networks of the future can help us strike that balance without too many clowns, fingers, or password reset calls. And maybe a few less CYPA-style IT monthly newsletters as well.

Chris Webber

Chris Webber

Product Manager

I've been on both the smart and dumb ends of the helpdesk phone, owned telephony and mobility, managed security policies and implementation, built and maintained site-to-site and internal networks, and owned and maintained "the lab" more times than I care to recall. After spending time at web security, cloud security, networking, and mobile companies, I'm now a Product Manager at Pertino.

comments powered by Disqus
Chat now Click to Chat