Live data from Hacker News

How I learned about corporate firewalls

valcanbuild.tech

171–180 of 204 posts

Re: How I learned about corporate firewalls

#171

Earlier quoted context omitted.

yeah, lets equate someone getting a limb ripped off with allowing developers to have local admin rights. That's everything that's wrong with the security mindset.

Developers dont need local admin rights to develop software, plenty of devs at regulated industries work with user rights. And statistics of developers falling victim of phish attack, credentials stealing that leads to major breach - there are plenty. The most recent Uber hack or Okta hack - were all tied to developer clicking on stupid stuff, opening executables from Internet and getting his a$$ owned. You just gott…

> 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_ prevent you from turning your wheels left because left turns are more dangerous than right turns and THEY CAN SHOW THAT YOU CAN ALWAYS GET TO YOUR DESTINATION WITH JUST RIGHT TURNS."

---

You see, you can still get to your destination with no left turns, it's just really damned inconvenient and has costs in terms of happiness and time.

It's a classic case of security people making decisions they themselves don't have to pay the cost of.

And don't get me wrong, you'll often hear security people _CLAIM_ they do, in fact, adhere to all of the security practices they insist on. And they may even do so.

But ...

THESE SECURITY PEOPLE ARE NOT DEVELOPERS.

There's no critical thinking in these decisions. A phone agent working in a very specific application all day doesn't need access to the PC the way a developer does.

---

> And statistics of developers falling victim of phish attack, credentials stealing that leads to major breach - there are plenty. The most recent Uber hack or Okta hack - were all tied to developer clicking on stupid stuff, opening executables from Internet and getting his a$$ owned.

uber hackers got through using slack, okta was a technician RDPing in.

Neither were developers, and unless you're prepared to claim slack wasn't sanctioned by the company, it's all just a long worded admission that removing local admin rights didn't actually help.

Then there's the question of, if someone steals a developers credentials, what do they have access to?

THAT is where the rubber hits the road. I've literally seen the following:

- Disallow developers from running powershell, but they can log directly into DB's with PII and PHI data ("they had a legitimate business need").

- Force developers making 6-figure salaries to "request access" for admin or the installation of software, said requests being granted by support teams of people making a little over minimum wage.

There's a reason why so many people call it security theatre.

> You just gotta accept the fact that developers are not security specialists, most of them cant even create a software without introducing plenty of bugs and vulnerabilities. They mostly google stuff and copypaste from stackoverflow, install shady barely working packages and copypaste directly into production whatever code snippet they found on the first page of Google results. Thats why they need extra control from security specialists

The reason your company is full of such developers is because you took away local admin rights and the ones with options left. You don't even have any left who could mentor the ones that need mentoring, they left too.

Put yourselves in the shoes of that developer who can access PHI at will, but cannot update their Visual Studio in the name of security because it requires local admin rights to do so.

Re: How I learned about corporate firewalls

#172
post #37

I wonder what _showHtmlPage_ does? Did he just write something, something that allows 3rd party (corporate firewalls) inject HTML under his domain within TLS protected connection? Cannot judge by not knowing how he displays errors. But a question to HN public: Is opening unknown HTML under my domain within another window safe? Or is there any possibility to strip down any "permissions" to cookies, requests, resources…

OP here - I'm open to advice about how best to handle this! I'm currently just opening a new window and writing the HTML to it. What's the safest way to handle this? Open it in an iframe?

Just look under this thread, I wrote one possible solution of using .innerText from constructed DOM. (Or maybe open window in another domain). However @repiret may be right - corporate proxy is already invasive enough, that means the users are already in mercy of those.

But still, I'd go with safer practices. Even in the slightly unlikely case someone manages to hack 3rd party (Stripe) and send your users arbitrary HTML for some periods of time... :)

Re: How I learned about corporate firewalls

#173
post #172

Earlier quoted context omitted.

OP here - I'm open to advice about how best to handle this! I'm currently just opening a new window and writing the HTML to it. What's the safest way to handle this? Open it in an iframe?

Just look under this thread, I wrote one possible solution of using .innerText from constructed DOM. (Or maybe open window in another domain). However @repiret may be right - corporate proxy is already invasive enough, that means the users are already in mercy of those. But still, I'd go with safer practices. Even in the slightly unlikely case someone manages to hack 3rd party (Stripe) and send your users arbitrary H…

Thanks, appreciate the advice!

Re: How I learned about corporate firewalls

#174

Earlier quoted context omitted.

Developers dont need local admin rights to develop software, plenty of devs at regulated industries work with user rights. And statistics of developers falling victim of phish attack, credentials stealing that leads to major breach - there are plenty. The most recent Uber hack or Okta hack - were all tied to developer clicking on stupid stuff, opening executables from Internet and getting his a$$ owned. You just gott…

> 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, prepare for the worst case. This is how you have some assurance that your security will work regardless of who is sitting in front of keyboard: teenage intern or gray beard guru.

using your car analogy - car designers created steering wheel, blinkers, and mirrors to increase safety, but you insist that since you are power user - you want to be able to turn left/right by drifting using parking brake. This is obviously safety risk on public roads, and understandable how corporate fleet employer like Greyhound might not allow drifting when driving company bus with passengers.

You are free to drift on your personal equipment though, during non-work hours and without wearing company clothes.

Developers really dont need admin rights, Visual Studio and any other software is updated automatically these days using tools like SCCM. This is not an issue at all. If you need full control over OS - install free VirtualBox, or get a lab VM and do whatever you want inside that isolated VM, but not on the host machine. Because your machine is tied to AD, email, bunch of other corporate stuff - IT cannot risk giving admin rights, so that you can disable all necessary security protections.

Just because you are power user, doesn't mean your colleague in next cubicle is as smart and doesn't click on phish Linkedin emails.

PII is not an issue at all, because of security endpoint agents, network traffic inspection, data loss prevention, and network segmentation, and bunch of other security controls.

Just because you make over 6 figures doesnt make you any better than minimum wage IT support folks, they are following scripts and established procedures very well, most of them do their job well.

I agree that a lot of places have security theatre, because Security engineering is even rare skill than software engineering, it is much harder to find skilled seceng than SDE.

But things like SQL injection, shell command injection, url traversal, and zillion of other attacks - are made possible by software developers, and it becomes then SecEng's problem to protect company against whatever crap they coded and pushed to prod.

Re: How I learned about corporate firewalls

#175

Earlier quoted context omitted.

More like you can’t possibly expect your work machine to have any kind of privacy, being in the trade and knowing all the ways companies can (and will) use anything they managed to gather about you should they need to obliterate you. It’s simply good practice not to use your work machine for anything personal at all ever. Because depending where in the world you are, anything stored or viewed on a work machine gives…

You can be careful as a worker and still be against workplace surveillance

For sure, but let’s face it… we’re getting more surveillance and bossware at work, not less unfortunately.

Re: How I learned about corporate firewalls

#176

Earlier quoted context omitted.

Sensible for the users that really download and execute attachments from the most obvious spam mails. The only protection you have is to put these high threat users in a separate subnet and use some antivirus to scan everything they download. At least that offers some protection. Not possible to scan downloads with TLS. Although I still think that breaking it up is a very bad idea in general and it is appalling that…

> put these high threat users in a separate subnet Ideally a subnet belonging to one of your competitors? I thought that nowadays only very ignorant people follow links or open attachments in spam emails. Certainly all the spam I've seen for a few years has been as plain as the nose on your face: only an ignorant person would mistake it for ham.

Companies get pretty sophisticated spam. You only need one compromised supplier and they have your names and usual mail format and just sneak edit some links to lead to compromised sites. But yes, some users also fall for the pretty obvious crap.

Re: How I learned about corporate firewalls

#177

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…

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.

Re: How I learned about corporate firewalls

#178

Earlier quoted context omitted.

I'm not saying it is right for people to be monitored, but that I would never trust that I wasn't being so I'd not be daft enough to do something I don't want the company to know about using their resources. And there are perfectly valid reasons for companies to monitor traffic: data exfiltration, accidental or malicious, is a significant concern for companies that hold and process PII and for the people who have the…

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 definitely a “working in an office, living at home” person which seems to mark me out as a dinosaur in the coming remote-work age!) but I don't think it is my employer's responsibility to provide me with unfettered unfiltered internet access to do personal stuff with. Work stuff on employer provided Internet which they can monitor all they like, personal stuff on my own devices & connections which they can keep the hell out of.

Re: How I learned about corporate firewalls

#180
post #47

My favourite issue caused by a corporate firewall was when it altered an AJAX request to replace a specific combination of digits (in a long product ID) by asterisks. Turns out that a substring of that product ID matched the client company's phone number and their security theatre intercepting proxy was replacing all occurrences of "sensitive" strings sent to the internet with asterisks. The irony is, of course, that…

this is because you deployed your somewhere in the public cloud and testing it from your workstation over public Internet? This is policy violation, and you need to learn how to develop and test properly over secure channels. Reach out to your Director of Engineering and request proper instructions how to develop and test software. public Internet facing channel is rightfully scanned and screened for these kind of pa…

Or, hear me out ... Get a different job.
Post reply on HN