To be honest, I find it odd when you treat it as if everyone else that you work with is a customer. I don't believe in this philosophy. The business is my customer. The business is what IT is trying to protect. If you have individuals that are not following policies, they would be disciplined like HR would discipline for not following policies. It's all in place to protect the business and what's best for the business. Sure you'd like admin rights to your own machine, that will help you individually, but will it help the business as a whole if we get hit with cryptowall again?
I find most “IT security policies” that hamper developers to be mostly security theatre. No matter how many policies they put in place, since they aren’t developers, one junior developer can write:
var sql = “select * from Customer where firstname = ‘“ + firstname + “‘“;
And thwart all of your security “best practices.”
I was the lead dev at a medium size non tech company, and the hoops I had to go through to get anything done dealing with the “security team” was ridiculous and of course I didn’t have access to production to troubleshoot for awhile.
I had ultimate control of all the code that did go through the process. If I were to do something stupid or purposefully malicious, while I didn’t have access to the environment - my code did.
As far as someone mistakingly installing a “crypto wall”, if a user can download a program that doesn’t require admin access, that program has access to the user’s files. The system can be restored much easier than the user’s data.
I find most “IT security policies” that hamper developers to be mostly security theatre. No matter how many policies they put in place, since they aren’t developers, one junior developer can write...
IT policies at large corporations aren't implemented for developers (only). They're implemented for everybody. For every developer, there is a salesperson, admin, manager, or HRBP who will do things they might not fully understand to be "bad".
I came into the industry in the late-90s and still remember the chaos that the ILOVEYOU and Anna Kournikova style viruses caused in corporate offices. Non-technical users didn't know that Windows hid file extensions by default. They didn't think that opening a picture could start a shitstorm the brought the corporate network to its knees. Fun times.
I agree that the current systems and policy for security is in-efficient. It seems that Security policies are mostly roadblocks to production, roadblocks for developers. It's a sad state at the moment and that I absolutely agree with. In this case IT isn't as worried about the users data on that machine. We're worried about the state of that machine taking everything else down with it. Users data should be stored on the network, some data may be local. A user with local admin access and installing malicious software has a higher risk of propagating everywhere. This is what I notice where a divide is between developers and IT. You must change you perspective. It's not a single user we're talking about, it's everything, the integrity of the system and the integrity of the network is based upon the integrity of every node on the network. A vast majority of the threats faced are user based. Somebody clicked on a link, somebody was spear-phished. The biggest threat to IT Security is ourselves.
Users data should be stored on the network, some data may be local.
If the user has read/write access to the network, so does anything the user run.
A user with local admin access and installing malicious software has a higher risk of propagating everywhere.
A sibling post just use an old example of the ILOVEYOU virus that didn’t require admin access to run or spread.
Somebody clicked on a link, somebody was spear-phished.
And if that happens, and if the user gave up their username and password. The perpetrator has access to everything the user has access to. The perpetrator will probably target a user with the access they desire. You say enforce two factor authentication? That’s also easy to scam out of user - get then to tell you the 2FA code. It was happening to Uber drivers.
If you can’t trust the user not to do something stupid, you can’t trust anything that the user runs not to do something malicious or be tricked into giving up confidential information.
Implicit in protecting a business is that the business continues to exist, i.e., that it's run competently and can hit revenue targets, it can grow, etc. Focusing on rules & decorum is playing from behind, rather than thinking about how IT can become a trusted partner from inception (so that you are out ahead).
BTW -- if IT's goal is really to protect the business, then you should find & discover the ways people are getting around your fences, because the first thing that a malicious actor is going to do is find & hop those same exact fences. These people finding security holes should be lauded as whitehats finding your mistakes, not people to be punished for not following rules.
>These people finding security holes should be lauded as whitehats finding your mistakes, not people to be punished for not following rules.
Yes but often if that whitehat reported it and they closed those "holes" you wouldn't be able to get work done, because you can be sure that they wouldn't go the extra mile to create a system where you can do stuff, they'd just close the "holes".
I don't think it's reasonable to treat everyone you work with as your customer, but that's not what's being proposed.
IT's role is generally to support the organization. The organization is its customer. For the most part, it doesn't "work with," but it supports. In any organization, there's a complex network of who is a customer, who is a client, who is a peer, and so on.
There are places I'm not IT's customer, but they're the exception rather than the rule. If IT isn't providing a service I need, then that's a failure of IT. At the end of the day, the fallback is to purchase the same service elsewhere. If IT needs to know about that (e.g. for audits or security), it's fine to have a process for that (I report to IT, IT verifies what it wants to), but if that process becomes an unnecessary roadblock (IT doesn't want to compete for my business, rather than a core security issue), either people will circumvent that process or the business will take a hit.
The customer-provider networks vary on business. In some cases, engineering is the customer of marketing, and in some cases, the other way around. You have companies where marketing decides what to build based on customer conversations, and engineering builds it. In other cases, engineering decides what to build, and marketing sells it. And then you have all sorts of cases in between, from synergistic peer relationships to all sorts of balances where one drives but the other informs.
That doesn't change the gross organizational dysfunction being described in this article.
Boxing IT into a support role minimizes its potential contribution. If business enablement is the goal, that includes innovation, business development, and fixing what isnt broke. Coming to management with new business ideas instead of either waiting to be handed something, or only moving forward with ideas because they address risk and security.
I don't quite think you understand the point of a support role. People who support me do a lot of innovation, fixing what isn't broken, and all of that. Most are highly empowered and I expect a few to take serious leadership roles in the organization, depending on seniority.
The primary question is one of purpose: someone in a support role is hired to keep me effective and productive, and evaluated on their ability to do so. I am their customer. If I win, they win.
The goal of IT isn't good systems architecture or innovation -- it's me. Supporting me well often requires good systems architecture and innovation. It also requires compromising those at times to my goals, having clean transition strategies, and similar choices as well. Those decisions are made based on their impact on me.
You are using IT as synonymous with Support/Helpdesk. Do you have an enterprise architect, do they report to the CIO? Maybe its the COO? Do you not consider systems architecture a part of your IT department?
I absolutely think you are wrong that innovating is derived from your needs, a technology group driving innovation could just as well include obsoleting you. An IT department can bring new business ideas to a leadership team, and arguably their leader is a part of that leadership team, at least until every c-suite person is tech savvy enough to obsolete the CIO position.
I am using IT to refer to more than support/help desk. It includes, for example, having a working network, email, and CRM. It includes custom database applications. It includes an internal wiki and an external web site. It includes lots of other things.
All of those things are there to support the business, not the other way around.
It goes both ways. Is the business user taking inappropriate risks to get his own work done quicker? Or is IT denying access to vendors to minimize his personal responsibility?
Did you miss the line where it was written "before we started the program, we were losing revenue. Now we increased it by 1MM$ / month"?
It seems that the whole point of the article is that while IT thinks that it is serving the customer (the business), it actually lost track of what it was needed to: helping it succeed.
Agreed. Everyone is beholden to the company and its principles, not the CEO or manager, though there should be alignment, but when there isn’t, then it’s the company.
