TD6 - Audit Corrigé Chantal Keller <chantal.keller@u-psud.fr> 14 janvier 2016 1 Généralités Question 1 Peut-on avoir confiance dans les tests détection d infection (c est-à-dire regardant a posteriori si une machine a été infectée ou non) proposés par la plupart des antivirus, même en supposant qu ils soient capable de détecter absolument tous les virus possibles? La plupart des tests de détection des antivirus tournant sur la machine potentiellement infectée, il est impossible de leur faire entièrement confiance (même à un antivirus parfait) car le virus a pu en prendre le contrôle. 2 Audit Dans cette partie et la suivante, on reprend notre exemple récurrent de base avec des clients, des commandes et leur contenu. Question 2 On veut s assurer que personne ne supprime de ligne dans aucune table. Proposer un moyen de surveiller cette option qui, si la propriété n est pas respectée, sauvegarde l utilisateur effectuant la suppression, la date de suppression, et la table sur laquelle la suppression porte. L implanter en SQL. On va conserver un historique des suppressions effectuées sur chacune des trois tables. CREATE TABLE suppressions ( utilisateur text, date timestamp, table text, PRIMARY KEY (utilisateur, date) On choisit le couple (utilisateur, date) comme clé primaire : d une part, un même utilisateur peut effectuer plusieurs suppressions ; et d autre part, des suppressions d utilisateurs différents peuvent survenir à la même date. On associe un trigger, qui va insérer une ligne dans l historique, à la suppression sur chacune des trois tables. CREATE FUNCTION suppression_clients() RETURNS trigger AS $suppression_clients$ INSERT INTO historique VALUES (current_user, current_timestamp, clients 1
$suppression_clients$ LANGUAGE plpgsql; CREATE FUNCTION suppression_commandes() RETURNS trigger AS $suppression_commandes$ INSERT INTO historique VALUES (current_user, current_timestamp, commandes $suppression_commandes$ LANGUAGE plpgsql; CREATE FUNCTION suppression_contenu_commandes() RETURNS trigger AS $suppression_contenu_comma INSERT INTO historique VALUES (current_user, current_timestamp, contenu_commandes $suppression_contenu_commandes$ LANGUAGE plpgsql; CREATE TRIGGER suppression_clients BEFORE delete ON clients FOR EACH ROW EXECUTE PROCEDURE suppression_clients( CREATE TRIGGER suppression_commandes BEFORE delete ON commandes FOR EACH ROW EXECUTE PROCEDURE suppression_commandes( CREATE TRIGGER suppression_contenu_commandes BEFORE delete ON contenu_commandes FOR EACH ROW EXECUTE PROCEDURE suppression_contenu_commandes( Question 3 Quels doivent être les droits d accès aux objets que vous avez définis dans la Question 2? Comment garantir ces droits? Donner les éventuelles commandes SQL pour ce faire. Les droits doivent être le plus restreint possible, pour éviter qu un intrus ne cherche à modifier l historique ou supprimer les triggers pour cacher ses traces. Ces droits sont déjà ceux qui sont définis par défaut (si c est le super-utilisateur qui a créé la table et le trigger). 3 Statistiques Question 4 Pour savoir si ses clients sont satisfaits, la société de vente par correspondante dont nous assurons la gestion informatique souhaite connaître : la proportion de clients qui passent seulement une commande, et de ceux qui passent au moins deux commandes ; dans ce dernier cas, la durée moyenne entre la première commande et la suivante. Proposer une solution et le code SQL correspondant. Un solution possible parmi plusieurs est la suivante. On définit deux nouvelles tables, une pour mémoriser les clients ayant passé une et une seule commande (avec la date de cette commande), et une pour les clients ayant passé deux commandes ou plus (avec la durée entre les deux premières commandes) : CREATE TABLE première_commande ( client numéro PRIMARY KEY REFERENCES clients (numéro), 2
date timestamp NOT NULL CREATE TABLE au_moins_deux_commandes ( client numéro PRIMARY KEY REFERENCES clients (numéro), durée timestamp NOT NULL On associe ensuite un trigger à chaque nouvelle insertion dans la table des commandes, qui va regarder si le client est présent dans la table première_commande : si oui, il faut le supprimer, et insérer une nouvelle ligne dans la table au_moins_deux_commandes avec la durée entre les deux ; sinon, on regarde si le client est présent dans la table au_moins_deux_commandes : si oui, il n y a rien à faire (le client a déjà passé au moins deux commandes) ; sinon, c est qu il s agit de la première commande de ce client, et il faut donc l insérer dans la table première_commande avec la date de la commande. CREATE FUNCTION stats() RETURNS trigger AS $stats$ IF (SELECT count(*) FROM première_commande WHERE client = NEW.client) > 0 THEN INSERT INTO au_moins_deux_commandes VALUES (NEW.client, current_timestamp - (SELECT date FROM première_commande WHERE client = NEW.client) DELETE FROM première_commande WHERE client = NEW.client ELSE IF (SELECT count(*) FROM au_moins_deux_commandes WHERE client = NEW.client) = 0 THEN INSERT INTO première_commande VALUES (NEW.client, current_timestamp) END IF; $stats$ LANGUAGE plpgsql; CREATE TRIGGER stats_clients BEFORE insert ON commandes FOR EACH ROW EXECUTE PROCEDURE stats( Par la suite, les requêtes pour connaître les proportions est : (SELECT count(*) FROM première_commande) / ((SELECT count(*) FROM première_commande) + (SELECT count(*) FROM au_moins_deux_commandes)) (SELECT count(*) FROM au_moins_deux_commandes) / ((SELECT count(*) FROM première_commande) + (SELECT count(*) FROM au_moins_deux_commandes)) et celle pour connaître la durée moyenne : SELECT average(duree) FROM au_moins_deux_commandes; 3
4 Le paradoxe des faux positifs Dans cette partie, on utilise un outil de détection d intrusion sur une base de données quelconque. Cet outil permet de détecter si une tentative de connexion échouée est frauduleuse ou simplement due à une erreur. Cet outil de détection est très fiable : pour chaque tentative de connexion échouée, il va déclencher une fausse alarme (faux positif) uniquement dans 5% des cas, et il n oubliera jamais de cas (pas de faux négatifs). On observe le fonctionnement de l outil sur 1000 tentatives de connexion. Question 5 Dans cette question, on suppose que 40% des tentatives de connexion échouées sont effectivement frauduleuses. Remplir le tableau suivant : Détection positive 30 Détection Négative Total Par exemple, le nombre de tentatives non frauduleuses qui reçoivent malgré tout une détection positive est calculé de la manière suivante en multipliant le nombre de tentatives non frauduleuses (1000 60%) par le taux d échec (5%) : 1000 60% 5% = 1000 0, 6 0, 05 = 30 En déduire la probabilité qu il y ait bien une attaque dans le cas d une alerte : Nombre de vrais positifs Nombre total de positifs Il n y a pas de faux négatifs, donc le nombre de détections négatives alors que la tentative est frauduleuse est 0. On connaît par ailleurs le nombre de tentatives frauduleuses (40% de 1000 tentatives, soit 400) et celui de tentatives non frauduleuses. On peut ensuite compléter le tableau en calculant les différences. Détection positive 400 30 430 Détection Négative 0 570 570 Total 400 600 1000 La probabilité qu il y ait bien une attaque dans le cas d une alerte est donc de 93%. Question 6 Fort heureusement, une grande majorité des tentatives de connexions échouées sont simplement des erreurs! On suppose dans cette question, de manière plus réaliste, que seulement 2% de ces tentatives sont frauduleuses (sans changer le système de détection). Remplir le tableau suivant : Détection positive Détection Négative Total En déduire la probabilité qu il y ait bien une attaque dans le cas d une alerte. On remplit le tableau de la même façon que précédemment : 4
Détection positive 20 49 69 Détection Négative 0 931 931 Total 20 980 1000 La probabilité qu il y ait bien une attaque dans le cas d une alerte est donc de 29%. Question 7 Comparer les deux résultats. À quoi faut-il faire attention lorsqu on utilise un système de détection d intrusion, même fiable? Lorsqu on dispose d un système de détection d intrusion ayant 5% de faux positifs, la première intuition est de considérer que 95% des alertes vont être justifiées, et seulement 5% seront des fausses alertes. En réalité, ce taux d alertes justifiées dépend également de la proportion de l évènement que l on cherche à détecter parmi tout l échantillon. Dès que cette proportion devient faible (ce qui est souvent le cas, car fort heureusement, les attaquants ne sont pas à tous les coins de rue), le taux de fausses alertes devient trop important pour que le système soit efficace. 5