Résumé

  • Les histoires institutionnelles d'ID-CERT attribuent sa fondation, en 1998, à Budi Rahardjo et décrivent une équipe indépendante issue de la communauté. Sa charte publiée exclut explicitement toute autorité opérationnelle sur les réseaux de ses interlocuteurs.
  • Ce mandat produit une capacité utile : faire circuler une preuve vers une personne légitime et autorisée à agir. Mais une plainte reçue, examinée ou transmise ne constitue pas une réparation vérifiée ; la suppression de la faiblesse et la sécurisation du système restent du ressort de la partie concernée.

La confiance ne consiste pas toujours à déléguer davantage de pouvoir. Dans un incident de réseau, elle peut au contraire commencer par une limite claire : voici ce que cet interlocuteur peut faire, voici ce qu'il ne peut pas faire, voici qui devra prendre la décision suivante. Un signalement traverse souvent des entreprises, des prestataires et des frontières. La personne qui en connaît le symptôme n'est pas nécessairement celle qui peut intervenir sur le service.

Budi Rahardjo a aidé à instituer un passage entre ces positions. Les pages historiques d'ID-CERT, en indonésien et en anglais, situent sa création en 1998 et le désignent comme fondateur. L'équipe se présente comme indépendante, construite par la communauté et pour elle. Son ambition n'était pas de devenir le propriétaire collectif des réseaux indonésiens, mais de leur permettre de mieux se parler lorsqu'un incident concernait plusieurs acteurs.

Le nom Computer Emergency Response Team ne suffit pas à comprendre cette fonction. Il suggère l'urgence, pas un droit d'accès aux machines. La charte anglaise d'ID-CERT, qui se donne comme version 1.11 publiée le 28 novembre 2012, précise que ses bénéficiaires sont le public au sens large. Elle indique surtout que l'équipe ne dispose d'aucune autorité opérationnelle sur les réseaux concernés, en Indonésie comme à l'étranger. Sa capacité dépend de la coopération des parties.

Cette précision évite une confusion fréquente entre connaissance et commande. Une équipe peut savoir qu'un problème mérite d'être examiné, identifier le fournisseur concerné et donner un avis technique. Elle ne peut pas en déduire qu'elle possède l'autorisation de modifier ce fournisseur. La charte cherche des relations de travail avec administrateurs, opérateurs, entreprises, organismes publics et universités plutôt qu'une relation autoritaire.

Ses services matérialisent cette séparation. Le triage examine si l'incident a réellement eu lieu et quelle en est l'étendue. La coordination rapproche les parties et les autres équipes de réponse. La résolution, elle, attribue à la partie signalée l'élimination de la faiblesse et la sécurisation du système. Le relais facilite une action qui demeure sous une autre responsabilité.

Cette architecture est modeste seulement si l'on considère la transmission comme un geste sans coût. Pour celui qui reçoit une plainte, il faut apprécier des éléments incomplets, distinguer une erreur d'aiguillage d'un incident pertinent et trouver une personne qui acceptera le dossier. Pour celui qui exploite le service, il faut distinguer un signalement crédible d'un message malveillant, trompeur ou simplement mal renseigné. Un interlocuteur connu peut réduire les frais de cette vérification mutuelle.

Une ancienne procédure publiée par ID-CERT demande des journaux, des horodatages et un moyen de joindre l'auteur du signalement. Ces éléments ne rendent pas l'allégation vraie par eux-mêmes. Ils lui donnent une forme exploitable. L'enjeu est de transformer une inquiétude en information assez précise pour que le propriétaire du système puisse décider d'une inspection ou d'une intervention autorisée.

La même procédure décrit le trajet suivant. Si la source est située à l'étranger, l'équipe coordonne avec un CERT du pays concerné. Si elle se trouve en Indonésie, elle sollicite une équipe sectorielle ou un fournisseur approprié. Lorsque le cas dépasse son périmètre, elle peut recommander et présenter un acteur plus compétent. Le texte insiste sur une coopération de bonne foi, sans pouvoir de contrainte.

Il faut donc compter plusieurs événements là où un tableau de bord pourrait n'en afficher qu'un. La réception d'un courriel prouve qu'il est arrivé. Son transfert prouve qu'un relais l'a envoyé. L'accusé de réception indique qu'un destinataire l'a accepté. L'identification d'un responsable permet d'attribuer la prochaine action. La réparation et son contrôle demandent encore d'autres éléments. Aucune de ces étapes ne peut être remplacée par la précédente.

Cela protège aussi le relais contre une promesse qu'il ne maîtrise pas. Si un fournisseur ne répond pas, une équipe de coordination ne possède pas automatiquement les outils, les accès ou l'autorité nécessaires pour agir à sa place. Son travail peut néanmoins avoir été précieux : rendre le problème visible, établir le bon contact et documenter ce qui manque. L'échec d'une action finale ne signifie pas que le premier aiguillage était inutile ; il signifie que les responsabilités doivent rester distinctes.

La confiance porte autant sur la destination que sur la preuve. La charte déclare une politique de confidentialité et décrit la signalisation des informations sensibles ainsi que des communications protégées et authentifiées. Un journal peut contenir des données personnelles ou des détails d'exploitation. Un expéditeur doit savoir à qui il s'adresse et pourquoi une information sera transmise avant d'en livrer davantage.

Mais un engagement écrit n'est ni une vérification indépendante de la pratique ni une garantie de protection juridique. L'article ne peut pas prouver l'application de la politique à chaque dossier. Les anciens exemples de clés cryptographiques ne doivent pas davantage servir de recommandations actuelles. Ils attestent que l'équipe a jugé nécessaire d'expliquer l'identification et la communication, non que ces paramètres historiques sont encore appropriés aujourd'hui.

Le temps de travail impose une autre limite. La charte ancienne décrit généralement des horaires ouvrés de semaine, de 09:00 à 17:00 hors jours fériés. Une procédure plus ancienne mentionne le traitement d'une plainte en un jour ouvré. Ce n'est pas la preuve d'une réparation sous vingt-quatre heures, ni un engagement actuel testé de permanence continue. L'urgence technique ne fabrique pas une équipe de nuit par le seul choix d'un nom.

Les pages institutionnelles rendent visible une organisation composée de bénévoles et de fonctions professionnelles, notamment d'assistance et de gestion. Elles sollicitent des soutiens et signalent des difficultés de financement pour participer aux rencontres régionales. Elles ne permettent pas de chiffrer le budget ou la capacité actuelle. Elles suffisent en revanche à montrer que le contact de confiance repose sur du travail, des remplaçants et des ressources.

Cette économie est peu visible pour les bénéficiaires. L'auteur du signalement veut une réponse ; l'opérateur veut une preuve claire ; la communauté veut qu'un problème dépassant les frontières d'une organisation trouve un responsable. Pourtant, aucun de ces intérêts ne rémunère automatiquement le temps de coordination. Le bénévolat peut ouvrir un service, mais la continuité exige aussi que quelqu'un suive un dossier après le premier message.

Le parcours public de Rahardjo éclaire cette activité sans autoriser une biographie héroïque. Dans un entretien de 2018, Institut Teknologi Bandung le présente comme enseignant en génie informatique et associe son écriture à la documentation et au partage de connaissances. L'université situe ses débuts de blogueur en 2002. Un portrait de 2019 décrit l'enseignement, l'expertise en sécurité de l'information et l'entrepreneuriat technologique. La page des enseignants de STEI mentionne la sécurité et la conception VLSI asynchrone parmi ses intérêts.

Le rapprochement avec la coordination est une interprétation éditoriale, pas un résultat mesuré. Une équipe spécialisée devient utilisable lorsque d'autres personnes comprennent ce qu'elle attend d'elles, ce qu'elle leur apporte et ce qui restera à leur charge. Documenter une limite peut être aussi important que documenter un outil. Cela donne à une relation entre experts une forme accessible au reste de la communauté.

La recherche participative prolonge cette fonction. En avril 2014, ID-CERT invitait étudiants, chercheurs, organismes publics et personnes intéressées par la sécurité à rejoindre une étude sur la diffusion des logiciels malveillants. Les pages historiques décrivent aussi un suivi des incidents à partir de plaintes. Ce sont des moyens de rendre les observations disponibles, pas une mesure exhaustive de la sécurité d'un pays.

Le volume reçu conserve le périmètre de ses contributeurs. Plus de signalements peuvent indiquer plus d'activité nuisible, mais aussi davantage de participants, de meilleurs instruments de détection ou plusieurs observations du même événement. On ne peut pas en déduire un nombre national d'attaques, de victimes ou de réparations. Le travail de connaissance gagne en valeur lorsqu'il affiche ce dénominateur au lieu de s'en débarrasser.

Le récit régional demande la même discipline. ID-CERT se souvient d'une première rencontre à Tokyo en 2001, à laquelle Rahardjo et Andika Triwidada auraient participé. Le récit du dixième anniversaire de JPCERT/CC décrit une réunion APSIRC à Tokyo en mars 2002, puis la fondation formelle d'APCERT en février 2003 avec quinze équipes de douze économies. La page de la conférence de 2003 date indépendamment la rencontre de Taipei des 24 et 25 février. Un souvenir de contact précoce n'est pas interchangeable avec un acte de constitution.

L'intérêt de ce réseau régional est de donner au relais local un chemin vers un interlocuteur étranger. Il ne lui confère pas de compétence sur les machines de cet interlocuteur. Rahardjo ne doit pas être présenté comme fondateur solitaire d'APCERT ni comme auteur de toutes ses politiques. Les contacts, les équipes et les décisions collectives restent plusieurs choses.

La liste actuelle des membres d'APCERT distingue d'ailleurs ID-CERT et Id-SIRTII/CC. Les deux noms ne doivent pas être fusionnés sous prétexte qu'ils concernent l'Indonésie. Le lecteur a besoin d'identifier le relais communautaire, l'opérateur qui peut modifier une infrastructure et les organismes dotés d'autres mandats. La précision des identités institutionnelles évite de prêter à la première équipe les pouvoirs d'une autre.

La référence RFC ne remplace pas ces mandats. RFC 2350, texte de 1998 signé par Nevil Brownlee et Erik Guttman, explique les informations qu'une équipe de réponse devrait communiquer : périmètre, autorité, services, procédures de divulgation et moyens de contact. Il souligne la participation des bénéficiaires et la coopération entre équipes. Rahardjo n'en est pas l'auteur, et remplir le canevas ne crée aucun droit de commande.

Sa contribution durable se situe donc dans une capacité intermédiaire. ID-CERT peut aider une information pertinente à franchir les frontières entre réseaux sans retirer leur contrôle aux exploitants. Le modèle conserve la possibilité d'une réponse distribuée. Il demande en échange que le coût du lien, la qualité du suivi et la responsabilité de l'action ne soient pas invisibles.

Les sources laissent plusieurs résultats ouverts. Nous ne disposons ici ni d'un bilan dossier par dossier attribuant les succès au fondateur, ni d'un taux national de réparation, ni du budget actuel. Les politiques publiques de l'équipe ne valent pas audit de performance. Ces inconnues empêchent une célébration sans nuance, mais elles ne retirent rien à la division de travail que la charte rend observable.

Le relais réussi n'est pas celui qui se prétend propriétaire de tout incident. C'est celui qui permet à une preuve d'atteindre une personne légitime, à une responsabilité d'être acceptée et à une action autorisée de produire un résultat vérifiable. L'apport de Rahardjo rappelle qu'un Internet partagé a besoin de cette confiance organisée, précisément parce qu'aucune boîte de réception ne commande tous ses réseaux.

Sources