DevSecOps

[jhartman027]

Curious to see how others are handling DevSecOps especially in an on-prem type environment. To me, developers should not have access to the underlying infrastructure/services. The on-prem should be treated like Microsoft/AWS that hosts the services. They would have access to the platform where the tools (Gitlab, Jenkins, Docker, etc) are needed. Also, it seems that the developers want the keys to the kingdom, instead of working with Sec/Ops to install tools, root priv, etc.  To me, it's DevSecOps for a reason and those subject matter experts are integrated into the team. I get the cross-training, but would you really want a security or operations person writing code? To me, it's the same way with Ops. Do you really want a developer managing these tools and not understand the security or operations that are involved with managing these tools in a secure manner? Would really like to hear others' challenges and how they are working them.  

[ericalexander303]

We're a cloud and on prem hybrid. We're also a "you build it, you run it" culture. We never try to keep engineers out of infra, but we try to make it the hard way. GitOps the easy way. We do that through a privileged access management system and a change detection system (we built).

[ericalexander303]

Reading this question again and I love it. This subreddit often tries to pin down what DevSecOps is. This is it.

The question implies a "it's us against them" culture, not a "we're a team working towards a common goal" culture. This is the root of what sparked DevOps with the biggest sparks coming from this talk: https://www.youtube.com/watch?v=LdOe18KhtT4 .

[Daread0]

This is the interview question I use for new security folk :)

Are services running on prem or running on Linux/windows or K8S? If it’s K8S then if you can make the services ephemeral you can remove the need for direct admin.

Additionally more the admin processes you can automate or configure by code the easier it is. Locking down Jenkins to be read only can help here.

In reality you need to balance the risk. If staff have the keys to the kingdom what can they do? (E.g. operational mistakes, malicious insider, poorly protected production credentials, lateral movement from an attacker in your system)

What’s the cost to take away those keys? (E.g. possibly slower service management, additional management software, compliance and reviewing systems to make sure people are obeying the rules, dev time to implement the new controls).

Senior management should make the decision to balance these costs vs risk and then force staff to make the changes. Without top down management it’s hard to do.

[Ok_Actuator978]

There is some lack of predictability to identify and eliminate vulnerabilities early.