WK-FNN DESIGN FOR DETECTION OF ANOMALIES IN THE COMPUTER NETWORK TRAFFIC

Anomaly-based intrusion detection systems identify abnormal computer network traffic based on deviations from the derived statistical model that describes the normal network behavior. The basic problem with anomaly detection is deciding what is considered normal. Supervised machine learning can be viewed as binary classification, since models are trained and tested on a data set containing a binary label to detect anomalies. Weighted k-Nearest Neighbor and Feedforward Neural Network are high-precision classifiers for decision-making. However, their decisions sometimes differ. In this paper, we present a WK-FNN hybrid model for the detection of the opposite decisions. It is shown that results can be improved with the xor bitwise operation. The sum of the binary “ones” is used to decide whether additional alerts are activated or not

Activity Report 2012. Project-Team RMOD. Analyses and Languages Constructs for Object-Oriented Application Evolution

Activity Report 2012 Project-Team RMOD Analyses and Languages Constructs for Object-Oriented Application Evolutio

Identifying the exact fixing actions of static rule violation

International audience—We study good programming practices expressed in rules and detected by static analysis checkers such as PMD or FindBugs. To understand how violations to these rules are corrected and whether this can be automated, we need to identify in the source code where they appear and how they were fixed. This presents some similarities with research on understanding software bugs, their causes, their fixes, and how they could be avoided. The traditional method to identify how a bug or a rule violation were fixed consists in finding the commit that contains this fix and identifying what was changed in this commit. If the commit is small, all the lines changed are ascribed to the fixing of the rule violation or the bug. However, commits are not always atomic, and several fixes and even enhancements can be mixed in a single one (a large commit). In this case, it is impossible to detect which modifications contribute to which fix. In this paper, we are proposing a method that identifies precisely the modifications that are related to the correction of a rule violation. The same method could be applied to bug fixes, providing there is a test illustrating this bug. We validate our solution on a real world system and actual rules

Aide à l'Évolution Logicielle dans les Organisations

Software systems are now so intrinsically part of our lives that we don't see them any more. They run our phones, our cars, our leisures, our banks, our shops, our cities … This brings a significant burden on the software industry. All these systems need to be updated, corrected, and enhanced as the users and consumers have new needs. As a result, most of the software engineering activity may be classified as Software Maintenance, “the totality of activities required to provide cost-effective support to a software system”.In an ecosystem where processing power for computers, and many other relevant metrics such as disk capacity or network bandwidth, doubles every 18 months (“Moore's Law”), technologies evolve at a fast pace. In this ecosystem, software maintenance suffers from the drawback of having to address the past (past languages, existing systems, old technologies). It is often ill-perceived, and treated as a punishment. Because of this, solutions and tools for software maintenance have long lagged far behind those for new software development. For example, the antique approach of manually inserting traces in the source code to understand the execution path is still a very valid one.All my research activity focused on helping people to do software maintenance in better conditions or more efficiently. An holistic approach of the problem must consider the software that has to be maintained, the people doing it, and the organization in which and for which it is done. As such, I studied different facets of the problem that will be presented in three parts in this document: Software: The source code is the center piece of the maintenance activity. Whatever the task (ex: enhancement or bug correction), it typically comes down to understand the current source code and find out what to change and/or add to make it behave as expected. I studied how to monitor the evolution of the source code, how to prevent it's decaying and how to remedy bad situations; People: One of the fundamental asset of people dealing with maintenance is the knowledge they have, of computer science (programming techniques), of the application domain, of the software itself. It is highly significant that from 40% to 60% of software maintenance time is spent reading the code to understand what it does, how it does it, how it can be changed; Organization: Organizations may have a strong impact on the way activities such as software maintenance are performed by their individual members. The support offered within the organization, the constraints they impose, the cultural environment, all affect how easy or difficult it can be to do the tasks and therefore how well or badly they can be done. I studied some software maintenance processes that organizations use.In this document, the various research topics I addressed, are organized in a logical way that does not always respect the chronological order of events. I wished to highlight, not only the results of the research, through the publications that attest to them, but also the collaborations that made them possible, collaboration with students or fellow researchers. For each result presented here, I tried to summarize as much as possible the discussion of the previous state of the art and the result itself. First because, more details can easily be found in the referenced publications, but also because some of this research is quite old and sometimes fell in the realm of “common sense”.Les systèmes logiciels font maintenant partie intrinsèque de nos vies à tel point que nous ne les voyons plus. Ils pilotent nos téléphones, nos voitures, nos loisirs, nos banques, nos magasins, nos villes, … Cela apporte de lourdes contraintes à l'industrie du logiciel car tous ces systèmes doivent être continuellement mis à jour, corrigés, étendus quand les utilisateurs et consommateurs expriment de nouveaux besoins. Le résultat en est que la plus grande part de l'activité de génie logiciel peut être classifié comme de la Maintenance Logicielle, « La totalité des activités requises pour fournir un support efficient d'un système logiciel ».Dans un écosystème où la puissance de calcul des ordinateurs, ou beaucoup d'autres métriques reliées comme la capacité des disques, ou le débit des réseaux, double tous les 18 mois (« loi de Moore »), les technologies évoluent rapidement. Dans cet écosystème la maintenance logiciel souffre de l'inconvénient de devoir traiter le passé (langages du passé, systèmes existants, vielles technologies). Elle est souvent mal perçue et traitée comme une punition. À cause de cela, les solutions et les outils pour la maintenance logicielle sont depuis toujours très en retard sur ceux pour le développement. Par exemple, l'antique méthode de correction de problème consistant à insérer des instructions pour retracer et comprendre le flot d'exécution d'un programme est toujours complètement actuelle.Toute mon activité de recherche s'est concentrée à aider les gens à faire de la maintenance logicielle dans de meilleures conditions ou plus efficacement. Une approche holistique du problème doit considérer le logiciel qui doit être maintenu, les gens qui le font et les organisations dans lesquelles et pour lesquelles cela est fait. Pour cela, j'ai étudié différents aspects du problème qui seront présentés en trois parties dans ce document : Le Logiciel : Le code source est la pièce centrale de l'activité de maintenance logicielle. Quelque soit la tâche (ex : amélioration ou correction d'erreur), elle revient typiquement à comprendre le code source actuel pour trouver quoi changer et/ou ajouter pour obtenir le comportement souhaité. J'ai étudié comment contrôler l'évolution du code source, comment prévenir son délitement et comment remédier à des mauvaises situations ; les Gens : L'un des principaux avantages des personnes qui traitent de maintenance logicielle est les connaissances qu'elles ont de l'informatique (techniques de programmation), du domaine d'application, du logiciel lui-même. Il est très significatif que de 40 % à 60 % du temps de maintenance logicielle soit passé à lire le code pour comprendre ce qu'il fait, comment il le fait et comment il peut-être changé ; les Organisations : Elles peuvent avoir un profond impact sur la façon dont des activités comme la maintenance logicielle sont exécutées par les individus. Le support offert à l'intérieur des organisations, ou les contraintes qu'elles imposent, l’environnement culturel, peuvent tous affecter la facilité ou difficulté de ces tâches et donc la qualité qui en résultera. J'ai étudié quelques processus liés à la maintenance logicielle utilisés dans les organisations.Dans ce document, les différents sujets de recherche que j'ai considéré sont présentés de façon logique qui ne respecte pas toujours l'ordre chronologique des évènements. J'ai souhaité aussi mettre en valeur, non uniquement les résultats scientifiques de mes recherches, au travers des publications qui les attestent, mais aussi les collaborations qui les ont rendus possibles, collaborations avec des étudiants ou des collègues chercheurs. Pour chaque résultat présenté ici, j'ai tenté de résumer le plus possible les discussions sur l'état de l'art antérieur et les résultats eux-mêmes. Ce d'abord parce que de plus amples détails peuvent facilement être trouvés dans les publications citées, mais aussi parce que une part de cette recherche est maintenant vielle et peux parfois être tombé dans le domaine du « sens commun »

Análisis estático de software

Uno de los aspectos más importantes a mitigar en el desarrollo de sistemas de alta calidad es el número de defectos presentes en el código fuente debido a que estos podrían manifestarse como fallos durante fases posteriores a la codificación. Por esta razón, se han diseñado múltiples prácticas de ingeniería de software encargadas de descubrir la mayor cantidad posible de dichos defectos, siendo el Análisis Estático Automatizado (ASA) una de las más prometedoras. Sin embargo, aquellas herramientas que se ocupan de llevar a cabo esta práctica presentan una gran desventaja, la cual es la generación de un elevado número de posibles defectos y cuya relevancia es imperceptible a la correcta funcionalidad del sistema (alertas no accionables), provocando un gran consumo de tiempo al momento de inspeccionar cada una de ellas. Por lo anterior, el presente trabajo de investigación hace uso del aprendizaje maquinal para crear una Técnica de Identificación de Alertas Accionables (AAIT) como una forma de incorporar el ASA al Proceso de Desarrollo de Software (PDS). Para dos proyectos de software ajenos entre sí, se han generado múltiples reportes de alertas de análisis estático, los cuales han sido transformados en conjuntos de vectores de 46 Características de Alerta (CA) que sirven para construir y evaluar diferentes modelos de clasificación de alertas con el fin de aumentar el número de defectos relevantes descubiertos (alertas accionables) luego de concluir la fase de codificación y previo a la fase de pruebas. Los resultados obtenidos muestran que la utilización de modelos internos o externos al proyecto (es decir, la construcción de modelos con base en las alertas de un proyecto y su ejecución sobre las alertas del mismo proyecto o de otro) ofrecen un desempeño promedio (exactitud, precisión y sensibilidad) del 96.4% y del 71.1% respectivamente. Adicionalmente, el análisis realizado sobre el impacto que produciría la ejecución de nuestro mejor modelo externo predice que se lograría una eficiencia de eliminación de defectos del 90.0% a costa de un aumento del 47.16% sobre el tiempo total invertido en la corrección de dichos defectos respecto a un PDS que no incorpore ASA, permitiendo aumentar el número de defectos relevantes descubiertos en un 42.9% y disminuir el número de alertas irrelevantes en un 56.0

A Framework to Compare Alert Ranking Algorithms

Abstract—To improve software quality, rule checkers statically check if a software contains violations of good programming practices. On a real sized system, the alerts (rule violations detected by the tool) may be numbered by the thousands. Unfortunately, these tools generate a high proportion of “false alerts”, which in the context of a specific software, should not be fixed. Huge numbers of false alerts may render impossible the finding and correction of “true alerts ” and dissuade developers from using these tools. In order to overcome this problem, the literature provides different ranking methods that aim at computing the probability of an alert being a “true one”. In this paper, we propose a framework for comparing these ranking algorithms and identify the best approach to rank alerts. We have selected six algorithms described in literature. For comparison, we use a benchmark covering two programming languages (Java and Smalltalk) and three rule checkers (FindBug, PMD, SmallLint). Results show that the best ranking methods are based on the history of past alerts and their location. We could not identify any significant advantage in using statistical tools such as linear regression or Bayesian networks or ad-hoc methods