Plata o Plomo

Image Source: Wikipedia, Carrot and Stick

If you have watched Netflix Series “Narcos”, the famous phrase we come across is “Plato o Plomo” which means Silver or Lead. Pablo Escobar smuggles the drugs to make a deal. The deal is either Plato ( silver which is a reward ) or Plomo ( Lead which is punishment). Comparing the same with how the cybersecurity team has to convince development/non-development teams is similar to making a deal. When a vulnerability is found, you walk to the developer and you say “Hey, we found a critical vulnerability. Fix this within the SLA due date” and hand down the ticking bomb. The developer will just throw the ticking bomb at you saying that “ I have more work to do than this bug”. Now you have to convince the developer that fixing this vulnerability is critical. You go back and reassess the vulnerability and you were like either lower the vulnerability because it’s not too much to be convincing. But if this scenario gets repeated, the fatigue just kicks in and convinces us that the developers won’t fix it and why we should spend time reassessing and collecting data metrics to prove that this bug is important to fix. The fatigue can damage team morale. We can’t blame the developer and us here, both have so much things on the plate.

You tried convincing the developer and then you went to Plomo mode. You reach out to the team’s manager saying that these are the issues to be prioritised or convincing both of them that if we don’t fix this up, we will not be compliant. Some teams won’t accept this and ask for approval from CTO or higher-level management and again you are blocked. When it reaches the higher-level management, you can’t go and assess each vulnerability and provide data points to prove that this has to be fixed. We can do it for 10 vulnerabilities but what about 100’s, 1000’s of vulnerabilities that got spit from SCA tools?. Since it’s difficult and takes effort to prove it, the vulnerabilities get pilled up into security debt and start to focus only on Critical vulnerabilities. This story says about the wrong incentivisation that the development team has and security is not planned at the start . As the Security team is a cross-department team and depends on the other’s team bandwidth , investing in prioritising, following up and planning well is crucial here. There are some ways to improve and get the developer’s hindsight.

1. Partner with another cross-functional team, for example: If QA teams are doing great and are mattered in the organisation. Hop on them, partner with them to move and push security forward rather than hitting the developer brick wall directly.

2. Getting Aligned with other teams, management and having it crystallised. RACI/RACI could be helpful here.

3. Using Carrot ( Plata ) by incentivising developers to be security champions. If development teams don’t have the bandwidth, they will fail. Having Security posture as a goal in OKR’s of organisation is important to drive this.

4. Using Stick ( Plomo ) is the last-minute help which never going to improve the security posture rather meets what is enough. If we use this more, then the development team might work only when there is a plomo.

Security engineers feel demotivated when the vulnerability is in the debt as the efforts go to waste. Being selfish is never wrong, showing what you are and what you can do we all should be proud of but going a little secret step can go a long way which is being empathetic and striking a win-win deal.

Other than these, there are uncontrollable variables in play. CISO is not given enough power to drive these things, less risk appetite, and bad culture. When the said variables are there and playing a big role, we can’t do anything. Understanding at which stage you have been hired. Is that you been hired when the org is in a mess ( a recent breach happened)? Is that you have been hired when the org is improving its security posture? or from scratch?. Setting the expectation on the time and situation of why and how you get hired won’t lead to disappointments.