De nouvelles perspectives d'utilisation des logs dans un contexte de sécurité informatique

RÉSUMÉ L'explosion des connexions des systèmes industriels liées au cyberespace a engendré une augmentation conséquente des attaques informatiques. Afin de garantir la sécurité des systèmes industriels il est devenu vital de développer de nouveaux outils de surveillance. La mise en place de tels dispositifs peut cependant avoir des conséquences sur l'outil de production, causant des ralentissements ou s'avérant handicapant pour le fonctionnement. Dans un tel contexte, mettre au point des méthodes non intrusives qui assurent leur sûreté est un enjeu majeur pour la sécurité des systèmes industriels. Les logs sont des ensembles séquentiels de messages produits par un programme dont le rôle est de conserver un historique de l'exécution. Leur génération et leur consultation n'interfèrent pas avec le programme dont ils sont issus, si ce n'est en consommant des ressources du système d'exploitation hôte. Ce caractère les rend particulièrement précieux afin de respecter la contrainte de non-intrusion sur les systèmes industriels que doivent respecter les outils de surveillance. La détection d'anomalies au travers des logs est un problème qui a déjà été couvert dans la littérature, en utilisant une grande variété de modèles. Si l'on considère qu'une attaque est une utilisation anormale du système laissant des traces différentes dans les fichiers de logs, la transposition de ces méthodes constitue une première approche intéressante du problème ainsi qu'un excellent point de départ pour apporter une solution. En suivant cette démarche, nous proposons deux modèles permettant de détecter des attaques en exploitant des données présentes dans les logs : un automate fini et un réseau de neurones. Ces deux modèles reçoivent des données différentes, extraites des logs. Précisons que le système étudié est un serveur Web, générant donc des logs Web et que les attaques qu'il subit sont parmi les plus répandues. L'automate travaille sur les requêtes traitées par le serveur et cherche à reconstituer le parcours du client sur le site Web. L'hypothèse est que si l'automate a été construit en reprenant toutes les utilisations normales possibles du site Web, une trace non reconnue par l'automate ne correspondra donc pas à un comportement normal du client et sera donc labellisée comme résultant d'une attaque. Ses paramètres d'entrée ont été adaptés à deux attaques particulières bien que les tests aient été effectués sur quatre attaques différentes. Le réseau de neurones choisi est un perceptron multicouches dont les paramètres d'entrée sont des vecteurs résumant des traces d'exécution. Le rôle du réseau de neurones sera, étant donné le résumé d'une trace, de déterminer si celle-ci correspond à un comportement normal ou à une attaque et, dans le cas d'une attaque, de préciser laquelle. Le réseau de neurones a également été pensé pour détecter les deux mêmes attaques que l'automate mais ses paramètres d'entrée ont été adaptés pour pouvoir répondre à un cas plus général. Concernant les résultats des expériences destinées à valider les capacités des deux modèles, l'automate a parfaitement répondu aux attentes. Il s'est avéré capable de détecter avec certitude deux des types d'attaques pour lesquelles il a été pensé, mais n'a pas été en mesure d'identifier les deux autres de nature trop différentes. Les traces correspondant à des comportements normaux ont été également correctement reconnues par l'automate. Le réseau de neurones a eu, quant à lui, des résultats plus frustrants, avec un pourcentage de réussite aux environs de 30%. Une version simplifiée du modèle a permis d'augmenter ce pourcentage à plus ou moins 60%. Le réseau de neurones a eu de moins bons résultats pour différentes raisons. Notamment, avec du recul, on peut considérer que le modèle lui-même n'était pas adapté au problème, en particulier ces paramètres qui ne permettaient pas de croiser les logs du serveur Web avec d'autres (comme ceux générés par le système d'exploitation) afin d'en extraire de nouveaux comportements. La raison principale reste cependant que le modèle devait détecter des attaques trop différentes. Contrairement à l'automate qui était dédié au déni de service et à l'attaque par force brute, le perceptron a cherché, dès sa conception, à détecter les quatre attaques. C'est pourquoi il a perdu en efficacité sur les deux attaques principales. Pour autant, le travail de recherche reste positif. L'objectif de ce projet était avant tout d'étudier des techniques de détection d'intrusion et de montrer le potentiel de l'utilisation de logs autour desquels construire des modèles de surveillance de systèmes industriels. Ce but a été atteint et la perspective de mettre au point de tels dispositifs peut être envisagée.----------ABSTRACT A sizable increase in the number of computer attacks was due to the outburst of connections between industrial systems and the cyberspace. In order to ensure the security of those systems, it became vital to develop new monitoring solutions. Yet, setting up those mechanisms may have consequences on the production tool, leading to falloffs or crippling its normal functioning. In this context, developing non-intrusive methods that ensure reliability in a major concern in the security of industrial systems. Logs are sequential sets of messages produced by a program whose role is to keep track of a historic of execution. Their generation and their reading do not interfere with the program that creates them, besides consuming resources of the host operating system. This feature makes them very valuable when trying to respect the non-intrusion constraint that monitoring tools must abide by when dealing with industrial systems. Anomaly detection through logs is a problem that was studied in the literature, using several models. If one considers an attack as an abnormal use of a system, writing different traces in the log files, the translation of these methods establish an interesting first approach of the problem as well as an excellent starting point to bring a solution. Following this process, we propose two models allowing to detect attacks by using data contained in logs: a finite state automaton and a neural network. There two models receive different data extracted from logs. Let us point out that the system studied is a web server, generating web logs and that the attacks it underwent are amongst the most spread ones. The automaton works on request handled by the server and seeks to rebuild the journey of the client on the website. The hypothesis is this: if the automaton was built using all the possible paths a normal client can follow, a non-recognized trace would not correspond to a normal behavior and thus will be labeled as the result of an attack. The neural network chosen is a multilayer perceptron which input parameters are vectors summarizing execution traces. The role of the network will be, given the summary of a trace, to determine if it corresponds to a normal behavior or an attack, and in the case of an attack, which one. Regarding the results of the experiences whose objective was to validate the capacities of the two models, the automaton addressed our needs. It proved itself able to detect two types of attacks with certainty, but was incapable of identify two others. Traces corresponding to a normal behavior have also been recognized by the automaton. The neural network, as for it, had much more frustrating results, with a success rate of about 30%. A simplified version of the model was able to increase this rate to about 60%. The neural network may have had lower results for various reasons. With more hindsight, the model itself was not the most suited for the problem. Parameters may not have been convenient for the model, et would not allow any cross analysis with others (such as logs generated by the host operating system) in order to extract new behaviors either. Though, the main reason is that the model had to detect attacks that were too much different. Contrary to the automaton that was dedicated to the denial of service and the bruteforce attack, the perceptron tried, according to its design, to detect the four attacks. This is why it lost its efficiency on the two mains attacks. Nevertheless, the overall work remains positive. The objective of this project was to study intrusion detection methods and to demonstrate the potential of the use of logs in building models to monitor industrial systems. This goal was reached and the perspective to develop such tools can be considered

DRACA: Decision-support for Root Cause Analysis and Change Impact Analysis

Most companies relying on an Information Technology (IT) system for their daily operations heavily invest in its maintenance. Tools that monitor network traffic, record anomalies and keep track of the changes that occur in the system are usually used. Root cause analysis and change impact analysis are two main activities involved in the management of IT systems. Currently, there exists no universal model to guide analysts while performing these activities. Although the Information Technology Infrastructure Library (ITIL) provides a guide to the or- ganization and structure of the tools and processes used to manage IT systems, it does not provide any models that can be used to implement the required features. This thesis focuses on providing simple and effective models and processes for root cause analysis and change impact analysis through mining useful artifacts stored in a Confguration Management Database (CMDB). The CMDB contains information about the different components in a system, called Confguration Items (CIs), as well as the relationships between them. Change reports and incident reports are also stored in a CMDB. The result of our work is the Decision support for Root cause Analysis and Change impact Analysis (DRACA) framework which suggests possible root cause(s) of a problem, as well as possible CIs involved in a change set based on di erent proposed models. The contributions of this thesis are as follows: - An exploration of data repositories (CMDBs) that have not been previously attempted in the mining software repositories research community. - A causality model providing decision support for root cause analysis based on this mined data. - A process for mining historical change information to suggest CIs for future change sets based on a ranking model. Support and con dence measures are used to make the suggestions. - Empirical results from applying the proposed change impact analysis process to industrial data. Our results show that the change sets in the CMDB were highly predictive, and that with a confidence threshold of 80% and a half life of 12 months, an overall recall of 69.8% and a precision of 88.5% were achieved. - An overview of lessons learned from using a CMDB, and the observations we made while working with the CMDB

Fault Diagnosis in Enterprise Software Systems Using Discrete Monitoring Data

Success for many businesses depends on their information software systems. Keeping these systems operational is critical, as failure in these systems is costly. Such systems are in many cases sophisticated, distributed and dynamically composed. To ensure high availability and correct operation, it is essential that failures be detected promptly, their causes diagnosed and remedial actions taken. Although automated recovery approaches exists for specific problem domains, the problem-resolution process is in many cases manual and painstaking. Computer support personnel put a great deal of effort into resolving the reported failures. The growing size and complexity of these systems creates the need to automate this process. The primary focus of our research is on automated fault diagnosis and recovery using discrete monitoring data such as log files and notifications. Our goal is to quickly pinpoint the root-cause of a failure. Our contributions are: Modelling discrete monitoring data for automated analysis, automatically leveraging common symptoms of failures from historic monitoring data using such models to pinpoint faults, and providing a model for decision-making under uncertainty such that appropriate recovery actions are chosen. Failures in such systems are caused by software defects, human error, hardware failures, environmental conditions and malicious behaviour. Our primary focus in this thesis is on software defects and misconfiguration

Features correlation-based workflows for high-performance computing systems diagnosis

Analysing failures to improve the reliability of high performance computing systems and data centres is important. The primary source of information for diagnosing system failures is the system logs and it is widely known that finding the cause of a system failure using only system logs is incomplete. Resource utilisation data – recently made available – is another potential useful source of information for failure analysis. However, large High-Performance Computing (HPC) systems generate a lot of data. Processing the huge amount of data presents a significant challenge for online failure diagnosis. Most of the work on failure diagnosis have studied errors that lead to system failures only, but there is little work that study errors which lead to a system failure or recovery on real data. In this thesis, we design, implement and evaluate two failure diagnostics frameworks. We name the frameworks CORRMEXT and EXERMEST. We implement the Data Type Extraction, Feature Extraction, Correlation and Time-bin Extraction modules. CORRMEXT integrates the Data Type Extraction, Correlation and Time-bin Extraction modules. It identifies error cases that occur frequently and reports the success and failure of error recovery protocols. EXERMEST integrates the Feature Extraction and Correlation modules. It extracts significant errors and resource use counters and identifies error cases that are rare. We apply the diagnostics frameworks on the resource use data and system logs on three HPC systems operated by the Texas Advanced Computing Center (TACC). Our results show that: (i) multiple correlation methods are required for identifying more dates of groups of correlated resource use counters and groups of correlated errors, (ii) the earliest hour of change in system behaviour can only be identified by using the correlated resource use counters and correlated errors, (iii) multiple feature extraction methods are required for identifying the rare error cases, and (iv) time-bins of multiple granularities are necessary for identifying the rare error cases. CORRMEXT and EXERMEST are available on the public domain for supporting system administrators in failure diagnosis