Hacker News Reader

Comment by ageofwant | Hacker News Reader

If your users have to resort to this they are not getting the appropriate support they need.

If your users are productive, chances are so is the company that pays both your salaries. If your users have to fight their infrastructure people to get their jobs done, you company will fail to effectively compete against those companies that don't.

It astounds me that so few security people understand what their purpose is: Your purpose is to assist the company you work for to keep on existing, and even make a profit. If you disempower those that are most effective in helping the company do what it does you're effectively destroying your own livelihood, and everyone else that is dependent on it.

View on HN

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.

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.

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.

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.

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.

Agreed. I personally don't have this problem. I have all my externally accessible dev servers on AWS. However, others are not so lucky.

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.

> If your users have to resort to this they are not getting the appropriate support they need.

I don't see where this follows from. "private repos" and "testing" implies "local testing" for me. If that implication does not hold, the development workflow is seriously screwed. (Don't tell me there is no money for a local test setup when you have dedicated IT security.)

And in my experience, more often than not, it is screwed because someone decided to use some other flashy tool without realizing the security implications.

If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.

> If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.

Wouldn't that still be the same, considering ngrok is just doing the tunneling. In this case, ngrok is your trusty hoster. You can park your trust into your own VM in Digital Ocean, or you can park it at ngrok.

Reply on news.ycombinator.com