C'est comme: "Mettez la boîte à bijoux à l'extérieur de la maison pour que les voleurs ne prennent pas la peine d'entrer pour la télé?"

Oui, c'est exactement comme ça.

Si vous ne vous souciez pas de la valeur de la base de données, relativement parlant, alors assurez-vous qu'il est logique de la laisser à l'extérieur - si l'on suppose que l'application est horriblement non sécurisée, mais que vous devez la mettre de toute façon pour une raison quelconque, et que vous ne voulez pas le sécuriser, alors c'est logique comme moyen d'isoler cet horrible système non sécurisé de tous les autres systèmes internes.

D'un autre côté, il n'y a vraiment aucune excuse pour s'attendre à avoir une telle application non sécurisée qui permet une prise de contrôle complète du serveur de base de données. Il n'y a pas non plus de vraie raison d'utiliser «l'exposition» comme alternative à «l'isolement» - il existe des solutions simples pour le faire correctement.

En fin de compte, il semble que ce soit l'une des 2 situations possibles:

1. Ces soi-disant «experts» sont vraiment ignorants.
2. Il y a d'autres exigences commerciales qui sont en train d'être négociées ici.

Je pense que votre analogie fonctionne parfaitement. S'ils vous disent ensuite l'équivalent de "En fait, ces bijoux sont faux, oh et btw le téléviseur est vraiment un travail personnalisé de 60" 5K avec des jantes en or ", alors cela pourrait être un compromis raisonnable (encore mieux de le faire correctement, bien que ).
Sinon, il est probable qu'il n'y ait aucun moyen de l'expliquer, car ils travaillent par manque de connaissances.

«Rendre votre réseau sûr pour les bases de données» de SANS ( http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24) lit un peu daté dans certaines sections, mais fournit un niveau de guidage décent "pour les nuls" dans la direction que vous recherchez.

Vous pouvez également vous épuiser en parcourant le centre de ressources du NIST américain ( http://csrc.nist.gov/). Je pense que l'ISO / CEI 27033-2: 2012 de l'ISO serait également sur le sujet, mais je n'en ai pas d'exemplaire sous la main pour être sûr.

Vous essayez de séparer / isoler les serveurs les plus sensibles (les serveurs de bases de données) des plus exposés (et donc vulnérables).

Vous proposez une "défense en profondeur ", qui vise à a) empêcher les attaques lorsque cela est possible, et b) retarder leur progression (et l'accès aux éléments importants) dans le cas contraire.

Idéalement, tout est toujours renforcé et corrigé, les serveurs n'écoutent que le trafic sur les ports requis, et uniquement à partir des appareils autorisés, tout le trafic "en vol" est inaccessible aux auditeurs non autorisés (par cryptage et / ou isolation) , et tout est surveillé pour l'intrusion et l'intégrité.

Si tout cela est en place avec une certitude à 100%, alors tant mieux, votre "opposition" a abordé le point a) ci-dessus, autant que possible . Bon début, mais qu'en est-il du point b)?

La justification de la séparation de la base de données des serveurs Web n'est pas différente de la justification qu'ils ont acceptée pour séparer les serveurs Web du LAN. Plus franchement: s'ils sont tellement convaincus qu'un serveur Web compromis ne présente aucun danger pour les autres systèmes de la même zone de sécurité, pourquoi pensent-ils qu'une DMZ est nécessaire?

C'est terriblement frustrant d'être dans votre situation. À tout le moins, à votre place, je créerais une note de risque décrivant vos préoccupations et suggestions, et je m'assurerais qu'ils en tiennent compte. CYA, de toute façon.

Si la base de données contient les détails de la carte, on peut très facilement affirmer que vous ne remplissez pas les exigences PCI DSS en matière de protection appropriée.

Il échoue également aux vérifications de cohérence sur les points de défaillance uniques et à la protection de vos actifs de base.

Si les données valent des milliards, pourquoi ne dépenseriez-vous pas quelques milliers de plus pour les ajouter couches de protection? Les bonnes pratiques de l'industrie sont d'avoir des zones de sécurité en couches.

Vous pouvez les orienter vers PCI, le guide des bonnes pratiques de l'ISF et bien d'autres.

Si vous suggérez que le serveur de base de données passe de la même zone de sécurité que le serveur Web à la même zone de sécurité que certains systèmes internes, alors on peut raisonnablement conclure que vous réduisez la sécurité.

Si le statu quo est que le serveur Web et le serveur de base de données sont tous les deux dans la DMZ et qu'aucune connexion n'est autorisée de la DMZ au réseau interne, alors le déplacement du serveur de base de données de la DMZ vers le réseau interne nécessiterait d'autoriser les connexions de la DMZ au réseau interne . Cela signifierait que vous réduisez la sécurité du réseau interne sans obtenir une meilleure protection de la base de données.

Si vous pensez vraiment que la base de données est plus sensible que le réseau interne (ce qui peut très bien être vrai) , alors vous ne voudriez pas qu'un compromis du réseau interne obtienne un accès direct à la base de données.

Donc, le point que vous devez faire est que vous ne voulez pas déplacer le serveur de base de données d'une sécurité zone à une autre, vous voulez plutôt créer une zone de sécurité entièrement nouvelle. Pour vraiment suivre cela, vous devrez en fait acheter un pare-feu supplémentaire et le placer entre la DMZ et le réseau sécurisé supplémentaire.

Ensuite, cela revient à évaluer le coût d'achat et de maintenance de ce pare-feu supplémentaire contre la sécurité supplémentaire qu'il offre.

AvID a déjà couvert la question principale, mais en abordant cette question sous un angle légèrement différent, la plupart des pare-feu prendront en charge plusieurs interfaces et peuvent fournir le contrôle du trafic entre les interfaces.

Configurer les multiples interfaces pour héberger chacune des aspects de la solution (frontend, middleware, backend) réduirait le risque de compromission de la base de données depuis le serveur Web sans nécessiter de multiples pare-feu physiques (si c'est ce qui inquiète les autres équipes ... est-ce un coût question?) et sans introduire une route vers le réseau interne.

Je me demande simplement si cela vous donnerait un «levier» pratique pour soutenir l'argument en faveur de la mise en œuvre d'une séparation, c'est-à-dire que cela apporte quelque chose de différent à la discussion qu'ils à contrer?

À défaut, qu'en est-il d'un scénario hypothétique basé sur une vulnérabilité de serveur Web historique, qui aurait entraîné une compromission ultérieure de tout autre serveur sur le même segment de réseau (y compris la base de données ase) et comment une DMZ en couches empêcherait le compromis ultérieur, vraisemblablement il y aurait un coût monétaire donc il serait `` facile '' d'illustrer le bénéfice coût / effort?

En supposant que vous essayez de les persuader de le faire plutôt que (nécessairement) de les convaincre que c'est correct:

Expliquez que lorsque leurs grands clients et prospects viendront faire un audit de sécurité, ils le feront échouer.

Si l’obstacle est l’entreprise, ce sera la seule raison suffisante et nécessaire.

Un bon argument est que la barre n'est vraiment pas si haute pour séparer les serveurs Web et les serveurs de base de données en DMZ séparés.

Utilisez un vrai routeur / pare-feu, et placez les serveurs Web et les serveurs de base de données sur des VLAN séparés, tous deux en dehors du LAN sécurisé interne, avec des règles de pare-feu contrôlant l'accès aux ports minimum requis d'Internet aux serveurs Web, des serveurs Web aux serveurs de base de données, et aucun accès provenant du Web les serveurs au LAN sécurisé.

Le pare-feu empêcherait également tout accès direct depuis Internet aux serveurs de base de données, et contrôlerait étroitement tout accès des serveurs de base de données vers le LAN sécurisé (à des fins d'authentification ou peu importe).

De cette façon, l'attaquant ne peut même pas accéder directement au réseau contenant les serveurs de base de données.

S'ils obtiennent une tête de pont sur l'un de vos serveurs Web, ils ' vous n'êtes toujours pas sur le même réseau avec un accès illimité pour attaquer votre (vos) serveur (s) de base de données, et si vous avez mis en place tout type de surveillance des journaux, vous devriez recevoir des notifications sur la violation des serveurs Web avant que les attaquants n'aient eu beaucoup de temps pour attaquer quoi que ce soit d'autre.

Même s'ils parviennent à violer vos serveurs de base de données après une certaine période de temps sur le seul port ouvert que le serveur Web utilise pour communiquer avec la base de données, ils ont perdu tout ce temps à accomplir relativement peu de temps, pendant lequel vous avez été au courant de leur attaque, au lieu de dépenser tout cela le temps d'entrer dans votre LAN sécurisé.

Ils ne peuvent même pas atteindre le LAN depuis la DMZ où vivent les serveurs Web, donc leur seul chemin vers le LAN sous quelque forme que ce soit est de sauter sur les serveurs de base de données , protégé dans l'autre DMZ. Il y a de fortes chances que vos serveurs de base de données soient ou soient liés à une sorte de système d'authentification d'entreprise (Active Directory ou autre). Voulez-vous cette fonctionnalité dans la même DMZ avec vos serveurs Web publics?

Si je peux être suffisamment préoccupé par les problèmes de sécurité pour créer des sous-réseaux invités et DMZ chez moi chez moi , pour avoir un endroit pour mettre des «choses» («Internet des objets») sans les avoir directement sur mon LAN, une entreprise qui vaut des milliards peut certainement se permettre le partage d'esprit et le temps de faire la même chose avec d'importants serveurs Web et serveurs de bases de données. Je fais cela au bureau avec une combinaison d'une pile de commutateurs L2 / L3 gérés par Procurve de plusieurs milliers de dollars, d'un SonicWall UTM et d'un routeur Ubiquiti EdgeMax. À la maison , j'ai un Ubiquiti EdgeRouter Lite à 100 $, un commutateur HP à 8 ports géré à 100 $ et un point d'accès Ubiquiti Unifi qui prend en charge plusieurs VLAN, et ma configuration est totalement capable de faire ce dont nous parlons .

Et j'ai la tranquillité d'esprit de ne pas m'inquiéter du fait que mon DVR, mon imprimante, mon lecteur BluRay, mon thermostat et tout le reste connectés au réseau exécutent un micrologiciel de buggy obsolète avec qui -connaît-quels exploits non découverts pourraient être piratés et accéder à mon ordinateur et à mes fichiers personnels via le réseau.

Ce n'est pas très difficile pour les experts en sécurité de configurer ce genre de chose, et ce n'est certainement pas le cas 'pas besoin d'impliquer un matériel physique distinct pour chaque pare-feu. Le SDN (réseau défini par logiciel) fait fureur de nos jours, n'est-ce pas?

Même le EdgeRouter Lite à 100 $ peut transmettre près de 1 Gbit / s via le routeur, avec prise en charge de plusieurs interfaces virtuelles et règles de pare-feu entre toutes ces interfaces .

Une petite boîte est en fait un panier plein de pare-feu.

Donc, si vous dépensez de l'argent réel sur un routeur haut de gamme, vous obtiendrez toutes ces fonctionnalités et quelques plus avec des performances de routage plus robustes.

Même quelque chose comme Ubiquiti EdgeRouter Pro 8 vous donne 2 millions de paquets par seconde pour seulement 375 $, avec 8 interfaces physiques et des sous-interfaces VLAN sur chacune d'elles si vous en avez besoin. Si vous avez besoin de performances plus élevées que celles-ci, recherchez Brocade (Vyatta), Cisco, Juniper, etc. Ou quelque chose comme la série SuperMassive de Dell / Sonicwall. Ou exécutez le routeur virtuel Vyatta sur un serveur Xeon multicœur costaud.

Je n'essaye pas de colporter des routeurs, je fais juste remarquer que la barre n'est pas si haute pour obtenir le genre de séparation de sécurité que vous devriez probablement avoir et que vous voulez évidemment ici.

Dites à votre responsable direct que vous n'êtes pas autorisé à accepter ce risque au nom de l'entreprise. Faites remarquer que la valeur des données de la base de données est de xxx $ et que ce niveau d'acceptation des risques doit provenir d'une personne autorisée à le faire, et demandez-lui de défendre l'idée qu'un membre de la direction générale approuve l'acceptation des risques.

Pour estimer la valeur des données, déterminez s'il s'agit de données liées à PCI DSS (si tel est le cas, regardez le coût par client que Target / Home Depot a encouru en cas de perte de ventes, de surveillance du crédit, fraude), ou s'il s'agit de PII (si oui, regardez le préjudice financier par patient que les systèmes médicaux ont subi en cas de perte de confiance, de surveillance du vol d'identité, de perte de réputation), ou s'il s'agit de l'avantage concurrentiel de votre entreprise (secrets commerciaux, données financières non encore publiées, propriété intellectuelle) alors la valeur des données pourrait être la valorisation actuelle de l'entreprise.

Si vous recevez un ordre direct d'accepter le risque au nom de la société, il se peut que l'on vous demande de commencer à agir en qualité de dirigeant de la société, et à ce titre, vous avez une obligation (éventuellement obligation légale) de souligner que vous êtes une personne non nommée appelée à agir en tant que telle, et que vous devez en informer la chaîne de gestion auprès du conseil d'administration de la société. Soyez prêt à subir un retour de force important et à dépenser un capital politique important pour le faire savoir.

Bonne chance!