Comment by cyrnel
2 years ago
I hope that kind of thing goes the way of other corporate efforts to break/backdoor encryption for the sake of "security". IMO, it's really the wrong way to go about security. Sure it would be nice to know if some automated script is being used to log into a machine, but better design can mean that information isn't important.
This has nothing to do with breaking encryption and of all the sketchy corporate surveillance tooling that's deployed for security purposes (so say nothing of HR purposes) monitoring for shells on the network seems about as benign as it comes.
It's only benign if we don't see new policies that say "everyone must disable keystroke obfuscation so we can still spy on traffic".
If a company's security strategy relies on the ability to tell if a given stream of encrypted bytes is shell traffic, and that it can be fooled by timing obfuscation, they need a better strategy. Attackers won't care to follow a "no timing obfuscation" policy.
I've definitely encountered security teams that thrash between different broken policies. For instance, one employer simultaneously had these two policies:
- All developer laptops must be able to log into prod
- You must type a 2FA pin each time you access the test environment, and that includes nightly automation scripts.
I imagine they'd love to run a thing that detected and blocked scripted access to the test environment, but allowed it in production.
(In case it isn't obvious, I agree that corporate security teams shouldn't use strange network monitoring heuristics to interfere with common engineering and ops workflows.)