That line really surprised me. I'd have thought that somebody who knows enough to move a frequently targeted service to a different port to avoid low effort attacks/scans would know enough to use other protections, then I saw it was partly because of cheap IoT devices that have zero issues violating specifications out of the box.
If someone is trying to use ports as their security measure then it's because they don't actually know how to make their API secure properly.
Strong disagree with that. If you do something as simple as moving SSH to a different port, the number of drive-by attacks will drop enormously. Raises the signal to noise of all connection attempts in the logs.
So it's like locking the screen door in front of your reinforced, deadbolted door. Some people will try the screen door, find it locked, and move on. It doesn't do a lot, but it's not entirely worthless, either.
Going to echo a sibling comment -
This catchphrase may help people who know very little about security be a bit better.
But to completely throw it out is counter to security’s goals.
Obscurity can help reduce the surface area of attacks, but shouldn’t be used as the exclusive tool to secure something.
I can hide my service with a random key and you will never get to it. This is how a lot of data is shared when you do not have identity management.
Of course once you share this URI then the one who what it can access the data. But again, it is a choice.
Security is difficult, especially when someone jumps on without assessing their threat profile.
Such as if you’ve ever gotten a confused note from IT that their automated health check failed to reach your internally hosted application.
Sometimes all you really need is for the low effort, high volume “white hat” to just go away. The answer for why the heath check that you didn’t ask for didn’t work is simply “security through obscurity.”
They love hearing that. It sounds clever.