Or why supplier questionnaires are not enough
The concept of zero trust (zero-trust) was used for the first time by John Kindervag in 2009 (then a Forrester consultant) and is based on the fact that trust can be a vulnerability of the system and, therefore, security must be protected. designed with the "Never trust, always verify" strategy.
Although it sounds excessive, we have to think that it was the height of the robot networks that turned computers into zombies to do with them what they wanted. Kindervag, after all, what it proposed was that, by the mere fact that a connection request came from a computer in which a user had been authenticated, we could not infer that the request had been made by said user and that, therefore, it was legitimate, since it could be the result of some malware installed on the computer.
This concept of zero trust has evolved since then and is currently enjoying its best health, having evolved into other areas of cybersecurity. This entry, in fact, seeks to explore its application in the world of third-party risk management (in line with what was recently proposed by the World Economic Forum). The World Economic Forum's approach is that "you can't just continue to trust that your provider is safe - you have to verify it, but how?"
"Rather than assuming that a company or product you are working with is safe, a zero trust approach requires verification of all assets, user accounts or applications", Dmitry Samarstev (BI.ZONE)
Obviously, this means that we are faced with a dilemma: On the one hand, the ideal seems to be to verify all suppliers and third parties in general; but on the other hand, we do not have the resources to tackle the task.
In our opinion, both approaches are compatible applying an approach based on the potential impact of the third party. What do we mean? Apply the zero trust philosophy to those suppliers and products with a potential impact greater than our risk tolerance threshold. And what do we do with the rest? The rest can be subjected to other types of lighter validations: remote or documentary audits or even responsible declarations for the less critical.
In this way, the lower our appetite for risk, the more extensive our third-party audit processes will be, and vice versa.
Corollary 1: Using only self-assessment questionnaires is not acceptable. If we limit ourselves to sending questionnaires to third parties, we will not be carrying out any type of evaluation. Suppliers have a strong incentive to answer the questions raised in the affirmative since they are aware that, if they do not, they will not be able to work with us. In our opinion, this is the worst possible option because it conveys a false sense of security to the rest of the organization that inevitably leads to bad decisions since we do not really know the level of security of said third parties.
Corollary 2: Risk appetite defines the breadth of assessments, not the other way around. We must not let ourselves be influenced by our ability to carry out audits to establish third-party evaluations, but rather we must establish our needs based on the risk we want to assume. But what if I can't do any more audits? In our opinion, the important thing is that the third party is audited, not that the user audits it. What does this mean? For example, if the third party presents us with a security rating issued by LEET Security, we will know that the service has been audited by an independent third party and we can know what has been audited thanks to the public rating methodology with which any framework can be mapped. of control and/or applicable standard.
In summary:
1. Applying the "Never Trust, Always Verify" philosophy to our supply chain is inescapable based on our appetite for risk.
2. Let us think that there are more options than our own resources to carry out the evaluations (shared audits, qualifications, etc.)
3. Let's not create a false sense of security by basing our assessments solely on self-assessments. We play too much.

All you need is LEET

Suscribe to our newsletter here

You can follow us on twitter.com/leet_security

7 de febrero de 2022