I know some people do network monitoring for hands-on-keyboard shells (presumably) by measuring packet timing, I wonder if this will mess with those detections and if so by how much.
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.)
Network monitoring for unauthorized/unusual access, reading more into how this works I don't think this would actually change anything, you can probably still discern scripted vs manual shells it would just be a bit harder.
