Tour de France Azure PaaS 4/7 Sécuriser la solution

Notes de l'éditeur

• #5: Datacenter Physical Security Video Virtual Tour For Pillars
• #6: <Spend some quality time on this slide.> Ask participants what their responsibilities are today. Tell them they would not lose their jobs if some of these responsibilities were transferred to a cloud provider. It would just make things more agile and simpler to them. They would still need to manage their cloud environment. In a traditional datacenter, the IT organization is responsible for the entire infrastructure. This is how on-premises computing has worked from the beginning of modern client/server computing (and even before that, in the mainframe era). If something was wrong with the network, storage, or compute infrastructure, the IT organization was responsible for finding out what the problem was, and fixing it. The same went for the security organization. The security organization worked with the IT organization as a whole to ensure that all components of the IT infrastructure were secure. The corporate security organization set requirements, rationalized those requirements with the corporate IT organization, and then defined controls that could be implemented by the IT infrastructure and operations staff. The security organization also defined compliance requirements and was responsible for auditing the infrastructure to make sure that those requirements were met on an ongoing basis. All of this is still true for the on-premises datacenter. However, with the introduction of public cloud computing, the IT and security organizations have a new partner—the cloud service provider. The cloud service provider has its own IT infrastructure and is responsible for the security requirements and controls implemented on that infrastructure. This means you need to not only be aware of and define your own security requirements, you need to also be able to have enough visibility into the security infrastructure and operations of your cloud service provider. The extent to which you need to do this depends on the cloud security model your company is using on the cloud service provider’s infrastructure.  Ceci étant dit, quels sont les acteurs et leurs responsabilités légitimes.
• #10: SDL (Security Development Lifecycle) est un processus d’assurance qualité centré sur le développement de logiciel. Initiative lancée en 2004 et processus appliqué à tous les développements Microsoft depuis cette date, SDL a joué un rôle important dans la prise en compte de la sécurité et du respect de la vie privée dans les logiciels Microsoft et dans la culture de l’entreprise. En combinant une approche globale et pratique, SDL introduit la sécurité et le respect de la vie privée dès le début du projet et tout au long des différentes phases du développement. Microsoft SDL repose sur trois concepts fondamentaux : formation, amélioration continue du processus et responsabilisation. La sensibilisation permanente et la formation des personnes au sein d’un groupe de développement jouent un rôle très important. Un investissement adéquat dans le transfert des connaissances aide les organisations à réagir correctement à des changements dans la technologie et le paysage des menaces. Le risque de sécurité n’étant pas statique, SDL insiste sur la compréhension des causes et l’effet des vulnérabilités en sécurité. SDL exige une évaluation régulière des processus SDL et l’introduction de changements en réponse à de nouvelles avancées technologiques ou à de nouvelles menaces. Des données sont collectées pour évaluer l’efficacité de la formation, des métriques pendant le déroulement du processus confirment la conformité du processus, et des métriques après la sortie du produit guident vers de futures modifications. Enfin, SDL exige l’archivage de toutes les données nécessaires à la résolution d’un problème en cas de crise. Lorsque SDL est couplé à des plans détaillés de communication et de réponse de sécurité, une organisation peut fournir des conseils précis et pertinents à toutes les parties concernées.
• #11: L’idée derriere cette application est très simple. J’ai une application Mobile (Desktop en l’occurrence), qui va copier des images dans un compte de stockage sous forme de blob. Une fonction Azure va automatiquement se déclencher et venir consommer cette image Elle va fournir à des fins d’analyze cette image à l’API Cognitive Vision L’API Vision retourne le résultat sous forme de ….. La Fonction Azure invoque l’API Rest L’API REST Sauvegarde le résultat dans une base de données SQL Database L’application Mobile invoke l’API Rest pour obtenir le résultat
• #12: En synthèse, Microsoft SDL est un ensemble d’activités obligatoires dans le domaine de la sécurité, réparties sur l’ensemble des phases du développement logiciel. Ces activités peuvent déjà contribuer à renforcer la sécurité lorsqu’elles sont appliquées chacune séparément. Toutefois, l’expérience pratique de Microsoft montre que ces activités conduisent à des améliorations bien supérieures de la sécurité lorsqu’elles sont combinées entre elles, tout au long du processus de développement. Rôles, responsabilités et qualifications du personnel de sécurité SDL inclut des descriptions des postes et des critères généraux pour les rôles relatifs à la sécurité et au respect de la vie privée. Ces rôles sont définis au cours de la phase Exigences du processus SDL. Ils permettent de définir la structure organisationnelle nécessaire pour identifier, cataloguer et atténuer des problèmes de sécurité et de respect de la vie privée présents dans un projet de développement logiciel. Ces rôles sont notamment : Rôles des conseillers. Ces rôles assurent la surveillance de la sécurité et du respect de la vie privée ; ils ont l’autorité pour accepter ou rejeter des plans de l’équipe projet concernant la sécurité et la vie privée. Un groupe central interne à l’entreprise est préférable car il connaît mieux le contexte de l’entreprise que des experts extérieurs.   Conseiller en sécurité / Conseiller en respect de la vie privée. Ces rôles sont tenus par des experts en la matière et n’appartiennent pas à l’équipe projet. Il peut s’agit d’un membre qualifié d’un groupe central et indépendant dans l’entreprise, spécialement formé pour effectuer des contrôles de ce type, ou d’un expert externe à l’entreprise. La personne choisie doit remplir deux sous-rôles : Auditeur. La personne contrôle chaque phase du processus de développement logiciel et atteste que l’application respecte chacune des exigences dans le domaine de la sécurité. Le conseiller doit avoir la liberté d’attester la conformité (ou la non-conformité) par rapport aux exigences en matière de sécurité et de respect de la vie privée, sans interférer avec l’équipe projet. Expert. La personne choisie pour un rôle de conseiller doit posséder une expertise reconnue dans le domaine de la sécurité. Combinaison des rôles de conseil. Le rôle de conseiller en sécurité peut être combiné avec le rôle de conseiller en respect de la vie privée si la personne possède des compétences et une expérience reconnues dans les deux domaines. Champions d’équipe. Les rôles de champions devraient être tenus par des experts en sécurité faisant partie de l’équipe projet. Ces personnes sont responsables de la négociation, de l’acceptation et du suivi des exigences minimales en termes de sécurité et de respect de la vie privée. Ils assurent une communication claire avec les conseillers et les chefs de projet. Champion en sécurité / Champion en respect de la vie privée. Cette personne (ou le groupe de personnes) n’a pas seule la responsabilité d’assurer qu’un logiciel réponde à tous les problèmes de sécurité, mais elle est responsable de la coordination et du suivi des questions de sécurité pour le projet. Ce rôle doit aussi remonter l’état du projet au conseiller en sécurité et aux autres parties concernées (par exemple, aux responsables des tests et du développement).   Combinaison des rôles. Comme pour les rôles de conseiller en sécurité et en respect de la vie privée, les rôles de champions peuvent se combiner si la personne possède des compétences et une expérience reconnues dans les deux domaines.
• #13: Activité SDL 5 : Exigences de conception Pour pouvoir influer sur la confiance mise dans la conception d’un projet, il est important de s’en préoccuper dès le début du projet. Il est particulièrement important de prendre en compte les problèmes de sécurité et de respect de la vie privée dès la phase de conception. La résolution ou l’atténuation de ces problèmes coûtent moins cher lorsqu’elles sont réalisées au tout début du projet. L’équipe ne doit pas reporter la prise en compte des problèmes de sécurité et de respect de la vie privée à la fin du développement. Une exception formelle ou une méthode de report de bogue doit faire partie de tout processus de développement logiciel. De nombreuses applications exploitent encore du code de conception ancienne et il peut être nécessaire de reporter certaines mesures de sécurité ou de respect de la vie privée en raison de contraintes techniques.   Par ailleurs, l’équipe doit comprendre la différence entre « fonction de sécurité » et « fonction sûre ». Il est tout à fait possible d’implémenter une fonction de sécurité qui n’est pas sûre. Une fonction sûre est conçue en plaçant la sécurité au cœur de son développement. Par exemple, les données sont validées de façon rigoureuse avant d’être traitées, et les technologies de cryptographie employées sont parmi les plus robustes. Une fonction de sécurité est une fonction qui a des implications dans le domaine de la sécurité, comme une authentification Kerberos ou un pare-feu. La définition des exigences lors de la conception implique un certain nombre d’actions obligatoires. Par exemple, il s’agit de définir les spécifications techniques de sécurité et de respect de la vie privée, d’analyser ces spécifications et de définir les exigences minimales en termes de cryptographie. Les spécifications techniques décrivent les fonctionnalités de sécurité et de respect de la vie privée qui seront directement exposées aux utilisateurs, comme demander une authentification de l’utilisateur pour accéder à certaines données ou obtenir le consentement de l’utilisateur avant d’utiliser une fonction présentant un risque élevé dans le domaine de la vie privée. De plus, les spécifications techniques doivent décrire comment implémenter de façon sûre les fonctionnalités décrites. Il est conseillé de valider les spécifications techniques en les rapprochant des spécificités fonctionnelles de l’application. Les spécifications fonctionnelles devraient : Décrire de façon complète et précise l’utilisation prévue d’une fonctionnalité. Décrire comment déployer la fonctionnalité de façon sûre. Activité SDL 6 : Réduction de la surface d’attaque La réduction de la surface d’attaque est étroitement liée à la modélisation des menaces bien qu’elle résolve des problèmes de sécurité selon une perspective différente. La réduction de la surface d’attaque est un moyen de diminuer les risques en offrant moins d’opportunités aux attaquants pour exploiter une faiblesse potentielle ou une vulnérabilité. Cette technique retire certains services ou en restreint l’accès, applique le principe de moindre privilège et emploie plusieurs niveaux de défense chaque fois que cela est possible. Activité SDL 7 : Modélisation des menaces La meilleure méthode pour modéliser les menaces est d’utiliser l’outil SDL Threat Modeling Tool. Il est basé sur la classification des menaces STRIDE.   La modélisation des menaces est employée dans des environnements où il existe un risque sérieux de sécurité. L’équipe de développement prend en compte, documente et étudie les implications de la conception dans le domaine de la sécurité, dans le contexte de l’environnement opérationnel prévu, et de façon structurée. La modélisation des menaces permet aussi de prendre en considération des problèmes de sécurité au niveau de l’application ou d’un composant. C’est un travail d’équipe impliquant les chefs de projet, les développeurs et les testeurs. La modélisation des menaces représente la principale tâche d’analyse de la sécurité effectuée au cours de la phase de conception du logiciel.
• #17: There are any techniques for prioritizing the threats. Source is Threat Modeling: designing for Security, Adam Shostack, Wiley ed., 12 February 2014. «Do the easy fixes first» is easy to do but tend to solve the less important things. It is commonly considered to be weak. Please consider that the «Dephi Oracle» method is sometimes simply called «Oracle» (ex.: (ISC)2 CSSLP). It is based on an overall estimation done «by the gut», considering synthetically parameters like the probability that the vulnerability is discovered, how easy would be to take advantage of it and how much damage would be done. The estimation is typically expressed with a scale from 1 to 3, where 1 means a low priority and 3 a high priority; it can be also used a three-level scale from LOW to HIGH. Do the easy fixes first «Delphi Oracle» method Average DREAD method Probability x Impact DREAD method [put your other more complex methods here]
• #18: Damage (Dommage) : quelle serait la gravité de l’attaque pour le système ? Reproducibility  (Reproductibilité)  : quelle est la facilité à reproduire l’attaque ? Exploitability  (Exploitabilité)  : quel volume de travail faut-il pour lancer l’attaque ? Affected users  (Utilisateurs impactés)  : combien d’utilisateurs seraient impactés ? Discoverability (Accessibilité) : quelle est l’accessibilité de la menace ? Here are some examples of how to quantify the DREAD categories. Damage Potential If a threat exploit occurs, how much damage will be caused? 0 = Nothing 5 = Individual user data is compromised or affected. 10 = Complete system or data destruction Reproducibility How easy is it to reproduce the threat exploit? 0 = Very hard or impossible, even for administrators of the application. 5 = One or two steps required, may need to be an authorized user. 10 = Just a web browser and the address bar is sufficient, without authentication. Exploitability What is needed to exploit this threat? 0 = Advanced programming and networking knowledge, with custom or advanced attack tools. 5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools. 10 = Just a web browser Affected Users How many users will be affected? 0 = None 5 = Some users, but not all 10 = All users Discoverability How easy is it to discover this threat? 0 = Very hard to impossible; requires source code or administrative access. 5 = Can figure it out by guessing or by monitoring network traces. 9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine. 10 = The information is visible in the web browser address bar or in a form.
• #20: On va se preter à un petit exercice
• #22: Démo du Threat modeling tools
• #27: Maintenant pour les
• #31: If you want the users of your app to authenticate with: Work/School accounts or on premise accounts, then you should use ADAL, and register your application with https://portal.azure.com Work/school accounts or MSA (Microsoft personal accounts), then you should use MSAL and register your application with https://apps.dev.Microsoft.com local or social accounts (such as Gmail, Twitter, MSA), etc … then you should use MSAL and register your application in an Azure AD B2C tenant in the http://portal.azure.com See also v1-v2-comparisons and v2 limitations
• #33: Création d’une application Web avec Visual Studio qui s’authentifie auprés d’azure Active directory
• #34: Title: Encryption technologies in Azure Objectives: Show what risks are covered by technologies Description The table details the three main risks covered or not in function of technology The ability for a malicious administrator on the cloud provider's side to access data The risk of information theft that one associates with a specifically malicious action Information leakage that is associated to an involuntary action resulting in the dissemination of information beyond authorized boundaries We can notice that: All encryption solutions protect against information theft; indeed, since the data is encrypted at rest on, the theft of media does not allow access to the data they host. Encryption of communications with TLS protects data in transit against interception that would lead to theft or leakage of information The risk of information leakage is not covered by the last 4 solutions as an authorized user can access the data in clear text and unintentionally copy or send it Logically, only the 2 encrypting the data at the client-side are those that protect against a malicious administrator of the cloud provider at the expense of a potential loss of functionality; as data is encrypted before being copied to the cloud, it is NOT available unencrypted on the drive or in memory from the cloud service.
• #36: Azure Key Vault can encrypt keys and small secrets such as passwords by using keys stored in hardware security modules (HSMs). For added assurance, you can import or generate keys in HSMs Microsoft does not see or extract your keys Monitor and audit key use with Azure logging—pipe logs into Azure HDInsight or your SIEM for additional analysis and threat detection Provides: Security Compliance Centralized Administration Keep Control of your keys Authorization Scalability Redundancy Reduced cost
• #38: On peut donc ensuite decliner pour tous les autres services
• #39: Faire demo Storage + MSI + Crypto, montrer Azure Explorer
• #40: Transparent Data Encryption Chiffrement déchiffrement en temps  réel de la base de données, des sauvegardes associées et des fichiers journaux transactionnels au repos, sans qu’il soit nécessaire de modifier l’application. Always Encrypted Always Encrypted est une fonctionnalité conçue pour protéger les données sensibles, telles que les numéros de carte de crédit ou les numéros nationaux d’identification (par exemple, les numéros de sécurité sociale aux États-Unis), qui sont stockées dans des bases de données Azure SQL Database ou SQL Server. Always Encrypted permet aux clients de chiffrer des données sensibles dans des applications clientes et de ne jamais révéler les clés de chiffrement au Moteur de base de données  Always Encrypted rend le chiffrement transparent pour les applications. À cette fin, un pilote Always Encrypted installé sur l’ordinateur client chiffre et déchiffre automatiquement les données sensibles dans l’application cliente. Le pilote chiffre les données dans les colonnes sensibles avant de les transmettre au Moteur de base de donnéeset il réécrit automatiquement les requêtes pour que la sémantique de l’application soit conservée. De même, il déchiffre de manière transparente les données stockées dans les colonnes de base de données chiffrées, qui figurent dans les résultats de la requête.
• #41: With Azure Security Center, you can do all of that and more. You can: Understand the security state of all your Azure resources – across all of your subscriptions Take control of cloud security with policies that enable you to recommend and monitor security configurations Make it easy for DevOps to deploy integrated Microsoft and partner security solutions Find threats with advanced analysis of your security-related events developed using Microsoft’s vast global intelligence assets and expertise Respond and recover from incidents faster with real-time security alerts Export security events to a SIEM for further analysis
• #42: Secure the subscription: A secure cloud subscription provides a core foundation upon which subsequent development and deployment activities can be conducted. An engineering team should have the capabilities to deploy and configure security in the subscription including elements such as alerts, ARM policies, RBAC, Security Center policies, JEA, Resource Locks, etc. Likewise, it should be possible to check that all settings are in conformance to a secure baseline. Enable secure development: During the coding and early development stages, developers should have the ability to write secure code and to test the secure configuration of their cloud applications. Just like build verification tests (BVTs), we introduce the concept of security verification tests (SVTs) which can check for security of various resource types in Azure. Integrate security into CICD: Test automation is a core tenet of devops. We emphasize this by providing the ability to run SVTs as part of the VSTS CICD pipeline. These SVTs can be used to ensure that the target subscription used to deploy a cloud application and the Azure resources the application is built upon are all setup in a secure manner. Continuous Assurance: In the constantly changing dev ops environment, it is important to move away from the mindset of security being a milestone. We have to treat security as a continuously varying state of a system. This is made possible through capabilities that enable continuous assurance using a combination of automation runbooks, schedules, etc. Alerting & Monitoring: Visibility of security status is important for individual application teams and also for central enterprise teams. We provide solutions that cater to the needs of both. Moreover, the solution spans across all stages of dev ops in effect bridging the gap between the dev team and the ops team from a security standpoint through the single, integrated views it generates. Cloud Risk Governance: Lastly, underlying all activities in the kit is a telemetry framework that generates events capturing usage, adoption, evaluation results, etc. This allows us to make measured improvements to security targeting areas of high risk and maximum usage before others.
• #43: Security IntelliSense augments standard Visual Studio IntelliSense feature with secure coding knowledge. This makes it possible to get 'inline' assistance for fixing potential security issues while writing code. Code that is vulnerable or not policy compliant is flagged with red or green squiggles based on the level of severity. In the current drop, we have support for the following features: About 80 rules that cover a variety of scenarios such as: various Azure PaaS API related secure coding rules ADAL-based authentication best practices Common Crypto errors Classic App Sec and Web App Sec issues Rule are auto-updated without needing to reinstall the plug-in. The plug-in periodically checks if new rules have been published to a central rule store and updates its local rule set based on that.
• #44: Montrer Azure Security Center Puis AzureSDK Get-AzSDKSubscriptionSecurityStatus -SubscriptionId 0e6b6c60-fcdf-46b6-90ab-a02f236df560 Get-AzSDKAzureServicesSecurityStatus -SubscriptionId 0e6b6c60-fcdf-46b6-90ab-a02f236df560 -ResourceGroupNames demozone9storage-rg