Premièrement, il serait peut-être préférable de bien comprendre les besoins du client (de votre chef). Il est possible qu'il ou elle n'ait besoin d'accéder qu'à un petit sous-ensemble de données sur ce serveur de n’importe où et pas nécessairement tout.

Dans la mesure du possible, au lieu de dire non dans cette situation, revenez avec quelques options. li> VPN pour que les voyageurs puissent accéder aux données où qu'ils se trouvent. Si possible, ajoutez des contrôles de sécurité supplémentaires tels que des pare-feu internes et la prévention de la perte de données (DLP) si nécessaire. Renforcez et ajoutez des contrôles de sécurité supplémentaires ici si nécessaire.

Soyez un résolveur de problèmes ici, fournissez à votre patron des solutions, plutôt que simplement des raisons de dire non. N'ayez pas peur de proposer des solutions coûteuses que vous jugez trop chères pour l'entreprise, votre patron peut être d'accord s'il fait avancer rapidement les fonctionnalités pour lui ou elle. Cela dit, lorsque cela est possible, gardez toujours la sécurité aussi bon marché que possible à long terme (évitez les coûts récurrents qui peuvent être réduits en cas de difficultés économiques). Considérez cela comme une opportunité pour vous de renforcer la sécurité en activant l'entreprise plutôt qu'en la combattant. Si vous montrez que vous pouvez responsabiliser l'entreprise et définir les besoins en fonction de ce qui fait avancer l'entreprise ou comment les choses pourraient affecter l'entreprise, vous obtiendrez une bien meilleure réponse de personnes comme votre PDG. Comprendre quand l'entreprise est pressée est également important, il n'est pas rare qu'une entreprise paie plus d'argent pour une solution ou approuve des choses qu'elle n'approuverait peut-être pas autrement si elle peut ajouter de la valeur et être déployée rapidement. Pour cela, savoir quand chronométrer les demandes et comprendre l'urgence des projets en vol vous aidera également.

Considérez cette partie des affaires comme un art martial , vous souhaitez exploiter l'énergie de vos adversaires et la rediriger vers un endroit où vous voulez qu'ils aillent tout en minimisant votre propre dépense énergétique. Si vous pouvez rapidement saisir son désir de le rendre accessible, le moment est peut-être idéal pour mettre en place beaucoup plus de sécurité. La vitesse est importante ici et vous devez obtenir l'adhésion tant qu'il fait chaud pour ainsi dire.

Enfin, sachez que vous ferez bien mieux de traiter ce problème en tant que problème commercial que vous pouvez résoudre , plutôt qu'un simple problème de sécurité technique. De même, commencez à rechercher et à anticiper les besoins de sécurité supplémentaires à l'avenir et à les présenter à votre patron dès le début afin que vous ressembliez à quelqu'un qui aide l'entreprise plutôt que comme un obstacle à la progression. Ce peu de cadrage accomplit le même objectif mais obtient la sécurité plus rapidement et avec moins de conflits.

Ajout après le message d'origine: une chose qui peut également vous être utile est de créer une feuille de route de sécurité à long terme et de la partager avec votre organisation. Ce que cela implique sera différent pour chaque organisation, mais il est très important de montrer le travail que vous ne faites pas actuellement et également le travail qui peut être des choses que votre organisation ne fera jamais en interne (les petites start-ups sont moins susceptibles d'avoir des équipes médico-légales en interne ). La raison en est d'aider à éduquer et aussi d'aider à définir les attentes avec votre équipe de direction. C'est quelque chose que de nombreuses équipes de sécurité ont en tête, mais formaliser un plan et montrer la voie à suivre peut vous aider à obtenir plus d'adhésion à votre programme de sécurité. Une grande partie de cela concerne la communication et une vision partagée du point de vue commercial, mais une autre partie de cela consiste à informer la direction sur les domaines où elle est en matière de risque. Je trouve que la visualisation de la dette de sécurité de votre organisation aide les gens à prendre automatiquement des décisions plus réfléchies.

Y a-t-il des raisons pour lesquelles connecter des systèmes internes directement à Internet est une mauvaise chose?

Vous augmentez inutilement la surface d'attaque. Voici les problèmes à prendre en compte:

• Un attaquant qui obtient le contrôle de ce seul service exposé peut éventuellement exploiter cet accès pour infiltrer d'autres services sur l'intranet.

• Vous pourriez avoir du mal à surveiller les journaux pour un accès non autorisé. Des attaquants de partout tenteront de se connecter et d'exploiter le service, déclenchant constamment de fausses alarmes.

• Les attaquants pourraient rendre le serveur indisponible, même involontairement, en utilisant des outils d'analyse automatisés pour tester l'application pour les vulnérabilités ou dans une tentative de connexion par force brute.
• Si un inconnu capture les informations de connexion d'un employé se connectant à partir d'un hotspot pulic (vous utilisez, espérons-le, HTTPS, mais il se peut que ce soit juste l'épaule- surf), ils peuvent se connecter directement à partir de leur propre navigateur sans avoir à entrer dans le réseau de l'entreprise en premier lieu.

• Même si le service utilise HTTPS, le propriétaire du hotspot saura que le l'employé a accédé à internal.yourcompany.com et pourrait devenir intéressé.

• Si vous utilisez un framework, un CMS ou un autre logiciel connu, vous avez être rapide avec les mises à jour si un problème de sécurité avec ce logiciel devient public. Vous devez vous attendre à ce que les attaquants analysent en masse les serveurs pour les instances non corrigées.

• Vous exposez les technologies que vous utilisez en interne. Ce n'est pas nécessairement une mauvaise chose, mais cela pourrait fonctionner comme un argument pour votre patron.

• Vous dites que le service a fait l'objet d'un audit de sécurité - votre patron fait-il confiance à l'évaluation dans une certaine mesure qu'un inconnu sur Internet peut le contester?

La plupart de ces problèmes pourraient être atténués avec une solution VPN pour l'accès à distance des employés au lieu d'exposer directement des parties de l'intranet. Un VPN donne à votre patron la possibilité d'activer, de bloquer et de surveiller rapidement l'accès à distance directement à la passerelle.

Dans un déploiement d'applications / de systèmes / de systèmes commerciaux, vous ne faites jamais exécuter un système en dehors des spécifications officielles .

Le fait que le système ait été développé et testé par pénétration en supposant qu'il ne sera déployé que sur le réseau interne devrait suffire à convaincre votre patron. Les développeurs et les gardiens (vous étant le dernier) d'un tel système n'accepteront et ne pourront pas accepter le blâme pour les conséquences, qui peuvent ou non être graves.

Si vous avez besoin d'analogies pour convaincre votre patron, voici certains:

• Faire passer les camions de l'entreprise au-delà du régime de la ligne rouge pour accélérer les livraisons
• surcharger votre réseau électrique avec un ampérage plus élevé que les fusibles permet d'économiser sur la mise à niveau du système électrique
• atterrir un avion à une vitesse supérieure à la vitesse d'atterrissage maximale

Je suis sûr que le boss n'oserait suggérer aucune des actions ci-dessus. C'est tout ce dont vous avez besoin pour le convaincre. De nombreuses personnes ont fourni des informations détaillées précieuses à ce fil de discussion, mais le cœur de l'argument se trouve dans ma première phrase, en gras.

Quelques bonnes réponses ici. Pour ajouter, voici quelques points.

• En plaçant l'application sur Internet, vous exposez non seulement cette application, mais augmentez également l'exposition de vos applications internes. si votre application de facturation est compromise, un pirate informatique pourra peut-être l'utiliser pour accéder à vos autres systèmes internes.

• Les données de facturation contiennent probablement des informations sur vos clients. Vous serez responsable si l'une de leurs données sensibles est exposée.

• Mettre votre application sur Internet peut ajouter une charge réglementaire supplémentaire. Par exemple, si vous gérez des informations sur les soins de santé, vous devrez respecter les normes de cybersécurité de la HIPAA; si certains de vos clients sont des agences gouvernementales, la norme ISO-27000 peut s'appliquer.

• Si vous avez l'intention d'utiliser le même mécanisme d'authentification, il est possible que vos règles de complexité de mot de passe ne soient pas bonnes assez. Vous devrez peut-être définir l'indicateur de réinitialisation du mot de passe sur tous les utilisateurs et leur demander de configurer de nouveaux mots de passe selon de nouvelles règles de complexité.

• Lorsque vous mettez un site sur Internet, vous pouvez nécessitent plus de matériel. Vous aurez besoin d'au moins un pare-feu de périmètre et éventuellement d'un pare-feu supplémentaire pour établir une DMZ. Cela peut signifier que vos serveurs Web auront besoin de deux NIC chacun.

• Vous devrez peut-être acheter un certificat SSL public, ce qui a un coût.

Avec les informations limitées que vous avez fournies, voici mes contributions.

Exposer un système actuellement interne à Internet peut ou non être une mauvaise idée selon divers autres facteurs. La question que vous devez vous poser avant de la rendre accessible au public est la suivante.

1. Qui sont les utilisateurs potentiels des systèmes et du service?

Si l'application n'est utilisée que par les employés, la sage décision est de la rendre accessible via VPN. Cependant, vous pouvez également le rendre public après avoir effectué une révision de l'architecture.

2. Quel est le profil de risque actuel de l'application?

Je comprends que l'application gère des données sensibles. Mais quel est le profil de risque de l'application selon l'organisation? Comprendre cela est important car l'un des facteurs affectant le profil de risque va considérablement changer - l'empreinte Internet - après avoir effectué ce changement.

3. À quelle fréquence testez-vous l'application au stylet?

Le profil de risque actuel de votre application n'est peut-être pas assez élevé pour fonctionner régulièrement tests au stylo. La probabilité de nouvelles vulnérabilités, zéro jour, etc. doit également être prise en compte lors de son exposition à un réseau externe.

4. Mécanisme d'authentification.

L'application utilise-t-elle les informations d'identification du domaine? Utilise-t-il du trafic crypté? Utilise-t-il 2FA? At-il une politique de verrouillage? Beaucoup de ces questions peuvent avoir été ignorées en tant que faible risque lors de l'exécution d'un test de stylet en considérant l'application comme interne. Une nouvelle perspective de test sur l'application en tant qu'application externe peut être nécessaire avant de la déployer au public.

1. Tout ce qui se trouve sur Internet peut être compromis et doit être traité comme non sécurisé.
2. Tout ce qui n'est pas sur Internet est plus difficile à compromettre, mais peut toujours être compromis et doit être traité comme s'il s'agissait de sur Internet.

En d’autres termes, garder un système hors d’Internet le rend plus sûr mais n’est pas une excuse pour une mauvaise sécurité ailleurs dans le système. Je suis préoccupé par votre "tout cela a été fait sur la base que le système n'était accessible qu'à partir du domaine interne" - un système qui n'est pas sur Internet devrait être rendu aussi sécurisé qu'un système qui est sur Internet, et comme En ce qui concerne la conception / l'audit / le pentesting, il doit être traité comme s'il était sur Internet. Cependant, un système sensible doit toujours être tenu à l'écart d'Internet, sauf s'il y a une raison très essentielle pour laquelle il doit être sur Internet (par exemple, il y a des bureaux dans un endroit éloigné).

Une situation similaire s'applique aux VPN, proxies, passerelles, etc. Ils rendent un système plus sûr, mais ils ne sont pas une excuse pour une mauvaise sécurité ailleurs et ils peuvent toujours être compromis. C'est comme mettre une autre serrure sur votre porte - cela pourrait ralentir un attaquant, mais cela ne peut pas les arrêter, et votre système est encore beaucoup moins sécurisé que s'il n'était pas connecté à Internet.

Il existe une formule rationnelle pour le risque.Risque = Menace x Vulerabilité

Quelle est la valeur de l'actif? (Combien cela coûtera-t-il pour récupérer si les données sont perdues, volées ou endommagées? Ce sont les données des clients qui vous feront être poursuivis en cas de vol? Quelle est la valeur de ces données pour les pirates ou les concurrents?)

L'identification de la valeur de l'actif permet de déterminer la probabilité qu'une menace exploite une vulnérabilité pour provoquer une perte.

Quelles sont les vulnérabilités? (Vous essayez déjà d'établir les vulnérabilités avec le test du stylo).

Quel est le coût d'un contrôle de sécurité pour atténuer une vulnérabilité? Si le coût du contrôle dépasse le coût de l'actif, cela ne vaut pas la peine d'installer l'atténuation de la vulnérabilité.

Si vous exécutez ces données par votre patron, il / elle peut penser au coût de la commodité. Certaines personnes pensent que le coût de la commodité vaut bien le risque, tandis que d'autres ne veulent aucun risque et ne se soucient pas de la commodité. N'oubliez pas que l'atténuation des risques est le facteur clé.

Le principal risque de sécurité ne concerne pas les VPN. Tous sont très bien renforcés contre toute fissure possible.

Le risque de sécurité est le contenu que vous déplacez à travers ces VPN, et la fausse croyance que les VPN vont défendre votre système. Oui, ils se défendront presque sûrement - contre les attaques contre le VPN. Mais pas contre les attaques de votre système de réservation, qui est sûrement beaucoup plus complexe et beaucoup moins sécurisé.

Son trafic entre vos hôtes externes et le réseau local est parfaitement légal du point de vue du VPN.

Si vous utilisez une solution différente, et non une solution basée sur un VPN (par exemple, en utilisant une synchronisation de données), alors vous pouvez protéger beaucoup mieux votre réseau interne, mais vous ne pouvez pas résoudre l'essence de ce problème.

À mon avis, s'il s'agit d'un logiciel de réservation, alors il peut s'agir de données financières, donc hautement sensibles et privées des clients . La plupart des entreprises que je connais défendent les données de leurs clients plus fortement que les leurs, et c'est un comportement assez rationnel de leur part. Sans rien savoir de votre système, je vois tout à fait possible que ces données soient en fait plus importantes pour votre employeur, comme l'ensemble de votre réseau local et al. Votre patron le sait sûrement, et je pense que si vous voulez le convaincre, argumentez dans cette direction et non dans les techniques.

Votre question comprend la principale raison ... elle a été testée par pénétration sous l'hypothèse que le système n'est pas accessible de l'extérieur. Commencez donc par le coût pour effectuer le pentesting sans cette hypothèse et ce test reviendra avec tous les risques.

Rendre leur application accessible en externe sans un pentesting approprié ne devrait même pas être considéré comme votre vous et votre entreprise. Vous n'êtes pas un expert en la matière dans l'évaluation du risque d'exposition d'un service qui a été conçu pour être interne à l'Internet public.

Nous pouvons tous deviner les nombreuses façons dont cette application exposerait votre entreprise, mais ce n'est que supposition. Vous devez supposer le pire des cas, à savoir que quelqu'un enfreint le serveur d'hébergement et obtient un accès root au serveur, puis l'utilise pour accéder à tous vos autres serveurs. SI votre entreprise dépend de vos systèmes informatiques, alors votre entreprise peut être perturbée au point que vous ne puissiez plus exercer vos activités, subir une perte de crédibilité au sein de votre secteur et potentiellement des conséquences juridiques.

Dans une langue que votre patron comprendra: L'inconvénient est qu'il doit se soucier de la sécurité, très probablement sous la forme de l'embauche d'experts externes, et nous sommes chers.

Une fois que vous mettez le système sur Internet, chaque hacker ennuyé de Chine peut s'introduire, juste pour le lolz. Si vous ne pensez pas qu'ils feront l'affaire (argument standard "nous n'avons rien à voler"), revoyez ce que j'ai écrit: Le lolz. Vous n'avez pas besoin d'une raison pour pénétrer dans un système. La majorité des attaques de nos jours ne sont pas dirigées, c'est-à-dire qu'elles lancent simplement un tas d'exploits standard sur tout un réseau et voient qui tombe. Ce n'est qu'après avoir fait irruption qu'ils vérifieront ce que c'est ou de qui il s'agit. Et si vous n'avez rien à voler, il y a toujours de la puissance du processeur, de la bande passante et faire partie d'un botnet.

Avoir un système pas sur Internet est la mesure de sécurité n ° 1, même pour les systèmes Internet. Cela signifie que s'il le veut sur Internet, très bien. Mais il devrait y avoir un pare-feu et / ou un WAF et / ou une passerelle d'application devant lui et une DMZ autour de lui. Bien sûr, vous pouvez le mettre sur Internet s'il le souhaite. D'après votre question, il n'est pas clair que votre patron comprend que cela signifie plus que mettre un autre câble dans le port réseau.

Si votre système a été conçu pour être accessible au public, il serait très intelligent de le faire.

Il existe des services qui vous permettent de gérer les factures directement sur Internet, par exemple.

Le fait d'avoir un service ouvert à Internet ne le rend pas intrinsèquement plus ou moins sécurisé. Cependant, le savoir plus exposé devrait devenir une très bonne incitation à le rendre le plus à l'épreuve des balles possible.

En d'autres termes, si vous savez que vos applications sont cachées derrière votre réseau interne, le jour où quelqu'un fait irruption, elle sera très fragile. La plupart des systèmes de nos jours ne sont pas isolés à 100% du monde extérieur pour toujours: accès wifi, coupures de pare-feu, virus, vpns, ...

Il est donc bon d'avoir une sécurité en profondeur.

S'il est intrinsèquement sécurisé, je ne vois pas pourquoi il n'a pas pu être ouvert sur Internet. Aujourd'hui, les services bancaires, les jeux d'argent en ligne et même les soins de santé sont accessibles sur Internet.

C'est donc faisable.