5 ms·

Uh, no. The purpose of a security team is to prevent data from being exfiltrated from the company's control. Passwords, PII, HIPPA/other-compliance-controlled s

Uh, no. The purpose of a security team is to prevent data from being exfiltrated from the company's control. Passwords, PII, HIPPA/other-compliance-controlled stuff, source code, etc. are all at risk of being stolen at all times, which means that security is a game of constant vigilance. And since everybody has at least a bit of this data under their control, this means that everybody is involved with security. (At least two of my past employers have had the motto, "Everybody is on the security team.") Productivity means nothing in the face of data exfiltration. You only have to fail once at guarding a password in order to be completely compromised. If we seem tightly wound, it's because we have fully internalized and grok the stakes of our efforts and the entailment of failure. "Our infrastructure sucked, so I used an insecure tool to leak our credentials to third parties, because I couldn't be productive otherwise!" is not really a valid excuse in this light, since there's no amount of productivity which offsets data exfiltration.

vidarh 9y ago
None of that matters to the company if in protecting it you tie staffs hands sufficient behind their back that the company fails. And you harm security if you're being sufficiently inflexible that staff see it as essential to circumvent your security measures to be able to do their job. Because they will almost certainly manage to do so. As such, if you hurt productivity enough, you are also going to be failing at protecting company data by making people find alternative solutions, and you're not likely to get permission to go far enough to stop it unless you're working in a field where security clearance is the norm.
dsr_ 9y ago
You're both right. If the dev team needs something like ngrok, the security team has failed to provide proper tools. If the dev team goes ahead and uses ngrok without consulting the security team, the dev team has likely committed an awful security breach. The dev team and the security team need to think of each other as being on the same team, and talk to each every day about what they want and need.
- icedchai 9y ago
  Pretty sure a lot of people using this don't even have a "security team." They likely have corporate IT that takes 2 weeks to add a DNS entry. Something complex like mapping a public IP to a dev server would take an act of $DEITY.
  - philsnow 9y ago
    so register a new domain and set it up in route53? is there some corporate law that says you can't? just don't use your company's name in the domain name, make it something obscure.
    - icedchai 9y ago
      Agreed. I personally don't have this problem. I have all my externally accessible dev servers on AWS. However, others are not so lucky.
lojack 9y ago
That mindset, while successful from the security perspective, can result in the slow death by strangulation. Ensuring the success of a company should always be your #1 priority, security is an important piece in ensuring the success of a company, but it isn't the only piece. If you're dismissing it as a security nightmare without considering why someone would want to use it and trying to figure out how to make it work or come up with alternatives, then you're failing your mission IMO. There's ways of securing ngrok... you can self host, put it behind a firewall, and whitelist services. It may still open a potential attack vector, but so does the mere existence of connecting to the internet. It's a balancing act, we should all be familiar with.

vidarh 9y ago

None of that matters to the company if in protecting it you tie staffs hands sufficient behind their back that the company fails. And you harm security if you're being sufficiently inflexible that staff see it as essential to circumvent your security measures to be able to do their job. Because they will almost certainly manage to do so. As such, if you hurt productivity enough, you are also going to be failing at protecting company data by making people find alternative solutions, and you're not likely to get permission to go far enough to stop it unless you're working in a field where security clearance is the norm.

dsr_ 9y ago

You're both right. If the dev team needs something like ngrok, the security team has failed to provide proper tools. If the dev team goes ahead and uses ngrok without consulting the security team, the dev team has likely committed an awful security breach. The dev team and the security team need to think of each other as being on the same team, and talk to each every day about what they want and need.

icedchai 9y ago
Pretty sure a lot of people using this don't even have a "security team." They likely have corporate IT that takes 2 weeks to add a DNS entry. Something complex like mapping a public IP to a dev server would take an act of $DEITY.
- philsnow 9y ago
  so register a new domain and set it up in route53? is there some corporate law that says you can't? just don't use your company's name in the domain name, make it something obscure.
  - icedchai 9y ago
    Agreed. I personally don't have this problem. I have all my externally accessible dev servers on AWS. However, others are not so lucky.

lojack 9y ago

That mindset, while successful from the security perspective, can result in the slow death by strangulation. Ensuring the success of a company should always be your #1 priority, security is an important piece in ensuring the success of a company, but it isn't the only piece. If you're dismissing it as a security nightmare without considering why someone would want to use it and trying to figure out how to make it work or come up with alternatives, then you're failing your mission IMO. There's ways of securing ngrok... you can self host, put it behind a firewall, and whitelist services. It may still open a potential attack vector, but so does the mere existence of connecting to the internet. It's a balancing act, we should all be familiar with.