> It really doesn’t make sense for cybersecurity to have its own special snowflake process for things. It does not make sense operationally, philosophically, or

> It really doesn’t make sense for cybersecurity to have its own special snowflake process for things. It does not make sense operationally, philosophically, or socially. It does not make sense to sustain systems resilience. And it even does not make sense for software security. Sorry, but it actually does make sense in multiple ways. Firstly, the core purpose of cybersecurity in the C-suite is to ensure the bottom line. System resilience is not the priority, the priority is the stock price. That means that it's way more important to triage an issue, collect evidence, determine impact, and see how many ways you can legally hide evidence or manipulate the situation to deny you ever even had a security incident. The quieter it stays, the smaller the impact to the bottom line. Keeping compromises to a minimum, improving UX, meeting modern best practices, etc are like the farthest things from their minds. And the people who run the company dictate what these teams prioritize. So to "the company", there's a good reason why they focus on their own thing. Secondly, security is really frickin' hard. Humans are not great at being masters of many things. You need a specialist who understands security well, and has the tools, and training, to do security-specific things. Why do you think "platform teams" (aka the new-new-sysadmins) exist and we don't just have developers build their own platform? Because there's ops crap in there that devs will never know, and shouldn't need to. Humans work more efficiently when they can focus on specific things, keep context switching to a minimum, and maximize their specific knowledge to a small domain. That includes security tools, practices, policies, etc. Thirdly, because of the competing priorities of security, and the specialization needed to truly do it well, you have to have a "security process" that people who aren't security experts can follow. You also want a "security process" because processes in general are useful tools to keep things working correctly. Even "security people" should be following a "security process". And there needs to be "security people" to come up with the process (ideally in collaboration with the other teams). What you don't want is bad process, or bad teams, or bad special snowflake solutions, etc. You want it to be supportive of other parts of the business, rather than a hindrance. That's what DevOps is all about - getting people to collaborate together, enabling self-service, increasing efficiency, improving quality, reducing waste, etc, etc, etc. You can do that with security too, and it doesn't mean you have to get rid of your security teams/solutions.