(My) CISSP Notes – Information Security Governance and Risk Management

Note: This notes were made using the following books: “CISPP Study Guide” and “CISSP for dummies”.
The Information Security Governance and Risk Management domain focuses on risk analysis and mitigation. This domain also details security governance, or the organizational structure required for a successful information security program.

CIA triad

  •  Confidentiality seeks to prevent the unauthorized disclosure of information. In other words, confidentiality seeks to prevent unauthorized read access to data.
  • Integrity seeks to prevent unauthorized modification of information. In other words, integrity seeks to prevent unauthorized write.
  • Availability ensures that information is available when needed.

The CIA triad may also be described by its opposite: Disclosure, Alteration, and Destruction (DAD).

The term “AAA” is often used, describing cornerstone concepts Authentication, Authorization, and Accountability.

  • Authorization describes the actions you can perform on a system once you have identified and authenticated.
  • Accountability holds users accountable for their actions. This is typically done by logging and analyzing audit data
  • Nonrepudiation means a user cannot deny (repudiate) having performed a transaction. It combines authentication and integrity: nonrepudiation authenticates the identity of a user who performs a transaction, and ensures the integrity of that transaction. You must have both authentication and integrity to have nonrepudiation.

Least privilege means users should be granted the minimum amount of access (authorization) required to do their jobs, but no more.

Need to know is more granular than least privilege: the user must need to know that specific piece of information before accessing it.

Defense-in-Depth (also called layered defenses) applies multiple safeguards (also called controls: measures taken to reduce risk) to protect an asset.

Risk analysis

  • Assets are valuable resources you are trying to protect.
  • A threat is a potentially harmful occurrence, like an earthquake, a power outage, or a network-based worm. A threat is a negative action that may harm a system.
  • A vulnerability is a weakness that allows a threat to cause harm.

Risk = Threat × Vulnerability

To have risk, a threat must connect to a vulnerability.

The “Risk = Threat × Vulnerability” equation sometimes uses an added variable called impact: “Risk = Threat × Vulnerability × Impact.

Impact is the severity of the damage, sometimes expressed in dollars.

Loss of human life has near-infinite impact on the exam. When calculating risk using the “Risk = Threat × Vulnerability × Impact” formula, any risk involving loss of human life is extremely high, and must be mitigated.

The Annualized Loss Expectancy (ALE) calculation allows you to determine the annual cost of a loss due to a risk. Once calculated, ALE allows you to make informed decisions to mitigate the risk.

The Asset value (AV) is the value of the asset you are trying to protect.

PIIPersonally Identifiable Information

The Exposure Factor (EF) is the percentage of value an asset lost due to an incident.

The Single Loss Expectancy (SLE) is the cost of a single loss. SLE  = AV x EF.

The Annual Rate of Occurrence (ARO) is the number of losses you suffer per year.

The Annualized Loss Expectancy (ALE) is your yearly cost due to a risk. It is calculated by multiplying the Single Loss Expectancy (SLE) times the Annual Rate of Occurrence (ARO).

The Total Cost of Ownership (TCO) is the total cost of a mitigating safeguard. TCO combines upfront costs (often a one-time capital expense) plus annual cost of maintenance, including staff hours, vendor maintenance fees, software subscriptions, etc.

The Return on Investment (ROI) is the amount of money saved by implementing a safeguard.

Risk Choices

Once we have assessed risk, we must decide what to do. Options include accepting the risk, mitigating or eliminating the risk, transferring the risk, and avoiding the risk.

Quantitative and Qualitative Risk Analysis are two methods for analyzing risk. Quantitative Risk Analysis uses hard metrics, such as dollars. Qualitative Risk Analysis uses simple approximate values. Quantitative is more objective; qualitative is more subjective.

The risk management process

Risk Management Guide for Information Technology Systems (see http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf).

The guide describes a 9-step Risk Analysis process:

1. System Characterization – System characterization describes the scope of the risk management effort and the systems that will be analyzed.

2. Threat Identification –

Threat Identification and Vulnerability Identification, identify the threats and vulnerabilities, required to identify risks using the “Risk = Threat × Vulnerability” formula.

3. Vulnerability Identification

4. Control Analysis – Control Analysis, analyzes the security controls (safeguards) that are in place or planned to mitigate risk.

5. Likelihood Determination

6. Impact Analysis

7. Risk Determination

8. Control Recommendations

9. Results Documentation

Information Security Governance

Information Security Governance is information security at the organizational level.

Security Policy and related documents

  • Policies are high-level management directives. Policy is high level: it does not delve into specifics. All policy should contain these basic components: Purpose, Scope, Responsibilities , Compliance.  NIST Special Publication 800-12 (see http://csrc.nist.gov/publications/nistpubs/800-12/800-12-html/chapter5.html) discusses three specific policy types: program policy, issue-specific policy, and system-specific policy. Program policy establishes an organization’s information security program.
  • A procedure is a step-by-step guide for accomplishing a task. They are low level and specific. Like policies, procedures are mandatory.
  • A standard describes the specific use of technology, often applied to hardware and software. Standards are mandatory. They lower the Total Cost of Ownership of a safeguard. Standards also support disaster recovery.
  • Guidelines are recommendations (which are discretionary).
  • Baselines are uniform ways of implementing a safeguard.

Roles and responsibilities

Primary information security roles include senior management, data owner, custodian, and user.

  • Senior Managementcreates the information security program and ensures that is properly staffed, funded, and has organizational priority. It is responsible for ensuring that all organizational assets are protected.
  • The Data Owner (also called information owner or business owner) is a management employee responsible for ensuring that specific data is protected. Data owners determine data sensitivity labels and the frequency of data backup. The Data Owner (capital “O”) is responsible for ensuring that data is protected. A user who “owns” data (lower case “o”) has read/write access to objects.
  • A Custodian provides hands-on protection of assets such as data. They perform data backups and restoration, patch systems, configure antivirus software, etc. The Custodians follow detailed orders; they do not make critical decisions on how data is protected.
  • Users must follow the rules: they must comply with mandatory policies procedures, standards, etc.

Complying with laws and regulations is a top information security management priority: both in the real world and on the exam.

The exam will hold you to a very high standard in regard to compliance with laws and regulations. We are not expected to know the law as well as a lawyer, but we are expected to know when to call a lawyer.

The most legally correct answer is often the best for the exam.

Privacy is the protection of the confidentiality of personal information.

Due care and Due Diligence

Due care is doing what a reasonable person would do. It is sometimes called the “prudent man” rule. The term derives from “duty of care”: parents have a duty to care for their children, for example. Due diligence is the management of due care.

Due care is informal; due diligence follows a process.

Gross negligence is the opposite of due care. It is a legally important concept. If you suffer loss of PII, but can demonstrate due care in protecting the PII, you are on legally stronger ground, for example.

Auditing and Control Frameworks

Auditing means verifying compliance to a security control framework (or published specification).

A number of control frameworks are available to assist auditing Risk Analysis. Some, such as PCI (Payment Card Industry), are industry-specific (vendors who use credit cards in the example). Others, such as OCTAVE, ISO 17799/27002, and COBIT.

OCTAVE stands for Operationally Critical Threat, Asset, and Vulnerability Evaluation, a risk management framework from Carnegie Mellon University. OCTAVE describes a three-phase process for managing risk. Phase 1 identifies staff knowledge, assets, and threats. Phase 2 identifies vulnerabilities and evaluates safeguards. Phase 3 conducts the Risk Analysis and develops the risk mitigation strategy. OCTAVE is a high-quality free resource which may be downloaded from: http://www.cert.org/octave/ ISO 17799 and the ISO 27000 Series.

ISO 17799 had 11 areas, focusing on specific information security controls:

1. Policy

2. Organization of information security

3. Asset management

4. Human resources security

5. Physical and environmental security

6. Communications and operations management

7. Access control

8. Information systems acquisition, development, and maintenance

9. Information security incident management

10. Business continuity management

11. Compliance3 ISO 17799 was renumbered to ISO 27002 in 2005, to make it consistent with the 27000 series of ISO security standards.

Simply put, ISO 27002 describes information security best practices (Techniques), and ISO 27001 describes a process for auditing (requirements) those best practices.

COBIT (Control Objectives for Information and related Technology) is a control framework for employing information security governance best practices within an organization.  COBIT was developed by ISACA (Information Systems Audit and Control Association.

ITIL(Information Technology Infrastructure Library) is a framework for providing best services in IT Service Management (ITSM). ITIL contains five “Service Management Practices—Core Guidance” publications: • Service Strategy • Service Design • Service Transition • Service Operation • Continual Service Improvement

Certification and Accreditation

Certification is a detailed inspection that verifies whether a system meets the documented security requirements.

Accreditation is the Data Owner’s acceptance of the risk represented by that system.

Introduction à l’investigation numérique (3) – Formalisations du processus d’investigation numérique

Dans [DUVAL] (chapitre 1.1), Duval fait un état de l’art des processus de formalisation d’investigation numérique.

La formalisation de McKemmish

Le premier model présenté est le modèle de McKemmish [KEMMISH] qui propose de décomposer l’étude de l’attaque d’un système informatique en 4 étapes :

  • Identification de la preuve digitale :  sert a identifier les éléments pouvant contenir des indices et des preuves. Cela permet de déterminer les outils qui devront être utilisés pendant la phase d’analyse.
  • Préservation de la preuve digitale. Cette phase est une phase critique puisque dans certains cas les preuves digitales doivent être présentées comme pièces à  conviction devant une instance judiciaire.
  • Analyse de la preuve digitale. Le but de cette phase est de transformer les données brutes dans une forme compréhensible par toute personne impliquée dans l’enquête.
  • Présentation de la preuve digitale. Le but de cette phase est de présenter les résultats aux personnes intéressées, qui ne sont pas forcément spécialistes du domaine.

McKemmish décrit aussi les quatre règles principales qui doivent être respectées par un logiciel d’analyse numérique afin que les résultats produits puissent être recevables :

  1. Une modification minimale des données d’origine
  2. Documentation de tout changement de la preuve digitale intervenu pendant l’analyse.
  3. Le respect des règles de bon usage des outils pour ne pas corrompre l’ensemble de l’analyse et pour ne pas modifier la signification des données
  4. Ne pas surestimer ses connaissances et ses capacités. Dans le cas ou l’enquêteur n’a pas les compétences pour analyser la preuve, il aura besoin soit de se mette à niveau, soit de se faire assister.

La formalisation de Mandia et Procise

Un autre modèle de formalisation est celui proposé pas Mandia et Procise dans le livre « Incident Response and Computer Forensics » [MANDIA].  Leur méthodologie comprend sept étapes majeures :

  1. « Pre-incident preparation » : Prendre des mesures pour préparer l’organisation avant l’apparition d’un incident.
  2. « Detection of incidents » : Identifier un potentiel incident (informatique) de sécurité.
  3. « Initial response » : Réaliser une enquête initiale et l’enregistrement des preuves concernant l’incident, la création de l’équipe de réponse aux incidents et l’information des personnes qui ont besoin de savoir de l’existence de l’incident.
  4. « Formulate response strategy » : Sur la base des résultats de tous les faits connus, déterminer la meilleure réponse et obtenir l’approbation de la direction de la société.
  5. « Investigate the incident » : Effectuer une collecte complète de données. Passer en revue les données recueillies pour déterminer la cause de l’incident, le moment de sa survenance, la personne a son origine et la manière dont elle a agi et enfin, la manière dont on peut prévenir à l’avenir ce type d’incidents.
  6. « Reporting » : Indiquer les informations relative a l’enquête d’une manière précise et utile aux décideurs.
  7. « Resolution » : Appliquer les mesures de sécurité et des changements de procédure, et développer à long terme des correctifs pour remédier aux problèmes identifiés
Les sept composants de la réponse a un incident

La formalisation du projet CTOSE

Un troisième modèle de formalisation est celui proposé par le projet européen CTOSE (Cyber Tools On-line Search for Evidence) [CTOSE]. Dès le départ, le but du projet CTOSE a été d’élaborer un modèle de processus de référence ressemblant à des lignes directrices organisationnelles, techniques et juridiques sur la façon dont une entreprise doit procéder lorsqu’un incident informatique se produit. L’objectif de ce modèle se focalise sur l’acquisition d’éléments de preuve numérique et ​​le processus a suivre pour améliorer la collecte, le stockage, la sécurité et l’analyse des données, de manière a ce qu’elles soient légalement admissibles dans les procédures judiciaires.

Le schéma suivant illustre les différentes composantes du projet CTOSE et explique la manière dont le modèle de référence est lié aux exigences techniques, juridiques et de présentation.

 Les éléments du projet CTOSE
Les éléments du projet CTOSE

Le modèle ci-dessus de processus de référence comporte cinq phases liées: la phase de préparation, la phase d’exécution, la phase d’évaluation, la phase d’enquête et la phase d’apprentissage. Ce modèle de processus décrit les actions et les décisions qui doivent être menées dans le cadre d’une enquête concernant des attaques informatiques. Des informations supplémentaires, concernant notamment les rôles et responsabilités spécifiques, l’ensemble de compétences requises, listes et guides d’autres documents de référence, les outils et conseils juridiques sont également prévus pour faciliter l’action et/ou la décision a chaque phase.

Les phases du processus du modèle CTOSE
Les phases du processus du modèle CTOSE

Le projet CTOSE n’est plus maintenu depuis 2004, le domaine Internet du projet (www.ctose.org) étant en vente.

La formalisation EDIP (Enhanced Digital Investigation Process)

Dans [EDIP], Baryamureeba et Tushabe proposent un modèle d’investigations informatiques basé sur 5 phases :

  1. « Readiness Phases » : Pendant cette phase, l’enquêteur vérifie s’il est prêt à effectuer  l’enquête. Cette vérification porte notamment sur la qualité des équipements et le niveau l’expérience de l’enquêteur.
  2. « Deployment Phases » ; Cela correspond à l’arrivée sur les lieux de l’incident et aux premières observations faites par les enquêteurs.
  3. « Physical Crime Scene Investigation Phases » : L’objectif de cette phase est de récolter et conserver toutes les preuves physiques potentielles (disques durs, disquettes, etc.) pour ensuite les analyser.
  4. « Digital Crime Scene Investigation Phases » : L’objectif de cette phase est d’analyser les éléments de preuve récoltes pour tenter de comprendre ce qui s’est passé.
  5. « Review Phase » : cette phase correspond au débriefing.
Les phases de la formalisation EDIP
Les phases de la formalisation EDIP

Introduction à l’investigation numérique (2)

Investigation numérique à froid (post-mortem)

L’investigation numérique à froid ou post-mortem représente la méthode classique d’investigation numérique. Dans cette approche, l’enquêteur débranche le système cible, puis prend des images (des copies) des disques, soit sur le site ou soit dans un laboratoire.  Ensuite, un analyste examine l’image (en fait une copie) dans un environnement contrôlé.

L’investigation numérique à froid comporte certains avantages découlant du fait que possède et travaille sur une copie figée du système. L’investigation numérique a froid est en outre non-invasive, car les données sont conservées uniquement en mode lecture, ce qui garantit leur authenticité. L’investigation à froid est reproductible car un environnement statique se prête à des résultats reproductibles. Dans le cas d’une investigation à froid, le temps n’est pas un facteur clé, puisque l’analyste travaille sur une image figée. En plus, le fait d’avoir un certain laps de temps pour analyser les données, permet de diminuer le nombre d’erreurs susceptibles d’apparaître. Enfin, l’investigation numérique a froid présente aussi l’avantage de pouvoir mettre en corrélation différents résultats, compte tenu de la capacité d’examiner d’autres sources d’informations.

Néanmoins, l’approche post-mortem présente aussi plusieurs inconvénients. Tout d’abord, cette approche ne permet pas toujours de déconnecter le système d’information. Comme la taille des disques des systèmes continue d’augmenter, faire une image du disque peut durer plusieurs heures. Le temps et les efforts nécessaires pour l’analyse des disques augmentent proportionnellement avec la taille des disques.

Pendant le clonage d’un disque, le système a qui il appartiens est déconnecté, mais pour de nombreux systèmes, tels que par exemple, les systèmes de commerce électronique, la perte de recettes due a une interruption de quelques heures est inacceptable.

Finalement, lorsque l’alimentation est coupée, beaucoup d’informations sur ce qui se passe sur un système d’informations vivant sont perdues L’investigation numérique traditionnelle tente de préserver toutes les preuves (les disques) dans un état immuable, tandis que l’investigation numérique des systèmes vivants cherche à prendre un instantané de l’état de l’ordinateur, semblable à une photographie d’une scène de crime.

Investigation numérique des systèmes vivants

Contrairement a l’investigation numérique post-mortem, l’investigation numérique des systèmes vivants se fait sans déconnecter le système cible de son environnement.

Selon leur nature, les informations disponibles sur un système vivant peuvent être classées dans l’une des catégories suivantes : les processus en cours, les connexions réseau, la mémoire (processus et physique), les fichiers de journalisation, les utilisateurs connectés, la charge du système d’exploitation. L’analyse des systèmes vivants peut capturer à la fois des informations volatiles et des informations statiques présentes sur le système de fichiers. Actuellement, la plus part des outils d’investigation numérique utilisent directement le système d’exploitation pour obtenir ces informations. Si une machine a été compromise, son noyau peut exécuter du code malveillant (via un rootkit) qui empêche le système d’exploitation de signaler de façon correcte l’existence des processus et des fichiers.  Bien qu’il existe des programmes qui permettent de détecter la présence des rootkits, il n’y a pas beaucoup de solutions si un rootkit est présent, sauf à utiliser l’approche traditionnelle (investigation a froid).

L’investigation numérique des systèmes vivants présente aussi une difficulté importante en raison du fait que le système n’est pas statique, les fichiers et les processus étant en constante évolution. Une investigation est un processus itératif: à plusieurs reprises on récupère et on analyse les données. L’enquêteur récupère les données volatiles du système en exécutant différents programmes. Compte tenu du fait que la collecte de preuves sur la cible peut affecter d’autres preuves sur la (même) cible, un ensemble des meilleures pratiques est apparu afin de maximiser la qualité des preuves. Les plus importants sont: exécuter des binaires surs, calculer des valeurs de hachage pour toutes les preuves et la collecte des données dans l’ordre de la volatilité des données.

Exécuter des binaires surs. Un enquêteur ne devrait pas faire confiance aux fichiers exécutables sur le système cible, mais devrait posséder tous les exécutables utilisés pour recueillir des preuves. Les fichiers exécutables devraient être compilés de façon statique, si possible, sinon ils devraient inclure toutes les bibliothèques partagées requises par l’exécutable.

Les programmes devraient provenir d’un support en lecture seule, tel qu’un CD-ROM. Les fichiers exécutables peuvent être copiés sur le système cible, mais cette action aura une incidence sur le disque, pouvant par exemple écraser des preuves résidant dans des fichiers supprimés.

S’il faut faire le choix entre la perte de certains éléments de preuve en écrasant des fichiers supprimés et la perte de toutes les preuves en n’obtenant pas l’information, il vaut mieux risquer des dommages mineurs en copiant des fichiers vers le système cible.

Calculer des valeurs de hachage pour toutes les preuves. Une fois acquise, la preuve doit être conservée de façon adéquate, afin que l’enquêteur puisse ensuite démontrer qu’elle n’a subi aucune altération. La méthode acceptée consiste à calculer une valeur utilisant un algorithme de hachage cryptographique sécurisé (généralement MD5 ou SHA-1).

La valeur de hachage peut être recalculée plus tard et comparée par rapport à l’original pour montrer que les données n’ont pas changé depuis l’obtention de la valeur de hachage d’origine. Si les données sont transmises par le réseau de la cible vers une autre machine, la valeur de hachage doit être calculée sur les deux machines et comparée pour s’assurer qu’aucune des données n’a été modifiée durant le transfert. La valeur de hachage et la preuve devraient être maintenues dans un endroit sûr.

Collecte des données par ordre de volatilité des données. Certaines données sont plus volatiles que d’autres. C’est pourquoi, les preuves devraient être rassemblées en fonction de l’ordre de volatilité des données. Par exemple, les connexions réseau changent plus fréquemment que les utilisateurs connectés au système.

Par ailleurs, certaines actions peuvent affecter d’autres données. Par exemple, la connexion à un système peut générer des entrées dans les fichiers de log du système. Pour compliquer encore plus les choses, le temps nécessaire pour recueillir des preuves peut dépendre de la nature de la preuve recueillie. Un listage (« dump ») de la mémoire physique d’une machine peut être utile mais, mais compte tenu de sa volatilité, il doit être effectue au début de l’enquête. Cependant, cette opération peut prendre des dizaines de minutes à accomplir, et pendant ce temps, les informations les plus utiles (telles que les listes de processus en cours, fichiers ouverts, et les connexions réseau) pourront avoir changé ou disparu.

Tandis que l’ensemble de la mémoire vive du système est en constante évolution, sur un système moderne avec un gigaoctet ou plus de mémoire, les pages mémoire peuvent persister pendant un temps considérable (quelques jours ou semaines). En d’autres termes, l’enquêteur doit être conscient du contexte global de l’enquête pour prendre des décisions sur l’ordre d’acquisition des preuves.

Le tableau suivant permet d’illustrer le temps de vie des différents artefacts digitaux [Farmer 2004]:

Registres, mémoire périphérique Nanosecondes
Mémoire principale Nanosecondes
L’état du réseaux Millisecondes
Processus actifs Secondes
Disc Minutes
Bandes d’archivage (backup) Années
CD-ROM, DVD-ROM Dizaines d’années

Le temps de vie des différents artefacts digitaux

Pour conclure, l’investigation numérique des systèmes vivants peut fournir des preuves qui ne sont pas disponibles dans une image statique d’un disque. Mais ce domaine est encore relativement nouveau.

Pour accroitre l’utilité de l’investigation numérique des systèmes vivants, des progrès dans plusieurs domaines seront essentiels, notamment en ce qui concerne les outils d’automatisation et standardisation du processus d’acquisition et de préservation des preuves et les outils de présentation des preuves.

Introduction à l’investigation numérique (1)

Qu’est-ce que c’est l’investigation numérique ?

Au premier workshop du Digital Forensics Research Group (DFRWS) in 2001, l’investigation numérique a été définie de la façon suivante :

« L’utilisation de méthodes scientifiquement prouvées qui ont comme but la préservation, la collecte, la validation, l’identification, l’analyse, l’interprétation, la documentation et la présentation de preuves numériques provenant de sources numériques dans le but de faciliter ou de favoriser la reconstitution des événements de nature criminelle, ou en aidant d’anticiper les actions non autorisées qui pourraient être préjudiciables pour les opérations planifiées. »[DFRWS]

Même si les techniques d’investigation numérique sont utilisées  dans d’autres contextes que des enquêtes criminelles, les principes et les procédures sont plus ou moins les mêmes indépendamment du type d’enquête. L’investigation numérique utilise comme source d’information les données générées par ordinateur.

Le but de toute investigation numérique est de trouver des faits, afin de reconstituer la vérité d’un événement. L’examinateur révèle la vérité d’un événement en découvrant et en exposant les traces que l’événement a laissées sur le système. En accord avec la métaphore ‘’archéologue numérique’’, ces traces sont connues comme des artefacts. Ces traces sont parfois appelées des preuves.

Ainsi que l’indique le principe d’échange de Locard, « lorsque deux corps entrent en contact l’un avec l’autre, il y a nécessairement un transfert entre ceux-ci. » [LOCARD]

Cette simple déclaration est le principe fondamental au cœur de la dynamique des éléments de preuve. Transposé à l’investigation numérique, cela signifie que l’action d’un acteur sur un système d’information laissera des traces de cette activité sur le système. Des actions très simples peuvent tout simplement causer des changements dans les registres du processeur. Les actions plus complexes ont une plus grande probabilité de créer et laisser des traces plus durables sur le système, mais même des tâches simples peuvent laisser des traces.

Il est important de rappeler le travail de l’examinateur: déterminer la vérité. Chaque examen devrait commencer par une hypothèse. La tâche de l’examinateur n’est pas de démontrer ces affirmations, mais de découvrir des artefacts indiquant si l’hypothèse est valide ou non valide.

Une subtilité supplémentaire apparait en raison de la facilité avec laquelle les éléments numériques peuvent être manipulés ou entièrement fabriqués. Dans beaucoup d’enquêtes, l’examinateur doit déterminer si les éléments de preuve numérique sont compatibles ou non avec les processus et les systèmes censés les avoir générés. Dans certains cas, la détermination de la cohérence des éléments de preuve numérique est le seul but de l’examen.

Le processus d’investigation numérique peut être décomposé en trois catégories d’activités: l’acquisition, l’analyse et la présentation.

  • L’acquisition se réfère à la collecte des supports numériques à  examiner. Selon le type d’analyse, il peut s’agir des disques durs physiques, des médias optiques, des cartes de stockage, des caméras numériques, des téléphones portables ou des simples documents. Dans tous les cas, les supports à examiner doivent être traités avec beaucoup de délicatesse. Il convient notamment de créer un duplicata des médias originaux (la copie de travail) ainsi que de maintenir des notes de toutes les mesures prises des supports originaux.
  • L’analyse consiste dans l’examen proprement dit des supports, «l’identification, l’analyse et l’interprétation » des éléments de la définition de DFRWS. L’identification consiste à localiser les éléments ou des éléments présents dans les médias en question, puis de réduire encore cet ensemble à des artefacts d’intérêt. Ces éléments sont ensuite soumis à une analyse appropriée. Cela peut être l’analyse du système de fichiers, l’examen du contenu d’un fichier, l’analyse d’un fichier de journalisation, l’analyse statistique ou n’importe quel autre type d’examens. Enfin, l’examinateur doit interpréter les résultats de cette analyse. La qualité de l’analyse dépend beaucoup de la formation de l’examinateur, de son expertise technique et de son niveau d’expérience.
  • La présentation est le processus par lequel l’examinateur partage les résultats de la phase d’analyse avec la partie ou les parties intéressées. Celle-ci consiste dans un rapport des mesures prises par l’examinateur, une description des artefacts découverts et la signification de ces artefacts.

Notez que les résultats de la phase d’analyse peuvent conduire à d’autres acquisitions, chacune pouvant conduire a des analyses supplémentaires, etc. Cette boucle peut se poursuivre pendant de nombreux cycles donnant lieux à des enquêtes de longue durée.

Web Application Firewall (WAF) – l’etat de l’art (4)

Produits et solutions

Solutions non-commerciales

ModSecurity – www.modsecurity.org

Le pare-feu applicatif Web le plus utilisé est ModSecurity qui est un projet open-source. ModSecurity est actuellement maintenu par TrustWave, une société qui vend également des pare-feu applicatifs Web commerciaux. ModSecurity
utilise généralement un modèle de sécurité négative et a également plusieurs projets connexes qui contribuent à améliorer la solution. ModSecurity Apache est un module pour le serveur web Apache. ModeSecurity Core Rules est un ensemble de règles permettant de déceler les attaques Web les plus courants. Les ModeSecurity Core Rules sont un excellent point de départ pour ceux qui sont novices en configuration du ModSecurity.

Microsoft URLScan – http://www.iis.net/download/urlscan

UrlScan est un outil de sécurité produit par Microsoft qui limite les types de requêtes HTTP qui Microsoft Internet Information Services (IIS) est capable a traiter. En bloquant des requêtes HTTP spécifiques, l’outil de sécurité UrlScan empêche les requêtes potentiellement dangereuses d’atteindre le serveur. UrlScan est implémenté comme un filtre ISAPI (Internet Server Application Programming Interface) qui analyse les requêtes HTTP reçus par IIS. Lorsqu’il est correctement configuré, UrlScan est efficace a réduire l’exposition des Services aux attaques Internet.

Solutions commerciales

Barracuda Networks – http://www.barracudanetworks.com

Barracuda Networks, les plus connus pour leurs pare-feu SPAM, sont entrées dans le monde des firewall applicatifs par l’acquisition de la société NetContinum.

La société vend ses produits comme applicances et possède actuellement deux lignes de produits, le pare-feu applicatif Web et le contrôleur d’applications Web. Le produit pare-feu est orienté vers des PME avec des unités qui ont un débit entre 25 et 100 Mbps. Le contrôleur d’applications Web est un type de produits orienté vers les grands clients. Prix d’un boitier pare-feu commence à 5 500$.

TrustWave – www.trustwave.com

TrustWave offre deux gammes d’appliances, WebDefend et ModSecurity Pro. ModSecurity Pro est basée sur le projet ModSecurity avec des règles de filtrage complémentaires. WebDefend est un produit qui peut être installé dans l’infrastructure réseaux du client ou comme un service externe offert par TrustWave.

Deny All – www.denyall.com

Deny All et leur produit rWeb est une autre option dans l’espace des pare-feu applicatifs Web. Le produit rWeb utilise un modèle de sécurité positive (white list). Le produit offre également des services de cache de compression et d’équilibrage de charge.

F5 – www.f5.com

F5 vend un pare-feu applicatif Web comme un module complémentaire pour sa ligne des produits BigIP Application Delivery Controllers ou comme une appliance autonome.

Le module WAF utilise un modèle de sécurité positive pour la définition des politiques de sécurité et est livré avec toutes les fonctionnalités que sont attendus d’un WAF prêts pour les entreprises. Une des caractéristiques les plus intéressantes est l’intégration avec WhiteHat Sentinel Vulnerability Assessment Service qui peut automatiquement créer des règles basés sur les vulnérabilités trouvées à partir d’un scan Sentinel WhiteHat. Le WAF autonome est vendu autour de 28.000$, tandis que le prix des solutions BigIP commence autour de 65.000$.

Imperva – www.imperva.com

Le pare-feu applicatif  SecureSphere d’Imperva est l’un des appareils plus réputés du marché. Selon Gartner, Imperva “apparaît le plus souvent sur la liste des produits préférées par les clients de Gartner.» (Young, 2008)

Imperva, utilise ce que la société appelle «l’inspection transparente”, une technologie pour combiner la sécurité avec la haute performance.

Les politiques de sécurité sont basées sur un modèle de sécurité positive et Imperva a également des options pour le suivi de base de données de vulnérabilités. Les prix commencent à 35.000 $.

Pour une liste contenant d’autres solutions consultez le site de OWASP : https://www.owasp.org/index.php/Web_Application_Firewall

Bibliographie (pour le 4 posts concernant les Waf)

[OWASP] https://www.owasp.org

[MISC 60] http://www.ed-diamond.com/produit.php?ref=misc60

[MISC 57] http://www.ed-diamond.com/produit.php?ref=misc57

[WASC] http://www.webappsec.org/

[WAFEC] http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%20Evaluation%20Criteria

[WAFBook] http://dl.acm.org/citation.cfm?id=1512788