Comme je l'ai dit à l'origine dans l'autre question, la sécurité ne peut pas être la principale, ni même une préoccupation principale. Parfois, au cours de certaines phases du démarrage, vous devez vraiment vous concentrer sur le développement rapide des fonctionnalités nécessaires pour piloter le produit et corriger la sécurité si nécessaire. La sécurité peut facilement entraver les opérations, la productivité des employés et ralentir le développement. Bien que si le vôtre est un produit ou une entreprise lié à la sécurité, vous pourriez certainement avoir besoin d'une sécurité à toute épreuve dès le début, vous ne pouvez vraiment pas généraliser et dire que toutes les entreprises devraient se concentrer sur la sécurité dès le début. (Sony, étant assez grand, doit apprendre beaucoup de leçons sur le développement logiciel au nouveau siècle, pas seulement sur la sécurité.)

Cela dit, les pratiques de sécurité et la sécurité pratique devraient être un facteur à l'esprit de tous les employés techniques. Où pouvez-vous ajouter de la sécurité sans gêner les gens? La sécurité à 100% n'existe pas, alors quel niveau de sécurité est suffisant?

Y a-t-il un défi de taille à relever contre les retards de sécurité? Non je ne pense pas. À moins que le secteur ne soit réglementé par des lois.

C'est pourquoi la sécurité des informations est parfois similaire à la gestion des risques. Vous minimisez le risque du mieux que vous pouvez (ce qui signifie généralement dans le budget), vous ne l'éliminez pas totalement.

Donc, retarder la sécurité est une forme d'acceptation du risque. Espérons que cette acceptation ne dure que peu de temps, car lorsque les dirigeants font cela, ils empruntent en fait à l'avenir. Lorsque la date d'échéance arrive, eh bien, disons simplement que ce serait embarrassant, désordonné et parfois même dévastateur.

Pour plus d'informations sur cette ligne de pensée, consultez Veracode:

http://www.veracode.com/blog/2011/02/application-security-debt-and-application-interest-rates/

http: //www.veracode.com/blog/2011/03/a-financial-model-for-application-security-debt/

Je suis d'accord avec l'exécutif. Si vous regardez le nombre de startups qui ont échoué en raison d'une faille de sécurité, par rapport au nombre de startups qui ont échoué en raison de la perte de la course à la première place, je pense qu'il est clair que ces dernières l'emportent largement sur les premières.

Les startups consistent avant tout à prendre des risques pour remporter la grande victoire. Il y a tellement de façons qu'une startup peut échouer. Dire que nous acceptons une faible probabilité que le démarrage échoue à cause d'une faille de sécurité n'est tout simplement pas si grave, si l'avantage est que nous arrivons à réduire considérablement le risque d'échec de la startup pour d'autres raisons.

Je pense que l'exécutif propose une stratégie plausible: il dit, nous acceptons une dette de sécurité maintenant, en échange d'atteindre la ligne d'arrivée plus rapidement. Cela coûtera plus tard à l'entreprise: l'entreprise devra soit rembourser la dette de sécurité plus tard, en restructurant / ré-implémenter ses systèmes, soit l'entreprise prendra plus tard un grand risque de faille de sécurité grave. Mais de nombreuses startups accepteraient volontiers ce compromis. "Payer plus tard, si la startup est un grand succès" l'emporte probablement sur "payer maintenant, et éventuellement faire échouer la startup".

Voici mon conseil. Plutôt que d'essayer de faire changer d'avis le dirigeant, je vous suggère de faire deux choses:

• Instaurer la notion de «dette de sécurité». Préparez les bases pour que, si l'entreprise réussit, vous obtiendrez plus tard votre adhésion pour rembourser la dette de sécurité et améliorer la sécurité des systèmes de l'entreprise.

• En ce moment, se concentrer sur des mécanismes de sécurité bon marché qui ne ralentiront pas la capacité de l'entreprise à atteindre la ligne d'arrivée. Je parle de choses simples comme les pare-feu, les mises à jour automatiques, les sauvegardes, etc. En outre, vous pouvez réfléchir et développer des solutions ou des conceptions de sécurité plus sophistiquées en parallèle avec l'effort de développement de l'équipe, afin de ne pas ralentir le reste de la équipe - en supposant que l'entreprise puisse vous épargner ce genre d'effort.

Les parasites ruineront non seulement vos sources de revenus potentielles pour les produits / services, mais ils ruineront également votre marque / réputation au début et votre capacité à commercialiser vos produits / services. Ils briseront votre référencement, AdWords et autres concepts de marketing Internet similaires - qui sont nécessaires pour renforcer votre présence en ligne.

Les adversaires automatisent l'infection parasitaire des sites Web avec des botnets et d'autres formes d'automatisation - faisant de chaque site Web un cible potentielle, en particulier ceux en mode démarrage (car ils s'appuient souvent sur des packages d'hébergement tiers / CMS / blog / forum / e-commerce, des composants, des services, etc.).

Récemment, j'ai mis en place un serveur FTP depuis chez moi car je travaille à distance et je voulais un moyen pour mes collègues et clients de pouvoir me transférer de gros fichiers pendant la nuit (à l'autre bout du monde). J'ai été vraiment choqué de découvrir combien de tentatives (automatisées?) Sont faites chaque semaine pour entrer par effraction sur mon serveur FTP - juste un petit serveur domestique sans publicité. Cela m'a convaincu que vous ne pouvez pas être assez paranoïaque - les gens vont essayer de s'introduire par effraction et de voler vos données ou celles de vos clients. Rien de moins que de faire de votre mieux en matière de sécurité est un échec

La sécurité est une question de gestion des risques, qui est en fin de compte une décision commerciale.

Vous devez aider votre responsable de démarrage à comprendre non seulement quels sont les risques, mais également quels seront les coûts de mise en œuvre différer entre le faire maintenant et ensuite. Essayer d'intégrer la sécurité dans un logiciel après sa sortie est difficile et bien plus coûteux.

S'il s'agit d'une course vers la ligne d'arrivée, proposez des solutions qui n'entravent pas leur progression. Les développeurs et les ingénieurs peuvent toujours créer des logiciels pendant que vous travaillez en parallèle avec eux. Essayez de trouver une solution de compromis qui:

• utilise des défenses commerciales prêtes à l'emploi ou des packages prédéfinis (par exemple, des pare-feu d'applications Web)
• vous permet d'intégrer la sécurité dans plus efficacement plus tard grâce à des décisions architecturales précoces (en particulier, savoir où ira le code défensif lorsque vous aurez le temps de l'implémenter)

Une réponse manquée jusqu'à présent est de mettre la sécurité à l'ordre du jour en tant que valeur ajoutée pour la startup. Cela peut être efficace, en particulier dans les industries qui ont récemment subi une attaque très médiatisée. Si les VC ou les parties prenantes peuvent comprendre comment une sécurité améliorée peut les aider à vendre le produit ou le service, alors cela devient un argument qu'ils peuvent comprendre: le profit!

Oui, il peut être très difficile de les convaincre, et beaucoup se résume au timing; comme je l'ai dit, il est beaucoup plus facile juste après quelque chose comme le crack PSN de pousser le concept de sécurité comme une valeur ajoutée pour une entreprise faisant des jeux en ligne, mais malheureusement pas aussi facile d'utiliser le même exemple dans un secteur différent, malgré le fait que le problème était lié à la compromission des données personnelles d'une base de données client, ce qui devrait être pertinent pour tout le monde!

Le cadre est-il cool de diriger l'entreprise sans aucune assurance? Si oui, écoutez ce que tout le monde a dit jusqu'à présent (et fuyez cette entreprise - vite), sinon, demandez-leur pourquoi ils le font alors en ne pensant pas à la sécurité.

Vous pouvez adopter une approche pratique: obtenir la permission et embaucher un testeur d'intrusion junior (de préférence) et le laisser «voler» le secret d'entreprise le plus important que vous ayez, ou trouver une autre faille majeure, ou même effectuer une attaque d'ingénierie sociale ( comme envoyer un fichier pdf malveillant à une secrétaire). Ensuite, présentez à l'exécutif les résultats et concentrez-vous sur les dommages à la réputation (c'est là que les startups font le plus mal).

Les scénarios papier de Pen & ne sont pas aussi efficaces pour démontrer l'insécurité que vos secrets à découvert. Cela devrait les convaincre d’au moins penser à mettre de l’argent en sécurité.

L’argument à faire valoir ici n’est pas que vous n’êtes pas en sécurité, mais la facilité avec laquelle une personne peu expérimentée peut pénétrer par effraction ou trouver un gros faute qui aurait pu être évitée avec un investissement de sécurité minimal.

Vous pouvez avoir un équilibre.

N'ouvrez AUCUN port inutile, et gardez vos éléments "admin" limités au LAN ou à certaines adresses IP d'administration connues. De cette façon, au moins les éléments sur lesquels vous utilisez des raccourcis deviennent uniquement internes.

Chaque startup devrait être tenue de suivre les principes de sécurité de base et pratiques. Si vous ne pouvez pas investir dans la sécurité comme vous le souhaitez, comptez sur la simplicité et un petit inconvénient de votre part pour réduire votre surface d'attaque.

Si votre dirigeant ne peut pas saisir le concept de la sécurité informatique en tant que problème de risque commercial, soit il n'est pas le bon pour le poste lui-même (car la gestion des risques devrait être un problème clé depuis le début) ou personne n'a pu le faire / elle est consciente de ce problème.

Connaître et accepter les risques est une approche valable, pour toutes les entreprises.

C'est le travail d'un cadre de gérer les risques. S'il pense que la sécurité devrait être retardée, c'est à lui de prendre cette décision.

Cela dit, vous devez vous assurer que c'est une décision éclairée. Comme toujours, cela nécessite une liste aussi complète que possible des menaces, de la probabilité et des dommages possibles qui pourraient survenir. Ainsi, par exemple, quelqu'un pourrait voler la base de données client. Ou une porte dérobée pourrait être installée dans vos produits.

Le problème ici est que la probabilité est le plus souvent inconnue ou vous êtes dans une situation N * M où N est la probabilité et M est le dommage et N est beaucoup plus petit que M. C'est comme les centrales nucléaires au Japon: les dommages possibles sont énormes mais la probabilité d'un incident est vraiment, vraiment minime. "Une fois tous les 100'000 ans". Cette «fois» peut être demain (et ce fut dans plusieurs cas comme nous l'avons tous vu). Donc, dans ce cas, le nombre qui en résulte est sans valeur.

Ce que je ferais, c'est m'assurer que le dirigeant prend une décision éclairée: je mettrais en relation son salaire avec le risque. S'il a raison, il obtient un gros bonus. S'il se trompe, les dommages devraient d'abord aller à l'encontre de sa richesse personnelle.

Ce type de filet de sécurité garantit généralement que les gens ne prennent pas trop de risques. Mais cela peut aussi tuer votre start-up car le manager peut arrêter de prendre des risques.

Comme indiqué dans d'autres réponses et commentaires, les deux arguments les plus courants pour intégrer la sécurité dès le début peuvent - probablement valablement - être rejetés dans un environnement de démarrage pressé par le temps:

• C'est Il est garanti que la modernisation de la sécurité coûtera plus cher que de commencer par elle - le modèle d'entreprise des start-ups technologiques suppose qu'il y aura beaucoup plus d'argent disponible au point de basculement de l'entreprise qu'à son lancement.
• Les dommages à la réputation ou les coûts liés à une violation peuvent sombrer dans l'entreprise - si le premier sur le marché est le seul avantage dont vous disposez, il n'y aura rien qui vaille la peine d'être violé si le processus de développement initial est prolongé.

Ce n'est pas seulement un problème de sécurité - cela affecte également d'autres métriques de qualité comme la convivialité et la maintenabilité.

Il y a un argument qui est spécifique aux startups - et il peut indiquer où se trouve le bon équilibre pour cet environnement: que faire si les problèmes de sécurité vous obligent à apporter des modifications intrusives une fois la production uct avait acquis un nombre important d'utilisateurs?

On sait que les logiciels finissent souvent par être utilisés différemment de la façon dont les créateurs l'avaient envisagé. Il s'ensuit que ce que les concepteurs considéraient comme des fonctionnalités clés n'est peut-être pas ce à quoi les utilisateurs se joignent. Cela rend très difficile de juger si un changement perturbera l'adhésivité ou l'acquisition de l'utilisateur. Une décision de conception qui aurait été tout à fait acceptable pour les utilisateurs dans le cadre du produit initial peut même provoquer des réactions négatives si elle est rejetée sur les utilisateurs existants du produit.

Un examen pour minimiser les modifications nécessaires après que le produit a des utilisateurs devrait être vendable sur cet argument. C'est probablement aussi le niveau d'activité de sécurité approprié pour une startup engagée dans une course effrénée pour être la première sur le marché.

Ce dirigeant a-t-il peur de la mauvaise presse?

Regardez ce qui se passe récemment avec Dropbox: Dropbox a menti aux utilisateurs sur la sécurité des données, plainte pour allégations FTC.

Je suis sûr qu'ils ne sont pas satisfaits de ce type d'attention.

Considérez le modèle commercial de votre startup et décrivez quelques mauvais scénarios dans lesquels le manque de sécurité pourrait ne pas simplement apporter une mauvaise presse, mais faire chuter l'entreprise.

Lorsque vous démarrez une nouvelle entreprise, vous n'avez aucune réputation en dehors des dirigeants qui peuvent avoir leurs précédentes distinctions en technologie / biz. En conséquence, si une startup a cette carte d'atteinte à la sécurité devant elle, les dommages à la réputation seront substantiels. Des endroits comme Sony, TJX, Michael sont d'énormes entreprises qui peuvent être en mesure de supporter un tel coup, mais si un dirigeant d'une startup sent qu'il peut survivre à une brèche en tant que startup, il a une vision naïve et myope de la gestion des risques de base. Essentiellement, dans un tel cas, une petite startup serait à la merci de leurs concurrents et de la presse qui pourraient facilement submerger l'esprit de leurs acheteurs potentiels en entachant leur image de la capacité de la startup à protéger ses clients ou ses données réglementées ou simplement accéder à leur Infrastructure.