Comment les grandes entreprises protègent-elles leur code source?
J'ai récemment lu la réponse canonique de notre suzerain de l'urine à la question sur Comment les autorités de certification stockent-elles leurs clés racine privées?
Je devais alors me demander:
Comment les grandes entreprises (par exemple Microsoft, Apple, ...) protègent-elles leur précieux code source?
En particulier, je me demandais comment protéger leur code source contre le vol, contre les modifications malveillantes externes et contre les modifications malveillantes basées sur des initiés.
La première sous-question a déjà été (quelque peu) répondue en réponse de CodeExpress le Comment empêcher la divulgation de données privées en dehors de l'Organisation .
Le raisonnement des questions est simple:
- Si le code source était volé, a) l'entreprise serait-elle (au moins partiellement) empêchée de le vendre et b) le produit risquerait-il une recherche d'attaque basée sur le code source. Imaginez ce qui se passerait si le code source Windows ou iOS était volé.
- Si le code était modifié par des attaquants externes malveillants, des portes dérobées secrètes pourraient être ajoutées, ce qui pourrait être catastrophique. C'est ce qui s'est passé avec Juniper ces derniers temps, où les coordonnées du second
DUAL_EC_DRBGle point a été remplacé dans sa source. - Si le code devait être modifié par un attaquant interne (par exemple, un Apple iOS?), Cette personne pourrait gagner beaucoup d'argent en vendant lesdites portes dérobées et pourrait mettre le produit en danger si la modification version navires.
Veuillez ne pas proposer de "loi" et de "contrats". Bien qu'il s'agisse de mesures efficaces contre le vol et la modification, elles ne fonctionnent certainement pas aussi bien que les défenses techniques et n'empêcheront pas les attaquants agressifs ( c'est-à-dire d'autres agences gouvernementales).
Tout d'abord, je veux dire que ce n'est pas parce qu'une entreprise est grande que sa sécurité sera meilleure.
Cela dit, je mentionnerai qu'ayant effectué des travaux de sécurité dans un grand nombre d'entreprises du Fortune 500, y compris de nombreuses marques connues de la plupart des gens, je dirai qu'actuellement 60 à 70% d'entre elles ne font pas autant que vous pensez qu'ils devraient faire. Certains donnent même à des centaines de sociétés tierces du monde entier un accès complet pour tirer de leur base de code, mais pas nécessairement pour y écrire.
Quelques-uns utilisent plusieurs référentiels Github privés pour des projets séparés avec une authentification à deux facteurs activée et un contrôle serré sur qui ils accordent également l'accès et ont un processus pour révoquer rapidement l'accès quand quelqu'un part.
Quelques autres sont très sérieux au sujet de la protection des choses, alors ils font tout à la maison et utilisent ce que de nombreuses autres entreprises pourraient considérer comme des niveaux excessifs de contrôle de sécurité et de surveillance des employés. Ces sociétés utilisent des solutions telles que les outils de prévention de la perte de données (DLP) pour surveiller l'exfiltration de code, l'accès VPN interne à des environnements fortement renforcés uniquement pour le développement avec une tonne de contrôles et de surveillance de sécurité traditionnels et, dans certains cas, la capture complète de tous trafic dans l'environnement où le code est stocké. Mais en 2015, cette situation est encore très rare.
Quelque chose qui peut être intéressant et qui m'a toujours semblé inhabituel, c'est que le secteur financier, en particulier les banques, a une sécurité bien pire qu'on ne le pense et que l'industrie pharmaceutique est bien meilleure que d'autres industries, y compris de nombreux entrepreneurs de la défense. Il y a certaines industries qui sont absolument horribles en matière de sécurité. Je mentionne cela parce qu'il y a d'autres dynamiques en jeu: ce n'est pas seulement les grandes entreprises contre les petites, une grande partie a à voir avec la culture organisationnelle.
Pour répondre à votre question, je vais souligner que c'est l'entreprise dans son ensemble qui prend ces décisions et non les équipes de sécurité. Si les équipes de sécurité étaient en charge de tout, ou même étaient au courant de tous les projets en cours, les choses ne ressembleraient probablement pas à ce qu'elles sont aujourd'hui.
Cela dit, vous devez garder à l'esprit que la plupart des grandes entreprises sont cotées en bourse et, pour un certain nombre de raisons, ont tendance à être beaucoup plus préoccupées par les bénéfices à court terme, les chiffres trimestriels et la concurrence pour la part de marché contre leurs autres grands concurrents que sur les risques de sécurité. , même si les risques pouvaient effectivement détruire leur entreprise. Gardez donc cela à l'esprit lorsque vous lisez les réponses suivantes.
Si le code source a été volé:
une. La plupart ne s'en soucieraient pas et cela n'aurait presque aucun impact sur leur marque ou leurs ventes. Gardez à l'esprit que le code lui-même n'est pas, dans de nombreux cas, ce qui stocke la valeur d'une offre d'entreprise. Si quelqu'un d'autre obtenait une copie de la source Windows 10, il ne pourrait pas créer soudainement une entreprise vendant un système d'exploitation clone Windows 10 et être en mesure de le prendre en charge. Le code lui-même n'est qu'une partie de la solution vendue.
b. Le produit serait-il plus à risque à cause de cela? Oui absolument.
Modification externe: Oui, mais c'est plus difficile à faire et plus facile à attraper. Cela dit, puisque la plupart des entreprises ne surveillent pas sérieusement cela, il est très possible que cela soit arrivé à de nombreuses grandes entreprises, surtout si l'accès détourné à leurs logiciels est d'une valeur significative pour d'autres États-nations. Cela se produit probablement beaucoup plus souvent que les gens ne le pensent.
Attaquant interne: selon le degré d'intelligence de l'attaquant, cela peut même ne jamais être remarqué ou pourrait ressembler à une erreur de programmation discrète. En dehors des vérifications des antécédents et de la surveillance du comportement, il n'y a pas grand-chose qui puisse empêcher cela, mais nous espérons que certains outils d'analyse de code source pourraient détecter cela et forcer l'équipe à le corriger. Il s'agit d'une attaque particulièrement difficile à défendre et c'est la raison pour laquelle quelques entreprises ne sous-traitent pas le travail à d'autres pays et font des vérifications approfondies des antécédents de leurs développeurs. Les outils d'analyse de code source statique s'améliorent, mais il y aura toujours un écart entre ce qu'ils peuvent détecter et ce qui peut être fait.
En un mot, les trous sortiront toujours avant les correctifs, donc traiter la plupart des problèmes de sécurité devient une sorte de course contre la montre. Les outils de sécurité vous aident à faire des compromis sur le temps, mais vous n'aurez jamais une sécurité "parfaite" et vous en approcher peut devenir très coûteux en temps (ralentir les développeurs ou nécessiter beaucoup plus d'heures de travail ailleurs).
Encore une fois, ce n'est pas parce qu'une entreprise est grande qu'elle a une bonne sécurité. J'ai vu quelques petites entreprises avec beaucoup une meilleure sécurité que leurs concurrents plus importants, et je pense que ce sera de plus en plus le cas, car les petites entreprises qui veulent prendre leur sécurité plus au sérieux n'ont pas à faire des efforts massifs les changements organisationnels, où les grandes entreprises seront obligées de s'en tenir à la façon dont elles ont fait les choses dans le passé en raison des coûts de transition.
Plus important encore, je pense qu'il est plus facile pour une nouvelle entreprise (de toute taille, mais surtout de plus petite taille) d'avoir une sécurité fortement intégrée dans sa culture de base plutôt que de devoir changer sa culture actuelle/héritée comme les entreprises plus âgées doivent le faire. Il peut même y avoir maintenant des opportunités de prendre des parts de marché au produit moins sécurisé en en créant une version très sécurisée. De même, je pense que votre question est importante pour une raison totalement différente: la sécurité est encore à ses balbutiements, nous avons donc besoin de meilleures solutions dans des domaines comme la gestion de code où il y a beaucoup de place pour l'amélioration.
Clause de non-responsabilité : Je travaille pour une très grande entreprise qui fait du bon travail dans ce domaine, mais ma réponse est mon opinion personnelle et n'indique pas mon la position ou les politiques de l'employeur.
Tout d'abord, comment protéger le code contre les fuites:
- Sécurité du réseau: Ceci est évident - si les pirates chinois obtiennent des informations d'identification dans vos systèmes internes, ils iront chercher votre code source (sinon autre raison que le fait que le code source leur indiquera où aller ensuite). La sécurité informatique de base doit donc être un "acquis".
- Contrôle d'accès: Votre réceptionniste a-t-elle besoin d'accéder à votre référentiel de code? Probablement pas. Limitez votre exposition.
- Soyez sélectif dans l'embauche et maintenez un environnement de travail sain: Les mesures DLP comme l'analyse des e-mails sortants sont astucieuses en théorie, mais si votre ingénieur est assez intelligent pour être quelle que soit votre utilisation, ils sont assez intelligents pour comprendre comment contourner vos mesures DLP. Vos employés ne devraient pas avoir de raison pour divulguer votre code source. S'ils le font, vous avez fait quelque chose d'horriblement, horriblement mal.
- Surveillez votre réseau: Il s'agit d'une extension de la réponse "sécurité réseau" mais avec un accent sur la prévention des pertes numériques. Si vous voyez un pic soudain de trafic DNS, cela peut être votre code source qui est exfiltré par un attaquant. OK, demandez-vous maintenant si vous voudriez même savoir s'il y avait une augmentation soudaine du trafic DNS de votre réseau. Probablement pas.
- Traitez les appareils mobiles différemment: Les téléphones et les ordinateurs portables se perdent vraiment souvent. Ils sont également volés vraiment souvent. Vous ne devez jamais stocker d'informations sensibles (y compris le code source, les données client et les secrets commerciaux) sur des appareils mobiles. Sérieusement. Jamais. Cela ne signifie pas que vous ne pouvez pas utiliser d'appareils mobiles pour accéder et modifier le code source. Mais si un ordinateur portable disparaît, vous devriez pouvoir révoquer à distance tout accès que l'ordinateur portable a aux données sensibles. Cela signifie généralement que le code et les documents sont modifiés "dans le cloud" (voir c9.io, koding.com, Google Docs, etc.) avec une authentification appropriée et tout cela. Cela peut être fait avec ou sans faire confiance à un tiers, selon la quantité de travail que vous souhaitez y consacrer. Si votre solution ne prend pas en charge le facteur 2, choisissez une autre solution; vous voulez réduire votre exposition avec cette mesure, pas augmenter.
Deuxièmement, comment empêcher la modification de code malveillant; il n'y a vraiment qu'une seule réponse à cette question: changer le contrôle.
Pour chaque caractère de code dans votre référentiel, vous devez savoir exactement qui a ajouté (ou supprimé) ce code, et quand. C'est si facile à faire avec la technologie d'aujourd'hui qu'il est presque plus difficile pas d'avoir un suivi des changements en place. Si vous utilisez Git ou Mercurial ou tout autre système de contrôle de source modestement utilisable, vous bénéficiez d'un suivi des modifications et vous comptez beaucoup sur lui.
Mais pour augmenter un peu la fiabilité, j'ajouterais que chaque modification de votre référentiel doit être approuvée par au moins une autre personne en plus de l'auteur qui soumet le changement. Des outils comme Gerrit peuvent rendre cela simple. De nombreux régimes de certification nécessitent de toute façon des révisions de code, de sorte que l'application de ces révisions au moment de l'enregistrement signifie que les acteurs malveillants ne peuvent pas agir seuls pour introduire du mauvais code dans votre référentiel, empêche la validation de code mal écrit et garantit qu'au moins 2 les gens comprennent chaque changement soumis.
Il y aura des mesures en place pour empêcher l'insertion accidentelle de code problématique, alias bogues. Certains d'entre eux contribueront également à éviter l'insertion délibérée de code problématique.
- Lorsqu'un développeur souhaite valider du code dans le référentiel, un autre développeur doit examiner cette demande de fusion. Peut-être que le deuxième développeur devra expliquer au premier développeur ce que fait le nouveau code. Cela signifie parcourir chaque ligne.
- Si le code semble confus, il peut être rejeté comme un mauvais style et non maintenable.
- Le code comporte des tests unitaires et d'intégration automatisés. Quand il n'y a pas de test pour une certaine ligne de code, les gens se demandent. Il devrait donc y avoir un test de fonctionnement de la porte dérobée, ou une sorte d'obscurcissement.
- Lorsqu'une nouvelle version du logiciel est construite, les développeurs et l'assurance qualité vérifient quels engagements font partie de la construction et pourquoi. Chaque commit doit avoir un objectif documenté.
- Le logiciel est construit et déployé à l'aide de scripts automatisés. Ce n'est pas seulement pour la sécurité mais aussi pour simplifier la charge de travail.
Bien entendu, ces mesures reposent sur l'honnêteté et la bonne volonté de tous les participants. Quelqu'un avec un accès administrateur au serveur de construction ou au référentiel pourrait faire beaucoup de ravages. D'un autre côté, les programmeurs ordinaires n'ont pas besoin de ce type d'accès.
Dans ma (grande) entreprise, nos ordinateurs portables utilisent tous des disques durs cryptés. Nous utilisons un outil appelé Digital Guardian qui surveille tous les transferts/téléchargements de fichiers et qui bloque les ports USB pour l'écriture de fichiers. Quiconque a besoin d'une exception doit utiliser un lecteur USB chiffré par le matériel (encore une fois, pour empêcher l'accès aux fichiers en cas de perte ou de vol du lecteur). De telles exceptions sont temporaires et il faut justifier les fichiers en cours d'écriture (qui sont journalisés). Digital Guardian empêche l'envoi de la plupart des types de pièces jointes à des adresses e-mail externes. Tout échange de fichiers interne se fait à l'aide de dossiers Web avec contrôle d'accès et une piste d'audit de qui a accédé à quoi - cela signifie que le partage de fichiers "pour les besoins de l'entreprise" est assez transparent, et tout le reste est difficile.
Le système n'est pas à toute épreuve et il a un impact sur la bande passante - mais les outils d'audit à eux seuls ont révélé plusieurs instances d'employés (souvent des employés qui étaient sur le point de quitter l'entreprise) qui ont tenté de prendre le code source/les documents de conception, etc. Au moins, nous arrêtons certains de ces tentatives.
Et au cas où quelqu'un penserait que les téléchargements https seraient "invisibles": tout le trafic Web externe est géré par un proxy dans le cloud qui utilise un certificat MITM pour inspecter le trafic https. Il est sans doute possible de contourner ces mesures - il y a beaucoup d'employés intelligents - mais parfois cela suffit pour rendre votre cible plus difficile que les autres.
C'est une question délicate et parce que je n'ai jamais travaillé dans cette industrie, mon idée pourrait être théorique ou très impraticable.
Que se passe-t-il si les employés de faible hiérarchie n'obtiennent que de petites parties du code source? L'équipe Explorer.exe a uniquement besoin d'accéder au code source d'Explorer.exe. Cela rendrait plus difficile le vol du code source de l'intérieur, car vous auriez besoin d'être dans des positions plus élevées pour avoir un aperçu de plus de parties du code source.
Bien sûr, vous auriez besoin d'avoir une bonne documentation sur toutes les parties dont l'équipe pourrait avoir besoin mais ne peut pas voir. Le débogage deviendrait également plus délicat car vous auriez à fusionner le code source précompilé avec le code fraîchement compilé de l'équipe Explorer.exe. Il peut y avoir un serveur de compilation qui contient tout le code source et peut compiler des versions complètes du produit même pour ceux qui n'ont édité qu'un petit morceau. (Parce qu'ils doivent tester leurs modifications) Ce serveur sait également qui a accès à quelles parties du code.
Je ne sais pas si c'est une approche pratique ou si cela se passe vraiment dans l'industrie ou non. C'est juste un concept qui, je pense, aurait du sens pour empêcher le vol de code source.