4 ms·

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 busin

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.

ghfjfh 5y ago
>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?
- AnIdiotOnTheNet 5y ago
  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.
  - llama052 5y ago
    > 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.
    - deleted 5y ago
      [deleted]
  - rurban 5y ago
    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.
- deleted 5y ago
  [deleted]
ecf 5y ago
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.
- AnIdiotOnTheNet 5y ago
  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.
hyperman1 5y ago
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.
- rarec 5y ago
  Big difference also is, sadly, one this is immediately visible and tangible versus a vague "security" diagram and document. Noone wants to get hurt in a fire, but noone really gets "hurt" when security is compromised.

ghfjfh 5y ago

>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?

AnIdiotOnTheNet 5y ago
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.
- llama052 5y ago
  > 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.
  - deleted 5y ago
    [deleted]
- rurban 5y ago
  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.
deleted 5y ago
[deleted]

ecf 5y ago

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.

AnIdiotOnTheNet 5y ago
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.

hyperman1 5y ago

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.

rarec 5y ago
Big difference also is, sadly, one this is immediately visible and tangible versus a vague "security" diagram and document. Noone wants to get hurt in a fire, but noone really gets "hurt" when security is compromised.