4 ms·

In my experience the reason stems from the fact that the interaction with security typically manifests itself in the form of an inquisition/audit where a series

In my experience the reason stems from the fact that the interaction with security typically manifests itself in the form of an inquisition/audit where a series of 'what ifs' and increasingly implausible corner cases (without solutions, time or budget) get dropped in the engineers lap to 'make work'. Security leaves the meeting with mission accomplished, Engineers leave the meeting with pile of new work and less time to do it.

rsj_hn 6y ago
Ultimately security is about code correctness, and the refactoring needed to gain more assurance is all the usual best practice stuff, like encapsulation/isolation. Here, the reason why it comes as a shock to devs is that they are often never taught about secure coding patterns and so build codebases that are very difficult to reason about, and don't express much interest in adopting more disciplined programming patterns to break the code into security boundaries that validate inputs crossing the boundary. So if your webapp has 1000 controllers that make arbitrary queries against the data model, then only manual audits of every controller is going to give you any assurance of correctness. But if there is a separate access control module that acts as a security kernel and the controllers merely request services from it based on the current user context, then correctness is much easier to verify. But in organizations that refuse to adopt these models, they are forcing the security team to manually audit everything, which is an unreasonable amount of work to pile on them. But there is a whole second thing that is meant when people say "security", which is the GRC space, infested with bureaucrats that bring lists of rules that are fundamentally code agnostic and often at odds with whatever codebase they are working on. So yes, in that case they are the ones walking blithely into a room, making unreasonable demands, and then leaving, creating a pile of work for the devs to do. So it's often a dysfunctional relationship, but it doesn't need to be that way. Like anything else, things go sour when people are put in charge who either lack technical competence in the fields they are interacting with, or have this competence and just don't care about the size of burdens they are placing on others.

rsj_hn 6y ago

Ultimately security is about code correctness, and the refactoring needed to gain more assurance is all the usual best practice stuff, like encapsulation/isolation. Here, the reason why it comes as a shock to devs is that they are often never taught about secure coding patterns and so build codebases that are very difficult to reason about, and don't express much interest in adopting more disciplined programming patterns to break the code into security boundaries that validate inputs crossing the boundary. So if your webapp has 1000 controllers that make arbitrary queries against the data model, then only manual audits of every controller is going to give you any assurance of correctness. But if there is a separate access control module that acts as a security kernel and the controllers merely request services from it based on the current user context, then correctness is much easier to verify. But in organizations that refuse to adopt these models, they are forcing the security team to manually audit everything, which is an unreasonable amount of work to pile on them. But there is a whole second thing that is meant when people say "security", which is the GRC space, infested with bureaucrats that bring lists of rules that are fundamentally code agnostic and often at odds with whatever codebase they are working on. So yes, in that case they are the ones walking blithely into a room, making unreasonable demands, and then leaving, creating a pile of work for the devs to do. So it's often a dysfunctional relationship, but it doesn't need to be that way. Like anything else, things go sour when people are put in charge who either lack technical competence in the fields they are interacting with, or have this competence and just don't care about the size of burdens they are placing on others.