161–170 of 204 posts
Earlier quoted context omitted.
(cue, as in "a signal (such as a word, phrase, or bit of stage business) to a performer to begin a specific speech or action", e.g. "That last line is your cue to exit the stage". See https://www.merriam-webster.com/dictionary/cue )
Rats. I should have known it was the wrong version when my brain made me slow down to spell it out. Thanks for the correction!
> It helpfully spits out this HTML response in return but, of course, my frontend code was expecting a JSON response. I had no idea I was ever going to get anything different. I wish more front-end devs recognized that they're building HTTP clients whenever they make HTTP requests. There's a whole specification written about how to do that well so one doesn't have to learn things like this the hard way. Specs may loo…
I've found often in my career that, sadly, learning things the hard way is usually the best way to remember the lessons.
I think you did a great job cementing the "why"—usually this topic is very hypothetical. I also liked how you tied it to real end users. After all, that's who the internet is for!! [1]
My intention wasn't to criticize your post. I hoped my comment would help one or two readers recognize the underlying problem space a little sooner, which might help them learn a more broadly applicable lesson when the time comes.
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…
And that kids is how it looks when security team just sits in their ivory tower and shits on everyone else in name of security theathre they're paid to play > 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 to get off the VPN every time I need to run these simple commands. IT absolute…
Security team should have provided you with golden image with hardened config, latest patches installed, and corporate certs installed in certificate store.
If they didnt, they aint doing correct DevSecOps/SecDevOps or whatever the fancy term is for integrating security within development team.
It is a big red flag that any developer can pull whatever image for container running in production, possibly with unpatched vulnerabilities and loose config and ports open, and running with root privileges, etc.
Usually stuff has to be vetted and checked prior to being deployed in production environment
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…
Palo Alto appliance should be configured with both Forward Trust and Forward Untrust CA certificates, and the issue you described will not exist. If some people misconfigure - thats their fault for not following instructions.
Secondly, rogue employee doesnt have access to CA key that is stored in Palo Alto appliance. Only your firewall admin will have it, but if your main firewall admin went rogue, capturing colleagues’s data is the least of your concerns. Insider threat of that calibre is equally applicable to rogue CEO or CFO stealing all money from the bank. Or your ActiveDirectory admin getting CFO’s credentials and corporate bank credentials.
Earlier quoted context omitted.
So these bulk scanners exist, and the issue is a solved problem, but none of the "root" repos for the popular language stacks are using them? It seems that Microsoft has built an internal tool that runs such a scan on NuGet ( https://devblogs.microsoft.com/nuget/how-to-scan-nuget-packa... ), at least against your individual app's packages. (That would be a very rare h/t to Microsoft from me.) EDIT: Apparently, you ca…
> So these bulk scanners exist, and the issue is a solved problem, but none of the "root" repos for the popular language stacks are using them? I could talk at length about this; unfortunately, I'm on my phone with a shotty connection. The tl;dr is that companies like Snyk make money by requiring companies to pay to check for vulnerabilities once they've been downloaded. There's not necessarily anything wrong with th…
This is why only commercial company can build a great product. The constant cat and mouse game between threat actors and defenders/researchers. Every new malware/trojan/cryptominer strain needs to be found, identified, signature written, and all clients need tk get latest signatures asap, and product has to work flawlessly with as few false positives as possible
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…
For pulling data from prod - this is often discussed. Data in production should not be pulled in lower environments (dev and test), because of segmentation, but you can absolutely operate with Prod data within prod environment, like by using approved production datalake or data warehouse or something.
Believe for every security decision that you think is stupid - there are many incidents that happened, and every rule and ban has happened because of these incodents/breaches/data corruption, etc.
It is like workplace safety instructions, they were written because of workplace injury, same for traffic laws.
Earlier quoted context omitted.
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…
You must be fun to work with.
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…
Security people usually hate adhoc and one-off requests for random stuff from random people. If you are part of the required business process - then there is 100% established and approved way of doing things. For example for Splunk - CISO simply needs to be added to a AD group that is designated to have Splunk access, something like SOC-analysts group. For pulling data from prod - this is often discussed. Data in pro…
That's everything that's wrong with the security mindset.
Earlier quoted context omitted.
Security people usually hate adhoc and one-off requests for random stuff from random people. If you are part of the required business process - then there is 100% established and approved way of doing things. For example for Splunk - CISO simply needs to be added to a AD group that is designated to have Splunk access, something like SOC-analysts group. For pulling data from prod - this is often discussed. Data in pro…
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.
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 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