Do you Dev ? Sec ? Oops ?
We have a basic threat model and abuser stories in our backlog. Developer’s pull requests is awaiting review and validation before being merged into the master branch, completing our user story. A boring thursday afternoon, and you are pretty confident that the feature is going to be validated before the end of the sprint and the live-demo infront of your customer schedulded to happen on Friday evening. (I used to do that, don’t you ?)
As a benevolent manager you send your encouragement to the team in the slack channel that you are using, having some spare time you decide to analyse the communication of your team : You notice a great cooperation and . . . the usual passwords or accounts sharing and some weird base64 characters (Maybe some json-secrets ?). And Nikolay’s account is still active.
Wait, didn’t Nikolay leave the company last year ?
Here is the catch : Before thinking of deploying highly-complex counter-measures and spending thousands of euros in specific trainings or products, we need to ensure that the working environnement is clean and up-to-date. Being comprehensive is hard, so try to think about it as a « developer journey » the same way you would think of a « customer journey » when leveraging design thinking. And then iterate as your « operations security » improves over time. (Yes security, Yes the « agile way » !).
Once again, an appropriate threat model would be nice here to better scope the recommandations.
Iteration_1 : As a developer I enter a building, turn on my computer and do my work.
1. I enter a building.
Here, we should be asking questions about surveillances, authorisations and segementation of spaces. We must look at both our processes and products that are responsible in ensuring the security of our operations. Closely follow the obsolescence of your products or any incident in order to never let your guard down.
2. Turn on my computer.
Here, we should be reviewing our company's policy regarding IT-devices and network connections that are being used in developing processes. We want to be clear as per what actions you are allowed to do with either an "unknown" device or an identified one. In addition we must define what we consider a "secure" working station. As a rule of thumb, I like to recommand a strict separation between personnal and private device and enforce hard-disk encryption for professional laptop.
Iteration_2 : As a developer I enter a building, turn on my computer, communicate with my colleagues.
Every iteration is an opportunity to review what has been done in the past and to keep track of the reasons that made you act this way, in the mean time : You are adding at least an item to your story that you find now relevant as per your threat model.
3. Communicate with my colleagues.
Here, we should be looking at every channel that is involved in our operations (Discord, slack, trello, jira, whatsapp, gitlab, github, youtrack, mantis . . .). There is two essential key points that need not to be overlooked here : The level of information disclosed and the persons that are able to access the information. You want to be sure that, at any given moment, only the right persons access the right data. (And that "secrets" or accounts are not openly shared. If they are, it might be that your security posture is either too strict or your processes too slow.)
As a side note : We think of cybersecurity as disponibity of services, integrity of data, confidentiality of communications and tracability of actions (Now that o-trust is gaining traction we may add segmentation of privileges ?). As you mature, you will soon enough question for an ISO 27k certification and will eventually engage in the process, capitalizing on all this hard work.
Follow this mantra for securing your development pipeline and apply it to every single item that you are able to list, always try to improve on the weakest link of a given chain and : Don’t limit your developers, trust and educate them.
They are not your weakest link, they are your first line of defense !
See you at the next step of the pipe !
Nice article Guillaume ! Just a thought : this process is really useful in terms of well establish infrastructures with money to spend on cybersecurity. What about the majority of more flexible businesses (start-up, TPE-PME) starting to make a living from their code ? The high competition and need for innovation makes the need to protect against espionage more urgent. What dialogue would you have reguarding these companies ?