6 ms·

>needs to be prioritized by management If the attitude of these engineers is "we don't emphasize security unless management tells us to" maybe they don't deser

>needs to be prioritized by management If the attitude of these engineers is "we don't emphasize security unless management tells us to" maybe they don't deserve to be hired elsewhere? Management are not omniscient; they depend on their staff.

sillysaurusx 7y ago
Yeah, that's not how infosec works. You've almost certainly written code that has exposed user information (unless you've written no user-facing code). Are you, as an engineer, going to organize a pentest for the software? Even if you encourage management to do so, it's still up to management to actually book the deal.
- aguyfromnb 7y ago
  >Are you, as an engineer, going to organize a pentest for the software? Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention? See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation.
  - _jal 7y ago
    > Are you, [...] going to sit back and watch the project you built get compromised? How does this work? Do you rip off your glasses, strike a manly pose and run for the data center, stopping only to force the infra team to give you the credentials? More seriously... Organize your own IR tiger team outside of management channels? Congrats, you're unemployed tomorrow, together with anyone silly enough to buy in. Start making rogue code changes you think are appropriate? That would run in to "want[ing] the title without the obligations". Oh, and also probably end up with you unemployed. So, really, what are you proposing?
    - dmix 7y ago
      > Organize your own IR tiger team outside of management channels? This gave me a good laugh, thank you
  - mopsi 7y ago
    > See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation. All engineers make mistakes and misjudgements, even the ones working in long-established fields, as we can see from the 737MAX saga. It's management's job to design a organizational structure that puts enough safeguards in place that mistakes get captured before the product rolls out. That's what management literally means.
  - saber6 7y ago
    > Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention? I'm glad I'm not the only one who feels like this. I nearly got fired by digging my heels in on a privacy/infosec flawed design... until CTO/CIO layer gleaned what I was freaking out about and the energy (angry, "wtf", etc) suddenly pivoted to the original architect and engineers who cooked up some half-baked stuff. You don't want your name attached to bad stuff in life. You only have one reputation. Don't mis-spend your social (political) capital by letting dummies bully you into ignoring tangible security issues.
- eropple 7y ago
  At minimum, I'm going to design a user-facing system as correctly as I am able and to the maximal extent of my abilities, because holding data in trust for a user is a profoundly serious responsibility and it wouldn't be right to do otherwise. And, when user-identifying information is involved, every place I've ever worked has had an understanding that that kind of sensitive work will be done when it's done and they can fire my ass if they don't like it. Whether they've been happy about it or not, nobody has ever tried to fight me over it, let alone take me up on the "fire me" bit. And when it is done, I will endeavor to hit it as absolutely hard as I can to break it. I will advocate for regular penetration tests and audits, and I will throw an absolute goddamned fit when they don't happen. (My current company retains very little personal information and we still put ourselves through a pretty rigorous security audit at least once a year. A measure of "do thou likewise" is fair.) The fun part is I don't even call myself an "engineer", because I'm not and I can't be with the tools and practices I have at my disposal. I'm a software developer, just like about 99.9% of this industry. I just happen to care a little, and I just happen to try to do better.
  - sillysaurusx 7y ago
    The only part that matters is the penetration test bit. And it's out of your control as a rank-and-file engineer. Those who don't accept this are like doctors who don't accept that washing their hands is the important part, not the care and emotional sensitivity that goes into treating a patient.
    - eropple 7y ago
      That's not true. Testing is reinforcement of that competence and that good design, it does not replace it. Relying on penetration tests to secure your systems has an implicit dependency on the completeness of those tests--and putting armor over the bullet holes isn't how you keep a plane in the air.
      - sillysaurusx 7y ago
        A pentest reports findings, and then regardless of how incompetent the programmers are, they are required to fix them. Then a retest happens, which verifies that the findings were fixed. I've seen a trading application go from "typing ' will result inn SQL injection" to "basically bulletproof" due to this process. Devs can become remarkably competent when their smugness is wiped away by finding some crucial vulnerabilities they overlooked. I know it's tempting to believe that the design part matters, but it's also tempting to believe that a doctor's emotional support matters just as much as washing your hands. Do a stint in the pentest industry. It's eye-opening. (Look into my eyes. I've seen things. Terrible... things...)
- tal8d 7y ago
  The AFF back to back breaches were interesting because there were faults to found at every level. * The breach included PII from a property they had already sold, but held onto for some reason. * SHA1. A good choice if you want to slightly inconvenience somebody with a GPU, while also increasing the odds of your hashes getting uploaded in full to one of many distributed cracking projects. * No effective user input validation. The exploit was one step in sophistication beyond those ancient IIS ../../hue.txt attacks. * No attempt at anything resembling principles of least privilege, exec whatever wherever. So, everyone failed - executives to DBAs. Screw pentests, start by implementing best practices that have been around for 40 years.

sillysaurusx 7y ago

Yeah, that's not how infosec works. You've almost certainly written code that has exposed user information (unless you've written no user-facing code). Are you, as an engineer, going to organize a pentest for the software? Even if you encourage management to do so, it's still up to management to actually book the deal.

aguyfromnb 7y ago
>Are you, as an engineer, going to organize a pentest for the software? Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention? See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation.
- _jal 7y ago
  > Are you, [...] going to sit back and watch the project you built get compromised? How does this work? Do you rip off your glasses, strike a manly pose and run for the data center, stopping only to force the infra team to give you the credentials? More seriously... Organize your own IR tiger team outside of management channels? Congrats, you're unemployed tomorrow, together with anyone silly enough to buy in. Start making rogue code changes you think are appropriate? That would run in to "want[ing] the title without the obligations". Oh, and also probably end up with you unemployed. So, really, what are you proposing?
  - dmix 7y ago
    > Organize your own IR tiger team outside of management channels? This gave me a good laugh, thank you
- mopsi 7y ago
  > See, that's the problem with every developer in Silicon Valley calling themselves an "engineer"; they want the title without the obligations that a professional engineer has. "Not my problem" would cost you your designation. All engineers make mistakes and misjudgements, even the ones working in long-established fields, as we can see from the 737MAX saga. It's management's job to design a organizational structure that puts enough safeguards in place that mistakes get captured before the product rolls out. That's what management literally means.
- saber6 7y ago
  > Are you, as an engineer, going to sit back and watch the project you built (containing very personal information in this case) get compromised? Even if you know management isn't paying proper attention? I'm glad I'm not the only one who feels like this. I nearly got fired by digging my heels in on a privacy/infosec flawed design... until CTO/CIO layer gleaned what I was freaking out about and the energy (angry, "wtf", etc) suddenly pivoted to the original architect and engineers who cooked up some half-baked stuff. You don't want your name attached to bad stuff in life. You only have one reputation. Don't mis-spend your social (political) capital by letting dummies bully you into ignoring tangible security issues.
eropple 7y ago
At minimum, I'm going to design a user-facing system as correctly as I am able and to the maximal extent of my abilities, because holding data in trust for a user is a profoundly serious responsibility and it wouldn't be right to do otherwise. And, when user-identifying information is involved, every place I've ever worked has had an understanding that that kind of sensitive work will be done when it's done and they can fire my ass if they don't like it. Whether they've been happy about it or not, nobody has ever tried to fight me over it, let alone take me up on the "fire me" bit. And when it is done, I will endeavor to hit it as absolutely hard as I can to break it. I will advocate for regular penetration tests and audits, and I will throw an absolute goddamned fit when they don't happen. (My current company retains very little personal information and we still put ourselves through a pretty rigorous security audit at least once a year. A measure of "do thou likewise" is fair.) The fun part is I don't even call myself an "engineer", because I'm not and I can't be with the tools and practices I have at my disposal. I'm a software developer, just like about 99.9% of this industry. I just happen to care a little, and I just happen to try to do better.
- sillysaurusx 7y ago
  The only part that matters is the penetration test bit. And it's out of your control as a rank-and-file engineer. Those who don't accept this are like doctors who don't accept that washing their hands is the important part, not the care and emotional sensitivity that goes into treating a patient.
  - eropple 7y ago
    That's not true. Testing is reinforcement of that competence and that good design, it does not replace it. Relying on penetration tests to secure your systems has an implicit dependency on the completeness of those tests--and putting armor over the bullet holes isn't how you keep a plane in the air.
    - sillysaurusx 7y ago
      A pentest reports findings, and then regardless of how incompetent the programmers are, they are required to fix them. Then a retest happens, which verifies that the findings were fixed. I've seen a trading application go from "typing ' will result inn SQL injection" to "basically bulletproof" due to this process. Devs can become remarkably competent when their smugness is wiped away by finding some crucial vulnerabilities they overlooked. I know it's tempting to believe that the design part matters, but it's also tempting to believe that a doctor's emotional support matters just as much as washing your hands. Do a stint in the pentest industry. It's eye-opening. (Look into my eyes. I've seen things. Terrible... things...)
tal8d 7y ago
The AFF back to back breaches were interesting because there were faults to found at every level. * The breach included PII from a property they had already sold, but held onto for some reason. * SHA1. A good choice if you want to slightly inconvenience somebody with a GPU, while also increasing the odds of your hashes getting uploaded in full to one of many distributed cracking projects. * No effective user input validation. The exploit was one step in sophistication beyond those ancient IIS ../../hue.txt attacks. * No attempt at anything resembling principles of least privilege, exec whatever wherever. So, everyone failed - executives to DBAs. Screw pentests, start by implementing best practices that have been around for 40 years.