Choix 2.En effet, en informatique la sûreté signifie que le système fait exactement ce que nous attendons de lui. S’il est faillible sur ce point, c’est déjà une source de vulnérabilité qui met à mal la sécurité. Ainsi, la sécurité a besoin, d’abord, de la sûreté de fonctionnement.

Choix 1. Comme cela a été présenté dans le cours, le virus n’est qu’une catégorie de malware. Le virus est un malware visant à nuire le fonctionnement du système avec la possibilité de contamination.

Choix 3. En effet, c’est derniers temps l’activité d’attaques cybernétiques a été industrialisée dans le but d’engendrer des gains.

Choix 2. La digitalisation vise la numérisation des activités humaines, et donc, automatiser un maximum de tâches. A chaque fois qu’une tâche humaine est automatisée, il y a risque de vulnérabilités dans sa conception et donc la possibilité de nouvelles attaques.

Choix 1,2. Le manque de consistance peut nuire à la qualité de l’information, mais n’est en aucun cas un facteur de sécurité.

Choix 1,3. La diversification de l'origine des développeurs de logiciels, peut constituer en elle-même une source de vulnérabilité, contrairement aux deux autres propositions. En effet, cette diversification peut mener à des inconsistances dans le code, qui peuvent mener à des vulnérabilités

Choix 1.

Choix 2. Le top 10 d’OWASP donne une information synthétique sur l’ensemble des attaques collectées. Mais, cette information concerne des logiciels venant de domaines diverses. Pour son propre logiciel, nous devons nous concentrer sur les vulnérabilités qui concerne son domaine applicatif, et cela peut nous amener à voir des vulnérabilités qui sont moins bien classées.

Choix 3. Le test de sécurité concerne aussi des aspects métiers du système. Ainsi, nous devons le spécifier en collaboration avec le client (expert du domaine applicatif). De plus, le plan de test constitue, en sois, des objectifs à atteindre lors du développement. Tout ceci milite pour que le plan de test soit réalisé en tout début du cycle de développement.

Choix 1. En effet, comme cela avait été dit lors du cours, tout au long du cycle de développement le système est enrichie. Mais cette enrichissement peut être source d’introduction de nouvelles vulnérabilités. D’où la nécessité de ce test permanent.

Choix 1,3. La deuxième réponse n’est pas une caractéristique de ce type d’outils, car comme nous l’avons déjà vu, ils ne couvrent pas toutes les vulnérabilités et produisent beaucoup de faux positifs.

Choix 2. Comme expliqué dans le cours, la personne qui a écrit le code est plus concentrée sur la logique métier, et par conséquent, elle peut passer à coté de quelques éléments de sécurité. Si la personne qui doit relire le code n’a aucune connaissance du projet, peut passer à coté des vulnérabilités liées à la logique métier. Ainsi, comme cela avait été expliqué dans le cours, la deuxième réponse est la seule valable.

Choix 3.

Choix 1. Initialement, les métriques logicielles avaient été crées pour mesurer la qualité du code. Ainsi, elle vont pouvoir repérer de possibles erreurs qui peuvent être des sources de vulnérabilité. Mais, cela ne peut correspondre à un niveau de vulnérabilité et encore moins à l’identification d’une vulnérabilité particulière.

Choix1. En effet, les outils sont génériques et n’ont aucune connaissance sur les différents métiers concernés par les logiciels que nous développons. Ainsi, il est même, parfois, impossible de détecter automatiquement ce type de vulnérabilités.

Choix 2. Comme cela a avait été vu dans le cours, le test d’intrusion est le dernier élément du plan de test. Il nous permet de vérifier que nous n’avons rien oublié lors des étapes précédentes et que l’intégration du système dans son environnement n’introduit pas de vulnérabilités.

Choix 1. Comme cela avait été mentionné lors du cours, un test d’intrusion ne permet pas de trouver une cause commune à plusieurs vulnérabilités. Il ne permet pas non plus d’assurer que notre couverture de test soit bonne. Comme le test d’intrusion est construit, majoritairement, sur la base d’exploits connus, il va nous permettre de trouver un lien entre un exploit et une potentiel vulnérabilité dans notre système.

L’utilisation du système ne fait pas partie de sa phase de conception.

Choix 1,2. Comme cela avait été expliqué lors du cours, il est nécessaire de vérifier que les vulnérabilités identifiées ont bien été corrigées (progression), et que entre temps nous n’avons pas introduit de nouvelles (non régression). Aucune attaque ne peut viser la phase de conception, et donc l’une de ses étape comme la maintenance.

Choix 2. Attention, la première réponse peut induire en erreur. En effet, le secure by design vise une sécurisation du système lors de son développement, et non que lors d’une seule étape (ex. conception) de ce dernier. La sécurisation des interactions avec l’utilisateur ne couvre qu’une partie des objectifs du « secure by design ». Ainsi, rendre la sécurité comme élément inhérent du logiciel est le principal objectif de l’approche « secure by design ».