Infosec best practice.

How IT and infosec can move past "best practices" to be the best versions of themselves

Bob Lewis wrote an article for CIO magazine entitled, "12 'Best Practices' IT Should Avoid at all Costs." Though it's helpful to have guidelines and benchmarks which help keep organizations on track, that act as a "sanity check" of sorts, not all recommendations put in print should be considered a holy grail. "Best practices" are subjective, of course, though the phraseology leads people to believe that these "best practices" are, in fact, the best. This is the point of Lewis's article, and while some of his suggestions are valid, he's got some of them wrong, too.

We'll look at each "don't do" individually, and I will provide my thoughts on what's good, what's not, and what security teams should do to adopt better practices (because, honestly, if we had any actual "best" practices, wouldn't we all be doing them already).

1. Tell everyone they're your customer.

In this first recommendation, Bob's referring to the relationship between IT and non-IT personnel in the corporate structure. The idea of treating everyone like your customer probably grew out of the historically adversarial relationships between IT and non-technical employees. While treating colleagues and coworkers well should be the golden rule, in actual practice, telling everyone they're your "customer" introduces other potential problems. Restructuring relationships from "colleague" to "customer" invokes the "customer is always right" paradigm, at least in the customer's mind. That's something we don't need. While the inverse isn't 100% true either, in theory non-IT staff are approaching IT staff for help because you are, in fact, the expert. That said, no one needs contentious relationships. 

What we do need are processes that can be used to interact with each other. For instance, employees have gotten into the habit of strolling by IT's work area and causally telling them there is a problem with their computer. If the customer is always right, the response would be to jump up and help that person. This is disruptive, not always possible, and doesn't allow IT to grow as a team. Instead, a better process is to remind the employee requesting help to fill out a ticket that allows IT to track tasks, efficiencies, and identify problem and resolution trends.

2. Establish SLAs and treat them like contracts

In this second section Bob discusses trust and how "the purpose of contracts isn't to define relationships—it's to define what happens when there's no trust and something goes seriously wrong." This assertion is absolutely wrong. In this case, the "best practice" is spot on. Contracts are, by their very nature, relationship definers; they list who holds responsibility for what tasks or actions so there is no confusion, and no recrimination. Service level agreements (SLAs) do that, as well, since they are a contract of sorts.

For example, with terms and conditions defined under an SLA, an end user can expect that someone on the IT staff will look at a "severity 1 problem" within twenty minutes of receipt, and that management will be immediately informed of the problem and will be on the bridge to track resolution.

On the flip side, the same SLA could assure engineers that if an end user inappropriately defines a small issue as a "severity 1" issue, and the team working to resolve the problem is forced to work at 3 AM or on a weekend or holiday, the end user must attend training.

SLAs define relationships, set expectations, and provide clarity to everyone involved. This clarity, in turn, creates better relationships and helps the business run more smoothly.

3. Tell dumb-user stories

Who doesn't like a rousing, good story from Reddit's Tales from Tech Support? They're funny, they're stress relief, they're cathartic! Now, if the story is more like, "Bob from accounting is a dumb*ss!," that's just plain rude. A good tech support story isn't rude; it's an illustration of what can happen if you make/fail to make something foolproof.

In this sense, Bob is both right and wrong. As he points out, it's never OK to insult, degrade, or call out a specific person by name (or detailed description). If, however, there is a real lesson to be learned, and no one is disrespected—or disrespectful—in the process, share stories of how things could have gone better. Things happen during the workday that can be instructive, and sometimes they're funny or ridiculous. But just because an end user isn't an IT expert, they're not dumb, and that's the big take away here.

4. Institute Charge Backs 

Bob seems to think that charge backs lead to idolatry, devil worship, and shadow IT. (Ok, just the last one.) While I don't think IT departments need a full-time accounting department of their own, reminding other groups that things cost money, time, and effort, isn't a bad way to show why additional budget is needed.

Again, it's about moderation. Accounting for the paperclip you used to spring Fred's CD player? Excess effort. Accounting for the 1500 virtual servers you had to build for the CFO's pet project that failed? Explains your overtime costs!

5. Insist on ROI

Everyone today wants to know the ROI on every project, every action, every everything. Time is money, after all. And businesses succeed or fail based on whether or not the organization is capable of turning a profit in a specified amount of time. However, as Bob asserts, not all ROI is or can be measured in "clear, tangible, financial return on investment." A monetary cost for every project simply does not exist. If you insist on measuring all IT projects in dollars and cents, some efficiency-increasing, satisfaction-increasing projects will never get funded and forward progress will not be made. If IT can measure satisfaction, efficiency, or ease of use, for example, then determining ROI makes sense. If you can't measure something, or the results of something, why are you doing it?

Just keep in mind that "ROI" doesn't always equal "budget." And one more thing: make sure you explain this to the finance department and your CEO. Have metrics, use them, present them, but clarify that the company isn't always going to see an immediate increase in profits because of your efficiency-increasing, satisfaction-increasing project.

6. Charter IT projects

"Ve vill finish ze project ven ze acceptance requirements are met!!!! Zen it is dun!!" Bad German accent aside, milestones are useful. Again, it's all about excess. Adhere to milestones, acceptance requirements, and test deadlines like they have been chiseled in stone and you'll piss everyone off, generate worse-than-useless data, and never truly advance. Use milestones, sprints, and goal times to spur your team on and keep them on track, not whip them to death. Degrees. It's all about how you use charter IT projects and the concept of projects themselves that are the problem.

7. Assign Project Sponsors

OK, Bob, you got me here. I, too, despise when whomever is in the bathroom is assigned to a project to "champion" it. Yeah, that nominated person is super invested and will undoubtedly do a top-notch job. (That's sarcasm, if it isn't jumping off the page at you.)

That said, putting together a liaison team which ensures every IT project meets the needs of the organization, asking the business what capabilities excite them most about this new system, discussing workflows with them to see how the new system could benefit users—that is how you cultivate champions. Its' also how you realize a project is a loser without wasting too much investment. (Hint, validation isn't just for startups!)

8. Establish a cloud computing strategy

Bob, dude, you're reaching by suggesting that companies shouldn't carefully consider cloud implementations. There are plenty of companies who aren't in the business of running a data center (and shouldn't be). By laying out a cloud computing strategy these organizations are emphasizing emptying their in-house data centers. Are they wrong? No. They're outsourcing, moving to cloud providers, updating their apps, and generally placing focus back on their core competencies.

Forming a strategy doesn't dictate a false purchase or determine outcomes. It simply means thinking through a set of requirements when or if the company decides taking on a new project, system, or methodology—in this case cloud—is a good idea.

9. Go Agile. Go offshore. Do both at the same time.

Yup, do it. Do both. Nope, not joking. Do it. Do it now. Bob, enterprises have been using offshore services since...forever. Whether you call it outsourcing, offshoring, delocalizing, or whatever the buzzword du jour, I've personally been involved in those types of projects since the 90's. If the equation of cost vs. results works for you, then do it. It's tough. It's a management nightmare to complete the transition, but it can be worth it. This recommendation is not a false best practice...or good practice, to be more precise. It all depends on your organization, its needs, and its capabilities (both current and future). There is no one-size-fits-all here; a company's decision to use Agile or offshoring depends entirely on the individual organization. It's a little silly to make a blanket statement in this context.

As with establishing a cloud strategy, if your company decides to explore outsourcing/offshoring, it's preferential to first outline a plan. Personally, I'm incredibly partial to identifying areas of the U.S. where it is economically advantageous to be located, and opening a satellite office there. For instance, there's a piece of southern Virginia that is amazingly affordable, has a great educational system, and has smart workers with incredible work ethics! My home state of Delaware has affordable labor rates, low taxes, no sales tax, and great access to data centers, bandwidth, etc.

So perhaps the answer is not to offshore in the traditional sense. Instead, delocalize your next workforce away from San Francisco, New York, or other pricy geographic areas and lower your costs, increase your productivity, and gain access to first-class talent. While you're at it, throw Agile into the mix, as well!

10. Interrupt Interruptions with interruptions

Knock knock!

Who's there?

Interrupting Manager!

Interrupting Manager w—HERE'S A NEW PROJECT! HAVE FUN! NEED A REPORT ON FEASIBILITY AND COSTS BY 9AM!! KTHXBAI!

Yeah, it's not bad enough when most techies have ADoS! (Attention Deficit ooh! Squirrel!). We have to juggle fourteen projects, three deadlines, and a caffeine habit that impresses even heroin junkies.

While I applaud the idea of reducing interruptions and throwing away the idea that multitasking is actually productive (it's not. It's been scientifically proven. Multitasking is a big, fat myth we perpetuate because it makes us feel good), I don't think this one is going to change much.

Employees today handle it. We've developed individual coping mechanisms. I, personally, tell my wife and my business partner (two separate people, to be clear), "I'm going to vent, please don't take this personally," and then scream a bit. It works. But I got your back on this one, Bob. The world would be a significantly more productive place if interruptions were kept to a minimum and employees were allowed to work on one thing at a time.

This is never going to change. Sorry, Bob. It's a good "best practice" to avoid, but we'll be saying "stop it" twenty, thirty years from now, too.

11. Juggle lots of projects

I love your optimism. This is a great recommendation. Yes, as with the previous faux "best practice," organizations should do away with requiring employees to work on multiple projects at once. Super idea.

But fully staffed projects? What's that? I haven't seen one of those in years. Any company that can fully staff a project from Day 1 is probably too bureaucratic to complete a project on time anyways. Yes, low- or under-staffed projects suffer from delays, burned out workers, and frustrated project managers, and it's wrong. Budgets are tight, though. Organizations are optimizing every dollar. In security, for instance, there is more work than there are bodies to do the work. However, if you want to figure out how to (realistically) fix this, Bob, I'll buy you a beer and we'll talk.

12. Say "no" or "yes" no matter the request

I can't agree with you more on this one, Bob! How many times in a corporate setting is "black or white" the only option? How many times have you, dear reader, instinctively and instantly thought "yes" or "no" when hearing something for the first time, but then after careful consideration and/or input from others, changed your mind?

Bob, your advice to open a discussion about what it will take—in terms of time, money, and other considerations—to accomplish that project is perfect. As an example, if the product teams wants custom code for a new application and you, the development/IT /freelance team, already have a full plate, instead of saying "no" right away, explain that the answer is "perhaps." Saying "yes" too quickly, too, could also land you in deeper-than-anticipated water. Instead, a conversation along these lines might be appropriate:

For this project, it will take three months, cost $XXXX, and require four people over six days to integrate it when complete. Another option is for us to provide access to the database and you are up and running in three days, with 95% of the data needed. Will either of these options work for you? Let's sit down and figure out what you need so we can work together.

If the requester isn't interested in any solution you offer and offers no acceptable alternatives of his or her own, then you'll have to make a determination on next steps. Just don't make that determination without a healthy discussion.

Conclusions

Overall, this list of "best practices" to not practice is not wrong, per se. Some of these counter recommendations were a bit of a reach and overcompensation for other, worse practices. However, as an industry (IT and security), we're stretched thin, we're tired, frustrated, and burned out. What's the solution?

Act like the professionals we are. Push back on projects that are beyond our current capacity to handle. Sit down with colleagues and coworkers to discuss what they need, and how we can work together to enable the business forward. Build relationships outside our silo. Treat coworkers like respected colleagues and receive the same in return.

Know, too, that "best practices" are simply something a group of individuals adopted because, perhaps, the practices were de rigueur; they worked at one time, in one situation, for one specific organization; someone wrote a compelling blog piece about them; or they are the best we've got at the moment. What "best practice" doesn't mean is that there is no other "best" for you and your team.