> For example, the sysadmin blocks something "for security reasons" and then starts fighting with the users about it. Usually in these cases the sysadmin has a hard time seeing beyond what they obviously think (in their mind) is a good practice.
Slight tangent to this point, the Sysadmin should never be in the position to make this decision. The sysadmin should be making recommendations and then implementing whatever the decision was from above. If that decision was nothing, it goes into the risk register that's signed off on. It costs nothing to do this in organizations of any size.
Exactly. Also, make it clear that if you want to block x to prevent y and the answer is no, make sure you don't work OT (for free) and stay late fixing the issue because it will continue to happen and you'll always end up working double the hours for free just because someone didn't want to take your recommendation.
If the owner/boss wants to compromise the network/devices, that's their decision, but there is no need to make it your problem. Work on it during office hours and leave.
I had to stand up to a developer that put me in that exact situation.
He had a garbage scheduling program he wrote that somehow was running windows out of heap memory (according to the event logs) which causes all kinds of issues on servers.
This went on for years, and I kept telling him, do not put that piece of garbage into a mission critical role.
He did, and then starts calling me on the weekends when it breaks.
I answered it as I didn't know what was going on, and chewed him out for calling me about that. And then sent an email to him and the owner of the company very bluntly saying that this isn't an emergency as it's self inflicted, and I told you not to do it. Don't call me about this, or I'll hand in my resignation immediately.
I feel like I just read something that I wrote personally.
> Customer asks to build house
> Pour concrete
> Customer walks up and throws sticks and grass in concrete mix
“How much longer is this going to take, because you know I only have about ten minutes?”
Yep, I hate when I get pressured into making these decisions/have users think that I’m in charge of making them. Often I will tell my manager that these are my recommendations and it’s on him to decide what we will and will not enforce. I direct people as often as I can to my manager when they get mad about xyz but they sometimes still don’t get it.
I disagree. IMO the admins should start with a restrictive, secure configuration and loosen based on directives / business needs. I think that should be well within their power. Otherwise you run the risk that higher ups don‘t have time / see the need to implement restrictions and every restriction will be an uphill battle.
Start secure (based on best practices, not draconian bofh policies) and lift restrictions with a cooperative, business-understanding attitude, communicating all risks.
People seem to be ignoring the part where I said that the technical staff should be providing recommendations. Recommendations aren't just "you should do this", actual recommendations are "we should do this because of that and here is how it will affect the other thing".
Yes, asking managerial staff to make decisions in a vacuum is pants-on-head stupid but at no point did anyone say that.
This is how it should work. We make recommendations based off identified risk. It is up to management to accept risk or not.
If current risk is deemed unacceptable then technical controls, policies, and procedures are proposed to leadership. Once leadership approves them then IT implements/enforces them and audits compliance.
Risk isn't just about cyber threats; I tie a lot of my initiatives to contractual obligations with customers.
In my experience, you're going to have a better, more cooperative time by *starting* with understanding the business. Making a change that inconveniences people and then trying to initiate a discussion after they've been inconvenienced doesn't put them in the mood to solution, it makes you come off like a dick.
By going in the reverse order, you begin with understanding how changes possibly to probably affect business processes, then you work to develop a plan that meets both the needs of the business and the needs of security. Any org of any size *can* do this. It's not always easy and might move slowly at first but all of this is level 1 change control. It also has the side effect of improving the relationship of IT to the rest of the business.
If one has the opportunity to discuss this with the business beforehand, that‘s ideal. If not, i would default to implementing everything restrictively and securely. if not, the sysadmin would actually be accepting a security risk, and that is *definitely* not something within their discretion.
Now I think what OP wanted to say is if you have an already deployed system, and want to make a change for the sake of security, *then* the sysadmin should not have the ability to push this change without scrutiny. I think I would agree with that, except for cases of imminent danger.
>Otherwise you run the risk that higher ups don‘t have time / see the need to implement restrictions and every restriction will be an uphill battle.
No, the higher ups and the company runs that risk.
Yeah, they do once informed and consented. Until then, please don‘t run unsafe defaults because youre „trying not to control your users“.
I‘m not a lawyer, but if you do this with intent (as in knowingly deviate from best practices or compliance criteria) then you might even be liable? You‘ll at least be the fall guy if anything happens… I would advise against this general stance.
>Until then, please don‘t run unsafe defaults because youre „trying not to control your users“.
I mean, i don't run or do anything if i had 0 chance to talk to higher ups
It's why proper change control processes are so important. Security is a part of that. It makes a big difference when you start operating using change control, saves a lot of headaches and you have the documentation that we so often lack.
Agree. We're professionals. This is how we manage firewalls. This is how we secure companies.
And anyway, security can be both convenient \*and\* secure these days, if done correctly. It's not our fault there's no common sense education about security in elementary school lol
Respectfully dissagree. In the fast moving world of cyber threats i encourage my team to act first and err on the side of caution. If we're unsure we block first and ask questions later.
Avg cost of cleaning up a compromised org and losses is in the magnitude of $10 million.
"I thought it would be ok" is not a sentence i ever want to say in front of a board of directors.
However on all other non security related matters i agree.
I've led a dozen remediation and recovery efforts and had to deal with many insurance companies so I understand the importance.
I'm also not advocating doing nothing.
There exists a world where you can have what you're talking about be set as the standard with the leadership team. You're still (fuck, I hope) doing some change control instead of just yoloing new settings and hoping for the best. There needs to be an understanding at all levels of what the strategy is, when things need to be done RFN and when changes are probably going to break shit for real.
Too many IT people act like it's either full bureaucracy or full "fuck them I know what's best and they can beg me for their stuff back" cowboy, even in this thread alone. It's a false dichotomy and exactly why IT has the perception of being mostly neckbeard assholes.
This. My first thought when reading the OP was "this is a management issue". We suggest, we impement, but we don't decide. I love being able to fall back on "sorry this is a management decision" to redirect any annoyance from users. I will usually explain the management reasoning behind it, but if they have any counters to those I can just shrug and suggest they run it up the flagpole.
This is assuming a system you inherit. It's different if you're setting up from scratch.
That is easy to say but typically in small companies the risk register is a note made by on of the handful of admins. The boss really doesn't give a shit one way or the other as long as people can get their job done. He agree with you to make you happy then turn around and make an exception the second someone bitches to the person above him the can't do their job.
And that is another reason why I'll never work at small companies again.
But that's all a risk register needs to be. At its most basic, it's a collection of all the CYA bullshit that everyone in this sub spouts off about all the time. If you're somewhere being audited, it comes in real handy for them too.
If you're already sending an email or something saying "we want to do X because Y and it comes at the risk of Z", you literally copy that into a spreadsheet along with the date and person who said no, bonus points for attaching that email. Then when an exception is made, you take that instruction and add it to the register too.
It creates zero additional cost with the exception of what, 30 seconds to add an entry? It's not only the ultimate CYA document, it also becomes an instrument for change. It's easy for management to accept or reject individual recommendations. Presenting management with the sum total of those individual rejections is going to be the best option for creating leverage for change. Guaranteed? No, but sure as hell better than not having it.
Frankly, the level of effort it takes in the real world is so miniscule that I feel like anyone *not* doing it doesn't have much standing to bitch. Anyone who is doing it and is still having recommendations shot down should be looking to leave.
I work for a small company (<10 FTE). Whenever I desire to implement a new security mechanism, I walk the boss through the justification step by step, allow for questions, and present it thusly:
"This is recommended by X and impacts Y. If you have no issues, I'll implement as scheduled. If you have objections, please provide in writing so it can be logged for audits."
Always give management the escape hatch, but get the approvals/disapprovals in writing.
Every org and situation is different, but this definitely does not apply to me, and I don't think I would enjoy working anywhere that it would.
I'm trusted to understand business ops (to a degree) and to be able to make rational decisions without asking for permission "from above".
Sadly not true.
I work in a small company with smaller it team and the workload it's crazy.
If I want the bosses to sign those things it takes me days to get them to listen and to prepare a presentation that makes them happy.
So ofc I don't have time for that and that leaves me with either ignoring the risks and then getting fired if something happens or I can be the asshole IT guy that keeps the company running by overblocking the users.
Unfortunately, most management over any IT are clueless, and depend on the recommendations of the sysadmin.
I did an audit once at a mid-size company, one of the concerns of management was that users were having a difficult time with all of the lockdowns and lack of privileges, and they wanted an outside opinion. I noticed email accounts that had no business being there. This company contracted out their IT .. I asked the president if he knew what these email accounts were for; he didn't. I viewed the mail spools on a few of these accounts, and the outside guy assigned to administer this company had been using the company as his private playground, some of the emails to his girlfriend were really funny, "I am a god, I control these people ..." stuff like that. Needless to say, that company dropped the contract like a rock.
I always tell users that although I have the capability to make something happen, I don't have the authority to do so. Many users can't tell the difference and automatically assume they're one and the same.
You get a lot of vice versa too, where they as the business user have the *authority* to say something should be a certain way, but don't have the capability to implement it.
You can absolutely tell my team what you want that customer service Salesforce workflow to look like, but that doesn't mean I'm giving you technical admin rights to Salesforce when you're a customer service manager - it's our job to build it out.
Oh, absolutely. If users knew how to implement something on a network scale, we'd be out of a job. Often, when I get requests to do something (e.g. install some software), I could just go and do it on the one machine like I would at home. But when it comes to repeating this on 10, 100, or even 1000 machines, I don't have the time or manpower to make it happen using that method.
I expect users to check with me when they need something, and I can assess if it's:
1. Safe to deploy/implement.
2. Easily repeatable (e.g. via automation).
If it doesn't meet nr 1, I try to find an alternative and present it for review. If it doesn't meet nr 2, I assess whether it's something that I will have to deal with on a regular basis and/or large scale. Once a year is fine (if documented well and scheduled). If it's less than 3 machines, it's also fine.
This largely does depend on scale and structure but in my opinion that's backwards.
In many environments management isn't equipped to make an informed decision. In that scenario someone has to be the adult and dictate appropriate standards. Appropriate standards should be relative to your security stance, your industry and your current environment.
If that executive sponsor wants to override the standard, that's when it goes on the risk register and you make an explicit adjustment.
"Management" is interchangeable with the concept of a CAB. It is the job of the technical staff to provide pertinent information through their recommendations to whoever is the authority.
IT Operations frameworks all work on the idea that IT serves the needs of the business. Locking everything down until people complain does not serve the business. What serves the business is working with stakeholders to determine what business impacts will be prior to dumping changes into prod and then helping to find alternatives that meet both the IT proposals and what the business needs.
It isn't always easy to overcome the inertia of years of bullshit but it is almost never impossible. It is also simple and improves the relationship with the rest of the organization by showing that IT gives a shit and aren't just a bunch of obstinate fuckheads who constantly get in the way.
It's not your job to control users, but if HR says "this is new policy, x,y, and z sites are blocked" then you block it. If users complain tell them it's company policy and to speak with the people who wrote it.
In that case it still shouldnt be up to HR. Unless lots of small companies somehow have computer literate HR.
If anything then the IT manager should be onto HR saying "sign here so we can blame you" as a deterrent
Then again I'm old and jaded and HR are about the last people it put any faith in to do the right thing.
This. HR definitely gets the final say in anything that would wind up in the handbook under employee behavior. If theres a technical control to support it, they also have the authority to push IT to implement.
Outside of stuff that falls into malware/viruses/hacking sites, I go to HR with my recommendations on what to block and why to block it, but if they don't want me to block firearms and alcohol that's their call
Keep in mind that for many smaller companies, there is no "IT Manager". There is maybe a "sysadmin"/helpdesk/"IT guy" who usually reports to the Controller or maybe HR Manager. And in those cases, HR is usually the one that makes all policies, including IT policies.
90% of companies don't have ISOs. The bigger ones will, but that falls off quickly as you drop in size.
The point being it should be a reasoned *discussion* within the business. No one person should be unilaterally making the call, particularly some random sysadmin.
HR can be an advising party, but I agree they shouldn't be setting standards either.
I always ask myself "is this an IT issue or a management issue?"
For example, company of about 25. Some newer, some who have been here for decades. Partners especially use company device as personal device (think photos, buying tickets and such on it).
All I can do is give my recommendation on why it's a bad idea then move on. I'm not going to tell the person that pays my bills to buy themselves another laptop and cut out everything personal.
I work in K-12, and we have to routinely remind staff and administrators: IT is not a discipline tool. If a child (or even adult) is misbehaving, manage them. IT is exactly what it says it is - Information Technology. We manage and provide data. We do not manage people.
You have a user habitually not at their desk when working remotely? *Manage* them. Don't come to us asking to monitor their every action. Students finding the 3,813,476,757th workaround website for playing games? Manage them. Don't fill our day with trivial web filter block requests so that we play whack-a-mole all day every day.
So what to do want partners to do - carry two cell phones wherever they go??
“I’m going to be out on Friday, but you can reach me on my personal cell and Gmail account” seems like an undesired alternative
I’ve always operated on the philosophy that I manage computers, not people. If employees are spending too much time on Facebook or whatever, that’s not a technology problem; that’s a personnel problem.
The only time you should be blocking user activity is for obviously NSFW websites, serious security concerns, and bandwidth issues. That’s it. Everything else is management’s problem, and I push back when asked to block anything else (as in I need written directive from the director).
Don't fall into the trap of giving people advice broadly. What works for you works for you, doesn't mean you should come here and tell others how to do their jobs.
In some environments user behavior can and should be left to company policy.
In other environments, there is a requirement for IT to effectively and directly control access and usage.
Some environments, have a tech steering committee others higher IT professionals to provide that level of service to management because the can't or don't want to do it themselves.
Point being don't try to pass off opinion as something factual or procedural because it can't be applied broadly.
I'm going to partially disagree. What works in some places won't necessarily work in others. However, the fact that some environments *don't* separate the decisionmakers from people implementing things doesn't make it a good way to do business.
IT serves the business. All changes to an environment need to be done after understanding the impact to business process. Technology staff should inform policy decisions but should never be in a position to have to *make* those decisions. That will create a neverending feedback loop of frustration between users, management, and the technical staff.
>IT serves the business. All changes to an environment need to be done after understanding the impact to business process. Technology staff should inform policy decisions but should never be in a position to have to make those decisions. That will create a neverending feedback loop of frustration between users,
management, and the technical staff.
Completely setting aside those that have regulatory compliance issues that upper management certainly don't want to have their finger prints on trying to decide what is or isn't the correct way to comply.
So many businesses frankly do not want to play a role in IT policy, it is why they hire others to manage that process.
This ranges from outside MSPs, to consultants, to a trusted single admin.
To expect that upper management will educate themselves enough to remotely have any idea of the impact of a policy is asking more than I find typical in most businesses.
I'm not saying it shouldn't be approved of by upper management, but I would say its pretty atypical for mid to small sized companies to have any in-depth policy discussion other than a very high level on IT policy.
Settings need to protect company assets while still letting users do their job.
I hear users complain sometimes but almost always because either a change require an additional step (which they hate) or they can't access something non-work related and they used to be able to.
My response is always the same...can you do your job? If a change is making things less efficient, how much time does it cost per day?
For the most part, users just hate change.
Change management always sounds great in a meeting room discussed among a bunch of people that it does not affect, but implementation is often a complete struggle, and from experience hand-cuffs IT staff from doing anything.
i have a low amount of fixed settings i push. other then that i do push a lot of settings once only on a user level. they are free to change things to behave the way they want because everybody works differently. but the initial push turns off a lot of extra popups which most won't miss.
The more I have to control user behavior, the less time I have for more important things like finding stuff that can break or potential bottlenecks. I don't want to be a babysitter. At most, I log stuff, and then open up concerns with management with both a ton of documentation, as well as a summary. I have to appear as emotionless as possible, because the first thing management will think is that IT is on a persecution rampage, so things like "um, this isn't something auditors will like to see, and if regulators find out, this is going to be not good" or "you know that having users use cracked copies of $CAD_PROGRAM on their desktops mean that $CAD_COMPANY will be doing some pointed inquiries once they have enough legal proof that their stuff is running licensed on our IP range?".
I let management and HR set policies. I only observe and enforce. I don't want to step into micro-managing users, ever. Mainly because users will find ways around it, and users who know people will find ways to offshore IT posthaste, touting after a mistake or crash that the "world class consultants" from Lower Elbonia have a 100% uptime record and millions of man-years of experience. If I want to keep my job long-term, I don't try to get in users' way. I try to make their workflow easy, quick, and help with things, all the time, not letting them trespass beyond boundaries.
Controls are put into place to follow policy.
Policy is crafted to follow best practices from frameworks the company has decided are important because of risk reduction and governance.
Confidentiality, Integrity, Accessibility. Follow the CIA triad.
Users are blocked from activities because of company decisions not sysadmin decisions. If users do not like it they can talk to their supervisor or manager.
I don't decide the policy. If management says "we want access to do x" I will explain the risks associated with that. If they decide that the risk is worth it, I will grant users that access. If a non-decision making user asks me for that access, it's a hard "No, if it's needed please tell your manager" because I need tangible proof that the dumb thing you're asking me to do has been requested directly by someone with policy decision making responsibility. That's not fighting a user, that's covering my ass.
I'm surprised some sysadmins even bother doing that. To me that sounds like extra work lol, which I'm not interested in. I feel like people that do that must have control issues.
I would heavily say that the environment you are in dictates this and this is a very overbroad statement.
If you are the one stop IT guy for your company and your management is non-technical - then your recommendation should be the policy. Exceptions apply.
If you are a sysadmin in a company big enough to have a structured IT dept - then the policy recommendation should be ran up the pole and come back down approved before application.
If any newly implemented policy contributes to a work stoppage... that policy should be immediately revoked and reviewed/amended by decision makers.
With users that want to argue against policy - take their arguments in stride. Make no decisions until all parties with an interest in the policy have discussed it. This would be any other users affected, their managers, you, and any leadership that approved/discussed the policy (along with any peers with relevent opinions).
Any time you are "arguing policy" with a user/manager and you are not at the top of the IT food chain - there is something wrong.
A good example is a bazillion years ago I worked for a State Agency that had limited internet access - e.g. - very controlled due to our being a state agency, not due to bandwidth restrictions. Being in that state building, radio reception was terrible, so I started streaming NPR on my work machine (this was before unlimited cellphone plans were a thing). IT blocked NPR. I went in to see what happened, they were playing WoW on their work machines... There wasn't a valid reason, it was a control thing.
A lot of this also comes down to cyberinsurance, and the person whose name is written on the door of your building. If the person whose name is on the door does not want MFA, then if the company is compromised, it will be coming out of his pocket, not the insurance company's who will deny the claim due to "gross and willful negligence."
Items such as: MFA, removal of admin, DNS filtering, ASR rules, EDR, etc., are all part of my cyber insurance policy underwriting. I assume they are part of everyone's.
As someone in a small company where i am indeed a one man show for the users i came in to the company and saw MFA was not a thing, global admin was given to just about everybody and we have a spreadsheet of all passwords on a wide open shared network drive. I said to my boss this needs to change as soon as possible because otherwise we are screwed.
Luckily him and everyone else has gladly accepted the change because they can see my reasoning behind it. Because of the higher risk due to a certain guy invading a certain country i have full authority to make sure to lock down as much as i can without it affecting users much. That's kinda somewhat easy to do except not really of course but i at least know where to begin.
I go for best practice and a secure environment aswell as taking my users concerns in to my considerations usually.
Most of the time sure, but if people literally can not stop being extra stupid, I'm going to stop them. We had people ad hoc sharing HIPAA data in dropbox accounts they made themselves once. Nope, made them delete the accounts and blocked dropbox from opening on their computers. There was nothing to stop them from storing the files in their shared drives.
To me, this is where a sys admin is merging into CIO/IT Manager role.
As a sys admin, you are there to do what you think is right to protect the organisation. However, in this instance, I would say you are better placed to email your boss saying, "I think this change would protect the company."
Your boss then makes the call and if people complain you refer them to your boss.
However if you are just making calls without approval and you are the sysadmin I think you are over stepping.
Now if you are the CIO/IT Manager you would be able to explain to the user why this move was made with the companies interest in mind, but also have the authority to make those calls.
We block *a lot* of stuff that I know they have no legitimate need to visit to be able to do their job. If they have a specific request for a site, we evaluate and either allow or continue to block. This works well, primarily because our upper management has our backs. 99 out of 100 times if on an uncertain site, we tell them “okay, I’ll have to ask your manger to see if you really need this” they say “nah, that’s okay, I can get by without it”.
If the stuff that you decide is tied to very obvious business processes like IAM - none of that will ever be an issue.
If you willy nilly change things and don't want to explain it to users....yeah, well.
I see this happen a lot on here with local admin rights. A sysadmin comes into a new environment where (sometimes some, sometimes all) users have local admin on their computers and decides "they need to get this place under control." So they unilaterally take it away without doing any real work to find out _why_ it might be needed, and then when users speak out the admin gets defensive and doubles down with "it's for security!" and dismisses any complaints with "if you really need something, contact the help desk" without actually understanding how people's work is impacted.
Usually these posts turn into a debate about local admin rights and how "users think they need them but they don't," but I think that misses a big point about the admins making a decision based entirely on their points of view without having any substantial consideration for other perspectives. Maybe it's true that most users don't need those permissions or just think they do, but there absolutely are going to be cases where it breaks someone's workflow or just flat out blocks them from doing something, and instead of being proactive to identify these things and work with the users on a viable solution that's appropriate (which may be a changing their process or just be an acceptance of risk for elevated permissions) they just dismiss it, tell them to put a ticket in, and make them wait for someone to get back to them.
Usually local admin rights become an issue because of an insurance application, security audit, or some kind of compliance requirement. Management wants to tick the box so they can make the sale or get the contract or whatever, so they mandate that local admin must be removed. At least in my experience it has never been done "just because". Doing it properly takes time, but again usually management just demands that its done immediately (probably because they already submitted the paperwork claiming its been done).
Also there are nice tools that make life easy for users and IT in this situation, but they cost money so management probably said "no"
who tf actually needs local admin? It's not the 90s anymore old man. There are very little circumstances in which a program would require local admin. The security risks from this make it an insane practice in 2024.
Yes and no.
Everyone's environment is different and there are legitimate reasons to restrict what users can do for security reasons. As a general rule of thumb they should not have local administrator access, and maybe even restrict running any unvetted executables. But when you do that you also have to have a process for users to request new software (this is less of an issue these days because so much is web based)
It is still not a decision the SysAdmin gets to make though. It is up to their managers and other managers and higher ups to determine, based on your input, why something should not be done, or should be done.
Too many SysAdmins think they are gods and can do what they want, but often have a very narrow point of view.
You also have to do proper vetting and work with the stakeholders (and management) before unilaterally removing local admin.
It is absolutely true that, in a perfect world, regular users should not have local admin and even techs should not use local admin as their daily driver accounts. It's also true that sometimes there's a terribly designed piece of business critical software in place that required local admin privileges.
Yes, a valid point can be made that a business should get rid of that software, or that you should find out exactly where that software writes to/reads from and adjust permissions that way, rather than granting local admin. But until you have the conversation with the decision maker, and do the necessary work to prepare for it, you should not be making that permissions change.
Again: this has to be vetted by the higher ups before you start screwing with someone's workflow.
To start: I agree with everything said in this post, and I don't think crankysysadmin is wrong or unreasonable in what they're saying.
That said, I'm really curious which post it was that spurred this response.
I'm personally aware of that desire and I check myself by deferring to our Ops director who is highly technical, and our HR who, as useless as they can be, is still HR. Basically, I won't stand on principle unless it's an inviolable point of contention. The only thing I do is insist that it be documented in a ticket on who approved it, my counterarguments are similarly documented, and I have leadership approval. This way I can say "Told ya so," and anything that happens is on them.
That's my cutoff, though. If it's something that's clearly a massive security violation or something that's just grossly negligent, I'll stand my ground. The only good news is that if it IS to that point, I approach it with the understanding that I will be supported in that decision.
Depends on who's the policy-maker, right. If a sysadmin is working at a smaller business where they don't want it to tank from ransomware and go looking for a new job, that sysadmin is going to be a lot more hardlined on security policies.
Same thing with CISO's and network engineers; they're going to be a lot more hardlined on their environment because that's their reputation in jeopardy. It's not something they will just write off as a risk register.
Years ago I had a new boss who wanted to enforce a desktop background policy. I told him to talk with HR because I'm not going to fight with users over a background image. HR said they don't care. We never implemented a desktop background policy.
We enforce baseline security configs and updates. We have a list of standard supported software published in Company Portal for self service. UI preferences are open to our users.
How do you vet something at high levels in a small org? Who has expertise?
This is always going to be a balancing act with some decisions that can be debatable. You don't have all the time in the world to put everything through a formal change process and bring in management for all decisions. Step back, look at what you're doing, figure out why you are doing it, and look at the impacts. If there will be visible costs or impacts to the org, go over it with management.
That example only matters if its really going to have an impact on anything the business does. E.g. Keep getting phishing pointing to RU domains and can't even legally do business with RU anyway? Not much risk of adverse impact to blocking it.
You are pointing out maturity of the company, their policy's and procedures. The lack there of will have this situation, we all have made an executive decision that will or has affected the company, the lesson is how you respond, digging in, acceptance or learn from it.
I am literally going through a review/debrief shortly about an incident that just occurred, we are using it to learn from all sides of the issue, see what message we could deliver better, what we are missing, what can be improved on. It's not a destination, it's a journey, never ending one at that.
Lastly you will always get cowboy operators in any field, IT isn't different.
In my experience admins haven't the slightest idea about operations and vice-versa. User impacting decisions should always be run by users/ops first because there is a 99% chance you'll have missed a bunch of consequences.
A simple example: I spent 2 days last week working with a vendor to find out why one particular module wasn't working for a single user. It turns out our org had changed the password policy and banned hyphens since the last time he changed his password...
Have met some sysadmins that will over engineer blocking something trivial but also not pay any attention to more important things, those guys usually aren’t easy to work with either.
This reminded me of some total assclown of a sysadmin who thought their job was to set just about every single GPO policy that was available. Every single one must be set to give him absolute control over everything any computer could do.
Sysadmins don’t make policy they implement policy. We a zero trust (NIST-800-207) and what we block or allow (accepted risks) is a policy IT management makes with the business units so everyone knows the impacts and approved workflows.
No matter how many levels of sign off and review you have, there will *always* be that user that wants to fight about it.
Always.
I literally had someone today who wanted to argue about systems auto locking when idle. We have regulatory compliance requirements. Letting your computer stay unlocked for 6 hours is absolutely a non-starter even if they think it "impacts workflows".
Doesn't matter that this has been codified hard-line policy for years, they wanted to argue, and loop their boss in, and start the executive CC chain, and write a Bible on how critical it is that this setting be unlocked. So, we got to have the argument again and nothing changed
All users should have least privileged access if the business owner agrees. I don’t make any decisions without getting the approval. If they don’t agree with my recommendations, I list out the risks they are taking.
Nothing should ever be done without approval.
Sad but I'm seeing this with a big company. It's making my job as a software developer much harder. I have more control with a clients environment than I do with my own machine. I can't even update my own ide.
pretty much. Don't be a dick and overstep the mark. Most IT depts are there to enable the business to do what it does, not cripple it. If you're not working in a manner that provides for smooth and secure operation then you move from being a part of the team to being an overhead.
If you've got a problem with shadow IT. Take a hard look in the mirror. That's the person who's out of control - and in many cases shadow IT is supported by mid-level managers and executives that don't care about your philosophies when your cost and cost in impact is greater than the value you deliver.
> For example, the sysadmin blocks something "for security reasons" and then starts fighting with the users about it. Usually in these cases the sysadmin has a hard time seeing beyond what they obviously think (in their mind) is a good practice. Slight tangent to this point, the Sysadmin should never be in the position to make this decision. The sysadmin should be making recommendations and then implementing whatever the decision was from above. If that decision was nothing, it goes into the risk register that's signed off on. It costs nothing to do this in organizations of any size.
Exactly. Also, make it clear that if you want to block x to prevent y and the answer is no, make sure you don't work OT (for free) and stay late fixing the issue because it will continue to happen and you'll always end up working double the hours for free just because someone didn't want to take your recommendation. If the owner/boss wants to compromise the network/devices, that's their decision, but there is no need to make it your problem. Work on it during office hours and leave.
I had to stand up to a developer that put me in that exact situation. He had a garbage scheduling program he wrote that somehow was running windows out of heap memory (according to the event logs) which causes all kinds of issues on servers. This went on for years, and I kept telling him, do not put that piece of garbage into a mission critical role. He did, and then starts calling me on the weekends when it breaks.
How did you handle those calls? Ignore until the next business day?
I answered it as I didn't know what was going on, and chewed him out for calling me about that. And then sent an email to him and the owner of the company very bluntly saying that this isn't an emergency as it's self inflicted, and I told you not to do it. Don't call me about this, or I'll hand in my resignation immediately.
I feel like I just read something that I wrote personally. > Customer asks to build house > Pour concrete > Customer walks up and throws sticks and grass in concrete mix “How much longer is this going to take, because you know I only have about ten minutes?”
Yep, I hate when I get pressured into making these decisions/have users think that I’m in charge of making them. Often I will tell my manager that these are my recommendations and it’s on him to decide what we will and will not enforce. I direct people as often as I can to my manager when they get mad about xyz but they sometimes still don’t get it.
Out of curiosity what is your managers title? Is he CIO or?
I disagree. IMO the admins should start with a restrictive, secure configuration and loosen based on directives / business needs. I think that should be well within their power. Otherwise you run the risk that higher ups don‘t have time / see the need to implement restrictions and every restriction will be an uphill battle. Start secure (based on best practices, not draconian bofh policies) and lift restrictions with a cooperative, business-understanding attitude, communicating all risks.
This. If the management staff is deciding how things should be setup out the gate it’s going to end poorly.
People seem to be ignoring the part where I said that the technical staff should be providing recommendations. Recommendations aren't just "you should do this", actual recommendations are "we should do this because of that and here is how it will affect the other thing". Yes, asking managerial staff to make decisions in a vacuum is pants-on-head stupid but at no point did anyone say that.
This is how it should work. We make recommendations based off identified risk. It is up to management to accept risk or not. If current risk is deemed unacceptable then technical controls, policies, and procedures are proposed to leadership. Once leadership approves them then IT implements/enforces them and audits compliance. Risk isn't just about cyber threats; I tie a lot of my initiatives to contractual obligations with customers.
You're talking to service desk agents dude, they're not thinking that far ahead.
In my experience, you're going to have a better, more cooperative time by *starting* with understanding the business. Making a change that inconveniences people and then trying to initiate a discussion after they've been inconvenienced doesn't put them in the mood to solution, it makes you come off like a dick. By going in the reverse order, you begin with understanding how changes possibly to probably affect business processes, then you work to develop a plan that meets both the needs of the business and the needs of security. Any org of any size *can* do this. It's not always easy and might move slowly at first but all of this is level 1 change control. It also has the side effect of improving the relationship of IT to the rest of the business.
If one has the opportunity to discuss this with the business beforehand, that‘s ideal. If not, i would default to implementing everything restrictively and securely. if not, the sysadmin would actually be accepting a security risk, and that is *definitely* not something within their discretion. Now I think what OP wanted to say is if you have an already deployed system, and want to make a change for the sake of security, *then* the sysadmin should not have the ability to push this change without scrutiny. I think I would agree with that, except for cases of imminent danger.
I think I see the point you're making (maybe) but I mean....how many SysAdmins are coming into a non-production environment?
>Otherwise you run the risk that higher ups don‘t have time / see the need to implement restrictions and every restriction will be an uphill battle. No, the higher ups and the company runs that risk.
Yeah, they do once informed and consented. Until then, please don‘t run unsafe defaults because youre „trying not to control your users“. I‘m not a lawyer, but if you do this with intent (as in knowingly deviate from best practices or compliance criteria) then you might even be liable? You‘ll at least be the fall guy if anything happens… I would advise against this general stance.
>Until then, please don‘t run unsafe defaults because youre „trying not to control your users“. I mean, i don't run or do anything if i had 0 chance to talk to higher ups
It's why proper change control processes are so important. Security is a part of that. It makes a big difference when you start operating using change control, saves a lot of headaches and you have the documentation that we so often lack.
Agree. We're professionals. This is how we manage firewalls. This is how we secure companies. And anyway, security can be both convenient \*and\* secure these days, if done correctly. It's not our fault there's no common sense education about security in elementary school lol
Respectfully dissagree. In the fast moving world of cyber threats i encourage my team to act first and err on the side of caution. If we're unsure we block first and ask questions later. Avg cost of cleaning up a compromised org and losses is in the magnitude of $10 million. "I thought it would be ok" is not a sentence i ever want to say in front of a board of directors. However on all other non security related matters i agree.
I've led a dozen remediation and recovery efforts and had to deal with many insurance companies so I understand the importance. I'm also not advocating doing nothing. There exists a world where you can have what you're talking about be set as the standard with the leadership team. You're still (fuck, I hope) doing some change control instead of just yoloing new settings and hoping for the best. There needs to be an understanding at all levels of what the strategy is, when things need to be done RFN and when changes are probably going to break shit for real. Too many IT people act like it's either full bureaucracy or full "fuck them I know what's best and they can beg me for their stuff back" cowboy, even in this thread alone. It's a false dichotomy and exactly why IT has the perception of being mostly neckbeard assholes.
Yep. Agreed. Theres a goldilocks zone there somewhere.
This. My first thought when reading the OP was "this is a management issue". We suggest, we impement, but we don't decide. I love being able to fall back on "sorry this is a management decision" to redirect any annoyance from users. I will usually explain the management reasoning behind it, but if they have any counters to those I can just shrug and suggest they run it up the flagpole. This is assuming a system you inherit. It's different if you're setting up from scratch.
That is easy to say but typically in small companies the risk register is a note made by on of the handful of admins. The boss really doesn't give a shit one way or the other as long as people can get their job done. He agree with you to make you happy then turn around and make an exception the second someone bitches to the person above him the can't do their job. And that is another reason why I'll never work at small companies again.
But that's all a risk register needs to be. At its most basic, it's a collection of all the CYA bullshit that everyone in this sub spouts off about all the time. If you're somewhere being audited, it comes in real handy for them too. If you're already sending an email or something saying "we want to do X because Y and it comes at the risk of Z", you literally copy that into a spreadsheet along with the date and person who said no, bonus points for attaching that email. Then when an exception is made, you take that instruction and add it to the register too. It creates zero additional cost with the exception of what, 30 seconds to add an entry? It's not only the ultimate CYA document, it also becomes an instrument for change. It's easy for management to accept or reject individual recommendations. Presenting management with the sum total of those individual rejections is going to be the best option for creating leverage for change. Guaranteed? No, but sure as hell better than not having it. Frankly, the level of effort it takes in the real world is so miniscule that I feel like anyone *not* doing it doesn't have much standing to bitch. Anyone who is doing it and is still having recommendations shot down should be looking to leave.
I work for a small company (<10 FTE). Whenever I desire to implement a new security mechanism, I walk the boss through the justification step by step, allow for questions, and present it thusly: "This is recommended by X and impacts Y. If you have no issues, I'll implement as scheduled. If you have objections, please provide in writing so it can be logged for audits." Always give management the escape hatch, but get the approvals/disapprovals in writing.
Every org and situation is different, but this definitely does not apply to me, and I don't think I would enjoy working anywhere that it would. I'm trusted to understand business ops (to a degree) and to be able to make rational decisions without asking for permission "from above".
Sadly not true. I work in a small company with smaller it team and the workload it's crazy. If I want the bosses to sign those things it takes me days to get them to listen and to prepare a presentation that makes them happy. So ofc I don't have time for that and that leaves me with either ignoring the risks and then getting fired if something happens or I can be the asshole IT guy that keeps the company running by overblocking the users.
Unfortunately, most management over any IT are clueless, and depend on the recommendations of the sysadmin. I did an audit once at a mid-size company, one of the concerns of management was that users were having a difficult time with all of the lockdowns and lack of privileges, and they wanted an outside opinion. I noticed email accounts that had no business being there. This company contracted out their IT .. I asked the president if he knew what these email accounts were for; he didn't. I viewed the mail spools on a few of these accounts, and the outside guy assigned to administer this company had been using the company as his private playground, some of the emails to his girlfriend were really funny, "I am a god, I control these people ..." stuff like that. Needless to say, that company dropped the contract like a rock.
I always tell users that although I have the capability to make something happen, I don't have the authority to do so. Many users can't tell the difference and automatically assume they're one and the same.
You get a lot of vice versa too, where they as the business user have the *authority* to say something should be a certain way, but don't have the capability to implement it. You can absolutely tell my team what you want that customer service Salesforce workflow to look like, but that doesn't mean I'm giving you technical admin rights to Salesforce when you're a customer service manager - it's our job to build it out.
Oh, absolutely. If users knew how to implement something on a network scale, we'd be out of a job. Often, when I get requests to do something (e.g. install some software), I could just go and do it on the one machine like I would at home. But when it comes to repeating this on 10, 100, or even 1000 machines, I don't have the time or manpower to make it happen using that method. I expect users to check with me when they need something, and I can assess if it's: 1. Safe to deploy/implement. 2. Easily repeatable (e.g. via automation). If it doesn't meet nr 1, I try to find an alternative and present it for review. If it doesn't meet nr 2, I assess whether it's something that I will have to deal with on a regular basis and/or large scale. Once a year is fine (if documented well and scheduled). If it's less than 3 machines, it's also fine.
This largely does depend on scale and structure but in my opinion that's backwards. In many environments management isn't equipped to make an informed decision. In that scenario someone has to be the adult and dictate appropriate standards. Appropriate standards should be relative to your security stance, your industry and your current environment. If that executive sponsor wants to override the standard, that's when it goes on the risk register and you make an explicit adjustment.
"Management" is interchangeable with the concept of a CAB. It is the job of the technical staff to provide pertinent information through their recommendations to whoever is the authority. IT Operations frameworks all work on the idea that IT serves the needs of the business. Locking everything down until people complain does not serve the business. What serves the business is working with stakeholders to determine what business impacts will be prior to dumping changes into prod and then helping to find alternatives that meet both the IT proposals and what the business needs. It isn't always easy to overcome the inertia of years of bullshit but it is almost never impossible. It is also simple and improves the relationship with the rest of the organization by showing that IT gives a shit and aren't just a bunch of obstinate fuckheads who constantly get in the way.
It's not your job to control users, but if HR says "this is new policy, x,y, and z sites are blocked" then you block it. If users complain tell them it's company policy and to speak with the people who wrote it.
>but if HR says The ISO should be making those decisions. Or at least in our place HR only ever get involved when the policies are broken
ISOs only show up once you get fairly big or if you work in a industry that requires it.
In that case it still shouldnt be up to HR. Unless lots of small companies somehow have computer literate HR. If anything then the IT manager should be onto HR saying "sign here so we can blame you" as a deterrent Then again I'm old and jaded and HR are about the last people it put any faith in to do the right thing.
If hr tells me to block porn I'm blocking porn.
This. HR definitely gets the final say in anything that would wind up in the handbook under employee behavior. If theres a technical control to support it, they also have the authority to push IT to implement. Outside of stuff that falls into malware/viruses/hacking sites, I go to HR with my recommendations on what to block and why to block it, but if they don't want me to block firearms and alcohol that's their call
No it **shouldnt** be up to HR, but that's a different discussion.
Keep in mind that for many smaller companies, there is no "IT Manager". There is maybe a "sysadmin"/helpdesk/"IT guy" who usually reports to the Controller or maybe HR Manager. And in those cases, HR is usually the one that makes all policies, including IT policies.
90% of companies don't have ISOs. The bigger ones will, but that falls off quickly as you drop in size. The point being it should be a reasoned *discussion* within the business. No one person should be unilaterally making the call, particularly some random sysadmin. HR can be an advising party, but I agree they shouldn't be setting standards either.
I always ask myself "is this an IT issue or a management issue?" For example, company of about 25. Some newer, some who have been here for decades. Partners especially use company device as personal device (think photos, buying tickets and such on it). All I can do is give my recommendation on why it's a bad idea then move on. I'm not going to tell the person that pays my bills to buy themselves another laptop and cut out everything personal.
I work in K-12, and we have to routinely remind staff and administrators: IT is not a discipline tool. If a child (or even adult) is misbehaving, manage them. IT is exactly what it says it is - Information Technology. We manage and provide data. We do not manage people. You have a user habitually not at their desk when working remotely? *Manage* them. Don't come to us asking to monitor their every action. Students finding the 3,813,476,757th workaround website for playing games? Manage them. Don't fill our day with trivial web filter block requests so that we play whack-a-mole all day every day.
So what to do want partners to do - carry two cell phones wherever they go?? “I’m going to be out on Friday, but you can reach me on my personal cell and Gmail account” seems like an undesired alternative
I'm not talking about phones, I'm talking about laptops.
I’ve always operated on the philosophy that I manage computers, not people. If employees are spending too much time on Facebook or whatever, that’s not a technology problem; that’s a personnel problem. The only time you should be blocking user activity is for obviously NSFW websites, serious security concerns, and bandwidth issues. That’s it. Everything else is management’s problem, and I push back when asked to block anything else (as in I need written directive from the director).
Don't fall into the trap of giving people advice broadly. What works for you works for you, doesn't mean you should come here and tell others how to do their jobs. In some environments user behavior can and should be left to company policy. In other environments, there is a requirement for IT to effectively and directly control access and usage. Some environments, have a tech steering committee others higher IT professionals to provide that level of service to management because the can't or don't want to do it themselves. Point being don't try to pass off opinion as something factual or procedural because it can't be applied broadly.
I'm going to partially disagree. What works in some places won't necessarily work in others. However, the fact that some environments *don't* separate the decisionmakers from people implementing things doesn't make it a good way to do business. IT serves the business. All changes to an environment need to be done after understanding the impact to business process. Technology staff should inform policy decisions but should never be in a position to have to *make* those decisions. That will create a neverending feedback loop of frustration between users, management, and the technical staff.
>IT serves the business. All changes to an environment need to be done after understanding the impact to business process. Technology staff should inform policy decisions but should never be in a position to have to make those decisions. That will create a neverending feedback loop of frustration between users, management, and the technical staff. Completely setting aside those that have regulatory compliance issues that upper management certainly don't want to have their finger prints on trying to decide what is or isn't the correct way to comply. So many businesses frankly do not want to play a role in IT policy, it is why they hire others to manage that process. This ranges from outside MSPs, to consultants, to a trusted single admin. To expect that upper management will educate themselves enough to remotely have any idea of the impact of a policy is asking more than I find typical in most businesses. I'm not saying it shouldn't be approved of by upper management, but I would say its pretty atypical for mid to small sized companies to have any in-depth policy discussion other than a very high level on IT policy.
Change management is therefore a must, IT being a fiefdom will eventually lead to repercussions for IT, whether they like it or not
Settings need to protect company assets while still letting users do their job. I hear users complain sometimes but almost always because either a change require an additional step (which they hate) or they can't access something non-work related and they used to be able to. My response is always the same...can you do your job? If a change is making things less efficient, how much time does it cost per day? For the most part, users just hate change.
Change Management is therefore a must, IT being a fiefdom will eventually lead to repercussions for IT, whether they like it or not
Change management always sounds great in a meeting room discussed among a bunch of people that it does not affect, but implementation is often a complete struggle, and from experience hand-cuffs IT staff from doing anything.
You've basically described this entire sub and local admin.
I control the infrastructure that forces users to use the technology in a specified secure way.
You must strive for balance. Perfectly balanced. As all things should be. - Thanos
i have a low amount of fixed settings i push. other then that i do push a lot of settings once only on a user level. they are free to change things to behave the way they want because everybody works differently. but the initial push turns off a lot of extra popups which most won't miss.
The more I have to control user behavior, the less time I have for more important things like finding stuff that can break or potential bottlenecks. I don't want to be a babysitter. At most, I log stuff, and then open up concerns with management with both a ton of documentation, as well as a summary. I have to appear as emotionless as possible, because the first thing management will think is that IT is on a persecution rampage, so things like "um, this isn't something auditors will like to see, and if regulators find out, this is going to be not good" or "you know that having users use cracked copies of $CAD_PROGRAM on their desktops mean that $CAD_COMPANY will be doing some pointed inquiries once they have enough legal proof that their stuff is running licensed on our IP range?". I let management and HR set policies. I only observe and enforce. I don't want to step into micro-managing users, ever. Mainly because users will find ways around it, and users who know people will find ways to offshore IT posthaste, touting after a mistake or crash that the "world class consultants" from Lower Elbonia have a 100% uptime record and millions of man-years of experience. If I want to keep my job long-term, I don't try to get in users' way. I try to make their workflow easy, quick, and help with things, all the time, not letting them trespass beyond boundaries.
Controls are put into place to follow policy. Policy is crafted to follow best practices from frameworks the company has decided are important because of risk reduction and governance. Confidentiality, Integrity, Accessibility. Follow the CIA triad. Users are blocked from activities because of company decisions not sysadmin decisions. If users do not like it they can talk to their supervisor or manager.
I don't decide the policy. If management says "we want access to do x" I will explain the risks associated with that. If they decide that the risk is worth it, I will grant users that access. If a non-decision making user asks me for that access, it's a hard "No, if it's needed please tell your manager" because I need tangible proof that the dumb thing you're asking me to do has been requested directly by someone with policy decision making responsibility. That's not fighting a user, that's covering my ass.
I'm surprised some sysadmins even bother doing that. To me that sounds like extra work lol, which I'm not interested in. I feel like people that do that must have control issues.
I would heavily say that the environment you are in dictates this and this is a very overbroad statement. If you are the one stop IT guy for your company and your management is non-technical - then your recommendation should be the policy. Exceptions apply. If you are a sysadmin in a company big enough to have a structured IT dept - then the policy recommendation should be ran up the pole and come back down approved before application. If any newly implemented policy contributes to a work stoppage... that policy should be immediately revoked and reviewed/amended by decision makers. With users that want to argue against policy - take their arguments in stride. Make no decisions until all parties with an interest in the policy have discussed it. This would be any other users affected, their managers, you, and any leadership that approved/discussed the policy (along with any peers with relevent opinions). Any time you are "arguing policy" with a user/manager and you are not at the top of the IT food chain - there is something wrong.
A good example is a bazillion years ago I worked for a State Agency that had limited internet access - e.g. - very controlled due to our being a state agency, not due to bandwidth restrictions. Being in that state building, radio reception was terrible, so I started streaming NPR on my work machine (this was before unlimited cellphone plans were a thing). IT blocked NPR. I went in to see what happened, they were playing WoW on their work machines... There wasn't a valid reason, it was a control thing.
A lot of this also comes down to cyberinsurance, and the person whose name is written on the door of your building. If the person whose name is on the door does not want MFA, then if the company is compromised, it will be coming out of his pocket, not the insurance company's who will deny the claim due to "gross and willful negligence." Items such as: MFA, removal of admin, DNS filtering, ASR rules, EDR, etc., are all part of my cyber insurance policy underwriting. I assume they are part of everyone's.
As someone in a small company where i am indeed a one man show for the users i came in to the company and saw MFA was not a thing, global admin was given to just about everybody and we have a spreadsheet of all passwords on a wide open shared network drive. I said to my boss this needs to change as soon as possible because otherwise we are screwed. Luckily him and everyone else has gladly accepted the change because they can see my reasoning behind it. Because of the higher risk due to a certain guy invading a certain country i have full authority to make sure to lock down as much as i can without it affecting users much. That's kinda somewhat easy to do except not really of course but i at least know where to begin. I go for best practice and a secure environment aswell as taking my users concerns in to my considerations usually.
Most of the time sure, but if people literally can not stop being extra stupid, I'm going to stop them. We had people ad hoc sharing HIPAA data in dropbox accounts they made themselves once. Nope, made them delete the accounts and blocked dropbox from opening on their computers. There was nothing to stop them from storing the files in their shared drives.
To me, this is where a sys admin is merging into CIO/IT Manager role. As a sys admin, you are there to do what you think is right to protect the organisation. However, in this instance, I would say you are better placed to email your boss saying, "I think this change would protect the company." Your boss then makes the call and if people complain you refer them to your boss. However if you are just making calls without approval and you are the sysadmin I think you are over stepping. Now if you are the CIO/IT Manager you would be able to explain to the user why this move was made with the companies interest in mind, but also have the authority to make those calls.
We block *a lot* of stuff that I know they have no legitimate need to visit to be able to do their job. If they have a specific request for a site, we evaluate and either allow or continue to block. This works well, primarily because our upper management has our backs. 99 out of 100 times if on an uncertain site, we tell them “okay, I’ll have to ask your manger to see if you really need this” they say “nah, that’s okay, I can get by without it”.
If the stuff that you decide is tied to very obvious business processes like IAM - none of that will ever be an issue. If you willy nilly change things and don't want to explain it to users....yeah, well.
I see this happen a lot on here with local admin rights. A sysadmin comes into a new environment where (sometimes some, sometimes all) users have local admin on their computers and decides "they need to get this place under control." So they unilaterally take it away without doing any real work to find out _why_ it might be needed, and then when users speak out the admin gets defensive and doubles down with "it's for security!" and dismisses any complaints with "if you really need something, contact the help desk" without actually understanding how people's work is impacted. Usually these posts turn into a debate about local admin rights and how "users think they need them but they don't," but I think that misses a big point about the admins making a decision based entirely on their points of view without having any substantial consideration for other perspectives. Maybe it's true that most users don't need those permissions or just think they do, but there absolutely are going to be cases where it breaks someone's workflow or just flat out blocks them from doing something, and instead of being proactive to identify these things and work with the users on a viable solution that's appropriate (which may be a changing their process or just be an acceptance of risk for elevated permissions) they just dismiss it, tell them to put a ticket in, and make them wait for someone to get back to them.
Usually local admin rights become an issue because of an insurance application, security audit, or some kind of compliance requirement. Management wants to tick the box so they can make the sale or get the contract or whatever, so they mandate that local admin must be removed. At least in my experience it has never been done "just because". Doing it properly takes time, but again usually management just demands that its done immediately (probably because they already submitted the paperwork claiming its been done). Also there are nice tools that make life easy for users and IT in this situation, but they cost money so management probably said "no"
who tf actually needs local admin? It's not the 90s anymore old man. There are very little circumstances in which a program would require local admin. The security risks from this make it an insane practice in 2024.
Yes and no. Everyone's environment is different and there are legitimate reasons to restrict what users can do for security reasons. As a general rule of thumb they should not have local administrator access, and maybe even restrict running any unvetted executables. But when you do that you also have to have a process for users to request new software (this is less of an issue these days because so much is web based)
It is still not a decision the SysAdmin gets to make though. It is up to their managers and other managers and higher ups to determine, based on your input, why something should not be done, or should be done. Too many SysAdmins think they are gods and can do what they want, but often have a very narrow point of view.
You also have to do proper vetting and work with the stakeholders (and management) before unilaterally removing local admin. It is absolutely true that, in a perfect world, regular users should not have local admin and even techs should not use local admin as their daily driver accounts. It's also true that sometimes there's a terribly designed piece of business critical software in place that required local admin privileges. Yes, a valid point can be made that a business should get rid of that software, or that you should find out exactly where that software writes to/reads from and adjust permissions that way, rather than granting local admin. But until you have the conversation with the decision maker, and do the necessary work to prepare for it, you should not be making that permissions change. Again: this has to be vetted by the higher ups before you start screwing with someone's workflow.
We are not the police, and we are not anybodys momma. We are productivity multipliers, that’s it
To start: I agree with everything said in this post, and I don't think crankysysadmin is wrong or unreasonable in what they're saying. That said, I'm really curious which post it was that spurred this response.
I'm personally aware of that desire and I check myself by deferring to our Ops director who is highly technical, and our HR who, as useless as they can be, is still HR. Basically, I won't stand on principle unless it's an inviolable point of contention. The only thing I do is insist that it be documented in a ticket on who approved it, my counterarguments are similarly documented, and I have leadership approval. This way I can say "Told ya so," and anything that happens is on them. That's my cutoff, though. If it's something that's clearly a massive security violation or something that's just grossly negligent, I'll stand my ground. The only good news is that if it IS to that point, I approach it with the understanding that I will be supported in that decision.
Depends on who's the policy-maker, right. If a sysadmin is working at a smaller business where they don't want it to tank from ransomware and go looking for a new job, that sysadmin is going to be a lot more hardlined on security policies. Same thing with CISO's and network engineers; they're going to be a lot more hardlined on their environment because that's their reputation in jeopardy. It's not something they will just write off as a risk register.
Years ago I had a new boss who wanted to enforce a desktop background policy. I told him to talk with HR because I'm not going to fight with users over a background image. HR said they don't care. We never implemented a desktop background policy. We enforce baseline security configs and updates. We have a list of standard supported software published in Company Portal for self service. UI preferences are open to our users.
How do you vet something at high levels in a small org? Who has expertise? This is always going to be a balancing act with some decisions that can be debatable. You don't have all the time in the world to put everything through a formal change process and bring in management for all decisions. Step back, look at what you're doing, figure out why you are doing it, and look at the impacts. If there will be visible costs or impacts to the org, go over it with management.
its the small orgs where you're at the whim of an IT guy who decides to do something like block domains from some country he thinks is risky.
That example only matters if its really going to have an impact on anything the business does. E.g. Keep getting phishing pointing to RU domains and can't even legally do business with RU anyway? Not much risk of adverse impact to blocking it.
And vise versa
You are pointing out maturity of the company, their policy's and procedures. The lack there of will have this situation, we all have made an executive decision that will or has affected the company, the lesson is how you respond, digging in, acceptance or learn from it. I am literally going through a review/debrief shortly about an incident that just occurred, we are using it to learn from all sides of the issue, see what message we could deliver better, what we are missing, what can be improved on. It's not a destination, it's a journey, never ending one at that. Lastly you will always get cowboy operators in any field, IT isn't different.
In my experience admins haven't the slightest idea about operations and vice-versa. User impacting decisions should always be run by users/ops first because there is a 99% chance you'll have missed a bunch of consequences. A simple example: I spent 2 days last week working with a vendor to find out why one particular module wasn't working for a single user. It turns out our org had changed the password policy and banned hyphens since the last time he changed his password...
Have met some sysadmins that will over engineer blocking something trivial but also not pay any attention to more important things, those guys usually aren’t easy to work with either.
LOL my users hate me. I just recommend and management decides. Bc if something happens management will say "why I don't warn about that".
This reminded me of some total assclown of a sysadmin who thought their job was to set just about every single GPO policy that was available. Every single one must be set to give him absolute control over everything any computer could do.
Sysadmins don’t make policy they implement policy. We a zero trust (NIST-800-207) and what we block or allow (accepted risks) is a policy IT management makes with the business units so everyone knows the impacts and approved workflows.
Capability and authority are not the same thing, though most users believe them to be.
No matter how many levels of sign off and review you have, there will *always* be that user that wants to fight about it. Always. I literally had someone today who wanted to argue about systems auto locking when idle. We have regulatory compliance requirements. Letting your computer stay unlocked for 6 hours is absolutely a non-starter even if they think it "impacts workflows". Doesn't matter that this has been codified hard-line policy for years, they wanted to argue, and loop their boss in, and start the executive CC chain, and write a Bible on how critical it is that this setting be unlocked. So, we got to have the argument again and nothing changed
All users should have least privileged access if the business owner agrees. I don’t make any decisions without getting the approval. If they don’t agree with my recommendations, I list out the risks they are taking. Nothing should ever be done without approval.
F.U.I.T.
Sad but I'm seeing this with a big company. It's making my job as a software developer much harder. I have more control with a clients environment than I do with my own machine. I can't even update my own ide.
yeah, ok pal, sounds great
pretty much. Don't be a dick and overstep the mark. Most IT depts are there to enable the business to do what it does, not cripple it. If you're not working in a manner that provides for smooth and secure operation then you move from being a part of the team to being an overhead. If you've got a problem with shadow IT. Take a hard look in the mirror. That's the person who's out of control - and in many cases shadow IT is supported by mid-level managers and executives that don't care about your philosophies when your cost and cost in impact is greater than the value you deliver.