Identifiez l'information qui a une importance critique pour l'organisation, la mission, le projet ou la maison [propriété intellectuelle, détails de la mission, plans, R&D, capacités, dégradations, données clés sur la répartition du personnel, dossiers médicaux, contrats, schémas de réseau, etc...]

Mais « Attendez », dites-vous, « je ne suis qu'un gamin avec un ordinateur portable ! » Vous fréquentez les cafés ? Vous utilisez les réseaux partagés ? Vous permettez aux autres de regarder par-dessus votre épaule lorsque vous vous connectez à votre banque ? Si c'est le cas, OPSEC est certainement fait pour vous.

Bien sûr, cette étape est nettement plus angoissante pour un administrateur système, car il est clair qu'il sait à quel point il est facile de planter un système et de perdre le travail de 30 professionnels ou plus en une seule commande, ou pour celui qui se rend bien compte que la défaite, c'est ne jamais pouvoir garantir de disponibilité stable. Cependant, tout utilisateur d'ordinateurs sait ce que c'est que de ne pas pouvoir compter sur la stabilité des données. Cette étape est donc très importante pour les administrateurs systèmes. Securité = stabilité en tout lieu.

Identifiez les adversaires, concurrents ou criminels qui valent la peine de s'en inquiéter, et ayant l'intention ainsi que la capacité d'acquérir des informations critiques chez vous.

Si vous n'avez pas pris le temps de regarder vos logs pour voir toutes les tentatives d'accès par SSH ou ftp, ou de vraiment vous poser dans un café pour estimer le trafic sans-fil, ou de regarder tcpdump pour voir ce qui se passe sur le réseau de l'Université, il serait peut-être temps de commencer. Il n'y a pas que les Chinois et les Russes (des scripts, parmi lesquels netcat, nmpa, et MetaSploit, peuvent être configurés facilement pour usurper ces adresses). Réveillez-vous et regardez autour de vous, dans les conférences, et posez-vous sérieusement la question, qui est un concurrent, qui est un criminel. Ceci est une étape indispensable avec OPSEC. Pendant les années 90 dans le nord-ouest des États-Unis, les administrateurs des systèmes Linux sous contrats concurrents se sont régulièrement attaqués aux serveurs web des uns des autres.

Mais, direz-vous, « pourquoi voudraient-ils s'infiltrer dans mon petit ordinateur portable ? ». Vous êtes connectés 24h sur 24, 7 jours sur 7, n'est-ce pas ? Votre système peut être configuré via Anacron, et utilisé comme obscur botnet intraçable , et vous n'en sauriez jamais rien ? Ce botnet peut exploiter votre bande-passante, voler votre puissance de calcul et au final être utilisé pour mettre des serveurs hors-service.

Il faut prendre le point de vue de l' adversaire, du concurrent ou du voleur, et identifier les vulnérabilités et moyens potentiels d'accéder aux résultats de l'étape 1. Questionnez un échantillon représentatif d'individus.

Si vous n'avez pas été sur google pour vous assurer que la version de Firefox que vous utilisez est sécurisée contre les menaces connues, vous n'avez pas terminé cette étape. Si vous ne connaissez pas les vulnérabilités actuelles de la version d'OpenSSH et d'Apache ou de Java ou autre code source binaire installé avec votre Ubuntu ou votre Fedora, vous n'avez pas les bases pour utiliser la technologie Linux en toute sagesse.

Bien que je ne recommande pas à tout le monde d'assister à la DefCon, la lecture de leur site web public pourrait bien suffire pour vous impressionner quant à l'importance de l'OPSEC. Mieux encore, gravez vous un LiveCD BackTrack4 et lancez quelques uns des outils contre vos propres systèmes.

Il y a deux façons classiques de s'infiltrer sur Linux en utilisant les modèles de la pile OSI : « de haut en bas » ou « de bas en haut ».

Source : Modèle OSI

Couche :

La plupart des problèmes est due à la couche 8 !

Évaluez les risques de chacune des vulnérabilités par son impact respectif sur la performance / l'accomplissement de la mission, si réalisé(e).

Après avoir testé votre SSH via un réseau extérieur ou après avoir scanné le cluster de votre application J2EE à partir d'une clé Trial IBM WatchFire AppScan; ou après avoir fait une recherche automatique des bogues sur votre Apache 1.33/LDAP depuis le partage (pas de réseau public VLAN) ou après avoir accédé/craqué votre propre clé WEP en cinq minutes, vous verrez clairement que vous ne possédez en réalité rien du tout, que vous ne pouvez vérifier aucune stabilité, et que, aussitôt qu'on empiète sur vos systèmes, rien ne va plus.

C'est par exemple le moment où l'administrateur serveur / l'utilisateur d'iPhone/de Blackberry s'aperçoit que son téléphone fait peut être plus que ce qu'il avait prévu. Et il se pose des questions sur la politique d'inclusion de fichiers PDF joints, sans qu'ils soient scannés et contrôlés, telle que définie dans la couche 8/9. Mais sans l'OPSEC, ce moment-là arrive toujours trop tard. Les téléphones s'intègrent potentiellement avec tout, ils ont des adresses IP et la plupart du temps, on n'y pense pas!

Encore une fois, laisser les imprimantes à part, par exemple, c'est de la folie, sachant que de nombreuses imprimantes HP et le protocole IPP peuvent être facilement pénétrés ou abusés par un programme intrusif ou autre lâché à l'ouverture d'une pièce jointe anodine.

Cette étape doit tout inclure, y compris toutes les technologies voisines avec lesquelles interfacent chaque système.

Générez/conseillez des mesures spécifiques qui parent aux faiblesses identifiées. Mettez en vigueur des mesures de protection efficaces après les avoir classées par ordre de priorité.

Maintenant, avant de piquer votre crise et de fuir cette intolérable « limitation » de votre liberté informatique soyez assurés qu'il y a des « solutions ».

Estimez et mesurez l'efficacité, et adaptez en conséquence.

Il y a des solutions très simples : cela peut être un conteneur pour votre SSH, la mise à niveau d'OpenVPN (qu'il est vraiment aisé de mettre en place), l'utilisation de NoScript dans un navigateur, ou le fait de ne jamais utiliser un navigateur en tant que root sur un serveur de production. Elles peuvent inclure une table IP basée serveur et mise en œuvre une fois pour toute, ou aller jusqu'à être complètement inclusives comme un changement d'application de la couche 7 (qui peut coûter moins cher dans un magasin de développement « château de cartes » qu'une révision complète du code — pour une compatibilité PCI — ou une réécriture). Pour une recherche automatique des bogues dans Tomcat par exemple, un changement d'architecture de l'IDS intégré ou de mod_security ou de mod_proxy vous épargnera des mois de DoS.

Si vous devez vous engager dans la mise en place de réseaux sociaux ou la navigation sur des sites de warez acceptant le javascript, ce serait peut-être pas mal de le faire depuis un système considéré comme non-sécurisé prévu pour ça .

Aborder la question sous plusieurs angles pour trouver des solutions en couches est un élément clé, et la moindre des choses est d'arrêter immédiatement le comportement de type couche 8 considéré comme dangereux. Éteignez le SSH quand vous êtes au café; vous ne vous en servez pas de toute façon. En fait, éteignez votre Bluetooth aussi, qui est probablement encore allumé par défaut, non ?

Une grande quantité de données va être dévoilée durant cette investigation, alors une approche organisée et documentée vous permettra d'y voir clair. Vous vous apercevrez qu'il pourrait être plus simple de remplacer ou mettre à niveau, plutôt que tenter de protéger. Il n'est pas irréaliste de s'attendre à devoir mettre à niveau au moins tous les quatre ans, vu que vous appliquez les patchs standards, si l'on en juge par le recul que nous donnent plus de 10 années d'histoire de Linux.

Si (quand) vous identifiez des politiques dangereuses (de gestion) au niveau de la couche 9, rédigez une documentation à ce sujet et faites remonter, de sorte que votre responsabilité en tant que techno-utilisateur conscient de la déontologie puisse circuler. L'indifférence ou d'autres attitudes telles que «les gens n'aiment pas les rapports de sécurité» ou « tout le monde l'a ignoré jusqu'ici, si je dis quelque chose maintenant, ils me prendront pour un idiot » portent préjudice à tous. Utilisez des références s'il le faut; la sécurité est la responsabilité de tous.

La plus dangereuse des politiques de la couche 8/9 intervient dans le cloisonnement de la sécurité informatique. Voici d'excellents exemples de cloisonnement :

Alors que dans un environnement d'entreprise sain la responsabilité remonte, dans un environnement open source sain la responsabilité est un processus organisé; et nulle part on ne peut ignorer la sécurité.

Avoir zéro faiblesse est complètement irréaliste. Si vous travaillez dans une boutique qui fonctionne comme si il y avait un système de sécurité complet sans OPSEC, ou que vous vous retrouvez à penser qu'il n'y a pas de risques de sécurité, votre alarme doit s'activer. Une vigilance constante est la seule approche réaliste. Une règle générale : ceux qui sont conscients de ce qu'ils doivent protéger ont plus de chance de protéger des informations sensibles, a contrario de ceux qui n'en sont pas conscients.

Récupérez les données des experts sur les menaces, n'essayez pas de faire toute l'analyse par vous-même.

Cela peut être aussi simple qu'obtenir une liste des données du CERT (note du traducteur : Computer Emergency Response Team - Équipe d'Aide Informatique Urgente) concernant les technologies que vous utilisez, que ce soit l'IOS de Cisco pour votre Pix, ou simplement OpenWRT (note du traducteur : distribution Linux pour routeurs).

Et bien sûr vous ne voudrez pas y croire, mais en général il restera 8% d'experts en sécurité informatique capables de pénétrer vos systèmes, même après que vous ayez atténué tous les risques connus. C'est une vérité à prendre en compte dans votre analyse.

Focalisez-vous sur ce qui peut être protégé plutôt que sur ce que vous avez découvert.

Par exemple, vous pourriez vous apercevoir, après avoir joué avec BackTrack3 SMB4K que depuis le début votre SAMBA permettait l'échange sans-fil de fichiers à vos voisins sous Windows et que vos informations personnelles y compris vos photos étaient à la disposition de tout le monde. Fermez tout simplement la porte. La paranoïa en sécurité est optionnelle mais certainement pas recommandée.

C'est dans un plan d'action jalonné avec l'objectif d' atténuer les vulnérabilités qu'on aura la meilleure mise en forme des observations, résultats et propositions de contre mesures. Dans un environnement de production, ce plan ferait l'objet d'un dossier complet transmis aux décideurs, aux utilisateurs des équipes voisines, à toute personne concernée par le temps de disponibilité.

Intégrez OPSEC dans vos processus de décision et d'organisation dès le départ. Attendre la dernière minute avant la mise d'un produit sur le marché (ou sa récupération sur le marché) pour effectuer une estimation pourrait être trop tard et trop onéreux.

Je vous entends d'ici : « De quel service AQ (Assurance Qualité) parlez-vous? C'est nous, le service AQ, et on n'a pas le temps de scanner. ». C'est pourtant simple de lancer un Wikto/Nikto ou un scanner d'estimation sur votre application.

Vous montez un joli CMS PHP/MySQL ou n'importe quel autre portail de partage ? Vous utilisez SVN ? Figurez-vous que vous venez peut-être d'ouvrir un beau petit tunnel crypté avec entrée directe dans vos systèmes. Si vous ne vérifiez pas, vous ne le saurez pas ! Avez-vous évalué la sécurité de cette version de SugarCRM avant de la générer ? Avez-vous jeté un œil aux failles connues de cet outil open source avant de l'adopter ?

Des estimations régulières vous garantiront la meilleure protection.

Tout comme la reconstruction après une catastrophe, les estimations OPSEC de systèmes sont construites les unes sur les autres. Toute information découverte devient une ressource; les évaluations programmées et régulières continuent à la façon d'évènements coordonnés d'une équipe.

La sécurité des systèmes n'est pas un secret; OPSEC nous rappelle que les systèmes ne sont malsains dans la mesure où ils ont des secrets.