14 ms·

I believe Zoom's continued struggle represents the state of software development in 2020. 1. Are you a software engineer? 2. How many "security" tickets have

I believe Zoom's continued struggle represents the state of software development in 2020. 1. Are you a software engineer? 2. How many "security" tickets have you been assigned in your career? 3. Has your employer ever paid for security training for you? (and I'm not talking about annoying powerpoint websites that teach you how to identify phishing emails) 4. Has your organization ever run a blue team / red team exercise? 5. Who is in charge of APPLICATION SECURITY at your company? (Not network security, or database security, but actual APPLICATION level vulns) 6. Does your organization scan for outdated dependencies? (Do you uncover CVEs in your software on your own, or do you check how bad things are when the news tells you something big happened and might be in your stack?) 7. Are you running a web application, and have you implemented ANY security headers? 8. Did your business unit mandate that "we support all browsers", so they still have you running on TLS v1.1? (who tf knows, or cares, am I right?) 9. Do you use the software you built? (Is your personal information in the database, along with legitimate usage stats, and possibly sensitive information you'd like to protect, or do you just write the code and deploy into the void?) 10. Do you have access to the production systems or database? (Most likely the answer is NO, so you wouldn't know about brute-force attacks, invalid requests, corrupted data, or other anomalies the developers should have their eyes on). My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. My recommendation; use the least amount of software you can get by with, and assume it's compromised.

ziddoap 6y ago
I fully agree with your sentiment, but the specific issues discussed here (having a maximum password length of 10, silently truncating passwords, silently replacing non-ASCII with '?', setting default passwords to 6 numbers, not rate-limiting password attempts) are not things that require a red team / blue team to figure out. They aren't things that require scanning dependencies, auditing source-code, etc. These should be as basic as not storing cleartext passwords.
- FabHK 6y ago
  Agreed. Yes, the state of InfoSec is bad in most companies, but with Zoom it is really abysmal. World class super bad.
- dathinab 6y ago
  > having a maximum password length of 10, silently truncating passwords, silently replacing non-ASCII with '?', setting default passwords to 6 numbers, not rate-limiting password attempts Most newly CS students would know better then to do this or at least would know they have to properly look this up. It's sometimes hard to believe major stupid things like this are done accidentally. (But I know very well how they happen accidentally, it starts with some bug somewhere with non-us-ASCII/to long and similar, then it's constrained "temporary" and put on a must fix list but that list never gets any priority ever, things like this are sadly supper common. As long as companies don't get legally hold responsible for negligence this won't ever go away.)
  - fendy3002 6y ago
    I believe it's company / business level decision. 6 to 10 length numeric password is easy to remember. And non rate limiting enables older, non tech savvy users to have as many error as they want. But the password complexity, rate limiting and other security measurements are there for a reason, and whoever cannot learn from history are doomed to repeat it.
    - winsome 6y ago
      Rate-limiting has nothing to do with the older, non-tech savvy users. You're thinking of maximum failed attempts. Rate-limiting is about preventing bots from spamming an API call.
      - fendy3002 6y ago
        Oh correct, it's as you've said.
- mac-chaffee 6y ago
dec0dedab0de 6y ago
11. Do you think exploits are cool? Do you keep up to date on types of exploits, at least at a high level, just because you want to know about them?
- pnine 6y ago
  I’m a front end engineer. I go to Defcon, i read CVEs and exploit news. It’s a hobby but I feel like it also helps to bring a different perspective into the application world because my peers don’t seem to care much.
cmeacham98 6y ago
> (Most likely the answer is NO, so you wouldn't know about brute-force attacks, invalid requests, corrupted data, or other anomalies the developers should have their eyes on). I would be much more worried about security if the developers had access to the production environment than if they didn't.
- alasdair_ 6y ago
  I once worked for a fortune 500 that blocked all but a few unix sysadmins from executing shell commands on prod servers. So far, so good. The issue was that the “sysadmins” knew almost nothing about how anything worked, so the procedure was that the devs would give them commands to type and they would just type them in to a terminal. Of course, if anything went wrong, or was ambiguous, the dev would need to check on it, and would end up standing next to the “sysadmin”’s desk and just telling them which characters to type. I once had to explain what a pipe character was... Anyway, the end result was that all of the devs had prod access, they just had a very slow interface to it.
  - pvtmert 6y ago
    I'm system engineer in a decent company. I wish devs could access to prod systems so they have to get to cleanup their mess / get responsible for actions they do... They already have access to staging and preprod what they do is basically coming to me and saying 'it did run well on their macos machine' There are outliers, some few good people and some random people having no idea what they are doing. IMHO there should be random quiz/task/test each day you login. Something obvious but not trivial at the same time related with domain of the system. So you would get 24h access if you pass, get denied for 3 hours if fail. 3 questions in each session... At least people might learn something out of requirement...
  - henryfjordan 6y ago
    > Anyway, the end result was that all of the devs had prod access, they just had a very slow interface to it. They also had a person who could see if the dev was stalking an ex-girlfriend or pilfering bank account info. Sounds perfect.
Bnshsysjab 6y ago
11. Do you audit third party libraries for security, malicious intent, and longevity?
- hinkley 6y ago
  11.a: Do you even know if the libraries you are shipping are the official versions?
- dathinab 6y ago
  I try do so. But non properly, i.e. I at least skim third party libraries as long as viable. I have more then one time stumbled about some "wtf is this" thing in libraries which seem to be very good/well maintained/etc. Things included: - Setting socket options which are both unnecessary and cause bugs (like non blocking flag on a socket which is used as if in blocking mode without having non-blocking support in that library). - Not properly clearing secrets while advertising to do so. (I.e. writing zeros without using volatile write or similar, not supper will known but authors of hashing libs can be expected to know better). - Less obvious Memory leaks. - Major logic flaws in the application logic which should easily have been cough by tests, except that the tests didn't really test anything. (Through ironically not security flaws.) - Libraries pretending to support X but only correctly support that common special limited usage of X while having code for full X support but all buggy and 100% unusable outside of the common special case. - EDIT: Fundamental design flaws in supposedly state of the art, supper fast, supper reliable web framework which makes it not so fast and not so reliable in many real work use-cases under load. - etc. It's sometimes really sad.
  - Bnshsysjab 6y ago
    I would love to see public code reviews of open source projects to highlight this kind of stuff but actually having a community driven effort requires a central vendor to support it cleanly. GitHub/gitlab: I’m looking at you.
    - Polylactic_acid 6y ago
      The problem is so much of what we use is not a community effort but the work of a single person in their free time unpaid. So you might do a big review of all the things you find weird and then the maintainer will say "eh, I don't have the time or desire to rewrite all of this" And fair enough, why should they accept all this extra unpaid work. I'm not sure what the solution is but it probably involves companies getting more active in the development of all the stuff they depend on especially when its not some mega project like linux or postgres.
pwdisswordfish2 6y ago
You forgot the key word: modern. %s/software/modern &/g In 2020, you are an "engineer" writing "modern" software. Don't forget the "updates"!
d4mi3n 6y ago
You touch on another important issue I don't see a lot of discussion about: There is a HUGE demand for application security engineers, or more broadly, security folks with software engineering backgrounds. I'm in SecEng and was laid off when my company's regional office went under. It's become pretty obvious to me that there's a huge need for security minded engineers, and most applicants companies get for "Application Security Engineer" roles don't have any experience or background as SWEs. I'm of the opinion that the industry needs to do a few things to help get traction on the problem: 1. Open up career paths that allow SWEs to move from product develop to technical security 2. Have companies better advertise their need for skilled technical security talent 3. Have InfoSec teams perform more cross team exercises. I've never met an engineer who wasn't all for participating in a red/blue team exercise. It's a fantastic way to cross-train and raise awareness.
- gwittel 6y ago
  Absolutely this. Many engineers simply lack security mindedness or secure development training. Similarly, many managers/PMs/etc have gaps here as well. Its important for them to understand how to ask effective questions and prioritize security work accordingly. I've run into many stupid security mistakes, and continue to do so :(. Even though security can be very hard, as an industry we'd be way better off if more understood at least the basics. Those with interest/expertise can then dive in and find the more tricky things. Those without, can at least understand WHY these things are important.
- netsectoday 6y ago
  From my experience; there is a huge NEED for app sec engineers, but the DEMAND isn't really there. Even if you find an organization that DEMANDs a security engineer (rare); that professional has an uphill battle to be granted the resources, time, and power to make meaningful change.
  - d4mi3n 6y ago
    You make a good point. Let me revise my original statement: There is a huge market for security engineers. I'm interviewing in SF with ~8 years of product engineering experience and ~2 years of AppSec/SecEng experience. I'm looking at 8 companies that are all willing to pay well for folks to do that work. Typically in range of ~180 - 220k base salary from what I've seen so far. On the topic of meaningful change: You're absolutely correct in that it's easy for folks in security to find themselves in places where they identify work that needs to happen without receiving support or authority to make it happen. For aspiring technical security folks, there's a few things you can screen for to avoid companies that will do this to you: 1. Does the company have a formal CSIO (Chief Information Security Officer)? If not, move on. CSIOs represent security risks and needs to your executives and board members. Without that, you won't see security work get on anybody's road maps. 2. Does the company have an established security program? If not, do they have a roadmap for making one? 3. What is the size of the technical security team compared to the larger engineering organization? There's no bad ratio here, but the smaller the ratio is, the more critical it is to automate as much as possible. 4. What training programs exist within the larger engineering organization? Do they cover security awareness? Technical security? How well is this program executed? A good training program is critical to reducing new work created for security teams that are typically overloaded to begin with. There's probably more you can look for here, but I find these questions to be reasonable filters.
jdironman 6y ago
Commenting to save to show my employer.
- netsectoday 6y ago
  Hell yes! Good luck! https://www.psychologytoday.com/us/blog/some-assembly-required/201703/how-have-difficult-conversations https://www.psychologytoday.com/us/blog/some-assembly-requir...
tristor 6y ago
> My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. I do not agree, but I am biased. I'm a former engineer with a security focus that is now a product manager. I think a more honest take is that security has never been a priority outside of some specialized use cases/industries and that didn't improve as software development moved from something esoteric to something which is business critical in every industry vertical. Even in industry verticals where security is theoretically a priority and a lot of money is spent on security, most of the "security" people don't actually know anything about security and most of the work is box-checking for compliance audits. You can only do so much and if we're being real security will always compete with other development priorities and the ones which drive revenue always win in any for profit enterprise which creates software as a core competency and the ones which reduce cost always win in any for profit enterprise where software creation is not their core function. Tech is either a product/revenue driver, or it's a cost center, and in both cases security adds additional expense, overhead, and time to release timelines which doesn't pass the PHB smell test. The other big issue is that security doesn't have strong advocates in most organizations because even the most technical people in most organizations are security illiterate, even in the tech industry vertical. As a SWE at most companies you're a "security genius" if you use a password manager and know how to generate a CSR with OpenSSL or configure Let's Encrypt. Maybe I'm overly cynical, but I've largely given up on seeing most companies pursue security with the passion and commitment necessary and see policy as the proper way to address these concerns. I applaud things like HITRUST CSF, which is strongly prescriptive and helps drive security in industries where every single company is full of box-checkers who like to buy appliances. I've been fortunate enough to work at companies that take security seriously and appreciate my background and as a product manager I have always considered user security and privacy to be critical and core components of UX in my products. So, I wouldn't blame the PMs, I'd blame the realities of doing business combined with the lack of adequate security literacy across the board in every industry vertical and at every technical role level.
sloshnmosh 6y ago
“ My recommendation; use the least amount of software you can get by with” So, developers shouldn’t shovel a bunch of third-party advertising SDK’s into their apps? That’s just crazy talk. /s
rglover 6y ago
You're right, and it all stems from impatience and a culture of do-it-later-ism. Nearly every single project I've worked on directly or indirectly has had problems (involving security or otherwise) that could have been fixed by a more patient management. The best thing to learn as an engineer at any level: "rushing makes messes."
- zrobotics 6y ago
  Like pretty much any other worthwhile endeavor in life, the same rule applies: 1) Good 2) Fast 3) Cheap Normally, you can pick one. If you are exceptionally lucky, 2. No project is ever all 3 at once, if anyone thinks so for a given project that is a sure sign of either delusion or inadequate ability to judge (after all, good is very subjective).
jSully24 6y ago
> My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. Sorry, calling BS on this one. You’re calling out an entire group when, like most things, it’s a subset of the broader group. Good PMs understand that a complete product is not just new fancy features but a combination of Features, tech debt work, security and more. At the end of the day if our customers aren’t secure, we’re in trouble. I’ve been on both teams. Once watching a PM stand n the midst of my engineering team proclaiming “I don’t give an F about your technical debt, when will my features be done?” And now I lead a product management team. Great companies have Product and Engineering trusting each other and working together. They may disagree from time to time, but they deliver together and work together to balance what gets done.
- kfarr 6y ago
  Yeah I like everything about that comment except for the line about PMs.
  - jSully24 6y ago
    Agree.
young_unixer 6y ago
From a purely economic point of view: if the end user doesn't care about security, then why bother having security? Regarding users caring about security, there's three possibilities: - Users should care about security but they don't because they're dumb/ignorant. - Users don't care about security because it's not worth the cost/it doesn't affect them, so they're right in not caring (they have 'nothing to hide'). - Some combination of them.
- ravenstine 6y ago
  Because they don't know that they care. They only will when they find their credit has been stolen, or their identity. Having security upfront is doing the right thing so that the industry doesn't become overly regulated.
jjav 6y ago
> the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. This is a good observation, it summarizes very well my feeling on what is wrong with the industry today. In the 90s in many (most?) companies where the product was tech, engineering was in charge of engineering decisions. This meant that feature requests had to pass a sanity filter which would discard or transform ideas which would compromise the soundness of the security, stability, maintainability and other core architectural considerations. Today, engineering is reduced to fungible user story jira ticket implementors with no decision making power so the more abstract (to PMs) work such as security will get no attention except as a crisis when it generates bad PR. (source: working as a security-focused eng/architect since the 90s, on both product engineering and infosec sides.)
robviren 6y ago
Product management is at the mercy of the business. Until the potential financial pain of having poor security is well understood at the leadership level they will never change direction. Improved security is the least attractive thing to have on a roadmap. Sales, marketing, and the business pretty much roll their collective eyes at the concept because it gives them nothing. Marketing a product as more secure is begging for someone to prove you wrong, and it is so hard to prove what would have happened if you did not make something more secure.
- chii 6y ago
  >financial pain of having poor security is well understood at the leadership level they will never change direction. is there financial pain? Is zoom losing money over these security issues? or is paying to fix them going to cost more than the offset in losses they would've had?
  - netsectoday 6y ago
    "Cost externalizing is a socioeconomic term describing how a business maximizes its profits by off-loading indirect costs and forcing negative effects to a third party. An externalized cost is known to economists as a negative externality." Here's our culprit. There IS financial pain but most of it is externalized onto the customers in unseen ways. What is it worth to someone to compromise a specific Zoom meeting? Add up all of the tangible and intangible losses Zoom customers have suffered from data leakage and there is the real cost in the market. The price Zoom pays to fix another bug, maybe write a blog post, and have a few accounts closed is a small fraction of this full cost to society. This is probably the strongest argument for regulation such as GDPR.
still_grokking 6y ago
I can set two check marks. I'm in finance, working on back-end systems used by banks. :-D >My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. Jop, that nails it. Software engineers are treated sometimes like children, sometimes like being crackbrained even, but almost never as the highly educated experts they are (or should be, if there wouldn't be so much botchers around also, which for sure causes to some degree the mentioned problem). Engineering decisions can often be overridden by management no matter what. The result are the usual "catastrophes" repeating over and over everywhere. But as long as this "catastrophes" (like breaches with exfiltration of user data) "require" mostly only a "pardon blog-post" from some executive but don't have any really hurting (financial!) consequences this won't change I guess. If there are costs the insurance will cover them usually. And you need to have and pay the insurance anyway, so why care further? Product management doesn't optimize for security. They optimize costs. Which as such is not wrong or so! If the incentives would be set by the market provider (the state) correctly the same mechanics could easily lead to improved security. I know many don't like to hear this but imho this industry needs stronger regulation. Without regulation nothing will change as on a free marked the "cheapest" product wins. And it will be (or is, as we can currently see) "cheap" in any dimension. "Worse is better" is a direct result of the fact that the "cheapest stuff" prevail in the long run. >My recommendation; use the least amount of software you can get by with, and assume it's compromised. Quite depressed recommendation and fatalistic viewpoint. But to be honest, after so many years in software this could have been my words. And as I see it: Without true political will this conclusion won't change on it's own.
- netsectoday 6y ago
  Who's your employer? ;)

ziddoap 6y ago

I fully agree with your sentiment, but the specific issues discussed here (having a maximum password length of 10, silently truncating passwords, silently replacing non-ASCII with '?', setting default passwords to 6 numbers, not rate-limiting password attempts) are not things that require a red team / blue team to figure out. They aren't things that require scanning dependencies, auditing source-code, etc. These should be as basic as not storing cleartext passwords.

FabHK 6y ago
Agreed. Yes, the state of InfoSec is bad in most companies, but with Zoom it is really abysmal. World class super bad.
dathinab 6y ago
> having a maximum password length of 10, silently truncating passwords, silently replacing non-ASCII with '?', setting default passwords to 6 numbers, not rate-limiting password attempts Most newly CS students would know better then to do this or at least would know they have to properly look this up. It's sometimes hard to believe major stupid things like this are done accidentally. (But I know very well how they happen accidentally, it starts with some bug somewhere with non-us-ASCII/to long and similar, then it's constrained "temporary" and put on a must fix list but that list never gets any priority ever, things like this are sadly supper common. As long as companies don't get legally hold responsible for negligence this won't ever go away.)
- fendy3002 6y ago
  I believe it's company / business level decision. 6 to 10 length numeric password is easy to remember. And non rate limiting enables older, non tech savvy users to have as many error as they want. But the password complexity, rate limiting and other security measurements are there for a reason, and whoever cannot learn from history are doomed to repeat it.
  - winsome 6y ago
    Rate-limiting has nothing to do with the older, non-tech savvy users. You're thinking of maximum failed attempts. Rate-limiting is about preventing bots from spamming an API call.
    - fendy3002 6y ago
      Oh correct, it's as you've said.
mac-chaffee 6y ago

dec0dedab0de 6y ago

11. Do you think exploits are cool? Do you keep up to date on types of exploits, at least at a high level, just because you want to know about them?

pnine 6y ago
I’m a front end engineer. I go to Defcon, i read CVEs and exploit news. It’s a hobby but I feel like it also helps to bring a different perspective into the application world because my peers don’t seem to care much.

cmeacham98 6y ago

> (Most likely the answer is NO, so you wouldn't know about brute-force attacks, invalid requests, corrupted data, or other anomalies the developers should have their eyes on). I would be much more worried about security if the developers had access to the production environment than if they didn't.

alasdair_ 6y ago
I once worked for a fortune 500 that blocked all but a few unix sysadmins from executing shell commands on prod servers. So far, so good. The issue was that the “sysadmins” knew almost nothing about how anything worked, so the procedure was that the devs would give them commands to type and they would just type them in to a terminal. Of course, if anything went wrong, or was ambiguous, the dev would need to check on it, and would end up standing next to the “sysadmin”’s desk and just telling them which characters to type. I once had to explain what a pipe character was... Anyway, the end result was that all of the devs had prod access, they just had a very slow interface to it.
- pvtmert 6y ago
  I'm system engineer in a decent company. I wish devs could access to prod systems so they have to get to cleanup their mess / get responsible for actions they do... They already have access to staging and preprod what they do is basically coming to me and saying 'it did run well on their macos machine' There are outliers, some few good people and some random people having no idea what they are doing. IMHO there should be random quiz/task/test each day you login. Something obvious but not trivial at the same time related with domain of the system. So you would get 24h access if you pass, get denied for 3 hours if fail. 3 questions in each session... At least people might learn something out of requirement...
- henryfjordan 6y ago
  > Anyway, the end result was that all of the devs had prod access, they just had a very slow interface to it. They also had a person who could see if the dev was stalking an ex-girlfriend or pilfering bank account info. Sounds perfect.

Bnshsysjab 6y ago

11. Do you audit third party libraries for security, malicious intent, and longevity?

hinkley 6y ago
11.a: Do you even know if the libraries you are shipping are the official versions?
dathinab 6y ago
I try do so. But non properly, i.e. I at least skim third party libraries as long as viable. I have more then one time stumbled about some "wtf is this" thing in libraries which seem to be very good/well maintained/etc. Things included: - Setting socket options which are both unnecessary and cause bugs (like non blocking flag on a socket which is used as if in blocking mode without having non-blocking support in that library). - Not properly clearing secrets while advertising to do so. (I.e. writing zeros without using volatile write or similar, not supper will known but authors of hashing libs can be expected to know better). - Less obvious Memory leaks. - Major logic flaws in the application logic which should easily have been cough by tests, except that the tests didn't really test anything. (Through ironically not security flaws.) - Libraries pretending to support X but only correctly support that common special limited usage of X while having code for full X support but all buggy and 100% unusable outside of the common special case. - EDIT: Fundamental design flaws in supposedly state of the art, supper fast, supper reliable web framework which makes it not so fast and not so reliable in many real work use-cases under load. - etc. It's sometimes really sad.
- Bnshsysjab 6y ago
  I would love to see public code reviews of open source projects to highlight this kind of stuff but actually having a community driven effort requires a central vendor to support it cleanly. GitHub/gitlab: I’m looking at you.
  - Polylactic_acid 6y ago
    The problem is so much of what we use is not a community effort but the work of a single person in their free time unpaid. So you might do a big review of all the things you find weird and then the maintainer will say "eh, I don't have the time or desire to rewrite all of this" And fair enough, why should they accept all this extra unpaid work. I'm not sure what the solution is but it probably involves companies getting more active in the development of all the stuff they depend on especially when its not some mega project like linux or postgres.

pwdisswordfish2 6y ago

You forgot the key word: modern. %s/software/modern &/g In 2020, you are an "engineer" writing "modern" software. Don't forget the "updates"!

d4mi3n 6y ago

You touch on another important issue I don't see a lot of discussion about: There is a HUGE demand for application security engineers, or more broadly, security folks with software engineering backgrounds. I'm in SecEng and was laid off when my company's regional office went under. It's become pretty obvious to me that there's a huge need for security minded engineers, and most applicants companies get for "Application Security Engineer" roles don't have any experience or background as SWEs. I'm of the opinion that the industry needs to do a few things to help get traction on the problem: 1. Open up career paths that allow SWEs to move from product develop to technical security 2. Have companies better advertise their need for skilled technical security talent 3. Have InfoSec teams perform more cross team exercises. I've never met an engineer who wasn't all for participating in a red/blue team exercise. It's a fantastic way to cross-train and raise awareness.

gwittel 6y ago
Absolutely this. Many engineers simply lack security mindedness or secure development training. Similarly, many managers/PMs/etc have gaps here as well. Its important for them to understand how to ask effective questions and prioritize security work accordingly. I've run into many stupid security mistakes, and continue to do so :(. Even though security can be very hard, as an industry we'd be way better off if more understood at least the basics. Those with interest/expertise can then dive in and find the more tricky things. Those without, can at least understand WHY these things are important.
netsectoday 6y ago
From my experience; there is a huge NEED for app sec engineers, but the DEMAND isn't really there. Even if you find an organization that DEMANDs a security engineer (rare); that professional has an uphill battle to be granted the resources, time, and power to make meaningful change.
- d4mi3n 6y ago
  You make a good point. Let me revise my original statement: There is a huge market for security engineers. I'm interviewing in SF with ~8 years of product engineering experience and ~2 years of AppSec/SecEng experience. I'm looking at 8 companies that are all willing to pay well for folks to do that work. Typically in range of ~180 - 220k base salary from what I've seen so far. On the topic of meaningful change: You're absolutely correct in that it's easy for folks in security to find themselves in places where they identify work that needs to happen without receiving support or authority to make it happen. For aspiring technical security folks, there's a few things you can screen for to avoid companies that will do this to you: 1. Does the company have a formal CSIO (Chief Information Security Officer)? If not, move on. CSIOs represent security risks and needs to your executives and board members. Without that, you won't see security work get on anybody's road maps. 2. Does the company have an established security program? If not, do they have a roadmap for making one? 3. What is the size of the technical security team compared to the larger engineering organization? There's no bad ratio here, but the smaller the ratio is, the more critical it is to automate as much as possible. 4. What training programs exist within the larger engineering organization? Do they cover security awareness? Technical security? How well is this program executed? A good training program is critical to reducing new work created for security teams that are typically overloaded to begin with. There's probably more you can look for here, but I find these questions to be reasonable filters.

jdironman 6y ago

Commenting to save to show my employer.

netsectoday 6y ago
Hell yes! Good luck! https://www.psychologytoday.com/us/blog/some-assembly-required/201703/how-have-difficult-conversations https://www.psychologytoday.com/us/blog/some-assembly-requir...

tristor 6y ago

> My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. I do not agree, but I am biased. I'm a former engineer with a security focus that is now a product manager. I think a more honest take is that security has never been a priority outside of some specialized use cases/industries and that didn't improve as software development moved from something esoteric to something which is business critical in every industry vertical. Even in industry verticals where security is theoretically a priority and a lot of money is spent on security, most of the "security" people don't actually know anything about security and most of the work is box-checking for compliance audits. You can only do so much and if we're being real security will always compete with other development priorities and the ones which drive revenue always win in any for profit enterprise which creates software as a core competency and the ones which reduce cost always win in any for profit enterprise where software creation is not their core function. Tech is either a product/revenue driver, or it's a cost center, and in both cases security adds additional expense, overhead, and time to release timelines which doesn't pass the PHB smell test. The other big issue is that security doesn't have strong advocates in most organizations because even the most technical people in most organizations are security illiterate, even in the tech industry vertical. As a SWE at most companies you're a "security genius" if you use a password manager and know how to generate a CSR with OpenSSL or configure Let's Encrypt. Maybe I'm overly cynical, but I've largely given up on seeing most companies pursue security with the passion and commitment necessary and see policy as the proper way to address these concerns. I applaud things like HITRUST CSF, which is strongly prescriptive and helps drive security in industries where every single company is full of box-checkers who like to buy appliances. I've been fortunate enough to work at companies that take security seriously and appreciate my background and as a product manager I have always considered user security and privacy to be critical and core components of UX in my products. So, I wouldn't blame the PMs, I'd blame the realities of doing business combined with the lack of adequate security literacy across the board in every industry vertical and at every technical role level.

sloshnmosh 6y ago

“ My recommendation; use the least amount of software you can get by with” So, developers shouldn’t shovel a bunch of third-party advertising SDK’s into their apps? That’s just crazy talk. /s

rglover 6y ago

You're right, and it all stems from impatience and a culture of do-it-later-ism. Nearly every single project I've worked on directly or indirectly has had problems (involving security or otherwise) that could have been fixed by a more patient management. The best thing to learn as an engineer at any level: "rushing makes messes."

zrobotics 6y ago
Like pretty much any other worthwhile endeavor in life, the same rule applies: 1) Good 2) Fast 3) Cheap Normally, you can pick one. If you are exceptionally lucky, 2. No project is ever all 3 at once, if anyone thinks so for a given project that is a sure sign of either delusion or inadequate ability to judge (after all, good is very subjective).

jSully24 6y ago

> My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. Sorry, calling BS on this one. You’re calling out an entire group when, like most things, it’s a subset of the broader group. Good PMs understand that a complete product is not just new fancy features but a combination of Features, tech debt work, security and more. At the end of the day if our customers aren’t secure, we’re in trouble. I’ve been on both teams. Once watching a PM stand n the midst of my engineering team proclaiming “I don’t give an F about your technical debt, when will my features be done?” And now I lead a product management team. Great companies have Product and Engineering trusting each other and working together. They may disagree from time to time, but they deliver together and work together to balance what gets done.

kfarr 6y ago
Yeah I like everything about that comment except for the line about PMs.
- jSully24 6y ago
  Agree.

young_unixer 6y ago

From a purely economic point of view: if the end user doesn't care about security, then why bother having security? Regarding users caring about security, there's three possibilities: - Users should care about security but they don't because they're dumb/ignorant. - Users don't care about security because it's not worth the cost/it doesn't affect them, so they're right in not caring (they have 'nothing to hide'). - Some combination of them.

ravenstine 6y ago
Because they don't know that they care. They only will when they find their credit has been stolen, or their identity. Having security upfront is doing the right thing so that the industry doesn't become overly regulated.

jjav 6y ago

> the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. This is a good observation, it summarizes very well my feeling on what is wrong with the industry today. In the 90s in many (most?) companies where the product was tech, engineering was in charge of engineering decisions. This meant that feature requests had to pass a sanity filter which would discard or transform ideas which would compromise the soundness of the security, stability, maintainability and other core architectural considerations. Today, engineering is reduced to fungible user story jira ticket implementors with no decision making power so the more abstract (to PMs) work such as security will get no attention except as a crisis when it generates bad PR. (source: working as a security-focused eng/architect since the 90s, on both product engineering and infosec sides.)

robviren 6y ago

Product management is at the mercy of the business. Until the potential financial pain of having poor security is well understood at the leadership level they will never change direction. Improved security is the least attractive thing to have on a roadmap. Sales, marketing, and the business pretty much roll their collective eyes at the concept because it gives them nothing. Marketing a product as more secure is begging for someone to prove you wrong, and it is so hard to prove what would have happened if you did not make something more secure.

chii 6y ago
>financial pain of having poor security is well understood at the leadership level they will never change direction. is there financial pain? Is zoom losing money over these security issues? or is paying to fix them going to cost more than the offset in losses they would've had?
- netsectoday 6y ago
  "Cost externalizing is a socioeconomic term describing how a business maximizes its profits by off-loading indirect costs and forcing negative effects to a third party. An externalized cost is known to economists as a negative externality." Here's our culprit. There IS financial pain but most of it is externalized onto the customers in unseen ways. What is it worth to someone to compromise a specific Zoom meeting? Add up all of the tangible and intangible losses Zoom customers have suffered from data leakage and there is the real cost in the market. The price Zoom pays to fix another bug, maybe write a blog post, and have a few accounts closed is a small fraction of this full cost to society. This is probably the strongest argument for regulation such as GDPR.

still_grokking 6y ago

I can set two check marks. I'm in finance, working on back-end systems used by banks. :-D >My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain. Jop, that nails it. Software engineers are treated sometimes like children, sometimes like being crackbrained even, but almost never as the highly educated experts they are (or should be, if there wouldn't be so much botchers around also, which for sure causes to some degree the mentioned problem). Engineering decisions can often be overridden by management no matter what. The result are the usual "catastrophes" repeating over and over everywhere. But as long as this "catastrophes" (like breaches with exfiltration of user data) "require" mostly only a "pardon blog-post" from some executive but don't have any really hurting (financial!) consequences this won't change I guess. If there are costs the insurance will cover them usually. And you need to have and pay the insurance anyway, so why care further? Product management doesn't optimize for security. They optimize costs. Which as such is not wrong or so! If the incentives would be set by the market provider (the state) correctly the same mechanics could easily lead to improved security. I know many don't like to hear this but imho this industry needs stronger regulation. Without regulation nothing will change as on a free marked the "cheapest" product wins. And it will be (or is, as we can currently see) "cheap" in any dimension. "Worse is better" is a direct result of the fact that the "cheapest stuff" prevail in the long run. >My recommendation; use the least amount of software you can get by with, and assume it's compromised. Quite depressed recommendation and fatalistic viewpoint. But to be honest, after so many years in software this could have been my words. And as I see it: Without true political will this conclusion won't change on it's own.

netsectoday 6y ago
Who's your employer? ;)