Développement et production séparés

Il est courant de donner aux développeurs des droits d'administrateur / root local sur leur poste de travail. Cependant, les développeurs ne doivent avoir accès qu'aux environnements de développement et ne jamais avoir accès aux données en direct. Les administrateurs système - qui ont accès à la production - devraient avoir des postes de travail beaucoup plus contrôlés. Idéalement, les postes de travail sys-admin ne devraient pas avoir accès à Internet, bien que cela soit rare dans la pratique.

Une variante que j'ai vue est que les développeurs ont une version d'entreprise verrouillée, mais peuvent faire ce qu'ils veulent dans le virtuel Machines. Cependant, cela peut être ennuyeux pour les développeurs, car les machines virtuelles ont des performances réduites et les avantages en matière de sécurité ne sont pas si grands. Il est donc plus courant de voir les développeurs avoir simplement un accès complet à leur propre poste de travail.

Cette réponse vient donc du point de vue d'un développeur. Garde cela à l'esprit.

Premièrement, ne pas avoir les droits "d'administrateur local" sur ma propre machine est un signe que je devrais chercher un emploi ailleurs. Il est presque impossible d'écrire du code, de manipuler des choses et de maintenir une chaîne d'outils si vous devez demander la permission chaque fois que vous devez mettre à jour (ou tester) une nouvelle dépendance ou un nouvel outil. Voici donc les niveaux d'autorisation dont je ai besoin . Gardez à l'esprit que je suis généralement assez haut sur l'échelle pour ainsi dire.

• Administrateur total et complet sur ma machine locale
• Administrateur total et complet sur tout le matériel de développement et de test
• Un certain niveau d'accès administrateur à la production serveurs (cela devient difficile, je n'ai pas besoin de tout ou je ne veux pas de tout, mais j'ai besoin de suffisamment pour diagnostiquer et résoudre les problèmes qui se produisent en production, et suffisamment pour déployer du code (en supposant que je suis celui qui doit superviser le déploiement du code). Habituellement, ce niveau d'accès évolue avec le temps, mais commence par les fichiers journaux.

Moins que cela, et vous pouvez aller trouver un nouveau développeur.

Cela dit, là Ce niveau d'accès comporte beaucoup de risques. Donc, ce que je recommande normalement, c'est un réseau séparé. Mettez tous les "trucs" de développement dans son propre réseau. Son propre AD, son propre hébergement de fichiers, son propre tout, et ne jamais laisser il parle au réseau de production. (Mais laissez-le sortir sur Internet)

Oui, cela signifie du matériel dupliqué (ou VPS) mais vous en avez de toute façon besoin pour les tests. Oui, cela signifie un peu plus de dépassement ead lors de la mise à niveau ou de l'administration, mais encore une fois, c'est nécessaire pour les tests. Vous avez également besoin d'un endroit pour voir "Qu'arrive-t-il au logiciel X si je mets à niveau le serveur AD?" Regardez que vous avez tout un réseau de machines de test prêtes pour ce type de test.

Ce que j'ai implémenté avec succès (avec l'aide d'une bonne équipe informatique) est un VLAN séparé pour tous les "trucs" de développement et un seul hôte VPS auquel le développeur a un accès complet, pour faire ce qu'il veut. Sur cet hôte se trouve un serveur AD configuré par le service informatique pour ressembler à une version plus petite du serveur AD de l'entreprise. Ensuite, un ensemble de documents et de directives sur ce qu'un serveur Web, par exemple, doit exécuter. Ce qu'un serveur DNS doit exécuter, ce qu'un serveur xyz doit exécuter. Ensuite, une partie du «développement» consiste à installer et configurer ces VPS pour notre usage. Tout ce qui se trouve sur ce VLAN est totalement isolé de la production et considéré comme externe à l'entreprise. Enfin, un ensemble de "punch through" est créé pour les ressources auxquelles nous avons besoin d'accéder (comme le courrier électronique). Normalement, cela était géré comme si nous étions externes, et la liste de ces outils était très petite.

Du point de vue d'un développeur:

Votre travail est d'empêcher le changement (les bogues et vulnérabilités connus valent mieux que l'inconnu, non?), mais le mien est de changer les choses. Cela nous met dans une impasse. Mon travail consiste à créer / changer des choses. Si votre politique empêche cela, alors, comme tout autre obstacle, une partie de mon travail consiste à trouver un moyen de contourner cela.

Selon vous, lequel est le plus dangereux, un développeur auquel vous avez accordé l'accès aux choses dont il a besoin pour faire son travail, ou à quelqu'un qui a obtenu cet accès en apprenant à contourner toutes vos mesures défensives? Et pourquoi votre entreprise vous paie-t-elle, vous et vos développeurs, pour mener cette guerre les uns contre les autres alors que vous devriez travailler ensemble?

La réponse simple est: donnez aux développeurs l'accès à ce dont ils ont besoin pour faire leur travail. Et parlez avec eux. Dans de rares cas (rétro-ingénierie en salle blanche avec des conséquences juridiques majeures ou traitement de données gouvernementales classifiées top-secrètes), vous avez besoin d'une politique plus complexe. Mais pour la plupart, ce n'est pas si grave. Si vous commencez une guerre et rendez vos développeurs ennemis, ils partiront ou deviendront beaucoup plus dangereux que si vous travaillez avec eux.

Les mesures sensées incluent l'interdiction des sauvegardes de bases de données de production sur les ordinateurs portables de développement (testant uniquement les bases de fausses données). De cette façon, si l'ordinateur portable est volé, aucune donnée confidentielle n'est perdue. Mais si le développeur a besoin de déboguer des choses, il a toujours besoin d'accéder à des copies de la base de données de production quelque part dans un environnement contrôlé.

Restreindre l'accès à Internet est ridicule. Vous pourriez aussi demander à tous vos développeurs d’écrire leur code sur papier avec une plume et de l’encre.

Parlez à vos développeurs, trouvez un moyen de leur donner ce dont ils ont besoin pour faire leur travail tout en conservant le sécurité dont vous avez besoin pour sécuriser les données importantes. Les détails dépendront de votre entreprise et des données avec lesquelles vous traitez. Mais il est peu probable que des mesures draconiennes soient nécessaires.

Un ingénieur en sécurité n'entretient pas les ordinateurs, c'est ce que fait le centre de services. Dans votre cas, vous lui demanderez d'installer trois outils:

• un hyperviseur
• docker
• logiciel de base de données

En termes de voyous, je ne peux qu'imaginer un attaquant ayant accès et ajoutant plus de code. C'est pourquoi vous devez avoir la sécurité intégrée à chaque étape du SDLC pour vous assurer que tout le code est au moins revu ou passé par un autre développeur avant de le pousser dans l'arborescence. En outre, vous pouvez également intégrer des scanners de code pour rechercher automatiquement les stubs de code suspects ou vulnérables.

Sur votre troisième point, cela dépend en fait. C'est exactement ce que font des entreprises comme Riot Games. Ils ont découvert que limiter les individus intelligents conduirait ces individus à contourner les contrôles. Ils ont donc décidé d'utiliser des règles simples et une formation de sensibilisation efficace pour s'assurer qu'ils gardent la sécurité à l'esprit et qu'ils accordaient tous les privilèges administratifs. Ils ont distribué de petites cartes indiquant ce dont ils devaient s'occuper et faire attention.

Nous donnons à nos développeurs un accès administrateur sur leurs ordinateurs et leur faisons savoir quelles sont les règles. La plupart fonctionnent sous Linux, mais nous avons également quelques développeurs sur Windows. Ils savent tous stocker leurs documents, conceptions, etc. sur nos partages de fichiers (qui ont des autorisations plus spécifiques) et pousser leur code source sur notre serveur Git.

Ils savent aussi que je ne passerai pas beaucoup de temps pour résoudre un problème avec leur système d'exploitation. Si leur ordinateur fonctionne mal, nous allons souvent l'effacer et réinstaller le système d'exploitation. Les applications et paramètres courants sont automatiquement installés via Puppet et ils devront faire le reste eux-mêmes. La plupart d'entre eux ont un Git-repo avec des fichiers dotfiles (les paramètres et les préférences de leur environnement).

Le temps qu'ils perdent dans un tel cas est une motivation suffisante pour la plupart d'entre eux. Ils aiment travailler au lieu de jouer avec la réparation de leur système d'exploitation. S'ils perdent un travail important parce qu'il a été stocké uniquement localement, ils seront désapprouvés par leurs collègues et leur patron.

Nous ne bloquons aucun site Web ni aucune application (à l'exception d'un filtre anti-malware basé sur DNS ) mais ont des règles de politique d'entreprise sur des choses comme les logiciels illégaux. Nous comptons sur la pression des pairs pour la plupart des choses. Les gens qui passent leur temps sur Facebook ne sont pas productifs et ne durent pas longtemps. La plupart de nos règles sont basées sur un système d'honneur et cela semble bien fonctionner.

Cela dépend fondamentalement du contexte. Considérez les deux configurations suivantes, que j'ai toutes deux rencontrées dans la nature:

• Les développeurs travaillent sur des machines qu'ils possèdent ou ont un accès complet, y compris l'installation de leurs propres systèmes d'exploitation. Il n'y a aucune restriction sur la façon dont ils écrivent l'application. Ils ont un accès SSH aux systèmes de production chaque fois qu'ils sont connectés au réseau, y compris VPN.
• Tout le développement est effectué dans un laboratoire de développement à vide, dans lequel les développeurs ne sont pas autorisés à importer des appareils électroniques. Tous les ordinateurs ont tous les logiciels autorisés préinstallés. Les artefacts déployables sont livrés en toute sécurité sur un support physique à une autre équipe, qui est responsable du déploiement.

Ces deux configurations étaient appropriées dans leur contexte - en tenant compte des menaces auxquelles l'organisation était confrontée et des besoins du projet.

Il y a ici un compromis fondamental. Tout éloignement de la première possibilité vers la seconde réduit la productivité. Quiconque a un contrôle sur l'application occupe une position de confiance. Tout ce que vous ne pouvez pas leur faire confiance est quelque chose dont vous devrez soit vous passer, soit créer un processus de transfert pour quelqu'un d'autre. Vous ne pouvez pas révoquer la confiance sans réduire la productivité.

Cela dépend du type de logiciel que vous développez et de la taille de votre organisation.

Pour un seul poste de travail de développeur Rockstar dans une petite entreprise, j'utiliserais une exception de sécurité de niveau exécutif. Les risques (y compris la gêne de l'informatique, des dirigeants et des autres développeurs) devraient être discutés, mais finalement, si la rockstar ne réussit pas, il va probablement passer dans une autre entreprise. Ces gars-là ne tolèrent pas les frictions, s'ils les rencontrent, ils peuvent facilement trouver des endroits plus intéressants pour travailler.

Un scénario plus typique qu'un uber-workstation est d'avoir un cluster de développement où les opérations gèrent la vie et mort des VM, l'environnement est surveillé avec IDS / IPS et l'accès Internet (sur le cluster de développement) est limité mais ouvert selon les besoins. Par exemple, pour la documentation ... rien de mal à mettre sur liste blanche toutes les sources technologiques liées à votre effort de développement. Les développeurs ne peuvent de toute façon pas extraire du code bon gré mal gré. Ils ont besoin de documenter leurs sources et de vérifier les licences étranges.

Si vous pouvez obtenir l'oreille de la rockstar, il peut aider à pousser les exigences vers les opérations et les cadres et concevoir le cluster et les processus, et éduquer les équipes de développement sur le besoin.

S'il y a un budget et que le développeur est réticent ... alors à mon humble avis, vous n'avez pas affaire à une rockstar, mais une diva et ses gémissements devraient être portés jusqu'à ce risque exécutif approbation.

Le plus dur est de gérer la durée de vie des machines et de s'assurer que les réflexions ultérieures des développeurs ne deviennent pas des systèmes de production-développeurs "semblables à des opérations". Mais c'est beaucoup plus facile que les VM sur les postes de travail des développeurs.

Cette question soulève un certain nombre de questions et de défis intéressants. Quelqu'un qui a travaillé en tant que développeur pendant de nombreuses années puis est passé à la sécurité, Ican apprécie de nombreux arguments et points de vue exprimés dans les réponses et commentaires. Malheureusement, il n'y a pas de réponse définitive car la bonne solution dépend du contexte, de l'exposition au risque et de l'appétit pour le risque de l'organisation.

La sécurité n'est pas quelque chose que vous pouvez mesurer en absolu. Chaque fois que vous rencontrez une personne de sécurité qui parle constamment de manière absolue et insiste sur l'application de politiques spécifiques indépendamment de toute autre chose, elle est inexpérimentée ou incompétente. Le rôle de l'ingénieur de sécurité est de faciliter les processus métier, non de les entraver et de s'assurer que les décisions commerciales sont prises en tenant compte des risques de sécurité pertinents. Un bon ingénieur en sécurité saura que toute politique qui empêche le personnel de faire son travail échouera inévitablement car le personnel trouvera des moyens de contourner la politique. Le plus souvent, ces travaux seront encore moins sécurisés. Il est de la responsabilité du responsable de la sécurité de comprendre les différents rôles au sein de l'organisation et de s'assurer que les politiques sont structurées de manière à non seulement soutenir ce que le rôle exige, mais aussi encourager les bonnes pratiques et décourager les mauvaises. Cela peut être très difficile, en particulier dans les grandes organisations. Dans le même temps, les développeurs et autres personnes au sein de l'organisation doivent également reconnaître qu'ils peuvent ne pas avoir toutes les informations pertinentes pour comprendre pourquoi certaines politiques sont nécessaires. Trop souvent, les développeurs et autres voient l'ingénieur en sécurité comme un obstacle ou un bureaucrate interférant qui ne comprend pas ce dont ils ont besoin pour faire leur travail.

Le plus souvent, la manière de résoudre ces problèmes est la communication. Des développeurs sont souvent venus me voir frustrés parce qu'une politique qu'ils considèrent comme inutile les gêne. Une fois que nous nous asseyons et discutons de la problème, un certain nombre de choses se produisent généralement;

• Le développeur a soit mal interprété la politique, soit elle a lu des hypothèses incorrectes et a eu l'impression que la politique empêche quelque chose qui n'est pas le cas. Cela aboutira souvent à un examen de la politique pour améliorer la clarté
• L'ingénieur de sécurité prend connaissance d'une exigence commerciale légitime qui doit être satisfaite de manière à maintenir des contrôles de sécurité adéquats. Cela entraînera probablement un examen de la politique.
• Le développeur prend conscience d'une autre exigence ou d'un risque qui ne lui était pas évident au départ. Cela conduit souvent le développeur à identifier des solutions alternatives pour satisfaire ses exigences
• Un problème est identifié qui ne peut être résolu à la satisfaction de l'une ou l'autre des parties d'une manière qui respecte l'appétit pour le risque accepté de l'organisation (c'est-à-dire les niveaux de risque acceptés ). Cette situation entraînera généralement une remontée du problème au niveau exécutif pour une décision. La difficulté à faire cela dépendra de la taille et de la structure de l'organisation. Une fois la décision prise, le développeur et l'ingénieur de sécurité doivent travailler selon les paramètres définis par l'exécutif pour trouver la meilleure solution possible.

Un certain nombre de réponses sont essentielles des politiques qui ont un impact négatif sur leur niveau de productivité. Alors que tout développeur devrait soulever de telles préoccupations, en fin de compte, il doit soit accepter la décision prise par le dirigeant, soit rechercher un autre employeur. Il est arrogant et dangereux pour vous et votre employeur de supposer que vous savez mieux ou que vous avez un droit spécial d'ignorer la politique. Si vous êtes convaincu que vous avez raison, vous devriez être en mesure de convaincre la direction. Si vous ne pouvez pas, soit vous n'êtes pas aussi bon que vous le pensez, manquez de compétences en communication adéquates pour présenter un argument convaincant, ne possédez pas toutes les informations ou travaillez pour un employeur incompétent. Après 35 ans dans l'industrie et malgré ce que Dilbert peut vous amener à penser, ce dernier n'est pas aussi courant qu'on pourrait s'y attendre. La source de conflit la plus courante dans ce domaine est due à une mauvaise communication et au manque d’informations.

Un échec courant parmi les développeurs (et dont j’ai été coupable) est de se concentrer tellement sur votre tâche ou objectif spécifique que vous manquez la plus grande image que les chefs d'équipe, les gestionnaires et la direction doivent également gérer. Environnements où les développeurs ont eu beaucoup de liberté et de confiance, ce qui a abouti à des niveaux élevés de productivité, mais cela a entraîné d'autres problèmes - la situation où un développeur clé est parti ou est malade pendant une période prolongée et personne d'autre ne peut récupérer son fonctionne parce que tout est sur leur bureau configuré et géré de manière unique ou tente de déboguer un problème difficile qui ne peut pas être facilement reproduit en raison d'un manque de configurations / configurations standard, ou de faire face à une éventuelle faille de sécurité due à un développeur laissant accidentellement un service en cours de développement et manquait de contrôles de sécurité standard. Être un développeur concentré sur un domaine ou une technologie spécifique ne garantit pas également une expertise dans tout le reste. Certains des meilleurs développeurs avec lesquels j'ai travaillé ont été parmi les pires en matière de sécurité et / ou de gestion de leur environnement. Cela est probablement dû en partie à l'accent mis sur un problème spécifique et plus probablement simplement à la capacité. Aucun de nous n'a la capacité de tout traverser et nous devons reconnaître qu'il est parfois important de s'en remettre à ceux qui se spécialisent dans des domaines que nous n'avons pas.

L'environnement en évolution

L'une des principales raisons pour lesquelles les politiques limitent ce qui peut être fait sur le bureau est due à l'hypothèse sous-jacente que les postes de travail du réseau local ont un niveau de confiance plus élevé que bureaux hors du réseau. Traditionnellement, ils sont à l'intérieur du pare-feu et d'un autre périmètre défenses et avoir un accès mobile aux ressources d'information. Cela signifie qu'ils présentent un risque plus élevé et nécessitent donc davantage de contrôles de sécurité. D'autres raisons de politiques / pratiques restrictives incluent la normalisation des environnements, qui peut réduire les coûts de support et augmenter la cohérence (ce qui était particulièrement vrai lorsqu'il y avait plus d'applications dépendant de la plate-forme / du système d'exploitation - rappelez-vous toutes ces horribles applications qui nécessitaient AtiveX ou une version spécifique de l'IE).

La croissance des machines virtuelles et des conteneurs, des services cloud et des services informatiques de base et l'augmentation de la capacité du réseau entraînent un certain nombre de changements qui rendront probablement la plupart des problèmes soulevés dans ce fil non pertinents. En particulier, le passage aux réseaux de confiance zéro entraînera probablement des changements importants. Dans un réseau sans confiance, les périphériques à l'intérieur du réseau ne sont pas considérés comme ayant un niveau de confiance supplémentaire spécial par rapport aux périphériques en dehors du réseau. Vous n'avez pas la possibilité d'accéder aux ressources simplement parce que vous avez la bonne adresse IP. Au lieu de cela, la confiance repose davantage sur une combinaison d'informations sur l'utilisateur et l'appareil. La politique qui détermine ce à quoi vous pouvez accéder est déterminée par vos informations d'identification et l'appareil à partir duquel vous vous connectez. L'endroit où se trouve cet appareil n'a pas d'importance. C'est aussi un modèle qui s'adapte beaucoup mieux à la croissance du BYOD et à la mobilité accrue de la main-d'œuvre et à la demande croissante d'employer du personnel en fonction des seuils / capacités et de l'emplacement non géographique.

Une fois que vous supprimez le niveau de «confiance» associé à l'appareil, vous n'exigez pas de contrôle sur ce que vous pouvez appliquer à l'appareil. Vous pouvez toujours avoir besoin d'appareils pour prendre en charge des profils spécifiques - par exemple, vous pouvez refuser à quiconque d'accéder à vos ressources si son appareil exécute Windows XPetc. Cependant, vous êtes moins préoccupé par l'appareil. De même, vous ne travaillerez pas autant directement sur l'appareil. Dans une certaine mesure, l'appareil sera plus comme un client léger. Vous utiliserez des VM et des conteneurs hébergés à distance. Cela ne résoudra pas en soi tous les problèmes et peut être considéré comme un simple déplacement de certains d'entre eux du bureau local vers la VM ou le conteneur distant. Cependant, une fois que vous combinez cela avec diverses orchestrations de style DevOps, de nombreuses raisons pour lesquelles les développeurs peuvent avoir besoin de privilèges améliorés sont supprimées. Par exemple, vous pouvez ne pas avoir besoin d'accès aux systèmes de production. La promotion d'un nouveau code sera gérée via un système d'intégration continue orchestré et lorsque vous avez besoin de déboguer un problème, vous recevrez une VM ou un conteneur qui est un clone exact du système de production.

Aucune de ces modifications ne sera résoudre n'importe quoi par magie, mais ils fourniront une gamme plus large d'outils et de solutions plus flexibles avec potentiellement moins de complexité. Réduire la complexité rendra la gestion de la sécurité beaucoup plus facile. Une gestion de la sécurité plus simple entraînera moins de restrictions ou d'obstacles involontaires ou inutiles à l'exécution des tâches. Cependant, à la fin de la journée, les exigences clés sont

• La reconnaissance par tous qu'une seule taille ne convient pas à tous. Tout doit être évalué dans le contexte de l'organisation.
• Volonté de mettre les besoins de l'organisation en premier.
• Bonne communication bidirectionnelle.
• Volonté de toutes les parties de travailler à des solutions mutuellement acceptables et
• Volonté de toutes les parties de faire des compromis
• Volonté de travailler au sein du système et d'ajuster votre flux de travail ou la manière préférée de faire les choses pour s'adapter aux exigences de l'organisation

Je suis aussi développeur et voici mon avis:

Le problème est pire que vous ne le pensez

Il n'y a pas de cuillère

Le développement n'est pas une question Logiciel. Le développement consiste à fabriquer ou à améliorer des produits, des services et des processus. Le logiciel est un équipement important, mais ce n'est pas le seul. Les bons développeurs définiront les processus au sens large pour savoir quels composants logiciels créer ainsi que quel processus humain, logistique et de gestion des risques proposer. Cela n'a aucun sens de développer un système logiciel qui dépend de processus humains, logistiques et papier qui ne sont pas implémentés.

Il n'y a pas de règles pour le développement car le développement définit les règles. C'est ce qui fait du développement le pire environnement à sécuriser.

Mais cela ne veut pas dire que certains contrôles ne doivent pas être établis. Au contraire, de nombreux contrôles doivent être mis en place par l'équipe de développement elle-même.

Processus d'ingénierie

Il existe des entreprises qui préconisent la séparation entre les activités et la technologie dans un processus descendant. C'est en fait très populaire car cela suggère que les gens d'affaires sans connaissances techniques devraient être au top. Les paresseux adorent ça . Mais en ingénierie, une conception descendante ne fonctionne tout simplement pas. Feyman (1985) a fait un bel article à ce sujet dans la commission présidentielle qui a analysé l'explosion du Challenger. Fondamentalement, l'ingénierie des processus descendants finit par briser l'entreprise. Et mon expérience du marché renforce cette compréhension.

L'explosion du Challenger en est un excellent exemple. Les responsables de la Nasa témoignent devant une caméra lors d'une commission d'enquête qu'ils ont développé un caoutchouc qui peut rester flexible sous 60 degrés sous le point de congélation. Une chose qui a été contredite par une simple expérience physique au lycée faite par l'un des commissaires (mettre le composant en caoutchouc dans de l'eau glacée pressée par une pince). C'était un excellent exemple parce que ce composant en caoutchouc devait être flexible pour que le booster n'explose pas; comme il fallait des températures estivales pour ce faire, le booster ne fonctionnait qu'en été. Une caractéristique d'un seul composant définit une caractéristique visible de l'ensemble du produit qui est très limitative.

L'ingénierie doit se faire de bas en haut car vous devez connaître les limites et les faiblesses de chaque composant pour élaborer des processus pour les atténuer . Le plus souvent, les processus d'atténuation ne sont pas des logiciels et auront une incidence sur le coût du produit. Cela signifie que les caractéristiques et les limites des composants individuels définiront les caractéristiques des produits, services et processus.

Les processus descendants sont fondamentalement interrompus. De nombreuses entreprises qui adoptent cette philosophie sur papier ont encore un certain succès sur le marché. Mais lorsque vous vous penchez sur leurs projets importants et les plus réussis, vous apprenez qu'ils ont été menés en dehors des règles normales de l'entreprise. Les plus grands succès sont atteints lorsqu'une personne possédant des connaissances approfondies en ingénierie et une vision du marché est habilitée de manière informelle. Puisque cela se produit de manière informelle, la direction pense que le processus descendant fonctionne. Ils signalent que toutes les autres équipes sont incompétentes. Fermer les yeux sur le fait que le plan initial du projet lorsqu'il a quitté la "phase supérieure" a été complètement ignoré et ne décrit pas les produits, services et processus créés.

Votre responsable peut définir que vous concevrez un appareil de téléportation d'ici la fin du mois, car il a conclu que cela permettrait un profit élevé dans le secteur du voyage ... mais cela ne le fera pas. Les projets descendants sont comme ça, définissent des attentes qui ne sont pas technologiquement solides.

Ne vous méprenez pas, il est bon de voir le problème sous plusieurs angles. De bas en haut, de haut en bas, SWOT et plus sont sains pour l'analyse, mais le véritable effort d'ingénierie est ascendant. Il n'y a pas de véritable objectif sans viabilité technique.

Sécurité du développement

Nous devons nous rappeler que les développeurs de logiciels changeront régulièrement le logiciel de l'entreprise et, de cette façon, ils peuvent: changer ce qui apparaît sur l'écran de n'importe qui, envoyer des e-mails automatisés à n'importe qui, y compris lui-même, ou ouvrir des portes dérobées pour faire ce qu'il veut. Cela signifie qu'un criminel embauché en tant que développeur peut causer des dommages importants à l'entreprise.

Pire que cela, il existe de nombreuses entreprises qui n'appliquent pas la provenance d'un référentiel de code source, puis le développeur embauché peut fournir un binaire différent de la source donnée. Cela permet aux développeurs criminels de détourner les systèmes de l'entreprise, s'ils ne sont pas embauchés, les choses cesseront bientôt de fonctionner.

Pour moi, la sécurité du développement devrait se concentrer sur:

• Contrôle de version du code source : pour s'assurer que le code source et les composants tiers nécessaires sont stockés dans un emplacement sécurisé.
• Division stratégique du travail : junior et temporaire les développeurs doivent avoir un accès limité au code source et aux données. Ils n'ont besoin que d'accéder aux composants qu'ils modifient pour éviter qu'un développeur junior ne puisse comprendre le fonctionnement interne de tous les systèmes et pouvoir l'exploiter.
• Faites confiance aux développeurs principaux : les développeurs principaux / principaux devront tout savoir, avoir accès à tout, planifier et distribuer les tâches et diagnostiquer les problèmes graves. Ce noyau doit avoir accès à l'ensemble, tant dans le développement que dans la production. Ils sont vos partenaires dans l'élaboration des politiques de sécurité. Nous devons accepter que les développeurs principaux soient en quelque sorte propriétaires de l'entreprise. Mon ancien patron disait: "Nous avons de la chance que Lucas soit de notre côté, de l'autre il nous détruirait". Les développeurs principaux peuvent faire beaucoup de dégâts s'ils le souhaitent et il n'y a pas de pare-feu et de contrôle de la production qui peuvent empêcher cela.
• Séparez l'environnement par des pare-feu : séparez votre réseau de développement de votre réseau de test, depuis votre réseau de production. Sur une entreprise, j'ai défini le réseau 10.1. comme développement, 10.2. comme test et 10.3. comme production. Les réseaux 10.2 et 10.3 ne reçoivent le code que via le CVS de l'entreprise et les construisent automatiquement sur la commande admin. Même si c'était une petite startup et que j'étais dans la production et dans les équipes de développement, j'ai fait quelques bureaucraties pour éviter mes propres erreurs (les développeurs peuvent être vos meilleurs alliés). J'ai également changé les couleurs du terminal par réseau: lors de la connexion à un serveur de production, l'arrière-plan du terminal était rouge, les tests étaient jaunes et le développement vert. Étant donné que tous mes serveurs utilisaient la même configuration, il était facile de les confondre si l'invite était ouverte. D'après mon expérience, la plupart des problèmes proviennent de logiciels mal testés et de nouvelles installations de logiciels. Pour être clair: où vous êtes est une fonction de sécurité puissante à mon avis. Cela n'a rien à voir avec l'accès, mais c'est la sécurité.
• Embaucher un développeur de tests qualifié : l'aspect clé des tests est de disposer de grandes quantités de bonnes données simulées qui soient pertinentes pour les problèmes auxquels l'entreprise est confrontée. Les simulations Monte-Carlo sont bonnes pour générer de grands ensembles de données qui ont un sens pour d'autres développeurs et peuvent conduire à des logiciels et des processus plus solides et résilients. Pour moi, il n'y a pas d'échecs de "production", le développeur est toujours à blâmer. Les tâches de maintenance et les imprévus doivent être écrits. Le logiciel doit être résilient.
• Vérification du code source : demandez aux gens de réviser le code source avant d'accepter la modification. Tous les projets doivent être branchés sur le contrôle de code source et la fusion doit être revue. L'examen du code source ne devrait se préoccuper que de la détection des logiciels malveillants, de l'escalade d'accès, des profils d'accès et d'une bonne explication de ce que le code source signifie et doit faire. La qualité du code sera assurée par les tests et non par la revue du code source. Vous pouvez voir cela en action dans la plupart des projets open source.
• Les tests de politiques de test sont bien plus une culture d'entreprise qu'un cadre. Certaines entreprises adoptent des cadres de marché, font des tests, mais la qualité de leur code est mauvaise. Cela se produit parce que vous avez besoin de personnes capables de concevoir des tests significatifs. En fait, le développement doit être piloté par les tests. Je ne connais pas d'autre moyen sûr de développement. Et ce qui est curieux, c'est que les humains, les achats et le conseil doivent tous être testés également. Les vendeurs affirment souvent que leurs produits fonctionnent parfaitement, mais je n'ai pas encore trouvé de produit irréprochable.
• Les politiques n'ont aucun sens si elles ne sont pas surveillées . Une entreprise que je connais a une bureaucratie selon laquelle chaque table de base de données devrait avoir une description au niveau des attributs. 95% des attributs sont décrits comme "le $ {nom d'attribut} de $ {nom de table}". Il n'explique pas ce qu'est réellement l'attribut, quelles valeurs peuvent contenir, etc.
• Rémunération et environnement de travail appropriés . Pour avoir de bons développeurs, à la fois en compétences et en personnalité, il faut avoir de bonnes politiques de rémunération. L'argent est important, bien sûr, mais ne suffit pas. Vous devez également avoir une perspective / stabilité, une vraie reconnaissance et un bon environnement de travail. Par exemple, à la place d'un bureau de développement à New York où les gens vivent dans de petits appartements, vous pouvez choisir une ville plus petite où la même compensation permet une maison plus grande et plus proche du travail. Des ordinateurs plus gros, de bons laboratoires sont également un plus pour les passionnés de technologie.
• Sécurité des données de nombreuses activités nécessitent des données de production sensibles et doivent être consultées dans un laboratoire spécial. À moins que vos informations ne soient publiques ou non sensibles, la meilleure politique est peut-être de placer les laboratoires dans de bons quartiers avec un accès physique contrôlé. Autorisez uniquement certaines données simulées à être placées sur les ordinateurs portables personnels et les composants qui ne sont pas sensibles. C'est possible. Par exemple, j'ai développé une archive de données de 4,5 milliards d'enregistrements pour une entreprise. Je l'ai fait chez moi et n'ai utilisé absolument aucune donnée d'entreprise à cette fin. Lorsque j'ai soumis le code, cela a fonctionné comme prévu lors de la première tentative. Outre les pannes matérielles et la migration des environnements de production, nous avons 100% de disponibilité en 10 ans. Le risque que le développeur emporte le code source avec lui n'est pas pertinent. Ce système particulier m'a pris 3 mois à développer, une grande partie de ce temps a été de comprendre les limites de performance des composants. C'est maintenant la connaissance dans ma tête. Même sans le code source, je peux re-développer cette solution dans environ une semaine maintenant.
• Les journaux solides sont importants pour connaître tous ceux qui ont fait quelque chose. Le mieux ici est que les journaux soient générés par un framework, en enregistrant pour des écrans détaillés de courte durée, pour des temps d'accès et d'activités plus longs et encore plus pour les journaux d'entreprise. Mes systèmes critiques enregistrent chaque fois qu'un écran est accédé (y compris la conception de l'écran). Certaines des ressources critiques doivent être journalisées par un déclencheur sur la base de données elle-même et les tables ou ressources critiques doivent être marquées pour l'audit du code source.
  - Le filtrage des journaux est difficile à faire manuellement. Apprenez à créer des filtres sur les journaux pour voir les éléments critiques. Un filtre très utile consiste à croiser les rapports de plainte avec l'accès et les activités des utilisateurs. Si vous avez des journaux assez bons, vous verrez des coïncidences. Par exemple: avant un problème, l'utilisateur1 se connecte toujours.

À propos de ne pas accéder à la production

Les règles qui exigent que les développeurs n'accèdent pas aux systèmes de production car les utilisateurs sont là pour éviter que les développeurs soumettant le code pour montrer à son propre utilisateur des informations privilégiées. Je pense que c'est une mesure de sécurité très, très faible et facile à détecter dans l'audit du code source. Il existe plusieurs moyens simples de contourner cela:

• un développeur et un employé faiblement rémunéré;
• s'envoyer un e-mail;
• ouvrir un porte dérobée dans le système.

L'audit du code source à la recherche de portes dérobées, d'escalade d'accès et de logiciels malveillants semble plus productif. Il permet d'identifier les mauvais développeurs lorsqu'ils testent leurs exploits et de les renvoyer. Bien sûr, un développeur expérimenté peut cacher un exploit à la vue de tous, il est donc important d'utiliser des langages et des noms de variables clairs et clairs. Ne recourez à des solutions étranges que dans les points documentés des applications qui nécessitent des performances ou un masquage spéciaux. Par exemple, 1 << 4 est identique à 1 * 16. Cela n'aurait de sens que si le langage n'effectue pas cette optimisation par lui-même et que le point où cela se produit est un goulot d'étranglement des performances. Les langages trop symboliques sont mauvais pour cette même raison. Le code source doit être lisible par n'importe quel geek.

Le problème est pire que vous ne le pensez

Les dommages les plus simples et les pires qu'un développeur peut causer ne sont pas liés à l'installation de l'outil. Même si l'environnement de développement est géré, cela fera peu de différence si l'entreprise ne dispose pas de pare-feu puissants, de référentiels de code source, de builds basés exclusivement sur les référentiels de code source et de révision de code.

En tant que consultant, j'ai travaillé pour de nombreuses entreprises différentes, et seulement 2 d'entre elles n'ont pas accordé aux développeurs l'accès administrateur à leurs machines; l'une était une petite entreprise, l'autre était une très grande entreprise.

Dans la petite entreprise, j'ai demandé un accès administrateur, expliqué pourquoi pendant environ 60 secondes, et je l'ai reçu tout de suite.

Dans la grande entreprise, j'ai demandé un accès administrateur et on m'a dit que même s'ils étaient d'accord que je devrais l'avoir, la politique de l'entreprise l'interdisait et ils ne pouvaient pas le changer. Un des informaticiens est donc venu et a créé un compte d'administrateur local sur ma machine et m'a demandé de définir le mot de passe pour celui-ci. À partir de là, à chaque fois que je devais être administrateur, je pouvais me connecter à la machine en tant qu'administrateur local, ou simplement utiliser des runas pour démarrer Visual Studio ou tout service / application dont j'avais besoin pour exécuter avec un utilisateur administrateur (IIS, par exemple). Ce n'est pas bien pire que de choisir le "Exécuter en tant qu'administrateur" intégré; c'est juste un peu plus lent, mais heureusement, cela n'arrive pas trop souvent.

N'oubliez pas que le plus gros problème de sécurité ici est l'exfiltration d'IP, pas de malware. J'espère que vous avez mis en place IDS / IPS pour gérer ce dernier, ce qui devrait en faire un non-problème.

Vous pouvez vous en sortir en donnant l'accès administrateur à l'équipement de développement, à condition que vous ayez les éléments suivants en place: / p>

• Anti-eDLP (réseau, USB, etc.)
• IDS / IPS
• proxy d'entreprise authentifié MITM NTLM via lequel vous forcez toutes les connexions et surveillez pour les violations DLP
• Refusez tous les logiciels de virtualisation sur les postes de travail. Si vous avez besoin d'une VM, provisionnez-en une à partir d'un cloud géré dans lequel toutes les VM exécutent la même image standardisée obsolète avec les outils ci-dessus en place.
• Bloquez l'accès aux référentiels de logiciels externes au niveau du réseau (cela paralyse pip, git, maven, apt, yast, zypper et tout le reste)
• Bloquer l'accès à github, codeplex et aux 150 autres sites de partage de code au niveau du réseau
• Bloquer l'accès à tous les 9000+ sites de partage de fichiers au niveau du réseau
• Bloquer l'accès au P2P ... etc ...

Mon employeur fait tout cela et plus encore. De toute façon, un bon nombre de collègues finissent par développer leur propre équipement personnel après les heures de travail à la maison et le rejeter par-dessus la clôture à travers des canaux latéraux juste pour contourner l'infrastructure paralysée. Personnellement, je préfère passer mes soirées à boire et à rêver de surdosage de tranquillisants pour chiens que de perdre 20 heures supplémentaires sans papiers à faire quelque chose qui me ferait de toute façon renvoyé.

Nous considérons l'informatique (et par extension, le génie logiciel ) une science. Des expériences scientifiques sont menées dans des conditions stériles pour garder les variables sous contrôle. Il n'est pas scientifique de se développer dans un environnement paralysé où les choses ne fonctionnent pas comme prévu en raison de facteurs environnementaux. Je peux vous dire par expérience que vous n'obtenez pas de logiciels bien conçus ... tout ce qui est développé en interne est défectueux, ce qui entraîne une augmentation des dépenses en solutions tierces.

Les développeurs doivent absolument disposer d'un environnement stérile pour se développer. Je ne peux pas vous dire combien de fois différents contrôles de sécurité ont introduit des gremlins dans l'architecture de développement et de production - donc un environnement de développement géré, stérile et basé sur le cloud est vraiment le seule voie à suivre. «Cela a fonctionné en laboratoire, le problème doit être quelque chose d'extérieur.

Il vous suffit de vous assurer que les VM que vous les laissez provisionner ne sont pas anémiques et vous devez automatiser le processus de provisionnement à la manière d'OpenStack ou d'AWS afin que les développeurs n'attendent pas des jours pour satisfaire les besoins de mise à l'échelle. Les avoir tous gérés de manière centralisée vous donne beaucoup de contrôle de l'audit et donne franchement aux développeurs de meilleures performances que celles qu'ils obtiendraient de toute façon sur leur propre équipement.

Je suis fan de l'option n ° 2: avoir des ordinateurs séparés.

Permettre aux machines de l'entreprise avec des informations propriétaires d'être connectées à Internet ouvre la porte aux pirates. Il est également beaucoup plus facile pour les employés d'exfiltrer les données de l'entreprise à des fins illégitimes.

Si l'employé doit utiliser une machine spéciale pour accéder aux ressources Internet, cela crée un chemin contrôlé pour l'infiltration et l'exfiltration des données qui sont beaucoup plus sûr. En outre, cela décourage les employés de naviguer inutilement sur le Web ou de perdre du temps sur les forums Internet, comme je le fais actuellement.

En tant qu'administrateur, ce problème est résolu complètement et totalement grâce à une approche SaaS. Virtualisez tous vos différents environnements, placez-les sur un rack serveur adapté au nombre de clients, et configurez certains accès à distance (RDP, Terminal Services, ou autre ...). Désormais, tout est sur le serveur et vous n'avez qu'un seul environnement à gérer pour tout le monde.