3 ms·

Why security and engineering don't get along

17 points by ffwang2 6y ago

wrnr 6y ago
As a programmer I always disliked DevOps because it expected engineers to write yaml instead of code. Well because code is too expressive for configuration, I hear you say with reproach. Then why is there this bash script that changes the config files of the staging environment and pushes the changes to a the production git repo from where it is deployed to kubernetes.
- detaro 6y ago
  DevOps has nothing to do with you writing YAML or not.
dzikimarian 6y ago
In my opinion security, devops and all other teams have common goal. Namely help company to create sellable product. Being insecure and undeployable are both fatal flaws working against this goal. Sadly, as any specialized department, security tends to loose this perspective and pursue own goals e.g. emulate external auditors, instead teaching the rest how to work with them efficiently or enforce whatever new shiny security standard is, without consideration of fit and impact. Of course the same problem can happen, when devops install k8s to support two instances of blogs or developers incorporate DDD into creation of simple CRUDs. My company is currently working as a vendor for customers in highly regulated area. Customers have own IT, however they are unable to do anything meaningful in reasonable time, because of completely over the top constraints put on the developers (definitely bigger than required by regulators and not well thought). What's funny the more customers are happy with our work, the more their security pushes us to adopt their own standards. Then our security tends to support them because they are clearly "superior" to us (namely more tight). Clear case of ceasing to cooperate and focusing on own area.
spaceprison 6y ago
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.

17 points by ffwang2 6y ago

wrnr 6y ago

As a programmer I always disliked DevOps because it expected engineers to write yaml instead of code. Well because code is too expressive for configuration, I hear you say with reproach. Then why is there this bash script that changes the config files of the staging environment and pushes the changes to a the production git repo from where it is deployed to kubernetes.

detaro 6y ago
DevOps has nothing to do with you writing YAML or not.

dzikimarian 6y ago

In my opinion security, devops and all other teams have common goal. Namely help company to create sellable product. Being insecure and undeployable are both fatal flaws working against this goal. Sadly, as any specialized department, security tends to loose this perspective and pursue own goals e.g. emulate external auditors, instead teaching the rest how to work with them efficiently or enforce whatever new shiny security standard is, without consideration of fit and impact. Of course the same problem can happen, when devops install k8s to support two instances of blogs or developers incorporate DDD into creation of simple CRUDs. My company is currently working as a vendor for customers in highly regulated area. Customers have own IT, however they are unable to do anything meaningful in reasonable time, because of completely over the top constraints put on the developers (definitely bigger than required by regulators and not well thought). What's funny the more customers are happy with our work, the more their security pushes us to adopt their own standards. Then our security tends to support them because they are clearly "superior" to us (namely more tight). Clear case of ceasing to cooperate and focusing on own area.

spaceprison 6y ago

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.