Of course security is compromised in favor of other goals, because the business doesn't exist if people can't do their jobs and produce whatever it is the business sells. Often I find that IT put too much priority on security in relation to other factors, in part because they lack the perspective to properly prioritize things.
>Often I find that IT put too much priority on security in relation to other factors, in part because they lack the perspective to properly prioritize things.
This sounds too similar to something they might say about you. Do you have any specific examples?
Yes: Spectre and Meltdown. If you are running a cloud hosting company (or are using their services) then these are a huge problem for you because you run untrusted code on systems with sensitive data, or are sharing hardware with untrusted parties. It is probably very much worth the effort to use the performance impacting mitigations here.
If you're running an on-prem server, you're not running rando code from untrusted sources so the performance-impacting mitigations don't make sense. Yet there were (and still are) a lot of people who insist these mitigations need to be applied everywhere.
This sort of thing comes up all the time though. Think about how often people run web browsers on development machines. Not only are the a vector for "accidentally" installing malware even without bugs, they can sometimes be exploited to obtain data from your computer. Yet would you ever try and tell a developer that they can't use a web browser? But you take a similar decision outside of IT and suddenly IT people think it's a good idea to, say, disable VBA macro execution across the org because they don't have any idea how heavily the accounting department relies on it.
> if you're running an on-prem server, you're not running rando code from untrusted sources so the performance-impacting mitigations don't make sense. Yet there were (and still are) a lot of people who insist these mitigations need to be applied everywhere.
There's always generally someone else's code running somewhere, if it's "trusted" or not it's still a valid risk to assess.
I rather thing the big players are ignoring security risks on purpose. Eg Amazon AWS just switched from their secure and isolated Xen to the insecure and faster KVM.
Everybody is praising the insecure eBPF on servers. You can certainly play with eBPF on your private isolated machines, but on big public servers it's a high risk. Still, there is where it's used.
Nobody but java cares about Unicode identifier insecurity. It's just shrug off, even if the standard gives explicit recommendations and guidelines.
Insecurity is the default until a desaster destroys the business model. Managers are making those decisions mostly.
This, my friends, is the thought process that allows Equifax-like breaches to happen.
In the same way that a business doesn’t exist if the business can’t do business, someone’s identity might be safe if the business never existed in the first place.
Shame on me that my “perspective” still includes the well-being of the customer we are serving.
I don't follow your argument. You seem to be saying that shutting down a business because security policy has destroyed its ability to do business is actually a really good thing because some business are bad.
That certainly is a certain kind of perspective I guess. You and I are not Equifax customers, our data was part of their product. This is an orthogonal issue.
In a company, a nice coffee corner was built in the hallway. Fire inspection said it would hinder evacuation and had to be adapted. Two weeks later, the coffee corner was adapted, no ifs, no buts.
I wish our IT could do the same thing. But on one side a lot of very ugly code is produced, on the other side infosec makes up all kind of weird rules and mitigation on the spot, with no recourse and very random enforcement.
I've worked for companies, where security issues weren't reported by power users because they themselves had to exploit those vulnerabilities to be able to do their job.
Now those issues are exposed to the internet to allow people to work from home, but the actual problem is still there.
If the people in charge don't understand the issue (technical details) and the people who understand it aren't saying anything, then there'll eventually be a breach
> I've worked for companies, where security issues weren't reported by power users because they themselves had to exploit those vulnerabilities to be able to do their job
Yes, this is a well known effect of security policies: when you add too much friction to people's lives they will find ways to work around it. Any competent security policy will have to take this into account.
I think the other stats in here are more interesting. It seems obvious to me that IT teams are forced to trade security for operations regularly - that's just the constant tension between security and usability. It's the job of IT to advocate for security and the job of other folks to advocate for usability, and of course that will likely lead to some compromises on security (as well as usability).
That doesn't mean security's being thrown out the window - trading security for business operations could be as simple as a 2FA code being six characters where IT would have preferred ten.
But in the article they also say: "76% of respondents said that security had taken a backseat, and furthermore, 83% believe that working from home has created a "ticking time bomb" for corporate security incidents."
That seems much more serious - it's one thing for there to be compromises made, but it's another for security to take a backseat entirely. Personally, if I were writing the story I would've focused the headline on the concerns about WFH (though I recognize the article's author didn't necessarily write the headline) - that's more specific and relevant to the issues of today than the more general "IT has to compromise on security" angle.
Businesses don't exist to be secure, they exist to make money, and thus security will always be compromised. It's very easy to have a super secure IT system that makes 0 money.
IT teams generally are only going to value security to meet business objectives and protect their reputation. The unfortunate point is that often security is in the public interest but businesses don't act in the public interest.
The article conflates "IT team" with "infosec" which misses the faulty dynamic. In many organizations the "IT/Ops" team is the one acting on behalf of stakeholders with competing interests. If the CISO and CEO both exert pressure on Ops the CEO will ofcourse have more leverage and force Ops hand. This is just an extra layer of indirection that shields those above from liability. Having Ops act as the arbitrar of these stakeholders is pure theatrics.
17 comments
[ 3.2 ms ] story [ 58.8 ms ] threadThis sounds too similar to something they might say about you. Do you have any specific examples?
If you're running an on-prem server, you're not running rando code from untrusted sources so the performance-impacting mitigations don't make sense. Yet there were (and still are) a lot of people who insist these mitigations need to be applied everywhere.
This sort of thing comes up all the time though. Think about how often people run web browsers on development machines. Not only are the a vector for "accidentally" installing malware even without bugs, they can sometimes be exploited to obtain data from your computer. Yet would you ever try and tell a developer that they can't use a web browser? But you take a similar decision outside of IT and suddenly IT people think it's a good idea to, say, disable VBA macro execution across the org because they don't have any idea how heavily the accounting department relies on it.
There's always generally someone else's code running somewhere, if it's "trusted" or not it's still a valid risk to assess.
Everybody is praising the insecure eBPF on servers. You can certainly play with eBPF on your private isolated machines, but on big public servers it's a high risk. Still, there is where it's used.
Nobody but java cares about Unicode identifier insecurity. It's just shrug off, even if the standard gives explicit recommendations and guidelines.
Insecurity is the default until a desaster destroys the business model. Managers are making those decisions mostly.
In the same way that a business doesn’t exist if the business can’t do business, someone’s identity might be safe if the business never existed in the first place.
Shame on me that my “perspective” still includes the well-being of the customer we are serving.
That certainly is a certain kind of perspective I guess. You and I are not Equifax customers, our data was part of their product. This is an orthogonal issue.
I wish our IT could do the same thing. But on one side a lot of very ugly code is produced, on the other side infosec makes up all kind of weird rules and mitigation on the spot, with no recourse and very random enforcement.
Noone wants to get hurt in a fire, but noone really gets "hurt" when security is compromised.
Now those issues are exposed to the internet to allow people to work from home, but the actual problem is still there.
If the people in charge don't understand the issue (technical details) and the people who understand it aren't saying anything, then there'll eventually be a breach
Yes, this is a well known effect of security policies: when you add too much friction to people's lives they will find ways to work around it. Any competent security policy will have to take this into account.
That doesn't mean security's being thrown out the window - trading security for business operations could be as simple as a 2FA code being six characters where IT would have preferred ten.
But in the article they also say: "76% of respondents said that security had taken a backseat, and furthermore, 83% believe that working from home has created a "ticking time bomb" for corporate security incidents."
That seems much more serious - it's one thing for there to be compromises made, but it's another for security to take a backseat entirely. Personally, if I were writing the story I would've focused the headline on the concerns about WFH (though I recognize the article's author didn't necessarily write the headline) - that's more specific and relevant to the issues of today than the more general "IT has to compromise on security" angle.
IT teams generally are only going to value security to meet business objectives and protect their reputation. The unfortunate point is that often security is in the public interest but businesses don't act in the public interest.
We see IT Security and HN making up stories like "Ransomware kills German hospital patient" to make themselves sound important - https://www.technologyreview.com/2020/11/12/1012015/ransomwa...
They do exist, like directly with the Ashley Madison incident, but it's the indirect lives saved that would be higher.
The deaths caused by IT security being to high have been fuck tonnes of course.
It's hard to compare the two side, but I think it's fair enough not to trust 'IT teams'
It's also hard to know how bad they are compared to Public Relations or HR for instance or management and CEOs power climbing.
IT security directly attacks the worker, other departments attack the company.
It's a complex equation