Question:
Comment les organisations vérifient-elles * ce qui * a été piraté?
ᔕᖺᘎᕊ
2015-10-27 16:22:01 UTC
view on stackexchange narkive permalink

Au Royaume-Uni, la société TalkTalk a été récemment piratée.

Il a été découvert plus tard, après une «enquête», que le piratage n'était pas aussi grave qu'il aurait pu l'être (et moins que prévu).

Je me demande: comment les organisations (pas nécessairement TalkTalk - c'est justement ce qui m'a incité à demander) vérifier ce qui a été piraté? Je suis sûr qu'il existe de nombreuses façons; mais quels sont les "principaux"?

Dans ce cas - probablement en demandant au hacker: http://www.wired.co.uk/news/archive/2015-10/26/talktalk-arrest
Outre toutes les bonnes réponses, et uniquement à titre de commentaire secondaire: le public obtient le plus souvent un résultat peut-être résultant de la criminalistique, auquel cas les réponses s'appliquent. Considérez également que tout résultat comme "oh, ce n'était vraiment pas mal", ne peut être qu'un mensonge sanglant des entreprises. Donc, en ce qui concerne la détermination de "* ce qui * a été piraté", une partie substantielle de ce que le public voit peut également avoir des traces ou des relations publiques et du marketing et pas seulement de la criminalistique. Même si vous choisissez peut-être de ne pas en tenir compte lorsque vous posez la question, l'image serait incomplète sans cela.
@humanity Je suppose que c'est possible, je n'y ai pas vraiment pensé comme ça ..: /
À mon humble avis, ils n'ont pas vraiment découvert spécifiquement ce qui a été piraté, ils ont simplement deviné sur la base de ce qui a été divulgué et l'ont dit comme une déclaration de PR pour essayer de réduire les dommages perçus. Étant donné le faible niveau de sécurité en premier lieu, je doute qu'ils aient sécurisé une journalisation fiable.
@JamesRyan J'ai aussi pensé la même chose, car la déclaration était très rapide et semblait étrange, mais honnêtement, je me fiche de * TalkTalk *: P - c'était juste un sujet intéressant qui m'a rendu curieux. Je viens d'utiliser TalkTalk comme exemple.
Je pense qu'un problème majeur avec la façon dont ceux-ci sont traités maintenant est que les `` experts '' d'enquête prennent les journaux compromis comme preuves, il semble qu'il serait trop facile de modifier les journaux pour pointer vers l'adresse IP de quelqu'un d'autre et SWAT une partie complètement innocente.
@JamesRyan [commentaire de gowenfawr] (http://security.stackexchange.com/questions/103805/how-do-companies-check-what-has-been-hacked?noredirect=1#comment180783_103808) explique en quelque sorte que
Neuf réponses:
gowenfawr
2015-10-27 16:43:47 UTC
view on stackexchange narkive permalink

En un mot: Forensics

La criminalistique informatique est l'art d'examiner un système et de déterminer ce qui lui est arrivé auparavant. L'examen des artefacts de fichiers et de mémoire, en particulier les calendriers de fichiers, peut brosser un tableau très clair de ce que l'attaquant a fait, quand il l'a fait et de ce qu'il a pris.

Juste à titre d'exemple - étant donné un vidage de mémoire d'un système Windows, il est possible d'extraire non seulement les lignes de commande tapées par un attaquant, mais également la sortie qu'il a vue à la suite de l'exécution de ces commandes. Assez utile pour déterminer l'impact, hein?

En fonction de la fraîcheur du compromis, il est possible d'en dire beaucoup sur ce qui s'est passé.


@AleksandrDubinsky a suggéré que ce serait être utile pour décrire les différents domaines et techniques de la criminalistique informatique, ce que je suis heureux de faire pour vous. Ils incluent, mais sans s'y limiter, les éléments suivants (je vais utiliser mes termes approximatifs; ils ne sont ni officiels ni complets):

Journaliser / Surveiller les Forensics : L'utilisation de données «externes» telles que les journaux centralisés, les journaux de pare-feu, les captures de paquets et les hits IDS chevauche la ligne entre «Détection» et «Forensics». Certaines données, comme les journaux (même centralisés), ne peuvent pas être considérées comme complètes ou même véridiques, car les attaquants peuvent les filtrer ou les injecter une fois qu'ils ont le contrôle du système. Les outils de journalisation de paquets hors système tels que le pare-feu, l'IDS ou les enregistreurs de paquets (comme (anciennement) NetWitness) sont peu susceptibles d'être falsifiés, mais ne contiennent qu'une quantité limitée d'informations; généralement juste un enregistrement des conversations IP et parfois des signatures (telles que des URL HTTP) associées à une activité malveillante.

Sauf si une connexion réseau non chiffrée a été utilisée dans le compromis, ces outils sont rarement capables de détailler l'activité lors d'un compromis, et donc (en revenant à la question d'origine) ne "vérifiez pas quoi A été piraté." D'un autre côté, si une connexion non chiffrée (ftp) a été utilisée pour exfiltrer des données out et que des paquets complets ont été enregistrés, il est alors possible de savoir exactement avec quelles données l'attaquant s'est enfui.

Analyse légale en direct : une partie plus appropriée de la réponse aux incidents, la criminalistique dite «en direct» consiste à se connecter au système et à regarder autour de lui. Les enquêteurs peuvent énumérer les processus, rechercher dans les applications (par exemple, l'historique du navigateur) et explorer le système de fichiers à la recherche d'indications sur ce qui s'est passé. Encore une fois, cela est généralement conçu pour vérifier qu'un compromis s'est produit, et non pour déterminer l'étendue d'un compromis, car un système compromis est capable de cacher des fichiers, des processus, des connexions réseau, vraiment tout ce qu'il veut. L'avantage est qu'il permet d'accéder à des éléments résidant en mémoire (processus, connexions réseau ouvertes) qui ne sont pas disponibles une fois que vous arrêtez le système pour créer une image du disque (mais, encore une fois, le système peut mentir, s'il est compromis! )

Forensics du système de fichiers : une fois qu'une copie du disque a été faite, il peut être monté sur un système propre et exploré, supprimant toute chance que le système d'exploitation compromis "ment "sur les fichiers en place. Des outils existent pour créer des chronologies en utilisant la variété d'horodatages et d'autres métadonnées disponibles, incorporant des données de fichier, des données de registre (sous Windows), même des données d'application (par exemple, l'historique du navigateur). Ce ne sont pas seulement les temps d'écriture des fichiers qui sont utilisés; les temps de lecture des fichiers peuvent indiquer quels fichiers ont été consultés et quels programmes ont été exécutés (et quand). Les fichiers suspects peuvent être exécutés via des vérificateurs antivirus propres, des signatures créées et soumises, des exécutables chargés dans des débogueurs et explorés, des «chaînes» utilisées pour rechercher des mots-clés. Sous Unix, les fichiers "historique" - s'ils ne sont pas désactivés par l'attaquant - peuvent détailler les commandes saisies par l'attaquant. Sous Windows, le service de cliché instantané peut fournir des instantanés des activités passées qui ont depuis été nettoyées.

Il s'agit de l ' étape la plus couramment utilisée pour déterminer la portée et l'étendue d'un compromis , et pour déterminer quelles données peuvent ou non avoir été consultées et / ou exfiltrées. C'est la meilleure réponse à la façon dont nous "vérifions ce qui a été piraté."

Analyse des disques : les fichiers supprimés disparaissent du système de fichiers, mais pas de le disque. De plus, des attaquants intelligents peuvent cacher leurs fichiers dans «l'espace libre» des fichiers existants. Ces choses ne peuvent être trouvées qu'en examinant les octets bruts du disque, et des outils comme The Sleuth Kit existent pour déchirer ces données brutes et déterminer ce que cela signifie sur le passé. S'il y avait un fichier .bash_history et que l'attaquant l'a supprimé lors de sa dernière étape avant de se déconnecter, alors ce fichier peut toujours exister en tant que blocs de disque et être récupérable. De même, les outils d'attaque téléchargés et les fichiers de données temporaires exfiltrés peuvent aider à déterminer l'étendue du compromis.

Analyse de la mémoire : si l'enquêteur peut y arriver assez tôt et obtenir un instantané de la mémoire du système impliqué, il peut alors sonder complètement les profondeurs du compromis. Un attaquant doit compromettre le noyau pour se cacher des programmes, mais il n'y a aucun moyen de cacher ce qui a été fait si une véritable image de la mémoire du noyau peut être créée. Et tout comme les blocs de disque contiennent des données qui ont depuis été supprimées du système de fichiers, le vidage de la mémoire contient des données qui étaient en mémoire dans le passé (telles que l'historique de la ligne de commande et la sortie!) Qui n'ont pas encore été écrasées ... et la plupart les données ne sont pas écrasées rapidement.

Vous en voulez plus? Il existe des programmes de formation et des certifications pour apprendre la criminalistique; la formation publique la plus courante est probablement celle de SANS. Je suis titulaire de leur certification GCFA («Forensic Analyst»). Vous pouvez également passer en revue les défis du projet Honeynet, dans lesquels les parties se font concurrence pour démêler les cas à partir d'images disque, de vidages de mémoire et d'échantillons de logiciels malveillants à partir de compromissions réelles - ils soumettent leurs rapports sur ce qu'ils ont trouvé. vous pouvez voir les types d'outils utilisés et les résultats obtenus dans ce champ.

Anti-Forensics est un sujet brûlant dans les commentaires - en gros, "l'attaquant ne peut-il pas simplement se cacher leurs traces? " Il existe des moyens de s'en débarrasser - voir cette liste de techniques - mais c'est loin d'être parfait et pas ce que j'appellerais fiable. Quand on considère que "le" Dieu "du cyberespionnage" est allé jusqu'à occuper le firmware du disque dur pour maintenir l'accès à un système sans laisser de trace sur le système lui-même - et toujours détecté - il semble clair qu’en fin de compte, il est plus facile de détecter des preuves que de les effacer.

Certaines entreprises peuvent également utiliser une analyse rétroactive des journaux comme outil, dans lequel les données sur les intrusions sont collectées, mais sans action. Ceci est inquiétant lorsque la sécurité de l'entreprise n'est pas considérée comme digne d'un personnel à plein temps. Dans ce cas, les journaux peuvent contenir tous les détails sur les données consultées, mais personne ne les regarde jusqu'à ce qu'une violation soit trouvée par d'autres moyens, qu'il s'agisse de rapports médiatiques ou de clients se plaignant que leurs comptes ont été consultés.
Un attaquant concerné ne nettoierait-il pas toutes ces informations avant de quitter le système? En fin de compte, la mémoire est limitée, l'attaquant peut soit accéder à cette partie de la mémoire pour l'effacer, soit inonder cette mémoire pour remplacer l'ancien contenu par de nouveau. N'est-ce pas possible?
@YoMismo, la version courte est, "Ce n'est pas si facile." Alors que de nombreux attaquants essaieront d'effacer leurs traces du disque, même ce n'est pas facile - c'est en quoi consiste l'analyse de la chronologie, inférer l'activité à partir des métadonnées. Très peu vont plus loin et essaient de limiter leur empreinte mémoire, et c'est impossible à faire totalement - à tout le moins, vous laissez une empreinte de votre programme de compensation d'empreinte! «Toutes les données laissent une trace. La recherche de données laisse une trace. L'effacement des données laisse une trace. L'absence de données, dans les bonnes circonstances, peut laisser la trace la plus claire de toutes. » - C.S. Friedman
Les hackers financés par l'État d'@YoMismo peuvent le faire. Même dans ce cas, ils peuvent échouer.
Merci d'avoir ajouté les détails. Je suis d'accord avec Alex qu'avant l'ajout du détail, la réponse pointe simplement vers un mot tout aussi indéfini de «criminalistique». Pour qu'une réponse soit utile, vous devez parler à un niveau familier au public. Si vous savez ce qu'est la criminalistique informatique, vous connaissez déjà la réponse à la question.
@YoMismo, ... il était une fois, lors de la conception d'un système particulièrement sensible, je me suis connecté sur une ligne série avec les broches pour la communication en lecture coupée - littéralement, une interface en écriture seule, avec le système à l'autre extrémité accessible uniquement par quelqu'un pénètre physiquement dans une zone sécurisée. Il y a pas mal de choses que l'on peut faire lorsque la situation le justifie.
Pour certains types d'attaques, comme Heartbleed, il est peu probable qu'il y ait des journaux suffisamment détaillés pour fournir les informations nécessaires. Dans de tels cas, il peut ne pas être possible de déterminer si une attaque a eu lieu, vous devez donc supposer le pire. C'est pourquoi vous verrez parfois des entreprises prudentes dire des choses comme ["nous avons peut-être été piratés, ou peut-être pas, mais veuillez quand même changer vos mots de passe."] (Https://blog.lastpass.com/2015/06/lastpass -security-notice.html /)
N'existe-t-il pas des fichiers en écriture seule pour empêcher l'effacement des traces?
@YoMismo `Parce que toutes ses parties sont connectées, l'environnement autour de l'ennemi contient des messages inestimables sur leur activité. En lisant cet environnement, vous lisez leurs créations, même la poussière parle. Ce n'est pas une connaissance du livre. Ce n'est même pas la connaissance de l'extraordinaire et de l'orthodoxie. Ce sont les observations d'un éclaireur sur le terrain. Puisque tout ce qui se produit affecte tout ce qui l'entoure, le moindre phénomène vous amène à la vue complète. Cela est vrai de la connaissance du scout à la vision totale du général. '' Déplacer l'armée L'art de la guerre Sun Tzu
@gerrit,, toutes les protections de fichiers appliquées par le système d'exploitation peuvent être renversées une fois que le système d'exploitation lui-même est compromis. Bien que le matériel [WORM] (https://en.wikipedia.org/wiki/Write_once_read_many) existe, il ne serait utile que pour (par exemple) les fichiers journaux, et ce n'est pas assez pratique que j'aie déjà vu quelqu'un le faire IRL - l'envoi de logs sur le réseau vers un SIEM est beaucoup plus simple et tout aussi efficace.
@gowenfawr Je pensais à des périphériques matériels en écriture seule appropriés. Mais si l'ensemble du * réseau * est compromis, le matériel WORM (l'impression physique de fichiers journaux sur des arbres morts devrait-il faire l'affaire?) Ne serait-il pas plus sécurisé?
@gerrit, alors vos journaux enregistreraient les signes du compromis jusqu'à ce que l'attaquant arrive au point où il prend le contrôle du démon de journal ... et votre capacité à analyser ces journaux serait incroyablement réduite (vous ne pouvez pas `grep` paper !)
@gerrit le volume de données que les applications modernes enregistrent dépasse généralement largement la capacité d'impression. Mais en général, écrire sur un support indélébile (lecteurs optiques non RW par exemple) serait une approche viable.
Dans le cadre du piratage, il est incroyablement facile de nettoyer leurs traces. Tout sur le disque n'est que des données, si le pirate a la racine, il peut changer les journaux, il peut changer l'historique, il peut changer les sauvegardes. À moins que vos preuves ne soient enregistrées en dehors du système compromis, elles ne peuvent pas être considérées comme exactes et ne peuvent être utilisées que comme une aide.
@Peter non, la criminalistique n'est souvent pas fiable parce que de fausses hypothèses sont faites et à l'avenir, il est probable que les condamnations seront annulées à mesure que la prise de conscience augmente que l'utilisation de données compromises comme preuve n'est pas fondée.
@YoMismo Ils essaient absolument d'effacer les choses. Je me souviens quand un administrateur système avec lequel j'ai travaillé a dit que le journal le plus sécurisé disponible en tant qu'imprimante matricielle imprimait des messages de journal sur du papier à alimentation continue. Il a affirmé que, parce que les pirates le savaient, il n'était pas rare de lancer un piratage en envoyant une quantité massive d'événements enregistrables vers le serveur, le faisant littéralement fonctionner sans journal de sorte qu'il ne parvienne pas à enregistrer le piratage réel.
@CortAmmon donc vous serez d'accord avec moi. Ce n'est peut-être pas facile, mais c'est certainement possible. Je suis intéressé par ** quoi ** et ** comment **, ces informations peuvent ou non être accessibles. Mais je suis très intéressé à savoir ** QUAND **, car vous pouvez toujours être piraté (peu importe les messages que vous prenez car il y a tellement de variables que vous ne pouvez pas toutes les prendre en compte) ** quand ** semble le point clé pour prendre des contre-messages en cas de brèche. J'aime considérer cela comme un meurtre, la police peut attraper le tueur, il peut s'échapper, ou le crime n'a pas été remarqué et n'a donc jamais fait l'objet d'une enquête.
"C'est l'étape la plus couramment utilisée pour déterminer la portée et l'étendue d'un compromis." Et l'un des plus faciles à vaincre. Avant d'accéder au fichier, un attaquant peut simplement lire les horodatages existants. Ensuite, ils ouvrent le fichier avec la «sémantique de sauvegarde» et écrivent enfin le ou les horodatages précédents après l'exfiltration des données cibles. L'effet net est un accès indétectable au système de fichiers. La sémantique de sauvegarde seule aboutit généralement à une opération de lecture indétectable. Les systèmes sont compromis beaucoup plus souvent que l'exploitant du système ne le sait. La seule approche correcte consiste à supposer que tout est compromis.
@YoMismo Vous ne pouvez pas toujours garantir que vous pouvez savoir exactement quand. Vous pouvez améliorer vos journaux et les rendre plus sûrs, mais à la fin, une fois que vous pensez avoir été violé, il s'agit de suivre les miettes de fil. Plus les pistes sont générales, plus il est probable qu'un pirate en soit conscient et soit les efface, soit potentiellement les contournes. Plus les sentiers sont spécifiques à votre réseau, plus il leur est difficile de vous empêcher de voir les choses. Le meilleur conseil que j'ai, c'est la défense en profondeur. Ne comptez jamais sur une seule contre-mesure pour tout faire.
@YoMismo voir le texte que je viens d'ajouter à la réponse sur l'anti-criminalistique, comprend un lien vers le «quoi et comment» les attaquants peuvent faire pour essayer de dissimuler leurs traces. Sachez que c'est une science très imparfaite, et que même les pros se font prendre malgré ces méthodes.
Merci @gowenfawr pour les nouveaux liens, ils sont très instructifs. Je suis d'accord avec le fait que des traces sont laissées et qu'il y a tellement de variables que vous ne pouvez pas toutes les prendre en compte (du point de vue attaquant et médico-légal), laissant ainsi des traces pour l'analyse médico-légale dans un cas ou être en mesure de pirater un système dans l'autre. Le fait est que vous ne pouvez pas enquêter sur un événement si vous ne l'avez pas remarqué. Ces groupes dont votre deuxième lien parle ont été remarqués, mais qu'en est-il des individus, des institutions gouvernementales qui ne l'étaient pas? nous n'en saurons jamais rien. Prenez l'œuf de coucou comme ...
Par exemple, ce pirate a été remarqué parce que certains centimes d'un compte ne correspondaient pas. Un technicien inquiet a commencé à enquêter et s'est retrouvé avec une machine piratée, mais qu'en est-il de ces machines avec cette incohérence de compte qui ont peut-être été ignorées? qu'en est-il de ces machines qui n'ont jamais été remarquées qu'un piratage a eu lieu? vous ne pouvez pas enquêter sur cela car cela n'a pas été remarqué.
@YoMismo,, c'est en fait un sujet avec lequel j'ai passé beaucoup de temps à me débattre, mais il va très loin sur cette question. Vous avez une bonne nouvelle question de haut niveau là-dedans - comment gérer les "inconnues inconnues", comme l'a dit Rumsfeld.
TheHidden
2015-10-27 16:39:23 UTC
view on stackexchange narkive permalink

En travaillant dans le secteur de la technologie, je ferais comme suit:

  1. Trouvez le hack, le trou, le point faible.

  2. Vérifiez le syslog, dmesg, access.log et error.log pour confirmer la thèse. (lors du piratage d'un réseau, vous avez normalement la rupture du système dans le cas de TalkTalk, c'était une injection MySQL, cela aurait laissé des erreurs dans le journal mysql.err car pour entrer, vous devez le casser.)

  3. Répliquer le hack, répliquer le hack vous permettra de voir jusqu'où le hack peut aller et vous permettra d'estimer les dégâts.

Si vous trouvez le trou, vous pouvez répliquer l'attaque, répliquer l'attaque et vous verrez ce que l'attaquant a vu.

Cette réponse est un bon complément aux autres réponses, car elle répond qu'un «hack» ne donne pas en général un accès complet à un système, mais est le plus souvent une fuite dans une partie spécifique du système.
Pourquoi n'avez-vous pas utilisé une liste numérotée? (vous pouvez remplacer `,` par `.` pour ce faire)
parce que je ne voulais pas.
Je ne pense pas que ce soit exact. Tout d'abord par «injection MySQL», je suppose que vous voulez simplement dire «injection SQL», ce n'est pas une vulnérabilité limitée à MySQL. Deuxièmement, je ne pense pas qu'il y aurait nécessairement une trace dans le journal des erreurs de la base de données, si mon attaque par injection doit changer: ... where userId = '123'into ... where userId =' 'or 1 = 1 this is SQL parfaitement valide et la base de données ne l'identifierait pas comme une erreur.
@DaveyDaveDave J'ai dit MySQL parce que j'utilise des bases de données MySQL, c'est juste une habitude de le taper, mais oui, vous avez raison. deuxièmement, vous supposeriez qu'il s'agissait d'une manipulation de données plutôt que d'une injection. Je doute fort qu'ils aient eu une si petite déclaration SQL que cela n'aurait pas causé d'erreur, en particulier dans la référence de discussion. pour obtenir le type d'informations que le pirate a fait, il aurait fallu un certain nombre d'instructions SQL et il l'a probablement terminé avec; - mais tout autre chose après cela entraînerait très probablement une erreur. Je peux vous proposer un jeu sympa si vous voulez 2 l'essayer.
@DaveyDaveDave a également oublié de mentionner, un excellent moyen d'obtenir un schéma de tables est de casser le code exprès, aussi je doute que la première injection ait fonctionné en premier. Si je voulais entrer dans une base de données SQL, j'essaierais d'abord de trouver une carte afin de pouvoir prendre les bonnes portes.
@silverpenguin: points raisonnables, mais tout ce que j'essayais de montrer, c'est que votre affirmation générale "pour entrer par effraction, vous devez le casser", n'est pas nécessairement vraie.
Les serveurs SQL @DaveDaveDave enregistrent généralement les requêtes effectuées sur la base de données. Il est assez facile de trouver une requête qui inclut `ou 1 = 1` dans la chaîne de requête, car ce n'est pas quelque chose qu'une requête SQL normale utiliserait dans la plupart des cas (au moins, elle aurait un ensemble de cloches d'avertissement dans mon esprit). Au minimum, de simples analyses judiciaires peuvent nous dire quelles requêtes inhabituelles ont été exécutées, en particulier si la plupart des requêtes utilisent des instructions de liaison, et constitueraient ainsi la majorité de toutes les requêtes exécutées.
David Scholefield
2015-10-27 16:59:29 UTC
view on stackexchange narkive permalink

En plus de l'excellente réponse sur Forensics (et des commentaires), certaines organisations utilisent des systèmes de détection d'intrusion tels que 'Snort' (détection d'intrusion réseau) et OSSEC (système de détection basé sur l'hôte) ainsi que de nombreux autres fournisseurs tels que Cisco, etc. .qui enregistrent divers aspects d'un comportement inhabituel ou non autorisé.

Par exemple, les systèmes de détection d'intrusion basés sur l'hôte enregistrent souvent les modifications de fichiers sur les serveurs afin qu'une enquête judiciaire puisse montrer quels fichiers ont été modifiés au cours d'une période donnée et une enquête judiciaire L'enquêteur peut l'utiliser pour rassembler les activités de certains utilisateurs ou attaquants.

Les attaquants laisseront également des traces dans les journaux de toute l'infrastructure, des journaux du pare-feu, aux journaux du serveur, aux journaux de service (Web, smtp, etc.) et ceux-ci peuvent fournir des indices vitaux. Cependant, il est possible pour les attaquants de modifier ces journaux à moins qu'ils n'aient été conçus pour être sécurisés et inaltérables, par exemple. en centralisant les journaux sur un support en écriture seule.

Une fois qu'un attaquant obtient un accès privilégié, les gants sont désactivés et les journaux peuvent être falsifiés ou supprimés.

En fin de compte, cela dépendra de la préparation - si l'organisation s'est préparée à l'intrusion et l'exercice médico-légal qui suivra. Cela devrait faire partie de la planification de la sécurité de chaque entreprise.

Cela dépendra également du fait que l'attaquant trouve / connaît chaque journal.
@DanHenderson mais comment connaissez-vous la différence entre un journal non trouvé et un faux journal planté?
Parce que vous avez besoin d'un moyen de vous assurer que les journaux ne peuvent pas être falsifiés (ou du moins nécessitent une collusion pour ce faire). La meilleure façon d'y parvenir est soit d'écrire des journaux sur un support à écriture unique (dans les systèmes * nix, vous pouvez monter un lecteur en tant que «ajout uniquement») ou d'écrire sur un serveur de journaux sécurisé et centralisé.
@JamesRyan un journal trouvé et falsifié sera en accord avec les autres journaux falsifiés trouvés. Un journal non trouvé contredira les journaux falsifiés.
Dave
2015-10-28 04:35:29 UTC
view on stackexchange narkive permalink

Je n'ai pas encore vu cela mentionné et c'est probablement une ressource majeure pour une telle enquête, en particulier celle qui tourne autour de l'accès aux données:

L'audit du SGBDR peut être un ressource pour déterminer exactement quelles données ont été consultées, quand et par qui. Cela dépend bien sûr de la manière dont il a été configuré ou s'il a été configuré.

Par exemple, SQL Server Audit permet de récupérer les ID utilisateur, les horodatages et les requêtes réelles soumises à le serveur permettant ainsi une reconstruction complète de l'ensemble de données volé.

Les systèmes d'audit devraient avoir des redondances intégrées pour empêcher la falsification de la piste d'audit. Certains de ces éléments peuvent être stockés dans le SGBDR, et certains peuvent être écrits sur des sources externes. SQL Server peut enregistrer les audits dans le journal de sécurité Windows.

Sevaara
2015-10-27 16:56:41 UTC
view on stackexchange narkive permalink

gowenfawr a mentionné l'investigation du système, mais l'identification de l'actif compromis se fait presque toujours via des journaux. Les journaux / doivent / doivent toujours indiquer l'actif compromis si vous recherchez suffisamment. Que vous ayez un IDS qui détecte les connexions externes / les tentatives de force brute / les tentatives d'injection SQL ou si vous recherchez manuellement dans les journaux ce que je viens de mentionner, il existe plusieurs façons de porter une violation à votre attention.

Une fois l'actif a été identifié, vous pouvez commencer l'examen médico-légal de l'actif. Surtout pour des informations supplémentaires que les journaux peuvent ne pas rapporter, en particulier s'il semble qu'un fichier a été supprimé pour maintenir l'accès de l'attaquant. Le grattage de la mémoire et l'analyse de ce que fait le fichier déposé, étape par étape, aideront l'équipe de sécurité / l'équipe IR à comprendre ce qui se passe, comment le compromis s'est initialement produit, la vulnérabilité utilisée et potentiellement la source de l'attaque ( la vraie source).

user45139
2015-10-27 16:59:10 UTC
view on stackexchange narkive permalink

Ils peuvent vérifier plusieurs choses que je peux mentionner au hasard:

  • Syslog
  • Journaux du pare-feu
  • Journaux des IDS et des routeurs
  • Système de fichiers
  • Événements
  • Tâches planifiées
Lightness Races in Orbit
2015-10-28 05:48:25 UTC
view on stackexchange narkive permalink

Si quelqu'un est entré par effraction dans votre maison en utilisant une clé volée et n'a rien volé, comment le sauriez-vous? Souvent, vous le feriez. Pensez à la manière dont vous détecteriez l'événement. Cela pourrait être aussi ridicule qu'une lettre ouverte sur le plan de travail de votre cuisine que vous ne vous souvenez pas avoir lu. Il n'y a fondamentalement aucune distinction ici. Cela aide si vous trouvez des marques de rayures sur votre serrure lors des dix premières tentatives d'entrée avant que le cambrioleur ne détermine finalement quelle clé était réellement la vôtre (lire: journaux de sécurité).

Qu'est-ce que tu racontes?
@Begueradj: C'est une analogie assez claire. Avec quelle partie avez-vous des problèmes?
par exemple la partie cuisine. Nous parlons de médecine légale. Peut-être n'avez-vous pas compris la question?
@Begueradj: Je l'ai parfaitement compris, merci beaucoup. La criminalistique peut être modélisée pour le profane comme analogue à la façon dont un propriétaire examine sa propriété pour des signes de dommages / pertes qui peuvent ne pas être apparents extérieurement sans une telle activité. L'OP ne considérait ostensiblement que le cas où le canapé et la télévision manquaient et ne pouvait donc pas penser à la détection de formes plus subtiles de vol / d'infiltration. Cela a conduit à la publication de cette question et, finalement, à cette réponse. Faîtes moi savoir si vous avez d'autres questions.
"Analogie" crée une relation entre 2 idées. Ce n'est pas une analogie - ce sont des points de suspension.
@schroeder: Non, c'est une analogie.
@Begueradj: La question ne nécessite pas de réponses médico-légales, et d'après mon expérience (allant des magasins à 3 hommes ainsi qu'aux «leaders de l'industrie»), la médecine légale est généralement un terme dont personne dans l'entreprise n'a jamais entendu parler, sauf qu'ils sont fans de CSI.
@schroeder Je n'ai jamais lu _ellipsis_ utilisé dans un sens quelconque, même à distance comme celui-ci, et ma recherche ne trouve aucune définition connexe. Cela aurait aidé à inclure une citation pour ceux d'entre nous dont l'anglais fait apparemment défaut.
Petah
2015-10-28 15:33:40 UTC
view on stackexchange narkive permalink

En termes de ce qui a été pris, plutôt que de comment, les grandes entreprises et les agences utilisent l'inspection approfondie des paquets pour enregistrer ce qui a été transféré dans / hors de leur réseau.

Les appareils enregistrent tout le trafic et peuvent utiliser IDS pour l'alerte. Après un incident, ils peuvent analyser l’ampleur de l’attaque.

Voici quelques outils standard de l’industrie:

Ian Ringrose
2015-10-29 01:36:58 UTC
view on stackexchange narkive permalink

Dans le cas de Talk Talk, nous savons que les données volées sont utilisées pour cibler des personnes.

  • Nous savons que ces personnes sont appelées par quelqu'un qui prétend être de Talk Talk, puis amenées à fournir leurs coordonnées bancaires.
  • Nous savons que les coordonnées bancaires ne sont plus utiles après un court laps de temps si elles sont connues, elles ont été piratées.
  • Nous savons donc que les coordonnées bancaires piratées seront utilisées RAPIDEMENT si elles sont extraites de TalkTalk.
  • Par conséquent, il est raisonnable de supposer que les coordonnées bancaires ne figuraient pas dans les données qui ont été collectées.

Les banques britanniques effectuent BEAUCOUP de surveillance pour voir quel est l'impact, cette surveillance augmentera suffisamment les cas, ainsi que les cas signalés par les clients de la banque, pour donner un bon idéal de l'impact maintenant.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...