| > The Windows ecosystem typically deployed in corporate PCs or workstations is often insecure, slow, and poorly implemented Yes, but that's not because of Windows itself (which is fast and secure out of the box) but because of an decades-old "security product" culture that insists on adding negative-value garbage like Crowdstrike and various anti-virus systems on the critical path, killing performance and harming real security. It's a hard problem. No matter how good Windows itself gets and no matter how bad these "security products" become, Windows administrators are stuck in the same system of crappy incentives. Decades of myth and superstition demand they perform rituals and make incantations they know harm system security, but they do them anyway, because fear and tradition. It's no wonder that they see Linux and macOS as a way out. It's not that they're any better -- but they're different, and the difference gives IT people air cover for escaping from this suffocating "you must add security products" culture. |
Disagree. At least in the context of business networks.
My favorite example is the SMB service, which is enabled by default.
In the Linux world, people preach:
- disabling SSH unless necessary
- use at least public key-based auth
- better both public key and password
- don't allow root login
In Windows, the SMB service:
- is enabled by default
- allows command execution as local admin via PsExec, so it's essentially like SSH except done poorly
- is only password-based
- doesn't even support MFA
- is not even encrypted by default
It's a huge issue why everyone gets encrypted by ransomware.
I always recommend disabling it using the Windows firewall unless it is actually used, and if it is necessary define a whitelist of address ranges, but apparently it is too hard to figure out who needs access to what, and much easier to deploy products like Crowdstrike which admittedly strongly mitigate the issue.
The next thing is that Windows still allows the NTLM authentication protocol by default (now finally about to be deprecated), which is a laughably bad authentication protocol. If you manage to steal the hash of the local admin on one machine, you can simply use it to authenticate to the next machine. Before LAPS gained traction, the local admin account password was the same on all machines in basically every organization. NT hashes are neither salted nor do they have a cost factor.
I could go on, but Microsoft made some very questionable security decisions that still haunt them to this day because of their strong commitment to backwards compatibility.