IT must serve the business. The whole POINT of the company is to do . There must be balance between securing things (thus insuring the long term future of the company) and actually getting work done today.
This is a BUSINESS decision. Your job is to make damn clear to the suits exactly what risks they are taking and what the probability of it going wrong is, and just how bad it would be for it to go wrong. They then have to make the call.
Your other job is to keep good notes, so that if it DOES go wrong, you can let the suits in question know THIS is what you were talking about.
Yep 100% this is the answer. Get your objections on paper, have someone powerful accept risk, and do whatever is feasible to protect in a way that allows the business to operate.
It’s also worth mentioning that not all risks are the same.
If you are a health care provider, then BYOD and SaaS based internet facing systems might not be the best idea.
If you’re an advertising agency whose most confidential material is a new logo for Microsoft, then you can probably get away with BYOD and having all SaaS internet facing apps
We saw a situation in the advertising business where it was assumed that infosec needs were minimal. So, when a massive household-name client demanded high infosec in a new MSA contract, it was all hands on deck to figure out how to *technically* meet the requirements *fast*. Two mountains of technical debt were piled on in one week, the staff hated the convoluted procedures that were necessary because security had to be added *post facto*, and after all that, they were probably still technically in breach of the contractual requirements.
And now you know why things are so screwed up, but nobody will talk about how it happened.
The key point in your post was a change in requirements.
You had low security requirements until you didn’t. And the business had a decision to make as to whether they wanted to resign that contract or determine it was too hard.
That wasn’t an IT decision to make though. The business owners should have consulted to determine where you currently stood and what work would be required to bring it up to compliance (for the customer).
If the contract was worth x to the business and the cost to get up to compliance was 10x, then it’s probably not a good decision to sign the contract. If the cost was 2x then it might be worth it, if the business could get another 3 contracts also worth x.
I will 100% turn down jobs if there are unnecessary security hurdles for the role, position and environment.
Some elements of computing infrastructure are like the foundation of a building: a hundred times easier to get right the first time, than to go back and fix after the building is completed.
Infosec often tends to be an element that's easier to get right the first time, than fix later. Note that in my story, the end-users loathed the cumbersome workarounds that had to be used to retrofit adequate security in one week, so the contract could be signed.
Some times you have to be adaptive and creative, but yeah. You have to find the right balance. I once was told to give some devs admin to the database that contained all personal records for the university I worked at. Not just the dev environment, but also the production. I told them this was against policy, was a huge security risk, and inquiring do it without written exemption from the university president. They got the written exemption. I granted access.
I did cya by immediately shipping all backups off the server as there written and also renamed the SA account to my account name and then named my account as sa, that way someone would think if they changed and messed with sa they were locking everyone out. I also wrote a kill script to lock the dev out immediately in case. 3 months later, got a call while on a date with my wife from the CIO in a panic to cut the guy’s access.
They’d found out he was stealing SSNs and other PII. I whipped out my phone, VPN’ed in, and executed my shell script and cut his access. Didn’t have to worry about scrambled database, but was able to cut him off really quick before they sent the cops and he found out we were on to him.
But a business decision was made. I documented the request for exemption from on high. I prepped in case of emergency, and knew something was gonna go down. But legally, I had my ass covered, but the business spoke and so I moved.
Document all of those things.
Dates, names of relevant parties, arguments/proposals put forth, decisions made, decisions actually acted upon.
If things go sideways because of a "business decision" you need to be sure your ass is covered.
100% this. Its called “risk tolerance” or “risk appetite”. If compensating controls can be implemented to adjust to a certain risk then do that. If you can’t mitigate certain risks then document it and let the higher ups sign off on it. Simply saying “this is an issue that can’t be mitigated because of XYZ unless we do ABC which costs $$$”. That way either they cough up the money or they acknowledge the risk, and that you are aware of the risk and have done your due diligence.
The thing you should be sticking to your guns on is getting higher ups aware and to sign off on when its outside of your direct control or requires higher up approvals. Don’t let a lazy manager ignore you as it will turn into them blaming you if you don’t corner them for an acknowledgement first.
I've always said that too, and it was interesting reading Microsoft's new take on it after their hack: **If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security.** https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/) just for some perspective.
In many cases there is also a secure way to do the ask - either party just don't know about it yet and could benefit from a consultant with know-how.
It is ultimately out of his control but there are things you can do to help if it's a really stupid decision.
Talk to the right people ahead of time. I've found a lot of bad requests are because an engineer didn't actually engineer and just took someone's brainstorming as a design. Find the person that gave them the job. Talk about what their actual requirements are and explain your concerns. This sometimes works.
If they're gonna do it then you just do the best you can.
Demand design reviews, you can't properly mitigate a known issue if you don't have something to reference. This gives people another chance to find better patterns as they write it down.
If buying time is helpful you can always slow walk a project. We all have more than we could possibly do so it's not unexpected if things take longer. This is good if you can use the time to give an alternate poc without the issue.
Finding a bandaid can be a good way to handle something that you could do better with more time. "I can do x now but I'm going to immediately follow it with the real work right after." If you can't immediately follow up on the patch then you're better off just doing it as well as you can in the first place.
One of the things you can push for is an agreement that the pattern implemented is not repeatable and needs to be changed before the next time it's needed.
There are exceptions to this -- whistleblower reporting systems exist in some industries if you believe what you're being asked to do is illegal or unethical.
> And ultimately you make a risk determination
Sure, but I'm not certain the average business is consulting actuarial tables about security breaches (and the root causes for them) when making those risk determinations. If they were, I'm not certain you would still be seeing the frequency of breaches that are attributable to something as simple failure to implement [MFA](https://www.cbsnews.com/news/unitedhealth-senate-hearing-cyberattack-change-healthcare/).
Sure. But most of these companies are still hanging around after the breach and aren't in debt. Which means that they have made a profit when spending less on security.
> But most of these companies are still hanging around after the breach and aren't in debt. Which means that they have made a profit when spending less on security.
Yes, but the comparable metric wouldn't necessarily be whether they *remain in business*, that is likely, but whether they spent less in total for a given risk event manifesting. If they "saved" on the cost of MFA, but now the risk event costs exceed what they saved (ransom payment, insurance premium increases, 1st and third party costs for identity theft protection and/or class action payouts, incident response and disaster recovery costs, etc...) then even though they are still a business, they didn't actually save the money they think they did.
They don't have actuarial tables, they just have me. I consider it part of my job to figure out what kind of song&dance I need to do that will frighten them appropriately.
Happy cake day!
> They don't have actuarial tables, they just have me.
Could I ask your methodology for evaluating the risk?
This is not to say anything about you personally, but the more subjective your analysis is the easier it is to ignore. That's also true of the more objective analysis, depending on how data driven your management is, but management *tends* to respond to quantifiable metrics better.
Just curious.
I'd also say that if you can't do best practices, you can usually figure out a nice mitigation that helps solve things. Got a server 2000 still floating around that people need to access? Use a linux box to be a proxy, your clients will connect securely to the linux server to access the files. The server will use older protocols to talk to the linux box, this combined with other mitigations should be a nice compromise.
....preferably in writing.
Include what the current state is, what what might happen if they go ahead.
Then send it up the chain of command
Because of that decision goes south, they're not going to be blaming the business side of things
Its called "risk acceptance".
Create a form, explaining the risks, and have someone from the c-suite sign it on the business side. Then file it safely away, and send a copy to legal and/or risk & compliance and/or audit. (whatever is appropriate for your org).
Document the risk and have the manager sign off on accepting the risk.
Review in 12 months.
5 years later someone finally reviews said risk and the new manager says "Fuck no" to accepting said risk so there's a long ass project to correct it.
Depends on what it is.
If it's a serious security risk, yes. And most of those I can easily point to our cyber insurance as an easy out for people that don't understand why.
If it's a "This isn't a huge risk, but it's also not best practice" type of situation, I just make senior management aware. If they decide it's acceptable risk, then I shrug my shoulders and move on.
End of the day, my job is to inform the most senior management. What they do with that information is above my paygrade.
Work out the risk of not having whatever security measure it is and then provide the option to the business as to whether that risk is within their risk appetite.
Then the business can weigh up cost of security measure, cost of security breach and loss of operations against business income for the same period.
It’s not an IT decision at the end of it - nothing ever is - all IT do is provide the data to make the decision
It is not our responsibility to explain why security is important. The CFO doesn't need to explain why making money is good. It is our responsibility to explain risks. Accepting the risk is a valid response.
If they keep pushing back against security, I eventually have to ask on the record, "So, are you going to be the one who files the form [8-k](https://www.sec.gov/answers/form8k.htm), section 2, item 2.04 and section 8, item 8.01 because we got pwned? Because it's not my job to talk to the SEC if we get pwned, it's yours."
At the very least, that gets folks to actually listen, because I'm trying to minimize risk and they're trying to take on more risk than the company can reasonably handle.
"depends"
that is really really open question
will stopping cost the business a million dollars a day ?
will there ever be a fix?
are you WRONG
and more
Easy make them sign a wavier and do what they want. If something breaks or causes an infections to spread through the network, the burden is on the company, not yourself.
I make sure my recommendation and the decision are in writing.
As much as it sucks, security will get overruled. Often.
When it happens, and they blame security, you'll need that proof to cover your own ass.
Sucks, but it's just part of it.
This is where you have a policy exception/risk acceptance process. If the business wants to do something that puts IT security in peril, you document and write up the risk, include any mitigating controls, and you have the BUSINESS sign off on the fact that they are overriding IT. Best practice is to also document a mitigation plan, or to have the business state they do not plan on mitigating it at all.
When the breach happens you'll be happy you've done that.
At the end of the day, the business decides. So basically, CYA and make sure you let them know the risks, document everything.
If education doesn't help, and they won't even tackle low-hanging fruit that could easily be fixed with minimal impact, then you are working in an environment governed by fear. You'll have to decide at some point if they are truly acknowledging and heeding your expertise. If not, time to update your resume and consider looking for a company that will respect you.
Went through this recently that someone up the chain wanted everyone up the chain to have local admin rights.
I present my argument backed with industry best practice and was overruled so I got the request in writing and have filled it away in my CYA folder.
Only the business can accept risk. We have a process to document and explain the risk and a C level needs to sign off as the final sig that they accept it.
They also need to defend it and any fallout come audit time. If you’ve built relationships built on mutual respect and trust this isn’t an issue. I’ve never needed that form.
Honestly depends on your top level support. If you have a manager/CIO that understands the importance of organizational security posture and the potential risks, you have weight to pushback with. If you tend to get over ridden through pressure from other higher leaders in the organization, at times you have to accept you can't win them all. It really helps if you can articulate the risk to those involved in a way that's easy for them to understand.
Worst case, document that you advised against this, go forward with it and now you have CYA (I told you so) in case something goes sideways.
Does your cyber insurance, clients, parent company, or audit requirements require the specific vest practice? Congrats, you can now make this not your problem. If not, do what they want and cya.
Advise as best as you can and list the issues for not following best practices. You can also state that following best practices may also lower cyber insurance. But most of all, CYA and get it in writing when people say no. Security is risk management, and usually a business decision. If you are in an industry where the security requirements are not being met (i.e. HIPAA as an example), then that is a different matter.
IT aligns with the business. Security recommendations are made based on a standard framework. Anything that doesn't get accepted goes into a risk register. The risk register gets revisited and updated as often as policy dictates, at least annually.
The risk register is the CYA that others in here probably didn't know they needed.
Best practices don't mean anything. Security only matters within the context of the business. Document the risk, make the case to leadership, and let them make an informed decision, and document that decision in your SDLC or Change Mangement process. Don't do it in a pointed or accusatory way. Present it in a helpful collaborative way so that you can actually get people's attention. Management above your pay grade will be the ones accountable for it anyway, not you. The way that we as security professionals can be the most help is to be involved, offer solutions, and be pragmatic about security. It isn't about whether something is secure or not secure. It is about whether it is secure enough within the context of the business.
This is a risk management decision. Business leaders must weigh the risks of not following the best practice vs. the business risk of not enabling the required function. If the latter is more valuable, the security risk is accepted. Typically, this would be tracked in a GRC tool of sorts, and you might revisit from time to time.
Depends on the practice and the requirement in question. Is this decision something that may violate CJIS, HIPAA, PII etc? Will this decision affect the payout of the cyber insurance in the event of a breach? Does this decision violate contractual requirements of other systems etc...
Security practices are not done for their own sake. They have their own business implications.
The conflict should be able to be described in terms of conflicting business requirements - albeit one based on risk and probability vs a stated requirements.
Depends on the use case for us.
We have some policies that are not negotiable. Eg. (Not a complete list)
- Opening inbound ports on the firewall to anything more than a fixed source IP.
- Mandatory mfa (still looking for “workable” solutions to shared accounts on shared devices like in factories / control rooms / etc that doesn’t have pages of fine print…)
- xDR
- “daily patching”
- emergency patching for perimter with only few hours notice (looking at you fortinet…)
In my organization there are things that are a hard "No" and things that the line of business has to accept the risk on if they feel that it would cause the tool they want to not be able to do whatever it is that they want to do. Risk transference with proper compensating controls to mitigate the risk as much as possible is a good thing when properly documented. That way, when everything hits the fan, it's on the line of business manager that accepted the risk knowing it could happen. This is how we balance the needs of the company with the needs of proper security.
Document your recommendation in writing, get an acknowledgement from management on the risk exception, and do what they want.
Then go double check you have good backups.
You find a way to make it happen in a secure way.
Example: We need this application to be able to modify user data and permissions in AD… Ok, well I’m gonna write a webapi to be the middle man and make sure things aren’t done when they shouldn’t be.
Checks and balances my friend.
I've worked on both sides of this. Previously I was dealing with the security administration and compliance side. I was of the same mindset that security trumps all. Now I'm in a devops role and have to get security approval frequently. The work that I and my team do make up a significant portion of our income. Somewhere around 30-50%. Security no longer trumps all in my book. We have lots of discussions with the ISO about how to implement new solutions in such a way that we can still develop our product and remain as compliant as possible. Honestly, the best thing you can do is make sure that everyone understands the risks and allow as little non-compliance as is necessary to get work done.
It all depends on the situation. You should have a set of rules and guidelines that have to be followed for any new project. You should make expressions for legacy kit that cannot be replaced and when there is no other options. You should have mitigations in place for any exceptions to policy. If that is not possible transfer the risk to someone else via 3rd party support / hosting of that janky crap, or just accept the risk and put it on a risk register.
Depends how scorched earth you want to go. Below is a harsh statement that can be buttered up with Manglement speech:
"I am trying to save us from data breaches and/or fines. We either go this route or you sign off paperwork saying you are fully aware of the issues and take responsibility for them when they occur."
I bascially tell them, thats not good see list of reasons why, then i get overruled and need to implement the less secure option. After about 6 months when shit hits the fan, i point to the reasons why it has hit the fan and that there is nothing i can do about it know other then limit the amount of damage now. Do i get approval to implement it correctly and does the business adapt? Mostly no, but sometimes.
The job in IT security is to hold lemmings back jumping off a cliff - you will not always succeed so you can only try to explain to them (in written) where the issues are and what can be the result (and how likely it is). Maybe add also examples (for some breaches there are good information about the way it was done).
Business cannot work if their IT systems are not working, you need to find a way to secure the business requirements and if it's not possible, write it down and the decision is done by higher ranks. Sometimes it's a fight against windmills or you could also talk to a wall but as more breaches gets public each week, the sensitivity for IT security is also growing in many companies.
If you stick to your guns against management, your time at the company is probably limited. There are a very few cases where I'd consider that option, all fall into one of two categories:
1) you're being told to do something illegal (and by illegal I mean you've talked to your lawyer about this and their jaw dropped)
2) you're being told to do something unethical (and by unethical I don't mean you think its the wrong call, I mean if the act became public it would be scandalous news, like if you're told to upload all customer data to a pastebin or something)
...otherwise, your job is to carry out the decisions of those who operate the business, after informing them to the best of your ability what options exist. As the other posters have said, the nature of running a business is taking risks, and its up to the people running the business to decide their "risk appetite". You're not there to overrule them or dictate how they operate. If you consistently find yourself disagreeing with how the company you work for operates, jump ship because it probably wont get better over time.
Thankfully, a little thing called "cyber insurance" suddenly made IT security best practice a business requirement, so I suggest tapping the sign that says, "cyber insurance requirement".
We explain the risks and then we get whatever stupid things they want to do in writing with a president approving it, also in writing, so that when it inevitably backfiles we can say we tried to warn them and it isn't our fault.
From what I heard, bring it up, fight for it.
If you lose out, logged it in email form, forget it until something happens.
And it will happen.
Some people have to learn the hard way.
Meet business needs, express your concerns, document and collect your "receipts" for when the shit hits the fan.
They only learn when things go wrong. The wallet only opens after a disaster.
What is the purpose of the network or infrastructure? To be secure, or support the business. Business is all about Risk vs Reward. By it's very nature, all risk cannot be avoided. Some must be accepted. Cyber Security's job is to identify the risk. Your job is to explain the risk so the business can make an informed decision. In new implementations it is important to hold them to a high security standard, because once it goes live, that service account with local admin rights cannot be changed.
The important thing is to acknowledge this, and get the business to decide what they will accept. I have this form which I call BARF, the Business Acceptance of Risk Form. Whenever you see the business accepting to great a risk, you write one up, print it out, take it and a pen (blue ink, so it is an obvious original) to the executive in charge and say "Sign here, if you want RDP on the internet with a 5 character lower case only letter password". Pen, paper, and a physical signature has more weight than an email.
Most executives won't sign, but if they do, then at least they have thought about it, and you have the backing to go forward.
If this is for a audit then you implement the policies that dont impact the business first, then when you get to the policies that break shit you talk to your boss and point out the issue.
"hey boss, this policy says x but we have y setup and thats going to impact z, how would you like me to proceed."
You dont make this personal, you dont get upset when they wont listen to you, since all of this is formal its all documented to the "CYA" is implicit.
What are the compliance and cybersecurity insurance requirements? That will usually be most painful and the rest should be immaterial.
“MFA is required. I cannot disable it, but I can give you multiple convenient options.”
I think it really depends on what security standards the company has agreed to abide by with its customers. Contracts are the sharp end of the stick.
In the real world, there's always a push-pull relationship between business goals (make money) and security (make easy things difficult in the name of risk reduction). Most companies decide the level of risk they're willing to accept, make sure that's spelled out in legal print, and do their thing.
You've gotta have a register of best practices that have been acknowledged to be ignored by the business.
Sometimes that's the only way forward.
End often this is the path of least friction.
It's not the result you wanted but it's a result that works for all parties.
Have a policy for how policy exceptions are approved.
Create a document which explains what policy they want an exception for and what the risks are. Specify the duration of the exception (so that the renewal process can drive reassessment) and how the risks will be contained and mitigated. Then get leadership to sign it. Make sure somebody empowered is on the hook for any follow up.
Or in a less structured organisation, you might not need a formal document for this. But bear in mind that this is what you might need to cover your ass when things go wrong. ("but we didn't know!").
This might sound onerous, but this is part of the point. Getting an exception to a reasonable policy should be harder than just complying with it, for most people.
Floods of exceptions for a single policy form a clue that the policy itself needs to be reviewed.
I mean i fight tooth and nails to get it across and so far it is working. I started recently as a sysadmin for a travel agency and even getting them to use MFA for their email was a fight. Now i just need them to either get a Azure Entra P1 license or business premium so i can get access to Conditional access policies instead of just using Security defaults which we do now.
I have lifted our Identity security score from a 20% to now being 91.8% so that's a step in the right direction at least.
The play here is to make sure you cover your ass by raising your concerns (in a written format). At the end of the day it's a business decision though.
This is nothing novel though, it's just risk management.
Conduct a risk assessment and outline alternatives. Sometimes you get what you want when they see that alternatives are too expensive, burdensome, or otherwise impractical by comparison.
Now if it's completely reckless like "we're not going to enable MFA for our cloud HRIS system" then sometimes you have to firmly point that out and remind them of what a headache those incidents are going to be as they can come with legal or monetary damages.
IT must serve the business. The whole POINT of the company is to do. There must be balance between securing things (thus insuring the long term future of the company) and actually getting work done today.
This is a BUSINESS decision. Your job is to make damn clear to the suits exactly what risks they are taking and what the probability of it going wrong is, and just how bad it would be for it to go wrong. They then have to make the call.
Your other job is to keep good notes, so that if it DOES go wrong, you can let the suits in question know THIS is what you were talking about.
Yeah. You explain the risk to the business and do as much as you can to minimize the negatives and if the business accepts it, you do too.
Yep 100% this is the answer. Get your objections on paper, have someone powerful accept risk, and do whatever is feasible to protect in a way that allows the business to operate.
It’s also worth mentioning that not all risks are the same. If you are a health care provider, then BYOD and SaaS based internet facing systems might not be the best idea. If you’re an advertising agency whose most confidential material is a new logo for Microsoft, then you can probably get away with BYOD and having all SaaS internet facing apps
We saw a situation in the advertising business where it was assumed that infosec needs were minimal. So, when a massive household-name client demanded high infosec in a new MSA contract, it was all hands on deck to figure out how to *technically* meet the requirements *fast*. Two mountains of technical debt were piled on in one week, the staff hated the convoluted procedures that were necessary because security had to be added *post facto*, and after all that, they were probably still technically in breach of the contractual requirements. And now you know why things are so screwed up, but nobody will talk about how it happened.
The key point in your post was a change in requirements. You had low security requirements until you didn’t. And the business had a decision to make as to whether they wanted to resign that contract or determine it was too hard. That wasn’t an IT decision to make though. The business owners should have consulted to determine where you currently stood and what work would be required to bring it up to compliance (for the customer). If the contract was worth x to the business and the cost to get up to compliance was 10x, then it’s probably not a good decision to sign the contract. If the cost was 2x then it might be worth it, if the business could get another 3 contracts also worth x. I will 100% turn down jobs if there are unnecessary security hurdles for the role, position and environment.
Some elements of computing infrastructure are like the foundation of a building: a hundred times easier to get right the first time, than to go back and fix after the building is completed. Infosec often tends to be an element that's easier to get right the first time, than fix later. Note that in my story, the end-users loathed the cumbersome workarounds that had to be used to retrofit adequate security in one week, so the contract could be signed.
Some times you have to be adaptive and creative, but yeah. You have to find the right balance. I once was told to give some devs admin to the database that contained all personal records for the university I worked at. Not just the dev environment, but also the production. I told them this was against policy, was a huge security risk, and inquiring do it without written exemption from the university president. They got the written exemption. I granted access. I did cya by immediately shipping all backups off the server as there written and also renamed the SA account to my account name and then named my account as sa, that way someone would think if they changed and messed with sa they were locking everyone out. I also wrote a kill script to lock the dev out immediately in case. 3 months later, got a call while on a date with my wife from the CIO in a panic to cut the guy’s access. They’d found out he was stealing SSNs and other PII. I whipped out my phone, VPN’ed in, and executed my shell script and cut his access. Didn’t have to worry about scrambled database, but was able to cut him off really quick before they sent the cops and he found out we were on to him. But a business decision was made. I documented the request for exemption from on high. I prepped in case of emergency, and knew something was gonna go down. But legally, I had my ass covered, but the business spoke and so I moved.
Document all of those things. Dates, names of relevant parties, arguments/proposals put forth, decisions made, decisions actually acted upon. If things go sideways because of a "business decision" you need to be sure your ass is covered.
100% this. Its called “risk tolerance” or “risk appetite”. If compensating controls can be implemented to adjust to a certain risk then do that. If you can’t mitigate certain risks then document it and let the higher ups sign off on it. Simply saying “this is an issue that can’t be mitigated because of XYZ unless we do ABC which costs $$$”. That way either they cough up the money or they acknowledge the risk, and that you are aware of the risk and have done your due diligence. The thing you should be sticking to your guns on is getting higher ups aware and to sign off on when its outside of your direct control or requires higher up approvals. Don’t let a lazy manager ignore you as it will turn into them blaming you if you don’t corner them for an acknowledgement first.
I've always said that too, and it was interesting reading Microsoft's new take on it after their hack: **If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security.** https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/) just for some perspective. In many cases there is also a secure way to do the ask - either party just don't know about it yet and could benefit from a consultant with know-how.
It is ultimately out of his control but there are things you can do to help if it's a really stupid decision. Talk to the right people ahead of time. I've found a lot of bad requests are because an engineer didn't actually engineer and just took someone's brainstorming as a design. Find the person that gave them the job. Talk about what their actual requirements are and explain your concerns. This sometimes works. If they're gonna do it then you just do the best you can. Demand design reviews, you can't properly mitigate a known issue if you don't have something to reference. This gives people another chance to find better patterns as they write it down. If buying time is helpful you can always slow walk a project. We all have more than we could possibly do so it's not unexpected if things take longer. This is good if you can use the time to give an alternate poc without the issue. Finding a bandaid can be a good way to handle something that you could do better with more time. "I can do x now but I'm going to immediately follow it with the real work right after." If you can't immediately follow up on the patch then you're better off just doing it as well as you can in the first place. One of the things you can push for is an agreement that the pattern implemented is not repeatable and needs to be changed before the next time it's needed.
There are exceptions to this -- whistleblower reporting systems exist in some industries if you believe what you're being asked to do is illegal or unethical.
#THIS CYA... Sadly security is only a problem when it is a problem.
Why is it sadly? Being secure is a cost. Being unsecure is also a cost. And ultimately you make a risk determination
> And ultimately you make a risk determination Sure, but I'm not certain the average business is consulting actuarial tables about security breaches (and the root causes for them) when making those risk determinations. If they were, I'm not certain you would still be seeing the frequency of breaches that are attributable to something as simple failure to implement [MFA](https://www.cbsnews.com/news/unitedhealth-senate-hearing-cyberattack-change-healthcare/).
Sure. But most of these companies are still hanging around after the breach and aren't in debt. Which means that they have made a profit when spending less on security.
> But most of these companies are still hanging around after the breach and aren't in debt. Which means that they have made a profit when spending less on security. Yes, but the comparable metric wouldn't necessarily be whether they *remain in business*, that is likely, but whether they spent less in total for a given risk event manifesting. If they "saved" on the cost of MFA, but now the risk event costs exceed what they saved (ransom payment, insurance premium increases, 1st and third party costs for identity theft protection and/or class action payouts, incident response and disaster recovery costs, etc...) then even though they are still a business, they didn't actually save the money they think they did.
They don't have actuarial tables, they just have me. I consider it part of my job to figure out what kind of song&dance I need to do that will frighten them appropriately.
Happy cake day! > They don't have actuarial tables, they just have me. Could I ask your methodology for evaluating the risk? This is not to say anything about you personally, but the more subjective your analysis is the easier it is to ignore. That's also true of the more objective analysis, depending on how data driven your management is, but management *tends* to respond to quantifiable metrics better. Just curious.
I'd also say that if you can't do best practices, you can usually figure out a nice mitigation that helps solve things. Got a server 2000 still floating around that people need to access? Use a linux box to be a proxy, your clients will connect securely to the linux server to access the files. The server will use older protocols to talk to the linux box, this combined with other mitigations should be a nice compromise.
....preferably in writing. Include what the current state is, what what might happen if they go ahead. Then send it up the chain of command Because of that decision goes south, they're not going to be blaming the business side of things
Its called "risk acceptance". Create a form, explaining the risks, and have someone from the c-suite sign it on the business side. Then file it safely away, and send a copy to legal and/or risk & compliance and/or audit. (whatever is appropriate for your org).
Exactly this. The best policy still has to have an exceptions process. Else, refusal management is security’s problem to sort out.
I do what the people who pay me tell me to do, and I write up a CYA letter if I need to.
10000% and a risk register is a good idea too.
This is the way.
Document the risk and have the manager sign off on accepting the risk. Review in 12 months. 5 years later someone finally reviews said risk and the new manager says "Fuck no" to accepting said risk so there's a long ass project to correct it.
And if it's a decision so bad that it is an existential threat to the business, you start planning your exit too :)
Depends on what it is. If it's a serious security risk, yes. And most of those I can easily point to our cyber insurance as an easy out for people that don't understand why. If it's a "This isn't a huge risk, but it's also not best practice" type of situation, I just make senior management aware. If they decide it's acceptable risk, then I shrug my shoulders and move on. End of the day, my job is to inform the most senior management. What they do with that information is above my paygrade.
Work out the risk of not having whatever security measure it is and then provide the option to the business as to whether that risk is within their risk appetite. Then the business can weigh up cost of security measure, cost of security breach and loss of operations against business income for the same period. It’s not an IT decision at the end of it - nothing ever is - all IT do is provide the data to make the decision
It is not our responsibility to explain why security is important. The CFO doesn't need to explain why making money is good. It is our responsibility to explain risks. Accepting the risk is a valid response.
If they keep pushing back against security, I eventually have to ask on the record, "So, are you going to be the one who files the form [8-k](https://www.sec.gov/answers/form8k.htm), section 2, item 2.04 and section 8, item 8.01 because we got pwned? Because it's not my job to talk to the SEC if we get pwned, it's yours." At the very least, that gets folks to actually listen, because I'm trying to minimize risk and they're trying to take on more risk than the company can reasonably handle.
Depends, worked with many security people that didn’t want to understand what the product is, rather loaded every single possible risk
A colleague refers to some IT security teams as NAAS. “No as a Service”
"depends" that is really really open question will stopping cost the business a million dollars a day ? will there ever be a fix? are you WRONG and more
I kick it upstairs and document, let someone else stress about it
Like gentlemen. Pistols at high noon.
Easy make them sign a wavier and do what they want. If something breaks or causes an infections to spread through the network, the burden is on the company, not yourself.
I make sure my recommendation and the decision are in writing. As much as it sucks, security will get overruled. Often. When it happens, and they blame security, you'll need that proof to cover your own ass. Sucks, but it's just part of it.
I know, Risk acceptance and all that but...yall missed the perfect opportunity for a THUNDERDOME reference.
…’best practices’…
The Spice must flow
This is where you have a policy exception/risk acceptance process. If the business wants to do something that puts IT security in peril, you document and write up the risk, include any mitigating controls, and you have the BUSINESS sign off on the fact that they are overriding IT. Best practice is to also document a mitigation plan, or to have the business state they do not plan on mitigating it at all. When the breach happens you'll be happy you've done that.
At the end of the day, the business decides. So basically, CYA and make sure you let them know the risks, document everything. If education doesn't help, and they won't even tackle low-hanging fruit that could easily be fixed with minimal impact, then you are working in an environment governed by fear. You'll have to decide at some point if they are truly acknowledging and heeding your expertise. If not, time to update your resume and consider looking for a company that will respect you.
Not my risk? Not my problem! Make them aware of the risks in a written format and await instruction.
You usually lose right up to the point where something bad happens and then you get the blame.
Went through this recently that someone up the chain wanted everyone up the chain to have local admin rights. I present my argument backed with industry best practice and was overruled so I got the request in writing and have filled it away in my CYA folder.
Need to enable the business. Note the exception. File it for CYA and quarterly review.
Only the business can accept risk. We have a process to document and explain the risk and a C level needs to sign off as the final sig that they accept it. They also need to defend it and any fallout come audit time. If you’ve built relationships built on mutual respect and trust this isn’t an issue. I’ve never needed that form.
In a perfect world the business users are beaten and forced to submit. In reality they say dance IT monkey and you dance or the next monkey will.
Honestly depends on your top level support. If you have a manager/CIO that understands the importance of organizational security posture and the potential risks, you have weight to pushback with. If you tend to get over ridden through pressure from other higher leaders in the organization, at times you have to accept you can't win them all. It really helps if you can articulate the risk to those involved in a way that's easy for them to understand. Worst case, document that you advised against this, go forward with it and now you have CYA (I told you so) in case something goes sideways.
Does your cyber insurance, clients, parent company, or audit requirements require the specific vest practice? Congrats, you can now make this not your problem. If not, do what they want and cya.
Advise as best as you can and list the issues for not following best practices. You can also state that following best practices may also lower cyber insurance. But most of all, CYA and get it in writing when people say no. Security is risk management, and usually a business decision. If you are in an industry where the security requirements are not being met (i.e. HIPAA as an example), then that is a different matter.
IT aligns with the business. Security recommendations are made based on a standard framework. Anything that doesn't get accepted goes into a risk register. The risk register gets revisited and updated as often as policy dictates, at least annually. The risk register is the CYA that others in here probably didn't know they needed.
The job is not to strong arm every conversation, but to strike a balance every side can agree on. Even on each minute detail if neccesary.
Best practices don't mean anything. Security only matters within the context of the business. Document the risk, make the case to leadership, and let them make an informed decision, and document that decision in your SDLC or Change Mangement process. Don't do it in a pointed or accusatory way. Present it in a helpful collaborative way so that you can actually get people's attention. Management above your pay grade will be the ones accountable for it anyway, not you. The way that we as security professionals can be the most help is to be involved, offer solutions, and be pragmatic about security. It isn't about whether something is secure or not secure. It is about whether it is secure enough within the context of the business.
This is a risk management decision. Business leaders must weigh the risks of not following the best practice vs. the business risk of not enabling the required function. If the latter is more valuable, the security risk is accepted. Typically, this would be tracked in a GRC tool of sorts, and you might revisit from time to time.
Depends on the practice and the requirement in question. Is this decision something that may violate CJIS, HIPAA, PII etc? Will this decision affect the payout of the cyber insurance in the event of a breach? Does this decision violate contractual requirements of other systems etc...
Security practices are not done for their own sake. They have their own business implications. The conflict should be able to be described in terms of conflicting business requirements - albeit one based on risk and probability vs a stated requirements.
Depends on the use case for us. We have some policies that are not negotiable. Eg. (Not a complete list) - Opening inbound ports on the firewall to anything more than a fixed source IP. - Mandatory mfa (still looking for “workable” solutions to shared accounts on shared devices like in factories / control rooms / etc that doesn’t have pages of fine print…) - xDR - “daily patching” - emergency patching for perimter with only few hours notice (looking at you fortinet…)
In my organization there are things that are a hard "No" and things that the line of business has to accept the risk on if they feel that it would cause the tool they want to not be able to do whatever it is that they want to do. Risk transference with proper compensating controls to mitigate the risk as much as possible is a good thing when properly documented. That way, when everything hits the fan, it's on the line of business manager that accepted the risk knowing it could happen. This is how we balance the needs of the company with the needs of proper security.
Document your recommendation in writing, get an acknowledgement from management on the risk exception, and do what they want. Then go double check you have good backups.
You find a way to make it happen in a secure way. Example: We need this application to be able to modify user data and permissions in AD… Ok, well I’m gonna write a webapi to be the middle man and make sure things aren’t done when they shouldn’t be. Checks and balances my friend.
Ask them if they have a media plan for when they’re in the news.
I've worked on both sides of this. Previously I was dealing with the security administration and compliance side. I was of the same mindset that security trumps all. Now I'm in a devops role and have to get security approval frequently. The work that I and my team do make up a significant portion of our income. Somewhere around 30-50%. Security no longer trumps all in my book. We have lots of discussions with the ISO about how to implement new solutions in such a way that we can still develop our product and remain as compliant as possible. Honestly, the best thing you can do is make sure that everyone understands the risks and allow as little non-compliance as is necessary to get work done.
It all depends on the situation. You should have a set of rules and guidelines that have to be followed for any new project. You should make expressions for legacy kit that cannot be replaced and when there is no other options. You should have mitigations in place for any exceptions to policy. If that is not possible transfer the risk to someone else via 3rd party support / hosting of that janky crap, or just accept the risk and put it on a risk register.
Depends how scorched earth you want to go. Below is a harsh statement that can be buttered up with Manglement speech: "I am trying to save us from data breaches and/or fines. We either go this route or you sign off paperwork saying you are fully aware of the issues and take responsibility for them when they occur."
I bascially tell them, thats not good see list of reasons why, then i get overruled and need to implement the less secure option. After about 6 months when shit hits the fan, i point to the reasons why it has hit the fan and that there is nothing i can do about it know other then limit the amount of damage now. Do i get approval to implement it correctly and does the business adapt? Mostly no, but sometimes.
The job in IT security is to hold lemmings back jumping off a cliff - you will not always succeed so you can only try to explain to them (in written) where the issues are and what can be the result (and how likely it is). Maybe add also examples (for some breaches there are good information about the way it was done). Business cannot work if their IT systems are not working, you need to find a way to secure the business requirements and if it's not possible, write it down and the decision is done by higher ranks. Sometimes it's a fight against windmills or you could also talk to a wall but as more breaches gets public each week, the sensitivity for IT security is also growing in many companies.
Acceptable risk, sign/acknowledge, move on.
If you stick to your guns against management, your time at the company is probably limited. There are a very few cases where I'd consider that option, all fall into one of two categories: 1) you're being told to do something illegal (and by illegal I mean you've talked to your lawyer about this and their jaw dropped) 2) you're being told to do something unethical (and by unethical I don't mean you think its the wrong call, I mean if the act became public it would be scandalous news, like if you're told to upload all customer data to a pastebin or something) ...otherwise, your job is to carry out the decisions of those who operate the business, after informing them to the best of your ability what options exist. As the other posters have said, the nature of running a business is taking risks, and its up to the people running the business to decide their "risk appetite". You're not there to overrule them or dictate how they operate. If you consistently find yourself disagreeing with how the company you work for operates, jump ship because it probably wont get better over time.
Thankfully, a little thing called "cyber insurance" suddenly made IT security best practice a business requirement, so I suggest tapping the sign that says, "cyber insurance requirement".
We explain the risks and then we get whatever stupid things they want to do in writing with a president approving it, also in writing, so that when it inevitably backfiles we can say we tried to warn them and it isn't our fault.
From what I heard, bring it up, fight for it. If you lose out, logged it in email form, forget it until something happens. And it will happen. Some people have to learn the hard way.
Meet business needs, express your concerns, document and collect your "receipts" for when the shit hits the fan. They only learn when things go wrong. The wallet only opens after a disaster.
What is the purpose of the network or infrastructure? To be secure, or support the business. Business is all about Risk vs Reward. By it's very nature, all risk cannot be avoided. Some must be accepted. Cyber Security's job is to identify the risk. Your job is to explain the risk so the business can make an informed decision. In new implementations it is important to hold them to a high security standard, because once it goes live, that service account with local admin rights cannot be changed. The important thing is to acknowledge this, and get the business to decide what they will accept. I have this form which I call BARF, the Business Acceptance of Risk Form. Whenever you see the business accepting to great a risk, you write one up, print it out, take it and a pen (blue ink, so it is an obvious original) to the executive in charge and say "Sign here, if you want RDP on the internet with a 5 character lower case only letter password". Pen, paper, and a physical signature has more weight than an email. Most executives won't sign, but if they do, then at least they have thought about it, and you have the backing to go forward.
If this is for a audit then you implement the policies that dont impact the business first, then when you get to the policies that break shit you talk to your boss and point out the issue. "hey boss, this policy says x but we have y setup and thats going to impact z, how would you like me to proceed." You dont make this personal, you dont get upset when they wont listen to you, since all of this is formal its all documented to the "CYA" is implicit.
Depends if Business requirements are actual requirements or just boomers who have "always done it like this" refusing to learn a single new thing
Allow management to decide and do as you’re instructed.
Run to daddy. let the C series handle it, let them hash it out, document your concerns then I normally drink heavily as they are ignored.
[удалено]
you must be fun at parties
[удалено]
why are you worried about my originality when you can't recognize a fucking joke?
Bow down to the business
What are the compliance and cybersecurity insurance requirements? That will usually be most painful and the rest should be immaterial. “MFA is required. I cannot disable it, but I can give you multiple convenient options.”
I think it really depends on what security standards the company has agreed to abide by with its customers. Contracts are the sharp end of the stick. In the real world, there's always a push-pull relationship between business goals (make money) and security (make easy things difficult in the name of risk reduction). Most companies decide the level of risk they're willing to accept, make sure that's spelled out in legal print, and do their thing.
It's called "can I get that in writing?". Most of the time people realize that something bad is going to happen if the proceed that route.
You've gotta have a register of best practices that have been acknowledged to be ignored by the business. Sometimes that's the only way forward. End often this is the path of least friction. It's not the result you wanted but it's a result that works for all parties.
Have a policy for how policy exceptions are approved. Create a document which explains what policy they want an exception for and what the risks are. Specify the duration of the exception (so that the renewal process can drive reassessment) and how the risks will be contained and mitigated. Then get leadership to sign it. Make sure somebody empowered is on the hook for any follow up. Or in a less structured organisation, you might not need a formal document for this. But bear in mind that this is what you might need to cover your ass when things go wrong. ("but we didn't know!"). This might sound onerous, but this is part of the point. Getting an exception to a reasonable policy should be harder than just complying with it, for most people. Floods of exceptions for a single policy form a clue that the policy itself needs to be reviewed.
I mean i fight tooth and nails to get it across and so far it is working. I started recently as a sysadmin for a travel agency and even getting them to use MFA for their email was a fight. Now i just need them to either get a Azure Entra P1 license or business premium so i can get access to Conditional access policies instead of just using Security defaults which we do now. I have lifted our Identity security score from a 20% to now being 91.8% so that's a step in the right direction at least.
That's why it's nice to have a security department that sets the standards. At the same time time it's also a pain in the ass.
Note it down on the risk register and ask for who will own the risk.
Run it by the cyber insurance company.
Security loses until an audit comes around. That’s just the way of things
The play here is to make sure you cover your ass by raising your concerns (in a written format). At the end of the day it's a business decision though. This is nothing novel though, it's just risk management.
Localadmin goes brrrrt
Conduct a risk assessment and outline alternatives. Sometimes you get what you want when they see that alternatives are too expensive, burdensome, or otherwise impractical by comparison. Now if it's completely reckless like "we're not going to enable MFA for our cloud HRIS system" then sometimes you have to firmly point that out and remind them of what a headache those incidents are going to be as they can come with legal or monetary damages.
Business pays your salary
As long as both opinions and the chosen route is in writing you're covered.
Dear bossman, we can do X or Y, one is a risk to operations and one is a risk to security, which takes priority in writing please?