J'ai seulement 4 heures par mois pour vérifier la sécurité d'une application basée sur le cloud - Comment utiliser mon temps?
J'ai été chargé de gérer une application déployée sur Azure. J'ai 4 heures par mois.
J'ai essentiellement une demi-journée de travail pour sécuriser/sécuriser cette application. Qu'est-ce qu'une utilisation efficace de mon temps?
Dois-je me concentrer sur:
- Vous assurer que tous les composants sont à jour?
- Vérifier tous les journaux pour vous assurer que rien ne semble douteux?
- Vous essayez de "pirater" l'application moi-même?
- Documenter le système en détail dans une perspective de sécurité?
- Vous recherchez des vulnérabilités actuelles dans cette technologie/connexe?
- Vous assurer que les sauvegardes, etc. fonctionnent correctement?
- Trucs de récupération après sinistre?
- Créer une politique de "piratage"?
- Auditer le code source avec un outil pour rechercher de mauvais modèles?
Ou une combinaison/autre chose?
Je recherche des réponses basées sur l'expérience, de préférence de quelqu'un qui fait ce genre de maintenance de sécurité. S'il existe un quelconque type de meilleures pratiques/lignes directrices existantes, cela serait également très utile.
La pile technologique est la suivante:
- Base de données SQL Server (Azure SQL)
- API Web C #
- Front End angulaire
Il y a plusieurs composants supplémentaires, mais je ne recherche pas vraiment de réponses spécifiques à la technologie, plus une stratégie sur la façon d'aborder cela.
Commencez par les meilleures pratiques de sécurité Azure afin de pouvoir maintenir et améliorer la sécurité de votre solution Azure étape par étape:
- 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;
- stockez vos clés, vos informations d'identification de base de données, vos clés API et vos certificats dans Azure Key Vault. Assurez-vous également que les clés et les secrets de la solution ne sont pas stockés dans le code source de l'application;
- installer un pare-feu d'application Web (WAF) qui est une fonctionnalité d'Application Gateway et assure la protection de votre application Web contre les exploits et les vulnérabilités courants;
- appliquer la vérification multifactorielle pour vos comptes d'administrateur;
- crypter vos fichiers de disque dur virtuel;
- connecter des machines virtuelles et des appliances Azure à d'autres appareils en réseau en les plaçant sur des réseaux virtuels Azure;
- atténuer et protéger contre les DDoS avec la norme de protection DDoS qui offre des capacités d'atténuation supplémentaires;
Lorsque vous êtes prêt avec le 1-7, concentrez-vous sur:
- gérer vos VM mises à jour car Azure ne pousse pas automatiquement les mises à jour Windows
- en veillant à configurer les processus pour les opérations cloud importantes telles que la gestion des correctifs, la sauvegarde, la gestion des incidents, la gestion des changements, l'accès utilisateur d'urgence, l'accès privilégié;
- activer la gestion des mots de passe et utiliser des politiques de sécurité appropriées pour éviter les abus;
- passez en revue 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, prendre des mesures sur les recommandations;
Lisez la documentation Microsoft sur les Meilleures pratiques de sécurité Azure .
Documentation:
Comme mentionné dans les commentaires, je suis moi aussi d'accord 4 heures par mois, c'est beaucoup trop bas. Comprenez, et plus important encore, faites comprendre à vos parties prenantes qu'avec 4h, elles ne devraient pas en attendre beaucoup. Étant donné qu'ils vous ont donné 4 heures, 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 préparer quelque chose. Voici à quoi je pense que vos options devraient ressembler dans l'ordre.
- Demandez plus de temps. Faites-leur comprendre s'ils veulent sécuriser une application en seulement 4h, c'est pratiquement inutile.
- Louez une agence et passez vos 4h à définir leur périmètre, prioriser leurs actions et revoir leurs résultats. (@Nelson)
- Si vous ne pouvez pas faire ce qui précède, je vous recommande de sécuriser les fruits bas pour que vous couvriez plus de terrain en 4h. Voici ce que je pense être important
- Configurez vos services externes pour la mise à jour. (~ 1h pour rechercher et définir les applications importantes à mettre à jour). Fermez les ports/services inutiles que vous ne trouvez pas utiles.
- Configurez MFA (~ 10 minutes) - puisque vous n'avez pas beaucoup de temps, configurez des choses qui sont rapides, vous protège contre les attaques courantes et vous alerte.
- 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)
- Récupération après sinistre - Je recommanderais 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,5 h)
- 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 requise, mais je ne pouvais tout simplement pas trouver un moyen de l'adapter au plan ci-dessus et je ne pouvais rien échanger pour cela. Peut-être que cela devrait être documenté dans vos prochaines étapes.
Dans l'ensemble, c'est une demande farfelue de 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 4h pour sécuriser, vous pouvez soit choisir de le dépenser pour sécuriser l'application contre les menaces potentielles, soit enquêter sur les attaquants de votre système (nécessite un plan différent). Ce choix initial est le vôtre.
Il s'agit d'une réponse de champ très à gauche (c'est-à-dire qu'elle a peu à voir avec la sécurité réelle), alors n'hésitez pas à ignorer mes conseils. Cette question elle-même est plutôt basée sur l'opinion, alors j'ai pensé essayer un "type" 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 quant à 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 encore 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 sont une somme dérisoire. Voici donc ce que vous faites:
- Courez avec toutes les suggestions que les gens donnent ici
- Passez beaucoup plus de 4 heures par mois
- Pour éviter de rendre votre employeur mécontent ou de désobéir directement aux ordres, faites le travail supplémentaire à votre rythme. Prévoyez de passer les prochains mois à travailler régulièrement une bonne partie des heures supplémentaires.
- Pendant ce temps, vous apprendrez des choses comme l'examen du code pour détecter les failles de sécurité, l'installation et l'utilisation des systèmes SEIM, l'installation et l'utilisation des systèmes de journalisation (la pile ELK est couramment utilisée), les systèmes de détection d'intrusions, l'analyse automatique des applications, et plus encore! (la liste complète est probablement trop longue pour tout apprendre en quelques mois de travail pendant votre temps libre, mais faites de votre mieux!)
- Votre entreprise va se retrouver avec les avantages de votre travail gratuit, ce qui est un peu triste, mais ...
- Dans le cadre de vos fonctions officielles, vous serez en bonne voie de vous former pour devenir un professionnel de la sécurité (si vous vouliez un titre d'emploi, vous êtes sur le point d'être un ingénieur de la sécurité des applications), sécurisant une application Web réelle en production. utilisation!
- Commencez à postuler pour votre prochain emploi en tant qu'ingénieur de sécurité des applications. Vous trouverez probablement un meilleur travail en faisant un travail plus amusant, et vous serez probablement mieux payé aussi!
Évidemment, je ne peux donner aucune garantie sur la façon dont les choses se passeraient, mais en fait, ce qu'on vous a donné, c'est la permission de commencer à vous former pour un changement de carrière. Une opportunité d'investir dans votre avenir! Les professionnels de la sécurité sont encore plus demandés que les ingénieurs, alors personnellement, je prendrais cela et je courrais avec. Surtout si cela fonctionnait en ma faveur, je ne voudrais même pas reprocher à mon employeur actuel le travail gratuit que j'allais leur donner en raison de leur myopie.
Je suggérerais de
- Commencez par faire une évaluation des risques
- Compilez les listes données ici (par vous-même et dans les réponses) en éléments exploitables
- Retournez voir vos supérieurs avec le résultat et demandez-leur plus de temps ou une hiérarchisation.
Je vais supposer que l'application est extrêmement petite, vous écrivez des scripts pour que les journaux recherchent les choses hors de propos (idéalement, cela ne se fait pas pendant la période de travail de 4 heures), la reprise après sinistre devrait déjà être en place pour une application principale (vérifiez si l'application nécessite un tel effort.).
La documentation est vitale car elle devrait vous permettre de savoir ce qui est utilisé et qui l'utilise également à quelle fréquence. Cela vous aidera lors du développement du script.
Des scripts sont nécessaires pour condenser la valeur d'un mois de journaux, alors choisissez soigneusement.
Vérifiez les sauvegardes.
Vérifiez toujours les technologies utilisées et s'il existe des POC ou des exploits. Ne sautez pas dedans et commencez vous-même à tenter un exploit, vous n'avez que 4h.
Demande d'assistance supplémentaire si l'application est vitale.
Idéalement, seuls la documentation et les scripts devraient prendre du temps et devraient être assez simples. Ce n'est pas le meilleur dont vous disposerez 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 le fourniront.
OP, on dirait que vous êtes principalement un développeur, en regardant vos contributions . Alors, que peut faire un développeur pour augmenter la sécurité?
Au premier mois:
- 2 heures: essayez de bump une version de certaines dépendances/composants/bibliothèques externes et essayez de 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 les tests, via la branche
masteret vers la production. Essayez d'essayer de jumeler 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 faites quelque chose d'utile (par exemple, créez des RP).
Répétez chaque mois, mais ajustez la ligne de division entre les deux au fur et à mesure. (Il y a de fortes chances que le partage final soit plus proche de 10 minutes contre 3 heures 50 minutes.)
De cette façon, vous corrigez le pire vecteur - l'un des composants/bibliothèques populaires a une vulnérabilité publiée (CVE) vieille de plusieurs mois. Des essaims de robots commencent à analyser l'intégralité d'Internet en attente de chaque déploiement vulnérable. Si vous mettez simplement à niveau les composants tiers, même uniquement en faisant des suppositions (informées?), Il y a de bonnes chances que vous ne deveniez jamais une victime et que vous ne puissiez jamais en avoir besoin pour gérer les désagréables vraiment désagréables situations.
C'est assez banal pour les développeurs, mais dans la plupart des entreprises, les développeurs évitent une telle maintenance sans intérêt. 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 "implémenter les WAF" ou "effectuer des analyses de vulnérabilité" visent principalement à combler cet écart sous tous les angles possibles restants.
D'après votre question, il semble que vous vous demandez comment concentrer votre apprentissage . J'aimerais contester cette hypothèse ici et maintenant. Celui qui vous a alloué 4 heures par mois a déjà coupé sa propre application de bénéficier de votre auto-éducation. Irresponsable d'eux! Pour apprendre quelque chose de dédié à ce projet, puis l'implémenter, puis apprendre sur vos erreurs et répéter ... Cela ne peut pas être fait en morceaux de 4 heures chaque mois. Ne "corrigez" pas cela, car ce n'était pas votre décision! À l'époque de ce projet, faites des choses que vous connaissez déjà bien.
Voilà une entrée. Ce que vous essayez d'apprendre et de mettre en œuvre dans 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 vous n'êtes pas intéressé par la sécurité, ce qui est tout à fait correct), mais d'autres vous ont quand même donné des tonnes de pistes. Recherchez également des choses 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.
Comme d'autres l'ont déjà mentionné, 4 heures représentent bien trop peu d'efforts, mais je fournirai quelques recommandations au cas où vous les trouveriez utiles.
- Exécutez un scanner de vulnérabilité tel que Qualys ou similaire. Cela détectera 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 les entrées utilisateur avant de les envoyer à la base de données)
- Installez un bon WAF interne (basé sur l'hôte) et externe (basé sur Edge ou cloud) qui protège contre les menaces OWASP et plus encore. Plusieurs WAF basés sur le cloud protègent également contre les attaques DDoS et certaines attaques par force brute.
- Isolez votre infrastructure dans des zones vlan par confiance et assurez un minimum de flux de données entre elles (par exemple, Edge, Présentation, Logique métier, Données)
- Quelqu'un d'autre l'a mentionné auparavant mais très important: assurez-vous de stocker les informations d'identification privilégiées (clés API, db creds, etc.) séparément du code source.
- Renforcez toutes les infrastructures.
- Cela peut prendre un certain temps, mais je vous recommande de produire une carte thermique ou un tableau de bord équilibré des risques de sécurité et de vous assurer qu'il 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.
D'un administrateur système qui a dû faire de telles choses, je recommanderais simplement de créer un dev VM que vous pouvez échanger avec prod.
- Sauvegardez votre serveur.
- 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.)
- Clonez le serveur principal et donnez au nouveau une adresse IP différente.
- Apportez toutes les modifications, mises à jour, révisions et vérifications nécessaires.
- Lorsque la fenêtre de 4 heures est disponible, arrêtez les services sur le réseau principal.
- Sauvegarde des bases de données. ÉTAPE CRITIQUE.
- Poussez tous les changements locaux du principal au cloné.
- Assurez-vous que tout a l'air bien et fonctionne correctement.
- Échangez les adresses IP pour principale et clonée.
- Le clonage est maintenant principal.
- Faites une autre sauvegarde de tout. (Oui, faites-en un autre.)
- Apportez les services sur le principal.
- Laissez l'autre système seul en tant que sauvegarde au cas où quelque chose se produirait.
Vous ne mentionnez pas les risques: stocke-t-il des données personnelles, etc. Mais s'il s'agit d'une application complexe, alors une approche qui est assez efficace en termes de temps est le test fuzz: extraire des requêtes valides des journaux, les muter avec le type de les métacaractères qui pourraient être dans une attaque par injection et signalent 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 l'être. Et transformer une vulnérabilité en exploit prend plus que vos quatre heures budgétisées.
Autre réponse: passez du temps à peaufiner votre CV, car cet employeur pourrait faire faillite à tout moment.