Live data from Hacker News

How I learned about corporate firewalls

valcanbuild.tech

181–190 of 204 posts

Re: How I learned about corporate firewalls

#181

Earlier quoted context omitted.

> Developers dont need local admin rights to develop software And now I'm going to quote myself from earlier to make it clear you're displaying exactly the silliness I was speaking to, with added emphasis. "If human beings took the same approach to safety that Security people do to security, they'd insist the wheels on your vehicle should only be able to turn straight and right. That the vehicle should _actively_ pre…

I've been on both sides, was a developer and then security engineer, now back to dev work. I know there are quite a few very well talented engineers, but there are also quite a lot of mediocre developers, including interns, new grads, or startup folks who are used to cowboy style edits directly in production and no tests. You always want to plan your security controls for the weakest link, for the dumbest person, pre…

> Because your machine is tied to AD, email, bunch of other corporate stuff

Most of the time, I genuinely wish it wasn't. There's so much I have access to, that I would never, ever need. And because I have that, I can't access things I actually need.

Just give me a iPad for all the corporate stuff and let me work on an open PC.

Re: How I learned about corporate firewalls

#182

Earlier quoted context omitted.

You must be fun to work with.

Had to deal with too many interns who go to company server and start updating packages and installing random stuff from internet using wget | sudo bash, like it is their college laptop, just to run some of crappy python snippet they found over at Stackoverflow

Why are you giving interns root access to production servers?

Re: How I learned about corporate firewalls

#183

Earlier quoted context omitted.

Some of these "security" products that MiM TLS traffic allow configurations that objectively reduce your security. You can configure Palo Alto devices to accept a self-signed cert from the Internet, but present your trusted MiM cert to the on-site user. Now the user isn't aware that they are the victim of a second MiM outside the organization. The organization also exposes itself to greater liability. E.g., a rogue e…

> but it doesn't prevent intentional exfiltration It can prevent accidental exfiltration, or deliberate exfiltration by a relative incompetent, which are the majority of such problems. You are right in that they will not stop deliberate actions by a competent disgruntled or a competent external attacker who has access (but you have a much wider set of problems in this latter case). Maybe I'm old-fashioned (I am defin…

Does this mean that it's OK for an employer to put cameras in employee bathrooms? The argument can be made that it's not the employers responsibility to provide me with unfettered access to a space to do personal stuff with, just like internet access, so why not?

Re: How I learned about corporate firewalls

#184

Earlier quoted context omitted.

The problem with devs is they think all security admins are reductionist. A good security admin will work within the bounds of compliance to make the business work. And any good blocks will be apparent to the user. Trust me, security doesn't enjoy pissing people off, we just accept that it happens sometimes.

last week a former co-worker called me laughing. He was on the phone with the CISO who was explaining it's impossible to give him access to SPLUNK because of the network segmentation. While he's ON THE PHONE, he received an email from the IT group with credentials to access splunk. And to be clear, I left specifically because of their security stance. I was once told they couldn't automate pulling data from productio…

I'm sorry you're so traumatized by a handful of experiences, and seemingly at only one or two places, that you can't comprehend a workplace or institution with a reasonable security team. They exist. Maybe one day you'll find one.

One of my former employers has developers, network admins and security professionals working together to maintain a deployment pipeline using Github, terraform and AWS to let developers do as much as possible without having to request anything from security, ever. All the guardrails and checks are built in. Labs get to deploy just about anything, test and prod are identical, and prod has implicit restrictions on requiring encryption for data, prohibiting excessively powerful roles, and so on. But they've worked directly with development to get them everything they need ahead of time, in order to make IT and the business as effective as possible.

Security is necessary, and good security does what it can to stay out of the way.

Re: How I learned about corporate firewalls

#185

Earlier quoted context omitted.

I've been on both sides, was a developer and then security engineer, now back to dev work. I know there are quite a few very well talented engineers, but there are also quite a lot of mediocre developers, including interns, new grads, or startup folks who are used to cowboy style edits directly in production and no tests. You always want to plan your security controls for the weakest link, for the dumbest person, pre…

None of the things you're describing are protected by removing local admin rights. That's the point. First you compare the risk of losing limbs to having admin rights, now it's drifting on public streets is like wanting to install python. You can't find anything reasonable because there isn't any.

You havent provided a single valid reason why developer needs admin privilege.

Re: How I learned about corporate firewalls

#186

I work at a government agency and here are my tales. 1) They install a root certificate on all machines and use that to MITM all TLS connections using a firewall appliance. They turn this MITM on one day without notifying any developer. Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have…

The MiM might not be your IT folks, but rather management. I was in a meeting which included folks from Palo Alto (PA) and management where PA was hard selling their ability to MiM all https connections and link all activities of the users to their usernames through various methods from directory integration to log scraping on radius servers. The managers were super excited about the possibilities. Management not onl…

Caught an ex employer using sslstrip and they definitely used bossware. Management would imply they were reading work and personal messages, emails, browsing through thinly veiled threats to workers (self included) and through gossip.

They also used push notifications on the desktops to know when people were active or what they were doing, and had keyloggers installed/active. Once caught a manager's personal laptop on the network running mitm software. A friendly coworker in IT confirmed all of this with me in private.

Tried warning a couple coworkers, but got brushed off. People don't seem to care nor believe even though they're being manipulated.

That place was a nightmare to say the least

Re: How I learned about corporate firewalls

#187

Earlier quoted context omitted.

last week a former co-worker called me laughing. He was on the phone with the CISO who was explaining it's impossible to give him access to SPLUNK because of the network segmentation. While he's ON THE PHONE, he received an email from the IT group with credentials to access splunk. And to be clear, I left specifically because of their security stance. I was once told they couldn't automate pulling data from productio…

I'm sorry you're so traumatized by a handful of experiences, and seemingly at only one or two places, that you can't comprehend a workplace or institution with a reasonable security team. They exist. Maybe one day you'll find one. One of my former employers has developers, network admins and security professionals working together to maintain a deployment pipeline using Github, terraform and AWS to let developers do…

Of course security is necessary, that's not the complaint.

Re: How I learned about corporate firewalls

#188

Earlier quoted context omitted.

None of the things you're describing are protected by removing local admin rights. That's the point. First you compare the risk of losing limbs to having admin rights, now it's drifting on public streets is like wanting to install python. You can't find anything reasonable because there isn't any.

You havent provided a single valid reason why developer needs admin privilege.

Should I quote myself a 3rd time with the analogy pointing out that just because you can get somewhere using only right turns doesn't mean that's how you should do it?

Re: How I learned about corporate firewalls

#189

I work at a government agency and here are my tales. 1) They install a root certificate on all machines and use that to MITM all TLS connections using a firewall appliance. They turn this MITM on one day without notifying any developer. Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have…

Oh, how I have learned the hard way on this. Our IT now blocks outbound SSH entirely . You know, the secure way to access VM's in, say, our cloud? Sigh. I'm sure there's a "jump" server somewhere that I'd have to log into, `sudo` to another account, THEN SSH to my target box. Whatever. I just avoid the VPN. I used to use `cntlm` to tunnel requests through our firewall for things like Ruby's bundler, as it required NT…

The way you brush it off is insane. Using a jumpbox IS more secure. I understand this may cause problems for your workflow (though there are many ways to work within the confines) it sounds like you're stubbornly insisting your way is the best (and therefore most secure) way. This reeks of entitlement. Work with people and stop being a prima donna, you're not above security concerns.

Re: How I learned about corporate firewalls

#190

Earlier quoted context omitted.

> but it doesn't prevent intentional exfiltration It can prevent accidental exfiltration, or deliberate exfiltration by a relative incompetent, which are the majority of such problems. You are right in that they will not stop deliberate actions by a competent disgruntled or a competent external attacker who has access (but you have a much wider set of problems in this latter case). Maybe I'm old-fashioned (I am defin…

Does this mean that it's OK for an employer to put cameras in employee bathrooms? The argument can be made that it's not the employers responsibility to provide me with unfettered access to a space to do personal stuff with, just like internet access, so why not?

Cameras in bathrooms? Complete hyperbole. If you're going to argue, atleast offer logical escalation concerns. day 1, inspect your ssl. day 2, cameras in bathrooms.
Post reply on HN