"Soon enough the CIO sniffed out the project and called her in to a disciplinary council."
Somebody has apparently lost touch with who the customer for IT is.
Somebody has apparently lost touch with who the customer for IT is.
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.
var sql = “select * from Customer where firstname = ‘“ + firstname + “‘“;
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.
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.
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.
- It spread by reading the person’s contact information which doesn’t require administrator access.
- It also corrupted the user’s files and didn’t require administrator access for that either.
It's really easy to secure / fix / support a system by making it nonfunctional and redefining that as success.
Lol! I'm stealing that.
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.
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.
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.
All of those things are there to support the business, not the other way around.
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.
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".
However it does often seem like IT doesn’t consider SaaS solutions - they always want to build something their selves without doing cost analysis.
If you need rules to force the business to engage with you, you've failed.
Thats the situation the CIO had to respond to. Just because its not part if your role to consider security implications of these SaaS services doesnt mean he's out of line for doing so.
Something like Azure AD, ADFS, or 3rd party (that you assume to trust) like OneLogin. In all cases you would never enter your password into the SaaS service you are redirected to a secure portal controlled by the Auth Service, a token is then issued back to the SaaS service
Further it would be recommended not to use an elevated account and certainly not something like a Domain Admin account for those services
The problem is typically that cookie-cutter solutions don't necessarily map what the leadership requires: either the cost is too high, the knowledge gap is massive (e.g. the tool can do everything, but requires specialized knowledge of an obscure DSL and implementation details only three people in the world have actually mastered...) or the security implications are nontrivial.
To be fair, I do know also people who will always prefer to build their own anyway, because it makes them feel more in control (which they are). It's the CEO's job to rein in these tendencies when necessary, though.
It's fear of malware.
It's fear of data being locked up in the format used by an employee's personal tool.
Above all, it's fear of being held responsible for any of the above.
It's also a fear of being not needed.
Having the resources to install a CRM for someone this year is a fundamental part of any properly equipped IT department.
Can you call your IT security strong if you are dangling irresistible incentives to break the security?
There's a reason they went around the CIO. I suspect if the CIO had met with this person they could have learned and helped.
"The CIO admitted that he had been approached and explained that he had informed the VP that IT already had a project with SAP to deliver what the VP needed. “Yes, but that won’t be ready for me to use for three years, and I need something today,” retorted the VP."
The manager had a valid and valuable reason ("increased revenue $1M per month") to require a service that CIO and their organization was unable to provide in a reasonable timeframe, but other companies on the market were.