We are going to take a look at a very real problem for the IT departments of large groups that exists on the border between information security and massive outsourcing: third-party security, as broad a subject as there can be.
Let's start with the current situation. From one side, the use of providers in the computer world has been widespread for many years. From the other, information security is one of the key concerns of CIOs. So what? Two things we already knew.
Now consider the environment into which these providers fit. They have to manage all these layers:
In other words, it's hugely complex. Looking at this from a security point of view: a relatively large population will have to work in your company, with less knowledge of the environment and much less exposure to the traditional security initiatives.
Indeed, what proportion of the providers in the company sign the IT charter, the non-disclosure agreement or attend an awareness session? And which of them have really come to know and understand them? Notwithstanding these commendable efforts, I really have some doubts about their real effectiveness.
I won't bore you with the customary speech on the increase of threats, malware, denial of service, APTs, whether anonymous or Russian state hackers (Chinese hackers are now yesterday's news). If you have no Fear, Uncertainty or Doubt (FUD for short), download the presentation from your friendly antivirus manufacturer!
Joking apart, I don't think I need convince you of the reality or seriousness of the threats to information security. You can get an excellent idea of the threat by looking at the relevant publications by CESIN (Club des experts de la sécurité de l'information et du numérique)  and CLUSIF (Club de la sécurité de l'information française) .
As it is impossible to address everything in a single article, I will here concentrate on the subject of IT services that directly interact with a customer environment. It therefore concerns services on a cost-plus or fixed-price basis, rather than large third-party application maintenance or support contracts. For the latter, it is easier to define perimeters and a boundary between "the external" and "the internal", and to apply good old perimeter security formulas if these are passed .
So let's start with a fairly widespread solution, which, to be honest, has serious limitations: the galaxy of contractual clauses, and its security avatar: the security insurance plan. These schemes, that have blind faith in the value of the contract, consider that it is sufficient to include clauses such as "I promise to take all necessary means to protect client data" for a provider to be equipped with state-of-the-art security.
Get real. These clauses are very rarely actually applied: most companies will take the risk of a problem tomorrow to win the contract today.
Some will think that, in the event of a problem, these clauses serve to prove that the provider is at fault and that it will have to compensate the client. This idea is no good for information security issues, where the impacts of a problem can be colossal. Many service companies would never have the means to compensate a large group for the level of damage in a serious incident, even if they took the whole company, their cars bought on credit and their dog!
Let's be clear: these contractual clauses are certainly not unnecessary, on the contrary: security must be defined in black and white in framework contracts. This is the starting point for achieving an appropriate level of security from the suppliers. The error would be to leave it at that.
Once this has been established, what next? We cannot hide from the fact that getting a good level of security from our service providers will require more commitment than having signed a contract that will have received about the same level of attention as Update #231 on the conditions of use of Candy Crush. I will come back to provide concrete advice for putting all this in place afterwards, but let's start by asking "What topics need to be addressed?"
You could ask for the application of the 114 measures of ISO / IEC 27002. That approach will only take a year or two! We might immediately ask our suppliers to be ISO / IEC 27001 certified. It is probably an excellent idea to ask suppliers for ISO 27001... but if you, my dear reader, are already at this point, you probably no longer need my tips on the subject!
We will therefore focus on five important topics regarding security with third parties:
Let's start with security awareness. You probably have security rules, good practice guides, one or more charters on the good use of the IS... It would be a shame if all these quality resources were only for internal use. It is actually essential that they be presented in a suitable manner, via a specific welcome pack for external users, for example. External users should also be integrated into existing awareness initiatives as much as possible. To exclude them is doubly damaging, first by depriving IS users of knowledge that is useful for security, then by sending the wrong message, disempowering. You will often find me stating this: it is crucial that everyone, including service providers, is made aware of their responsibilities in the security of the IS.
Let's go further: these schemes are designed to advance everyone's security skills, so why not require a minimum level of information security from your providers? Perhaps request evidence from the company of recent awareness initiatives? We must face the fact that security is now a basic skill in the use of the IS, especially in computer-based professions.
Now let's move on to a more mundane topic, but nonetheless very important: asset management. A laptop or a company smartphone is an extremely precious asset with regard to information security, whether it is for the information it contains or its access to the IS, its registered passwords, emails, address books, etc... The possibilities for abuse are enormous . I assume that you already have centralized hardware management, and in this case, there are very few imaginative and realistic solutions: it is necessary to ensure that an inventory is created and maintained, and to ensure restitution; to use the existing management tools and ensure that they are included in the entry and especially exit processes of the providers. Nevertheless, the criticality of material management required me to mention it.
Let's now take a look at a critical issue in operational security: incident management. It is entirely justifiable to require a provider to have detection and reaction capabilities... when the information and the processing entrusted to it justify it! In the simplest cases, the provision of consultants on a case-by-case basis; relatively few incidents on the provider side can have a serious impact on you. If a provider is entrusted with the hosting of sensitive systems, this is obviously another story, but this will quickly take us beyond the scope of this already involved article.
We should perhaps spend a moment looking at the information entrusted to the provider, who is generally required by contract to safeguard them adequately. Do you remember my advice regarding the contractual clauses? It applies fully to this issue: the protection of confidential data risks being ineffective in the absence of precise instructions from you. Two steps seem crucial to me: firstly, having experience in the topic of data protection, and therefore knowing how to classify it; secondly, requesting encryption and other conventional measures to protect confidentiality. I will not detail them here as this subject is already widely discussed. If you want more information on this, the good practices categories of the ANSSI site seems to be a good starting point .
Finally, we finish this chapter with practical advice on a somewhat more specific point; that of integration of security into projects. The theoretical idea is one of security by design . In short, this means integrating security into all stages of a project: specifications, development, testing, acceptance, production ... (or in each sprint, for the agile among us). Presumably, the phases that will concern us the most with respect to the topic of integration of security into the service will be the beginning and the end of the project process. In other words, when drafting the specifications, think about expressing the security needs of the product, and demanding a response to these needs, the same as for any other functionality (and take it into account when choosing the winner of the bid!). And in the acceptance phase, require or conduct security acceptance to validate the proper functioning of the security... just as you would any other functionality! Naturally, you say? Personally, I'm still waiting to see security be a natural function, among others!
So much for the ideas and great principles. You will have understood, I hope, that this article is not only about sharing good ideas, but about implementing them and raising the real level of security! I will also share our experience on the implementation of these principles in emagine for the benefit of some of our customers.
A bit of background: emagine is a consulting firm that relies heavily on the expertise of its network of freelancers and very small companies. People who are highly competent but whose job is generally not security and who do not have the necessary structure to rely on internal security skills. Our responsibility is to pass on the security requirements of our customers to often poorly equipped service providers. This meant we had a great need for tools and procedures to integrate security into the service!
I would begin by clarifying our vision of this process: The integration of security into a service is both a monitoring / evaluation task as well as a project to raise the awareness of the actors. The best results are obtained with a harmonious blend of these two trends.
As far as awareness is concerned, I feel it is essential to communicate the requirements and to support the various partners. Formulating the requirements clearly, writing guides, explaining the ins and outs of the process... these actions give legitimacy to security as a whole and make it possible to attenuate the "extra constraints!" effect. Let's be clear: this process is an additional constraint, and we must demonstrate that it is not an unnecessary constraint but rather an investment, a source of added value for all.
In the same vein, it is important to adapt the tone, the tools for the interlocutor. Stating the obvious again you say? Of course, but the procedures tend to over-standardize, and you should not demand the same security guarantees on:
Only one thing must remain constant and non-negotiable: clearly identified minimum security guarantees, below which the client organization would be too exposed to risk.
Now let's talk about the task of evaluation and monitoring. Here we touch on a very important point, both for the credibility of the process and for the confidence of the final customer. We have a little problem to contend with: how do we convince this illustrious customer of the sincerity and value of our process, while a service company, like ours, is by definition judge and judged?
The solution is ready-made: it is necessary to set up an audit process, respecting principles, integrity, deontology, professional conscience, and above all a proof-based process . Indeed, all the security requirements mentioned above should, whenever possible, be supported by documentary evidence. Procedures, documentation, examples of experiences, all this can be acceptable, and will be more convincing than an empty statement.
I have spoken rather a lot during the course of this article, so I will try to be concise: I hope I have managed to share with you my interest in spreading security in service. No theoretical or conceptual revolution, but a concrete and real increase in the level of security for entities welcoming contributors. No revolutionary tool or technology, rather the conscientious application of awareness to a public thus far little reached. This is probably the biggest merit of this kind of process, initiating a virtuous circle of requirements for large accounts and a better level from service companies.
Nicolas Levain, Chief Information Security Officer within emagine
 for example: https://www.clever-cloud.com/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/
 https://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/ for various illustrations
 For more details: https://www.owasp.org/index.php/Security_by_Design_Principles
 Principles specified in the norm ISO/IEC 19011:2011