[tguvot]

i worked in variety of companies that varied from development of security products and were very security oriented to companies where security were driven by client needs (telecom industry for example), to "other places" where management grew with the company and it's case of "you can't teach old dog new tricks". there are always security departments, but unfortunately most of the time their thinking is "slap crowdstrike everywhere, it will solve all problems" and "here is sdlc that engineering must to follow" (lol)

[neeleshs]

Indeed, I've seen that latter behavior in large companies back in the days. A security department that refuses approvals to upgrade operating systems because it's too risky, a full-blown ops team that doesn't know how to do it without killing all services for days on, doesn't have recommendations on security patches, doesn't know if a CVE is actually exploitable in that setup or not - the list goes on.

[tguvot]

i work now on fedramp certification (essentially leading scoping and solutioning) and interaction with security department is both funny,sad and scary af. i discovered that they developed risk assessment policy for system components (in commercial environment) whose purpose to drop down risk level of components in order to remove need for security patching for SOC. and crowdstrike in monitoring mode (nobody knew that it's in monitoring mode) because they afraid of enforcing mode. and that temporary access from/to production network is actually permanent because there is no flow in ticketing system to remove it .