Policy matters - How to discuss with security vs. efficiency with restrictive CTO
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Policy matters - How to discuss with security vs. efficiency with restrictive CTO
I'm wondering how to handle a discussion I'm going to have a at work and would like some suggestions.
The place I work has been a nice place to work. Management lets us know what needs to be done, then gets out of the way and lets us get it done. The new CTO is changing that, though. He's implementing a bunch of new controls and he doesn't seem to mind much if his new rules get in the way, making the work slow, inefficient, and aggravating.
One of the new rules is that employees can't run any software that's not pre-approved by the IT department. That's to reduce a) security risks from people running dumb software and b) licensing issues, because some programs that are free for personal use are not free for business use (mainly for the employees using Windows). I can understand that. However, for low priority issues the IT department can take two weeks to respond. If I have some unformatted XML, for example, and I need to run a pretty printer on it in order to be able to understand and edit it, I don't have two weeks to wait for approval to run an XML formatter. When I need to do cross-browser testing, waiting ten days for approval to install Chrome just won't work.
As developers, we're not going to be installing silly browser bars, greeting card makers, and other "win an iphone" junk. We're also more than capable of checking to see if a program is free or not, so for developers, at least, I don't think the new rules make any sense. Not when balanced against the lost efficiency and morale.
This afternoon we have a meeting with the CTO (head of IT) to discuss our concerns. What would you say to try to sway the CTO? A big part of the problem is how slow approvals will be, and since that problem is 100% his fault as head of IT, I suspect he'll deny that they are so slow. If his IT department responded quickly to requests, so I could approval to run an XML editor within a few minutes, that would be okay, though annoying. The truth is they can take weeks to make a one-line configuration fix, so I wouldn't be surprised if approving a software utility took months. How can I approach it that might get him to back off the policy, rather than defending his department and pretending they'll be responsive?
I think that I'm qualified to make a few contributions to that discussion from the other side of that desk.
First of all, I'm not going to fire you. But I am going to oblige you to present a specific set of concerns and to then make a business case for them. For instance: what tools do you need, what improvements in efficiency of the acquisition process do you recommend and how would you implement them. Do there need to be improvements and streamlining of the processes that you are now using, for which you require these XML editors? If so, I might task you to report to me specifically what they are, what should be implemented and why, in the form of "something I can approve." Think outside every box, and turn them into actionable recommendations with both business advantages and costs. (Every proposal has both.)
Then, I as the imaginary CTO am going to (maybe) oblige you to listen to the contrasting perspective: mine.
A "CTO" is a member of the so-called "C-team." It's a corporate governance position, and therefore laws apply and at least some personal liability is peeled-back. There are many laws such as HIPAA and Sarbanes-Oxeley, just in the United States, which mandate the adoption and the auditing of software-related procedures exactly like the ones that you describe, and I suspect that these regulations might have a part. If not, good corporate best-practices do.
You won't get a-n-y-w-h-e-r-e with the "attitude" that you express here ... that the person, because you perhaps have not taken time to fully understand his or her position, is obstructive, incompetent or just generally clueless. (And if I have mis-read you here, I cordially and sincerely apologize. I mean to be speaking in a general, not a 'talking about YOU specifically' sense here.) That they're doing what they're doing to pursue some power-trippy. I assure you they are not. A position of high-level authority and governance is in fact much harder than it looks. You need to take the time to understand where this individual is coming from. You don't have countering authority, but you are the person on the floor, doing a job that (suh-prize!) that person might in fact be very familiar with even if you don't know it.
The door is open. Make your business case, briefly. Then, "shut up and listen." Not to be reprimanded, but to learn about the other side of this coin.
You have severely lost-points by going directly to a corporate officer with what should have been dealt with by your line-manager. You err, seriously, by imagining that such an officer should rightly be concerned about an XML Editor. But the "open door" policy exists for a reason, and the CTO has an interest in keeping the whole team moving forward, and for taking the time to understand an issue that is obviously simmering in the ranks. It is highly unlikely that you will be given a cardboard box, but you are not handling this in an appropriate way.
Oops. #undef SOAPBOX
I hope that you take these words in the way that I intended, and do not suppose that I mean to chastise you in a public place. I'm somewhat addressing the Peanut Gallery.
Last edited by sundialsvcs; 03-20-2013 at 09:21 AM.
Thank you very much for your reply. I should perhaps clarify two things:
Originally Posted by sundialsvcs
You won't get a-n-y-w-h-e-r-e with the "attitude" that you express here ... that the person, because you perhaps have not taken time to fully understand his or her position, is obstructive, incompetent or just generally clueless. (And if I have mis-read you here, I cordially and sincerely apologize. I mean to be speaking in a general, not a 'talking about YOU specifically' sense here.) That they're doing what they're doing to pursue some power-trippy.
I'm not saying he's power-trippy, obstructive, or incompetent. I said the new controls are intended address security and licensing concerns. Some of the new policies just come at a high cost - making a ten minute job take two weeks. Unless he's psychic, he has no way knowing what problems it creates for us until we let him know. In the department he used to run, people ignored his policies rather than addressing the problems they cause, but I'd rather fix the policies than ignore them.
True, most employees do say he's clueless and he is the butt of jokes, but that's beside the point. The point is getting him to address the cost of lost productivity. In this case, he's trying to implement good and proper controls. He just might be being a bit ham fisted about it.
Originally Posted by sundialsvcs
You have severely lost-points by going directly to a corporate officer with what should have been dealt with by your line-manager. You err, seriously, by imagining that such an officer should rightly be concerned about an XML Editor.
It didn't happen that way. Someone a few levels up the chain of command from me, the head of our department, asked us how the policies are/will affect us. I (and others) answered, matter-of-factly, letting him know about the problems. The senior exec who asked the question then scheduled the meeting with the CTO. You said "by imagining that such an officer should rightly be concerned about an XML Editor". I do not imagine he should be. It is my opinion that he should NOT be so concerned about an XML Editor.
Perhaps therein lies a solution - perhaps department management could approve Notepad++, rather than waiting a few weeks for the CTO or his immediate deputies to review such trivial things. Maybe some other manager can say "yes, check the site in Firefox and Safari" so that "such an officer" doesn't have to get involved in every triviality.
It is, as you can well guess, very difficult to find the proper tradeoffs especially with regard to software acquisitions policies. One thing that often works is to carefully(!) treat the IT group as a slight exception to the usual rules ... as you suggest ... giving them a little bit more autonomy in the selection of internal tools that are peculiar to their needs and with the proviso that the tools that are covered by that ... well, no, it's not a "policy exception" so much as an "exceptional policy" ... must be 'just for the IT group' and still must be accounted-for. In other words, you can more-quickly get your productivity tool, because no one other than you or your group is probably going to need such a tool, but if others do need tools they shouldn't be using your department to end-run. Your department manager would be delegated the authority to make those calls.
Mostly, the C-team concern has to do with auditability, and quite a few of the more recent laws include a definite auditability component. It may sound a bit strange to suggest that a law is actually good with regard to sound IT thinking, but so it is. However, their inspectors can be an entirely different story. You don't necessarily want to be ham-fisted about anything, but your corporate butt has to be covered to satisfy Internal Audit.
Last edited by sundialsvcs; 03-20-2013 at 09:09 PM.
"employees can't run any software that's not pre-approved by the IT department"
This should be true of any business and is true of almost every well run organization. You simply can not allow any Tom, Dick or Harry load what they want to. Too many chances for malware and abuse. While the issue of licensing is there also I'd be more worried about data security. I provide a dedicated computer for people to wreck. I simply refuse to let any unauthorized programs to run on business systems. Why? Past disasters and best practices tell me to have full control in all aspects.
Second to data security is interaction between programs. Even simple programs could be loaded that would interact with other approved apps.
To me he sounds like a good admin.
Too many past examples of issues where companies have lost millions of dollars and countless hours trying to recover from what seemed to be harmless. It's hard to get people to change ways but burn them once and they never forget. If you get burned by some issue, you'll be unlikely to do it ever again.
We're also more than capable of checking to see if a program is free or not, so for developers, at least, I don't think the new rules make any sense. Not when balanced against the lost efficiency and morale.
...A big part of the problem is how slow approvals will be, and since that problem is 100% his fault as head of IT, I suspect he'll deny that they are so slow.
This is kind of going off topic a bit, but I've always understood there to be two ideologies in IT. One is that the function of IT is to be behind the scenes and act as a facilitator to ensure that things work and that people have the resources they need to get things done. The other is the Mordac model, where the employees are viewed as rogues and must be locked down and prevented from doing anything. I find the latter to be much more harmful and that it is best, if not necessary, to strike some sort of balance. To do otherwise results in resistance and people working around you rather than working with you.
It's really not a CTO's primary concern that a developer team thinks that the process is or is not "slow." The C-team responsibility is to be sure that the process meets every point of legal corporate liability, and achieves every governance point, and ... yes ... works as efficiently and smoothly as possible from the point-of-view of those who are doing the daily work. The need for an XML-editing tool is not entirely obvious and must be "on the radar." It doesn't have to be a CTO's specific concern or approval-point ... but a bottleneck caused by it, is.
Noway2, it really isn't either one of these "ideologies," although from the bottom up, it might well look that way. On the one hand, yes, you need to know what resources are needed and why. And simultaneously,without for an instant regarding any of the professionals that you've hired as "rogues," you also must control risk. Those risks being, by the way, both extremely real and generally not well enough controlled.
The challenge, in the upper reaches of executive-dom, is to make sure somehow that the process does work, that people are not end-running the system (which creates a source of risk that you don't know about), and that the auditors, regulators and shareholders are happy. So that you don't wind up as front-page news on The Huffington Post or Wired.
(And if you envy people in that position, the Tommy Lee Jones line in Men in Black comes to mind: "You try it." It's like herding cats.)
Last edited by sundialsvcs; 03-22-2013 at 09:52 AM.