7 ms·

Is it a moral failing to be slow to update a Struts vulnerability? As an IT engineer that makes be nervous because I don't know which of a hundred actions I tak

Is it a moral failing to be slow to update a Struts vulnerability? As an IT engineer that makes be nervous because I don't know which of a hundred actions I take or don't take in a given day will explode on me. Or was the moral failing to agree to build such a system in the first place?

chickenfries 9y ago
> to be slow to update a Struts vulnerability If this Struts vulnerability can lead to the personal information of literally half of America? I'm not a lawyer, but that sounds pretty damn negligent to me. I agree with your larger point that the system probably shouldn't be built in the first place, at least not the way it is now, but there are still plenty of things they could have done, like not store it in plaintext at rest.
fish_fan 9y ago
My issue is not that they had the vulnerability, but that the vulberability allowed full access to social security numbers and it wasn’t even the “critical” database! You can take proactive efforts to minimize the risk of breaches; they appeared to store large amounts of unencrypted (or encrypted in aggregate) personally identifiably information together and allowed a single struts vulnerability unfettered access. For instance, one could not duplicate social security numbers, or could allow you to encrypt your data so you need to provide a key for others to access it. The possibilities are endless.
- KekDemaga 9y ago
  My design would be a ZeroMQ message bus between the database server and the application server. Social Security numbers shouldn't need to be displayed to the user (as they should already know it) thus all the message bus should be carrying is "it matches" or "it doesn't match" in regards to them.
josephg 9y ago
> Is it a moral failing to be slow to update a Struts vulnerability? Yes. As a professional engineer you are responsible for the systems you build and maintain. The security of the modern internet depends on engineers on the ground understanding and proactively fixing security issues. There is no one else who can take responsiblity for code you deploy to production. The buck stops with you.
- briandear 9y ago
  Yeah, unless your management has other priorities and their management has other priorities. The buck actually stops at the CEO.
  - Ntrails 9y ago
    As a member of an unrelated professional body, the buck always stops with me on issues of ethical behaviour. I don't care how much the CEO wants me to do a thing that is good for the bottom line - if I want to keep letters after my name I have to behave in a way that is in line with the professional code of conduct I signed up to. I'm not saying that such a model is the right one for devs, but it would certainly be an interesting move away from "not my fault - nobody would let me do it right". CEOs would, of course, then have the choice to hire non-accredited engineers to work on their software, and then the buck does stop there because they made an active decision.
    - FussyZeus 9y ago
      > I'm not saying that such a model is the right one for devs, but it would certainly be an interesting move away from "not my fault - nobody would let me do it right". I would say I'm in a similar position, but that's because I'm more or less essential (no ego here, and can't explain obviously, but I am) and if I walk out, the company has a lot of BFPs to deal with. Perhaps there should be some sort of guild? Some way that we could make it harder for ourselves to be replaced in such a way where we can actually stop bucks without just getting fired while they find some script kiddie to do what we wouldn't.
  - jowiar 9y ago
    But ideally, "I was just following orders" should not be an excuse. Part of the reason we need proper professional accreditation is so that engineers can say "No, this is wrong.", and the CEO can't say "you're fired, I'm going to hire someone who will do what I say". We need to put loyalty to the profession ahead of loyalty to the business.
- treerock 9y ago
MrQuincle 9y ago
If the data would be considered the customer's, it would have made sense to use application-level encryption [1]. Each user has a unique key which should be their property. If you need to give access to that data without the user's consent, you'll need to store their unique key for them. You'll better do that in a very secure manner. If now somehow the database gets exposed, good luck! You'll also need to get the individual keys to decipher everything. Then, although still you can be blamed for not using a vulnerability scanner, there is much less at stake. [1] https://www.compose.com/articles/encrypting-sensitive-data-in-your-mongodb-database/ https://www.compose.com/articles/encrypting-sensitive-data-i...
- twobyfour 9y ago
  The users whose data was exposed are not Equifax's customers. People who want credit reports on them are.
deathanatos 9y ago
It was somewhere between that and: * The executives selling stock before telling the public about the breach[1] — but "Equifax responded to TechCrunch’s questions about the timing of the transactions, particularly those of CFO John Gamble, with the following statement claiming that the executives in question were not aware of the hack which the company was made aware of on July 29" * entering in phony name into the "Have I been breached?" site resulted in random answers; "Others have tweeted they received different answers after entering the same information."[2] * Equifax hosted said "Have I been breached?" site, and services related to protecting oneself from the breach, on a domain that looked for all the world like a phishing site, and further, "What’s more, there is nothing tying the domain registration records for trustedidpremier.com to Equifax: The domain is registered to a WHOIS privacy service, which masks information about who really owns the domain (again, not exactly something you might expect from an identity monitoring site)." [4] * Equifax wanted people to agree to a forced arbitration clause. [3] * Equifax directed people to a fake phishing site [5] …that it became a moral failing. [1]: https://techcrunch.com/2017/09/07/equifax-managers-dumped-stock/ https://techcrunch.com/2017/09/07/equifax-managers-dumped-st... [2]: https://techcrunch.com/2017/09/08/psa-no-matter-what-you-write-equifax-may-tell-you-youve-been-impacted-by-the-hack/ https://techcrunch.com/2017/09/08/psa-no-matter-what-you-wri... [3]: https://theintercept.com/2017/09/08/equifax-is-proving-why-forced-arbitration-clauses-ought-to-be-banned-just-like-the-cfpb-wants-to-do/ https://theintercept.com/2017/09/08/equifax-is-proving-why-f... [4]: https://krebsonsecurity.com/2017/09/equifax-or-equiphish/ https://krebsonsecurity.com/2017/09/equifax-or-equiphish/ [5]: https://www.theverge.com/2017/9/20/16339612/equifax-tweet-wrong-website-phishing-identity-monitoring https://www.theverge.com/2017/9/20/16339612/equifax-tweet-wr...
jowiar 9y ago
The latter. It is a moral failing to build/market a product with failure modes that expose unconsenting victims to consequences they did not sign up for. And "we were just following orders" should not be a defense, either.
spydum 9y ago
It seems dishonest to pretend struts was their only problem. That just happened to be the trick of the day. As others have mentioned, security is designed in layers. The fact that a single layer can fail and cause so much damage is simply bad design. Unfortunately there is a lot of bad design in IT. InfoSec may not be new, but I would argue up until about the last 15 years, it was really not considered outside of defense departments.
ska 9y ago
It's a moral failing to be engaged in the collection of personal data of this type and scale without having a solid, well articulated, well communicated, robust and redundant plan for managing security and mitigating the impact of security issues. It's an ethical failure that this industry has so many examples of above.
- trgv 9y ago
  I don't think this is a moral question. Whether or not this information should be collected at all may be a moral question, but how it's secured is about technical competence. I also think we should keep in mind that, even if it was well-secured, there could have still been a breach. Would that have been less bad? The result would be the same.
  - ska 9y ago
    Would that have been less bad? Quite plausible yes, with better systems design.
  - garrettdc 9y ago
    The moral issue isn't one of technical competence, but rather of having the integrity to perform the appropriate due diligence required of a company handling such sensitive information. No security professional is going to argue that you can or will prevent every vulnerability from being exploited. However, when you leave a critical vulnerability open for months on end, you knowingly and unnecessarily expose yourself, and any parties associated with you (by choice or otherwise), to a level of risk that is unacceptable. If this were a 0-day exploit, then the conversation would be different. If their exec's hadn't sold off so much stock a such a suspect moment, then the conversation would be different. If the IT department had appropriately began remediating the vulnerability within a respectable timeframe but had already been exploited, then the conversation would be different.
  - vec 9y ago
    To my view, collecting and storing that much information is presumptively immoral. It creates a public hazard, in the same vein as stockpiling explosives or toxic chemicals. There is, however, a degree of respect for that hazard, demonstrated in concrete safety practices, that can override that presumption. I don't think Equifax has demonstrated that respect. To a layman's view, not many companies do. It's possible that the amount of respect necessary for a hazard as large as the one Equifax created is too onerous for a for-profit entity to realistically implement, but I don't know that there's a fundamental reason that sufficiently paranoid engineering practices couldn't make this moral.
plandis 9y ago
Failed to patch in a prompt manor. Waited to disclose the issue to the public. Set up a credit monitoring service that was insecure and would auto charge you (the auto charge was dropped after people were outraged). The CEO blamed the whole thing on one person (and that person was not him). What part of that doesn't seem like a moral failure?

chickenfries 9y ago

> to be slow to update a Struts vulnerability If this Struts vulnerability can lead to the personal information of literally half of America? I'm not a lawyer, but that sounds pretty damn negligent to me. I agree with your larger point that the system probably shouldn't be built in the first place, at least not the way it is now, but there are still plenty of things they could have done, like not store it in plaintext at rest.

fish_fan 9y ago

My issue is not that they had the vulnerability, but that the vulberability allowed full access to social security numbers and it wasn’t even the “critical” database! You can take proactive efforts to minimize the risk of breaches; they appeared to store large amounts of unencrypted (or encrypted in aggregate) personally identifiably information together and allowed a single struts vulnerability unfettered access. For instance, one could not duplicate social security numbers, or could allow you to encrypt your data so you need to provide a key for others to access it. The possibilities are endless.

KekDemaga 9y ago
My design would be a ZeroMQ message bus between the database server and the application server. Social Security numbers shouldn't need to be displayed to the user (as they should already know it) thus all the message bus should be carrying is "it matches" or "it doesn't match" in regards to them.

josephg 9y ago

> Is it a moral failing to be slow to update a Struts vulnerability? Yes. As a professional engineer you are responsible for the systems you build and maintain. The security of the modern internet depends on engineers on the ground understanding and proactively fixing security issues. There is no one else who can take responsiblity for code you deploy to production. The buck stops with you.

briandear 9y ago
Yeah, unless your management has other priorities and their management has other priorities. The buck actually stops at the CEO.
- Ntrails 9y ago
  As a member of an unrelated professional body, the buck always stops with me on issues of ethical behaviour. I don't care how much the CEO wants me to do a thing that is good for the bottom line - if I want to keep letters after my name I have to behave in a way that is in line with the professional code of conduct I signed up to. I'm not saying that such a model is the right one for devs, but it would certainly be an interesting move away from "not my fault - nobody would let me do it right". CEOs would, of course, then have the choice to hire non-accredited engineers to work on their software, and then the buck does stop there because they made an active decision.
  - FussyZeus 9y ago
    > I'm not saying that such a model is the right one for devs, but it would certainly be an interesting move away from "not my fault - nobody would let me do it right". I would say I'm in a similar position, but that's because I'm more or less essential (no ego here, and can't explain obviously, but I am) and if I walk out, the company has a lot of BFPs to deal with. Perhaps there should be some sort of guild? Some way that we could make it harder for ourselves to be replaced in such a way where we can actually stop bucks without just getting fired while they find some script kiddie to do what we wouldn't.
- jowiar 9y ago
  But ideally, "I was just following orders" should not be an excuse. Part of the reason we need proper professional accreditation is so that engineers can say "No, this is wrong.", and the CEO can't say "you're fired, I'm going to hire someone who will do what I say". We need to put loyalty to the profession ahead of loyalty to the business.
treerock 9y ago

MrQuincle 9y ago

If the data would be considered the customer's, it would have made sense to use application-level encryption [1]. Each user has a unique key which should be their property. If you need to give access to that data without the user's consent, you'll need to store their unique key for them. You'll better do that in a very secure manner. If now somehow the database gets exposed, good luck! You'll also need to get the individual keys to decipher everything. Then, although still you can be blamed for not using a vulnerability scanner, there is much less at stake. [1] https://www.compose.com/articles/encrypting-sensitive-data-in-your-mongodb-database/ https://www.compose.com/articles/encrypting-sensitive-data-i...

twobyfour 9y ago
The users whose data was exposed are not Equifax's customers. People who want credit reports on them are.

deathanatos 9y ago

It was somewhere between that and: * The executives selling stock before telling the public about the breach[1] — but "Equifax responded to TechCrunch’s questions about the timing of the transactions, particularly those of CFO John Gamble, with the following statement claiming that the executives in question were not aware of the hack which the company was made aware of on July 29" * entering in phony name into the "Have I been breached?" site resulted in random answers; "Others have tweeted they received different answers after entering the same information."[2] * Equifax hosted said "Have I been breached?" site, and services related to protecting oneself from the breach, on a domain that looked for all the world like a phishing site, and further, "What’s more, there is nothing tying the domain registration records for trustedidpremier.com to Equifax: The domain is registered to a WHOIS privacy service, which masks information about who really owns the domain (again, not exactly something you might expect from an identity monitoring site)." [4] * Equifax wanted people to agree to a forced arbitration clause. [3] * Equifax directed people to a fake phishing site [5] …that it became a moral failing. [1]: https://techcrunch.com/2017/09/07/equifax-managers-dumped-stock/ https://techcrunch.com/2017/09/07/equifax-managers-dumped-st... [2]: https://techcrunch.com/2017/09/08/psa-no-matter-what-you-write-equifax-may-tell-you-youve-been-impacted-by-the-hack/ https://techcrunch.com/2017/09/08/psa-no-matter-what-you-wri... [3]: https://theintercept.com/2017/09/08/equifax-is-proving-why-forced-arbitration-clauses-ought-to-be-banned-just-like-the-cfpb-wants-to-do/ https://theintercept.com/2017/09/08/equifax-is-proving-why-f... [4]: https://krebsonsecurity.com/2017/09/equifax-or-equiphish/ https://krebsonsecurity.com/2017/09/equifax-or-equiphish/ [5]: https://www.theverge.com/2017/9/20/16339612/equifax-tweet-wrong-website-phishing-identity-monitoring https://www.theverge.com/2017/9/20/16339612/equifax-tweet-wr...

jowiar 9y ago

The latter. It is a moral failing to build/market a product with failure modes that expose unconsenting victims to consequences they did not sign up for. And "we were just following orders" should not be a defense, either.

spydum 9y ago

It seems dishonest to pretend struts was their only problem. That just happened to be the trick of the day. As others have mentioned, security is designed in layers. The fact that a single layer can fail and cause so much damage is simply bad design. Unfortunately there is a lot of bad design in IT. InfoSec may not be new, but I would argue up until about the last 15 years, it was really not considered outside of defense departments.

ska 9y ago

It's a moral failing to be engaged in the collection of personal data of this type and scale without having a solid, well articulated, well communicated, robust and redundant plan for managing security and mitigating the impact of security issues. It's an ethical failure that this industry has so many examples of above.

trgv 9y ago
I don't think this is a moral question. Whether or not this information should be collected at all may be a moral question, but how it's secured is about technical competence. I also think we should keep in mind that, even if it was well-secured, there could have still been a breach. Would that have been less bad? The result would be the same.
- ska 9y ago
  Would that have been less bad? Quite plausible yes, with better systems design.
- garrettdc 9y ago
  The moral issue isn't one of technical competence, but rather of having the integrity to perform the appropriate due diligence required of a company handling such sensitive information. No security professional is going to argue that you can or will prevent every vulnerability from being exploited. However, when you leave a critical vulnerability open for months on end, you knowingly and unnecessarily expose yourself, and any parties associated with you (by choice or otherwise), to a level of risk that is unacceptable. If this were a 0-day exploit, then the conversation would be different. If their exec's hadn't sold off so much stock a such a suspect moment, then the conversation would be different. If the IT department had appropriately began remediating the vulnerability within a respectable timeframe but had already been exploited, then the conversation would be different.
- vec 9y ago
  To my view, collecting and storing that much information is presumptively immoral. It creates a public hazard, in the same vein as stockpiling explosives or toxic chemicals. There is, however, a degree of respect for that hazard, demonstrated in concrete safety practices, that can override that presumption. I don't think Equifax has demonstrated that respect. To a layman's view, not many companies do. It's possible that the amount of respect necessary for a hazard as large as the one Equifax created is too onerous for a for-profit entity to realistically implement, but I don't know that there's a fundamental reason that sufficiently paranoid engineering practices couldn't make this moral.

plandis 9y ago

Failed to patch in a prompt manor. Waited to disclose the issue to the public. Set up a credit monitoring service that was insecure and would auto charge you (the auto charge was dropped after people were outraged). The CEO blamed the whole thing on one person (and that person was not him). What part of that doesn't seem like a moral failure?