Sécurité : Microsoft encourage l’adoption de PowerShell 5

Les administrateurs le savent bien : PowerShell est un puissant outil d’administration. Mais comme FireEye l’a montré l’an passé, il peut être détourné à des fins malveillantes. Et les équipes de Microsoft en ont bien conscience.

C’est ainsi qu’elles présentent, dans un long billet de blog, les avancées qu’offrira PowerShell 5 pour détecter et combattre les menaces, avec Windows 10.

Le postulat de base est là essentiel : il s’agit d’accepter le fait d’être victime d’une intrusion. Et partant, il s’agit de pouvoir la détecter, la retracer, et enfin la combattre. Pour cela, PowerShell 5 s’appuie sur les apports de son prédécesseur : transcription, génération de logs, etc.

La transcription permet d’obtenir une trace d’actions, y compris avec la nouvelle version pour les sessions d’accès à distance. L’entête fournit également plus d’informations. Mais la transcription peut surtout être automatisée via les stratégies de groupe. Elle peut en outre appliquée en profondeur, jusqu’au bloc de script, le niveau de base d’un exécutable PowerShell, touchant à toute application hébergeant le moteur d’exécution. Un élément d’investigation précieux mais « la plupart des entreprises réalisent qu’elles doivent l’activer lorsqu’il est trop tard ». Du coup, PowerShell 5 l’active automatiquement pour les blocs « contenant des éléments souvent utilisés par les scripts malicieux ».

Surtout, PowerShell 5 dispose d’une interface permettant l’analyse de scripts par des outils de protection contre les logiciels malveillants, l’AMSI, ou Antimalware Scan Interface. Il supporte en outre le chiffrement de contenus, au format CMS, un standard de l’IETF. D’où des capacités étendues d’interopérabilité, notamment en s’appuyant sur OpenSSL.

Avec Windows 10, PowerShell promet donc de gagner en sûreté. A condition que ses capacités soient mises à profit. Et cela passe notamment par l’adoption de sa version 5. Et ce n’est pas forcément gagné.

Se référant à PowerShell 3.0, déjà plus sûr que ses prédécesseurs, Gérôme Billois, responsable de la practice sécurité de Solucom, soulignait dans nos colonnes la difficulté de son adoption, « comme avec toutes les montées de version. Ce n’est pas qu’un changement technique et cela demande de valider des scripts qui sont assez largement utilisés en production aujourd’hui. Le risque d’impact est évident. D’autant plus que, souvent, il n’y a pas de cartographie des endroits où sont utilisés les scripts ». Et il faut également tenir compte des différences de jeux de commandes accessibles d’une version de Windows à l’autre…