Tout d'abord, je tiens à dire que ce n'est pas parce qu'une entreprise est grande que sa sécurité sera meilleure.

Cela dit, je mentionnerai qu'après avoir effectué un travail de sécurité dans une grande nombre de sociétés Fortune 500, y compris de nombreuses marques connues que la plupart des gens connaissent, je dirai qu'actuellement, 60 à 70% d'entre elles ne font pas autant que vous pensez qu'elles devraient faire. Certains donnent même à des centaines d'entreprises tierces à travers le monde un accès complet pour extraire de leur base de code, mais pas nécessairement y écrire.

Quelques-unes utilisent plusieurs référentiels privés Github pour des projets séparés avec l'authentification à deux facteurs activée et un contrôle strict sur les personnes auxquelles ils accordent l'accès et disposent d'un processus pour révoquer rapidement l'accès lorsque quelqu'un quitte.

Quelques autres sont très sérieux au sujet de la protection des choses, ils font donc tout en interne et utilisent quoi pour beaucoup d'autres les entreprises ressembleraient à des niveaux excessifs de contrôle de sécurité et de surveillance des employés. Ces entreprises 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 les paquets. trafic dans l'environnement où le code est stocké. Mais à partir de 2015, cette situation est encore très rare.

Ce 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. Certaines industries sont absolument horribles en matière de sécurité. Je mentionne cela parce qu'il y a d'autres dynamiques en jeu: il n'y a pas que les grandes entreprises par rapport aux petites, une grande partie est liée à 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 font aujourd'hui.

Cela dit, vous devez garder à l'esprit que les plus grands les 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, par le respect des chiffres trimestriels et par la concurrence pour la part de marché contre leurs autres grands concurrents que par les risques de sécurité, même si les risques pourraient effectivement détruire leur entreprise. Gardez cela à l'esprit lorsque vous lisez les réponses suivantes.

• Si le code source était volé:

  1. La plupart ne s'en soucieraient pas. n'aurait pratiquement aucun impact sur leur marque ou leurs ventes. Gardez à l'esprit que le code lui-même n'est dans de nombreux cas pas ce qui stocke la valeur de l'offre d'une entreprise. Si quelqu'un d'autre obtenait une copie de la source de Windows 10, il ne pouvait pas soudainement créer 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.

  2. 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, comme la plupart des entreprises ne surveillent pas sérieusement cela, il est très possible que cela soit arrivé à de nombreuses grandes entreprises, en particulier si l'accès détourné à leurs logiciels est d'une valeur significative pour d'autres États-nations. Cela arrive probablement beaucoup plus souvent que les gens ne le pensent.

• Attaquant interne: en fonction de l'intelligence de l'attaquant, cela peut ne jamais être remarqué ou ressembler à une erreur de programmation discrète. En dehors de la vérification des antécédents et de la surveillance du comportement, il n'y a pas grand-chose qui puisse empêcher cela, mais j'espère que certains outils d'analyse du code source attraperont cela et forceront l'équipe à le corriger. Il s'agit d'une attaque particulièrement difficile contre laquelle se défendre et c'est la raison pour laquelle certaines entreprises n'externalisent pas leur travail dans d'autres pays et ne vérifient pas les 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 viendront toujours avant les correctifs, ainsi traiter la plupart des problèmes de sécurité devient une sorte de course contre la montre. Les outils de sécurité vous permettent de faire des compromis sur le temps, mais vous n'aurez jamais une sécurité «parfaite» et s'en rapprocher peut coûter très cher en temps (ralentir les développeurs ou exiger beaucoup plus d'heures de travail ailleurs). >

Encore une fois, ce n'est pas parce qu'une entreprise est grande qu'elle bénéficie d'une bonne sécurité. J'ai vu des 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 souhaitent prendre leur sécurité plus au sérieux n'ont pas à faire les changements organisationnels, où les grandes entreprises seront obligées de s'en tenir à la façon dont elles faisaient les choses dans le passé en raison du coût de la transition.

Plus important encore, je pense qu'il est plus facile pour une nouvelle entreprise (quelle que soit sa taille, mais surtout les plus petites) d'intégrer la sécurité dans sa culture de base plutôt que de devoir changer sa culture actuelle / héritée comme les entreprises plus anciennes doivent le faire. Il peut même y avoir des opportunités maintenant de prendre des parts de marché à un produit moins sécurisé en créant une version très sécurisée de celui-ci. De même, je pense que votre question est importante pour une raison totalement différente: la sécurité en est encore à ses balbutiements, nous avons donc besoin de meilleures solutions dans des domaines comme la gestion du code où il y a beaucoup de place à 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 ne reflète pas la position de mon employeur ou des politiques.}

Tout d'abord, comment protéger le code contre les fuites:

• Sécurité du réseau: C'est la plus évidente - si les pirates chinois obtiennent des informations d'identification dans vos systèmes internes, ils iront chercher votre code source (si pour aucune autre raison que le fait que le code source leur dira où aller ensuite). Donc, la sécurité informatique de base doit être un "donné".
• Contrôle d'accès: Votre réceptionniste a-t-il besoin d'accéder à votre référentiel de codes? Probablement pas. Limitez votre exposition.
• Soyez sélectif dans l'embauche et maintenez un environnement de travail sain: les mesures DLP telles que la numérisation des e-mails sortants sont astucieuses en théorie, mais si votre ingénieur est assez intelligent pour être de quelle que soit votre utilité, ils sont suffisamment intelligents pour comprendre comment contourner vos mesures DLP. Vos employés ne devraient pas avoir de raison de divulguer votre code source. Si tel est le cas, vous avez fait quelque chose d'horriblement, d'horriblement mal.
• Surveillez votre réseau: Ceci est une extension de la réponse "sécurité du réseau" mais avec un accent sur la prévention des pertes numériques . Si vous voyez un pic soudain dans le trafic DNS, cela peut être votre code source exfiltré par un attaquant. OK, demandez-vous maintenant si vous sauriez s'il y a eu un pic soudain 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 très souvent. Ils sont également volés très souvent. Vous ne devez jamais stocker d'informations sensibles (y compris le code source, les données client et les secrets commerciaux) sur les appareils mobiles. Sérieusement. Jamais. Cela ne signifie pas que vous ne pouvez pas utiliser d'appareils mobiles pour accéder au code source et le modifier. Mais si un ordinateur portable disparaît, vous devriez pouvoir révoquer à distance tout accès de l'ordinateur portable aux données sensibles. En général, cela signifie que le code et les documents sont édité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, en fonction de la quantité de travail que vous souhaitez y consacrer. Si votre solution ne prend pas en charge 2 facteurs, choisissez une autre solution; vous voulez réduire votre exposition avec cette mesure, et non l'augmenter .

Deuxièmement, comment empêcher la modification de code malveillant; il n'y a vraiment qu'une seule réponse à cette question: le contrôle des changements.

Pour chaque caractère de code de 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 actuelle que c'est il est presque plus difficile de ne pas mettre en place un suivi des modifications. Si vous utilisez Git ou Mercurial ou tout autre système de contrôle de source modérément utilisable, vous bénéficiez d'un suivi des modifications et vous comptez beaucoup dessus.

Mais pour améliorer un peu la fiabilité, j'ajouterais que chaque changement à votre référentiel doit être signé par au moins une autre personne en plus de l'auteur soumettant la modification. 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, donc l'application de ces révisions au moment de l'enregistrement signifie que les acteurs malveillants ne peuvent pas agir seuls pour obtenir du mauvais code dans votre dépôt, cela aide à empêcher la validation d'un code mal écrit et permet de garantir 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, c'est-à-dire des bogues. Certains d'entre eux aideront é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 déroutant, il pourrait être rejeté comme étant de mauvais style et non maintenable.
• Le code a automatisé des tests unitaires et d'intégration. Quand il n'y a pas de test pour une certaine ligne de code, les gens se demandent. Il faudrait donc qu'il y ait un test pour que la porte dérobée fonctionne, ou une sorte d'obfuscation.
• Lorsqu'une nouvelle version du logiciel est construite, les développeurs et l'assurance qualité vérifient quels commits font partie de la construction et pourquoi . Chaque commit doit avoir un but 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, de telles mesures reposent sur l'honnêteté et la bonne volonté de tous les participants. Une personne disposant d'un accès administrateur au serveur de build 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 une clé USB chiffrée matérielle (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 d'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 infaillible, et il a un impact sur la bande passante - mais les outils d'audit à eux seuls ont détecté plusieurs instances d'employés (souvent des employés sur le point de quitter l'entreprise) qui ont tenté de prendre du code source / des documents de conception, etc. . Au moins, nous arrêtons certaines de ces tentatives.

Et au cas où quelqu'un penserait que les importations https seraient "invisibles": tout le trafic Web externe est géré par un proxy-in -le-cloud qui utilise un certificat MITM pour inspecter le trafic https. Il est sans aucun 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 comme je n'ai jamais travaillé dans ce secteur, mon idée pourrait être théorique ou très irréalisable.

Et si les employés à faible niveau de hiérarchie n'obtenaient que de petites parties du code source? L'équipe explorer.exe n'a besoin que d'accéder au code source de explorer.exe, ce qui rendrait le vol du code source de l'intérieur plus difficile 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'une bonne documentation sur toutes les parties dont l'équipe pourrait avoir besoin mais ne peut pas voir. De plus, le débogage deviendrait plus délicat car vous auriez à fusionner le code source pré-comilé avec celui fraîchement compilé de explorer.exe-Team.Il pourrait 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 ont besoin de 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 produit vraiment dans l'industrie ou ne pas. C'est juste un concept qui, à mon avis, aurait du sens pour empêcher le vol de code source.

La valeur marchande d'un logiciel est une fonction directe de

• La valeur des analyses de rentabilisation qu'il prend en charge. RoI, c'est-à-dire.
• Valeur marchande des produits concurrents
• Le fait qu'il continuerait à être amélioré et soutenu par l'entreprise
• Marque de l'entreprise. Effort de marketing et de vente autour du produit
• Nombre de clients, développeurs et membres de la communauté satisfaits existants
• Caractéristiques, LoC, nombre de brevets, exhaustivité et qualité du logiciel

Le code source fait donc simplement partie du jeu. Pas le tout.

Le code source lui-même est protégé par

• Contrats légaux / T&Cs signés par les employés et l'entrepreneur
• Brevets
• Décomposition du produit en plusieurs composants boîte noire auxquels aucune personne ou équipe n'a accès.
• Utilisation de mécanismes de sécurité au niveau logiciel et au niveau physique pour protéger l'accès au code