Comme mentionné dans les commentaires, je suis moi aussi d'accord que 4 heures par mois, c'est bien trop bas. Comprenez, et surtout, faites comprendre à vos parties prenantes qu'avec 4h, elles ne devraient pas s'attendre à grand-chose. Étant donné qu'ils vous ont donné 4h, il ne semble pas non plus qu'ils soient sérieux au sujet de la sécurisation de cette application.

Sur la base des commentaires, des réponses et de mes propres réflexions, je vais essayer de rassembler quelque chose. Voici à quoi je pense que vos options devraient ressembler dans l'ordre.

1. Demandez plus de temps. Faites-leur comprendre s'ils veulent sécuriser une application en seulement 4h, c'est pratiquement inutile.
2. Recrutez une agence et passez vos 4h à définir leur périmètre, prioriser leurs actions et revoir leurs résultats. (@Nelson)
3. Si vous ne pouvez pas faire ce qui précède, je vous recommande de sécuriser les fruits à portée de main pour couvrir plus de terrain en 4h. Voici ce que je pense être important
   • Configurez vos services externes à mettre à jour. (~ 1h pour trouver et définir les applications importantes pour la mise à jour). Fermez les ports / services inutiles que vous ne trouvez pas utiles.
   • Configurez l'authentification multifacteur (~ 10 minutes) - puisque vous n'avez pas beaucoup de temps, configurez des éléments rapides, protégez-vous contre les attaques courantes et vous alerter.
   • Passez en revue vos secrets - Assurez-vous qu'ils sont stockés en toute sécurité, exécutez des scanners sur votre code pour trouver des secrets codés en dur. (~ 1h)
   • Reprise après sinistre - Je vous recommande de consacrer une partie de vos 4 heures précieuses à la mise en place de protections en cas de problème, car elles le feront. Commencez à créer des sauvegardes (2 si possible) dans différentes zones. Je suppose que la plate-forme vous aidera avec cela, mais cela prendra encore du temps. Pendant ce temps, vous pouvez également rédiger un plan de reprise après sinistre approximatif. (~ 1.5h)
   • Enfin, avec le peu de temps qu'il vous reste, documentez. Documentez ce que vous avez fait, ce que vous n'avez pas fait et quelles devraient être les prochaines étapes pour la prochaine fois que quelqu'un aura 4h pour sécuriser davantage l'application. (~ restes)

La protection DoS est bonne et nécessaire, mais je n'ai tout simplement pas trouvé de moyen de l'intégrer au plan ci-dessus et je ne pouvais pas non plus échanger quoi que ce soit contre elle. Peut-être que cela devrait être documenté dans vos prochaines étapes.

Dans l'ensemble, c'est une demande farfelue pour sécuriser quelque chose en 4h. Mais si j'étais chargé de cela, je le ferais avec les étapes ci-dessus. Je ne sais pas si des enquêtes pour savoir si le système est déjà piraté sont réalisables dans ces 4h. Lorsque vous disposez de 4 heures pour sécuriser, vous pouvez choisir de le consacrer à la sécurisation de l'application contre les menaces potentielles ou rechercher des attaquants dans votre système (nécessite un plan différent). Ce choix initial vous appartient.

Commencez par les meilleures pratiques de sécurité Azure pour pouvoir maintenir et améliorer la sécurité de votre solution Azure étape par étape:

1. acceptez et mettez à niveau votre abonnement Azure vers Azure Security Center Standard. Cela vous aidera à trouver et à corriger les vulnérabilités de sécurité, à appliquer des contrôles d'accès et d'application pour bloquer les activités malveillantes, à détecter les menaces à l'aide d'analyses et à répondre rapidement aux attaques;
2. stockez vos clés, vos informations d'identification de base de données, vos clés API et vos certificats dans Azure Key Vault. En outre, assurez-vous que les clés et les secrets de la solution ne sont pas stockés dans le code source de l'application;
3. installez un pare-feu d'application Web (WAF) qui est une fonctionnalité d'Application Gateway et fournit une protection de votre application Web contre les exploits courants et vulnérabilités;
4. appliquer la vérification multifactorielle pour vos comptes d'administrateur;
5. chiffrer vos fichiers de disque dur virtuel;
6. connecter des machines virtuelles et des appliances Azure à d'autres appareils en les plaçant sur les réseaux virtuels Azure;
7. atténuer et protéger contre DDoS avec DDoS Protection Standard qui fournit des capacités d'atténuation supplémentaires;

Lorsque vous êtes prêt avec le 1-7, concentrez-vous sur:

8. gérer les mises à jour de vos VM car Azure ne transmet pas automatiquement les mises à jour Windows
9. en vous assurant de configurer les processus pour les opérations cloud importantes telles que la gestion des correctifs, la sauvegarde, la gestion des incidents, gestion des modifications, accès utilisateur d'urgence, accès privilégié;
10. activer la gestion des mots de passe et utiliser des politiques de sécurité appropriées pour empêcher les abus;
11. examiner votre tableau de bord Security Center pour conserver une vue d'ensemble de l'état de sécurité de toutes vos ressources Azure afin que vous puissiez, si nécessaire, donner suite aux recommandations;

Lisez la documentation Microsoft sur les meilleures pratiques de sécurité Azure.

Documentation:

Les principes de base de la sécurité Microsoft Azure

Documentation de sécurité Microsoft Azure

Il s'agit d'une réponse de champ très hors de gauche (c'est-à-dire qu'elle n'a pas grand-chose à voir avec la sécurité réelle), alors n'hésitez pas à ignorer mes conseils. Cette question elle-même est assez basée sur l'opinion, j'ai donc pensé essayer un "genre" de réponse complètement différent.

Vous avez été chargé de la sécurité des applications. C'est une bonne chose!

Malheureusement, votre employeur a des attentes très irréalistes de ce qui est nécessaire pour sécuriser une application. 4 heures, ce n'est pas assez de temps pour bien faire ce travail. Pour être clair, c'est toujours mieux que la plupart des entreprises (qui attribuent exactement 0 heure par mois de temps de sécurité dédié). La réalité est que 4 heures, c'est une misère. Voici donc ce que vous faites:

1. Courez avec toutes les suggestions que les gens donnent ici
2. Passez bien plus de 4 heures par mois
3. Pour éviter rendre votre employeur mécontent ou désobéir directement aux ordres, faites le travail supplémentaire à votre rythme. Prévoyez de passer les prochains mois à travailler une bonne partie d'heures supplémentaires sur une base régulière.
4. Pendant ce temps, vous apprendrez des choses comme l'examen du code pour les faiblesses de sécurité, l'installation et l'utilisation des systèmes SEIM, installer et utiliser des systèmes de journalisation (la pile ELK est couramment utilisée), des systèmes de détection d'intrusion, une analyse automatique des applications, et plus encore! (la liste complète est probablement trop longue apprenez tout en quelques mois de travail pendant votre temps libre, mais faites de votre mieux!)
5. Votre entreprise va se retrouver avec les avantages de votre travail gratuit, ce qui est un peu triste, mais ...
6. Vous serez sur la bonne voie pour vous former pour devenir un professionnel de la sécurité (si vous vouliez un titre de poste, vous êtes sur la bonne voie pour devenir Candidat Security Engineer) dans le cadre de vos fonctions officielles, sécuriser une application Web réelle en production!
7. Commencez à postuler pour votre prochain emploi en tant qu'ingénieur de sécurité d'application. Vous trouverez probablement un meilleur travail en faisant un travail plus amusant, et vous serez probablement mieux payé aussi!

De toute évidence, je ne peux pas donner de garanties sur la façon dont les choses se passeraient, mais effectivement, ce que vous avez reçu est la permission de commencer à vous entraîner pour un changement de carrière. Une opportunité d'investir dans votre avenir! Les professionnels de la sécurité sont encore plus en demande que les ingénieurs, alors personnellement, je prendrais cela et je fonctionnerais avec. Surtout si cela fonctionnait en ma faveur, je ne voudrais même pas en vouloir à mon employeur actuel pour le travail gratuit que j'allais leur donner en raison de leur myopie.

Je suggère de

1. Commencez par faire une évaluation des risques
2. Compilez les listes données ici (à la fois par vous-même et dans les réponses ) en éléments exploitables
3. Retournez voir vos supérieurs avec le résultat et demandez plus de temps ou une hiérarchisation de leur part.

Comme d'autres l'ont déjà mentionné, 4 heures représentent beaucoup trop peu d'effort, mais je vous fournirai quelques recommandations au cas où vous les trouveriez utiles.

• Exécutez un scanner de vulnérabilité tel que Qualys ou similaire. Cela ramassera un certain nombre de vulnérabilités d'application utiles telles que XSS, injection SQL, CSRF et similaires.
• Exécutez un outil de révision de code pour identifier les mauvaises pratiques évidentes (c'est-à-dire ne pas échapper correctement aux entrées de l'utilisateur avant de les envoyer à la base de données)
• Installer un bon interne (basé sur l'hôte) et externe ( Edge ou cloud) WAF qui protège contre les menaces OWASP et plus encore. Plusieurs WAF basés sur le cloud protégeront également contre les attaques DDoS et certaines attaques par force brute.
• Isolez votre infrastructure dans des zones vlan par la confiance et assurez-vous que les flux de données sont minimaux entre elles (par exemple, Edge, Présentation, Logique métier, Données)
• Quelqu'un l'a déjà mentionné mais très important: assurez-vous stockez les informations d'identification privilégiées (clés API, db creds, etc.) séparément du code source.
• Renforcez toute l'infrastructure.
• Cela peut prendre un certain temps, mais je vous recommande de produire une carte thermique ou une carte de pointage équilibrée des risques de sécurité et de vous assurer qu'elle est visible par vos principaux intervenants. Les bonnes pratiques de sécurité peuvent réduire les risques, mais aucune n’est une solution miracle en soi.

Je vais supposer que l'application est extrêmement petite, vous écrivez des scripts pour les journaux pour rechercher des choses hors de propos (idéalement, cela n'est pas fait pendant la période de travail de 4h), la reprise après sinistre devrait déjà être en place pour un application (vérifiez si l'application nécessite un tel effort.).

1. La documentation est vitale car elle doit vous permettre de savoir ce qui est utilisé et qui l'utilise également à quelle fréquence elle est utilisée. Cela vous aidera lors du développement du script.

2. Les scripts sont nécessaires pour condenser l'équivalent d'un mois de journaux, alors choisissez soigneusement.

3. Vérifiez les sauvegardes.

4. Vérifiez toujours les technologies utilisées et s'il y a des POC ou des exploits. Ne sautez pas dedans et commencez à tenter un exploit vous-même, vous n'avez que 4h.

5. Demande de support supplémentaire si l'application est vitale.

Idéalement, seule la documentation et les scripts devraient prendre du temps. Le repos devrait être assez simple. Ce n'est pas la meilleure chose à faire pour déterminer la valeur du projet et choisir si 4h suffisent.

Comprendre votre cible vous aide à mieux la protéger.

Je suis sûr qu'il y a une meilleure réponse, j'espère qu'ils la fourniront.

OP, il semble que vous soyez principalement un développeur, en regardant vos contributions. Alors, que peut faire un développeur pour augmenter la sécurité?

Au cours du premier mois:

• 2 heures: essayez de modifier une version de certaines dépendances / composants / bibliothèques externes et essayez pour reconstruire l'application. Documentez les incompatibilités en cas d'échec.
• 2 heures: faites tout ce qui est nécessaire pour pousser vos propres modifications via CI / CD, via des tests, via la branche master et en production. Essayez de rattacher d'autres développements s'il y en a, mais dans ce cas, faites particulièrement attention à laisser des traces que vous avez réellement fait quelque chose d'utile (par exemple, créer des PR).

Répétez tous les mois, mais ajustez la ligne de division entre les deux au fur et à mesure. (Il y a de fortes chances que la séparation finale soit plus de 10 minutes contre 3 heures 50 minutes.)

De cette façon, vous corrigez le pire vecteur - que l'un des composants / bibliothèques populaires a une vulnérabilité publiée il y a des mois ( CVE). Des essaims de robots commencent à analyser l'intégralité de l'Internet, repérant chaque déploiement vulnérable. Si vous mettez simplement à niveau les composants tiers, ne serait-ce qu'en faisant des suppositions (informées?), Il y a de bonnes chances que vous ne deveniez jamais une victime et que vous n'ayez jamais besoin de gérer les situations vraiment désagréables.

C'est assez trivial pour les développeurs, mais dans la plupart des entreprises, les développeurs évitent une telle maintenance inintéressante. Cela devient un gros problème pour les services de sécurité typiques (car ils ne recompilent pas les applications). Les grands efforts pour «analyser les journaux» ou «mettre en œuvre des WAF» ou «effectuer des analyses de vulnérabilité» visent principalement à couvrir cette lacune sous tous les angles possibles.

D'après votre question, il semble que vous vous demandez comment concentrer votre apprentissage . Je voudrais contester cette hypothèse ici et maintenant. Celui qui vous a alloué 4 heures par mois a déjà coupé sa propre candidature du bénéfice de votre auto-formation. Irresponsable de leur part! Pour apprendre quelque chose de dédié à ce projet, puis le mettre en œuvre, puis apprendre sur vos erreurs et itérer ... Cela ne peut pas être fait par tranches de 4 heures chaque mois. Ne «réparez» pas cela, car ce n'était pas votre décision! À l'époque de ce projet, faites des choses que vous connaissez déjà bien.

C'est un début. Ce que vous essayez d'apprendre et de mettre en œuvre pendant votre temps libre, c'est votre préférence et votre propre entreprise. Je pense que c'est trop large pour ce site (car il se peut que vous décidiez que la sécurité ne vous intéresse pas, ce qui est tout à fait correct), mais d'autres vous ont quand même donné des tonnes de pistes. Recherchez également des éléments utiles lors de vos autres projets. Certains des premiers ou des derniers s'inscriront dans ces 4 heures et contribueront à améliorer l'état du projet.

De la part d'un administrateur système qui a dû faire de telles choses, je recommanderais simplement de créer une VM de développement que vous pouvez échanger avec prod.

1. Sauvegardez votre serveur.
2. Séparez vos bases de données sur leurs propres serveurs. Assurez-vous qu'ils ne peuvent communiquer qu'avec UNE SEULE adresse IP, le serveur / service de production qui en a besoin. (Changement unique, très important.)
3. Clonez le serveur principal et attribuez au nouveau une adresse IP différente.
4. Apportez toutes les modifications, mises à jour, révisions et vérifications nécessaires.
5. Lorsque la fenêtre de 4 heures est disponible, arrêtez les services sur les bases de données principales.
6. Sauvegarde des bases de données. ÉTAPE CRITIQUE.
7. Transférer toutes les modifications locales de principal à cloné.
8. Assurez-vous que tout a l'air bien et fonctionne correctement.
9. Échangez les adresses IP pour les adresses principales et clonées. .
10. Cloné est maintenant principal.
11. Faites une autre sauvegarde de tout. (Oui, faites-en une autre.)
12. Amenez les services sur main.
13. Laissez l'autre système seul comme sauvegarde en cas de problème.

Vous ne mentionnez pas les risques: stocke-t-il des données personnelles, etc. le genre de métacaractères qui pourraient être dans une attaque par injection, et signaler une vulnérabilité chaque fois que vous obtenez une erreur 500.

Malheureusement, la réponse habituelle est "ce n'est pas exploitable", en particulier dans un environnement naïf de sécurité comme vous semblez être. Et transformer une vulnérabilité en exploit prend plus que les quatre heures prévues au budget.

Autre réponse: passez le temps à peaufiner votre CV, car cet employeur pourrait fermer ses portes à tout moment.