Cisco a fait de la chasse au plan de gestion IOS XE un test de responsabilité des périphériques réseau

Résumé

• Cisco a divulgué l'exploitation active de vulnérabilités de l'interface Web IOS XE en 2023, et la CISA a exhorté les organisations à désactiver les interfaces de gestion exposées, à rechercher des activités malveillantes et à mettre à niveau vers des versions corrigées.
• Qui avait le contrôle pratique sur la gestion Web exposée à Internet, l'état du serveur HTTP, la sélection des versions corrigées, les nouveaux utilisateurs créés, la chasse aux implants, la récupération de configuration et la preuve qu'un périphérique réseau était digne de confiance après exploitation?
• Le problème de responsabilité est qu'un routeur ou un commutateur peut continuer à transmettre du trafic après une compromission, donc la récupération ne peut pas s'arrêter aux numéros de version; elle doit prouver que le plan de gestion, les utilisateurs, la configuration et l'image du périphérique sont dignes de confiance.
• Les opérateurs réseau, les agences publiques, les entreprises, les équipes d'intervention, les acheteurs d'équipement et les clients en amont avaient besoin de preuves que le risque de gestion exposée a été traité et récupéré plutôt que simplement corrigé.
• L'article conserve les déclarations de l'entreprise, les enregistrements gouvernementaux ou réglementaires, les recherches en sécurité, les documents juridiques et les directives de normalisation dans des voies de preuve distinctes afin que le dossier public ne surestime pas ce qui est connu.

Pourquoi ce cas appartient à un dossier de risque et de responsabilité

Cisco a fait de la chasse au plan de gestion IOS XE un test de responsabilité des périphériques réseau car l'incident visible n'est que la surface d'une question institutionnelle plus profonde. Cisco a divulgué l'exploitation active de vulnérabilités de l'interface Web IOS XE en 2023, et la CISA a exhorté les organisations à désactiver les interfaces de gestion exposées, à rechercher des activités malveillantes et à mettre à niveau vers des versions corrigées.

Ce déclencheur a créé un schéma public familier: une entreprise ou un organisme public a dû publier rapidement un communiqué, les équipes techniques ont dû travailler à partir de preuves incomplètes, les personnes concernées ont dû décider quoi faire, et les observateurs extérieurs ont dû séparer la confiance de la preuve. Le risque n'était pas seulement la compromission ou la perturbation initiale. C'était la possibilité que chaque public reçoive un récit différent du contrôle pratique.

Pour Cisco Systems, Inc., la question porte sur l'interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, la création de comptes privilégiés, l'écriture d'implants, l'exposition du serveur HTTP, les directives de la CISA, les versions corrigées et les preuves de récupération post-exploitation. Ce sont des noms opérationnels, mais ce sont aussi des noms de gouvernance. Ils nomment qui aurait pu empêcher l'événement, qui aurait pu limiter son rayon d'impact, qui aurait pu rendre l'événement plus facile à détecter, et qui aurait pu rendre la réparation visible pour ceux qui en dépendaient.

Un dossier de responsabilité mature ne se satisfait pas d'une déclaration selon laquelle une enquête a été menée ou que les systèmes ont été restaurés. Il demande quelles preuves ont rendu cette déclaration vraie, quelles preuves sont restées incomplètes et qui a dû agir avant que ces preuves ne soient disponibles.

La question centrale est donc directe: Qui avait le contrôle pratique sur la gestion Web exposée à Internet, l'état du serveur HTTP, la sélection des versions corrigées, les nouveaux utilisateurs créés, la chasse aux implants, la récupération de configuration et la preuve qu'un périphérique réseau était digne de confiance après exploitation? Une réponse publique ne devrait pas obliger les lecteurs à déduire des contrôles privés à partir d'un langage d'incident poli. Elle devrait identifier le point de contrôle, la source de preuve, le public affecté et l'incertitude restante. Cette structure protège à la fois l'organisation et le public.

Elle empêche les spéculations de combler les lacunes qui auraient pu être décrites honnêtement, et elle empêche les assurances générales d'être traitées comme des preuves d'une réparation spécifique.

Le premier devoir de preuve est le contrôle, pas le blâme

Le premier devoir de preuve est le contrôle, pas le blâme pour Cisco Systems, Inc. car le problème de responsabilité est qu'un routeur ou un commutateur peut continuer à transmettre du trafic après une compromission, donc la récupération ne peut pas s'arrêter aux numéros de version; elle doit prouver que le plan de gestion, les utilisateurs, la configuration et l'image du périphérique sont dignes de confiance. Un examen faible commencerait par le nom le plus dramatique de l'incident, puis demanderait qui peut être blâmé. Un examen utile commence plus tôt.

Il demande qui possédait la surface de contrôle pratique avant que l'événement ne soit visible, qui pouvait voir le signal faible pendant qu'il était encore exploitable, et qui avait l'autorité de modifier la condition qui rendait le signal important. Dans ce cas, cette surface de contrôle comprend l'interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, la création de comptes privilégiés, l'écriture d'implants, l'exposition du serveur HTTP, les directives de la CISA, les versions corrigées et les preuves de récupération post-exploitation. Ces éléments ne sont pas une liste décorative.

Ce sont les endroits où la responsabilité devient soit observable, soit se dissout dans la mémoire institutionnelle.

Le dossier public autour de l'exploitation de l'interface Web IOS XE, de la création de comptes privilégiés, de la récupération d'implants, de l'interface de gestion exposée et du dossier de responsabilité des périphériques réseau montre également pourquoi le même incident peut être mal interprété par différents publics. Un client veut savoir s'il doit faire pivoter les informations d'identification, avertir les utilisateurs, reconstruire un périphérique, appeler un régulateur, arrêter un flux de travail ou accepter une incertitude résiduelle.

Un conseil d'administration veut savoir si la direction disposait de suffisamment de preuves pour faire ces choix lorsque l'événement évoluait. Un régulateur veut les dates, les catégories, les populations affectées et les devoirs. Un fournisseur veut distinguer le contrôle de sa propre plateforme, produit ou service de la configuration du client. Aucune de ces questions n'est illégitime. Le problème de responsabilité apparaît lorsque chaque public reçoit un fragment différent du dossier et que personne ne peut voir comment les fragments s'assemblent.

Une limite de source pour cette section esthttps://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z. Elle est utile pour le dossier de preuves public, mais elle ne peut pas répondre à toutes les questions internes de propriété. Le but n'est pas de gonfler la source. Le but est de dire ce qu'elle peut prouver, ce qu'elle ne peut que contextualiser et ce qui reste en dehors du dossier public. Cette discipline est particulièrement importante lorsque la copie publique utilise des expressions telles que incident, compromission, accès, affecté, restauré, sécurisé ou corrigé. Ces mots peuvent être précis et encore trop vagues pour soutenir une décision à moins qu'ils ne soient liés à des dates, des systèmes, des personnes, des publics affectés et des exceptions restantes.

Un dossier plus solide relierait donc des propriétaires nommés, des preuves datées, un langage destiné aux clients et des journaux techniques. Il montrerait quand l'organisation est passée du soupçon à la confirmation, quand elle a averti les parties affectées, quand elle a modifié le contrôle pertinent et quand elle a pu prouver que le changement avait atteint l'environnement affecté. Il préserverait également les contre-preuves. Si un fournisseur dit que l'environnement produit n'a pas été affecté, l'examen devrait expliquer la preuve de cette limite.

Si une entreprise dit que seuls certains domaines ont été impliqués, l'examen devrait expliquer comment cette portée a été établie. Si une agence publique dit que le service s'est poursuivi, l'examen devrait encore demander quelles solutions de contournement manuelles ont été créées et comment elles ont été réconciliées plus tard.

Cet article traite les déclarations de l'entreprise comme des preuves de ce que l'entreprise a dit et rapporté, pas comme des preuves indépendantes de chaque fait médico-légal privé. Une deuxième limite de source esthttps://www.cisa.gov/guidance-addressing-cisco-ios-xe-web-ui-vulnerabilities. Lues ensemble, les sources soutiennent un style d'examen responsable: pas un verdict, pas une assurance marketing, et pas une reconstruction médico-légale que le dossier public ne permet pas, mais une carte de ce qu'un lecteur peut savoir de manière responsable. C'est pourquoi cet article revient sans cesse au contrôle pratique. La responsabilité n'est pas la même chose que l'omniscience. C'est l'obligation de dire quelle preuve a changé quelle décision, qui avait le pouvoir de modifier le contrôle pertinent et quelles personnes ont supporté le coût pendant que l'institution rassemblait encore des preuves.

Le dossier de preuves doit correspondre à la surface opérationnelle

Le dossier de preuves doit correspondre à la surface opérationnelle pour Cisco Systems, Inc. car le problème de responsabilité est qu'un routeur ou un commutateur peut continuer à transmettre du trafic après une compromission, donc la récupération ne peut pas s'arrêter aux numéros de version; elle doit prouver que le plan de gestion, les utilisateurs, la configuration et l'image du périphérique sont dignes de confiance. Un examen faible commencerait par le nom le plus dramatique de l'incident, puis demanderait qui peut être blâmé. Un examen utile commence plus tôt.

Il demande qui possédait la surface de contrôle pratique avant que l'événement ne soit visible, qui pouvait voir le signal faible pendant qu'il était encore exploitable, et qui avait l'autorité de modifier la condition qui rendait le signal important. Dans ce cas, cette surface de contrôle comprend l'interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, la création de comptes privilégiés, l'écriture d'implants, l'exposition du serveur HTTP, les directives de la CISA, les versions corrigées et les preuves de récupération post-exploitation. Ces éléments ne sont pas une liste décorative.

Ce sont les endroits où la responsabilité devient soit observable, soit se dissout dans la mémoire institutionnelle.

Le dossier public autour de l'exploitation de l'interface Web IOS XE, de la création de comptes privilégiés, de la récupération d'implants, de l'interface de gestion exposée et du dossier de responsabilité des périphériques réseau montre également pourquoi le même incident peut être mal interprété par différents publics. Un client veut savoir s'il doit faire pivoter les informations d'identification, avertir les utilisateurs, reconstruire un périphérique, appeler un régulateur, arrêter un flux de travail ou accepter une incertitude résiduelle.

Un conseil d'administration veut savoir si la direction disposait de suffisamment de preuves pour faire ces choix lorsque l'événement évoluait. Un régulateur veut les dates, les catégories, les populations affectées et les devoirs. Un fournisseur veut distinguer le contrôle de sa propre plateforme, produit ou service de la configuration du client. Aucune de ces questions n'est illégitime. Le problème de responsabilité apparaît lorsque chaque public reçoit un fragment différent du dossier et que personne ne peut voir comment les fragments s'assemblent.

Une limite de source pour cette section esthttps://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/. Elle est utile pour le dossier de preuves public, mais elle ne peut pas répondre à toutes les questions internes de propriété. Le but n'est pas de gonfler la source. Le but est de dire ce qu'elle peut prouver, ce qu'elle ne peut que contextualiser et ce qui reste en dehors du dossier public. Cette discipline est particulièrement importante lorsque la copie publique utilise des expressions telles que incident, compromission, accès, affecté, restauré, sécurisé ou corrigé. Ces mots peuvent être précis et encore trop vagues pour soutenir une décision à moins qu'ils ne soient liés à des dates, des systèmes, des personnes, des publics affectés et des exceptions restantes.

Un dossier plus solide relierait donc des preuves datées, un langage destiné aux clients, des journaux techniques et une visibilité du conseil d'administration. Il montrerait quand l'organisation est passée du soupçon à la confirmation, quand elle a averti les parties affectées, quand elle a modifié le contrôle pertinent et quand elle a pu prouver que le changement avait atteint l'environnement affecté. Il préserverait également les contre-preuves. Si un fournisseur dit que l'environnement produit n'a pas été affecté, l'examen devrait expliquer la preuve de cette limite.

Si une entreprise dit que seuls certains domaines ont été impliqués, l'examen devrait expliquer comment cette portée a été établie. Si une agence publique dit que le service s'est poursuivi, l'examen devrait encore demander quelles solutions de contournement manuelles ont été créées et comment elles ont été réconciliées plus tard.

Les enregistrements gouvernementaux et réglementaires sont utilisés pour les devoirs publics, les avis et les classes de contrôle, mais ils ne sont pas traités comme des reconstructions techniques victime par victime. Une deuxième limite de source esthttps://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xe-dublin-17121/221128-software-fix-availability-for-cisco-ios.html. Lues ensemble, les sources soutiennent un style d'examen responsable: pas un verdict, pas une assurance marketing, et pas une reconstruction médico-légale que le dossier public ne permet pas, mais une carte de ce qu'un lecteur peut savoir de manière responsable. C'est pourquoi cet article revient sans cesse au contrôle pratique. La responsabilité n'est pas la même chose que l'omniscience. C'est l'obligation de dire quelle preuve a changé quelle décision, qui avait le pouvoir de modifier le contrôle pertinent et quelles personnes ont supporté le coût pendant que l'institution rassemblait encore des preuves.

L'action du client n'est juste que lorsque les preuves du fournisseur sont utilisables

L'action du client n'est juste que lorsque les preuves du fournisseur sont utilisables pour Cisco Systems, Inc. car le problème de responsabilité est qu'un routeur ou un commutateur peut continuer à transmettre du trafic après une compromission, donc la récupération ne peut pas s'arrêter aux numéros de version; elle doit prouver que le plan de gestion, les utilisateurs, la configuration et l'image du périphérique sont dignes de confiance. Un examen faible commencerait par le nom le plus dramatique de l'incident, puis demanderait qui peut être blâmé. Un examen utile commence plus tôt.

Il demande qui possédait la surface de contrôle pratique avant que l'événement ne soit visible, qui pouvait voir le signal faible pendant qu'il était encore exploitable, et qui avait l'autorité de modifier la condition qui rendait le signal important. Dans ce cas, cette surface de contrôle comprend l'interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, la création de comptes privilégiés, l'écriture d'implants, l'exposition du serveur HTTP, les directives de la CISA, les versions corrigées et les preuves de récupération post-exploitation. Ces éléments ne sont pas une liste décorative.

Ce sont les endroits où la responsabilité devient soit observable, soit se dissout dans la mémoire institutionnelle.

Le dossier public autour de l'exploitation de l'interface Web IOS XE, de la création de comptes privilégiés, de la récupération d'implants, de l'interface de gestion exposée et du dossier de responsabilité des périphériques réseau montre également pourquoi le même incident peut être mal interprété par différents publics. Un client veut savoir s'il doit faire pivoter les informations d'identification, avertir les utilisateurs, reconstruire un périphérique, appeler un régulateur, arrêter un flux de travail ou accepter une incertitude résiduelle.

Un conseil d'administration veut savoir si la direction disposait de suffisamment de preuves pour faire ces choix lorsque l'événement évoluait. Un régulateur veut les dates, les catégories, les populations affectées et les devoirs. Un fournisseur veut distinguer le contrôle de sa propre plateforme, produit ou service de la configuration du client. Aucune de ces questions n'est illégitime. Le problème de responsabilité apparaît lorsque chaque public reçoit un fragment différent du dossier et que personne ne peut voir comment les fragments s'assemblent.

Une limite de source pour cette section esthttps://sec.cloudapps.cisco.com/security/center/softwarechecker.x. Elle est utile pour le dossier de preuves public, mais elle ne peut pas répondre à toutes les questions internes de propriété. Le but n'est pas de gonfler la source. Le but est de dire ce qu'elle peut prouver, ce qu'elle ne peut que contextualiser et ce qui reste en dehors du dossier public. Cette discipline est particulièrement importante lorsque la copie publique utilise des expressions telles que incident, compromission, accès, affecté, restauré, sécurisé ou corrigé. Ces mots peuvent être précis et encore trop vagues pour soutenir une décision à moins qu'ils ne soient liés à des dates, des systèmes, des personnes, des publics affectés et des exceptions restantes.

Un dossier plus solide relierait donc un langage destiné aux clients, des journaux techniques, une visibilité du conseil d'administration et des jalons de correction. Il montrerait quand l'organisation est passée du soupçon à la confirmation, quand elle a averti les parties affectées, quand elle a modifié le contrôle pertinent et quand elle a pu prouver que le changement avait atteint l'environnement affecté. Il préserverait également les contre-preuves. Si un fournisseur dit que l'environnement produit n'a pas été affecté, l'examen devrait expliquer la preuve de cette limite.

Si une entreprise dit que seuls certains domaines ont été impliqués, l'examen devrait expliquer comment cette portée a été établie. Si une agence publique dit que le service s'est poursuivi, l'examen devrait encore demander quelles solutions de contournement manuelles ont été créées et comment elles ont été réconciliées plus tard.

L'analyse du fournisseur de sécurité est utilisée pour les techniques observées, les conseils aux défenseurs et la chronologie, mais l'article ne transforme pas le langage général de la campagne en une affirmation concernant chaque client ou installation. Une deuxième limite de source esthttps://sec.cloudapps.cisco.com/security/center/resources/IOS_XE_hardening. Lues ensemble, les sources soutiennent un style d'examen responsable: pas un verdict, pas une assurance marketing, et pas une reconstruction médico-légale que le dossier public ne permet pas, mais une carte de ce qu'un lecteur peut savoir de manière responsable. C'est pourquoi cet article revient sans cesse au contrôle pratique. La responsabilité n'est pas la même chose que l'omniscience. C'est l'obligation de dire quelle preuve a changé quelle décision, qui avait le pouvoir de modifier le contrôle pertinent et quelles personnes ont supporté le coût pendant que l'institution rassemblait encore des preuves.

Un examen fiable sépare ce qui était connu de ce qui était déduit

Un examen fiable sépare ce qui était connu de ce qui était déduit pour Cisco Systems, Inc. car le problème de responsabilité est qu'un routeur ou un commutateur peut continuer à transmettre du trafic après une compromission, donc la récupération ne peut pas s'arrêter aux numéros de version; elle doit prouver que le plan de gestion, les utilisateurs, la configuration et l'image du périphérique sont dignes de confiance. Un examen faible commencerait par le nom le plus dramatique de l'incident, puis demanderait qui peut être blâmé. Un examen utile commence plus tôt.

Il demande qui possédait la surface de contrôle pratique avant que l'événement ne soit visible, qui pouvait voir le signal faible pendant qu'il était encore exploitable, et qui avait l'autorité de modifier la condition qui rendait le signal important. Dans ce cas, cette surface de contrôle comprend l'interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, la création de comptes privilégiés, l'écriture d'implants, l'exposition du serveur HTTP, les directives de la CISA, les versions corrigées et les preuves de récupération post-exploitation. Ces éléments ne sont pas une liste décorative.

Ce sont les endroits où la responsabilité devient soit observable, soit se dissout dans la mémoire institutionnelle.

Le dossier public autour de l'exploitation de l'interface Web IOS XE, de la création de comptes privilégiés, de la récupération d'implants, de l'interface de gestion exposée et du dossier de responsabilité des périphériques réseau montre également pourquoi le même incident peut être mal interprété par différents publics. Un client veut savoir s'il doit faire pivoter les informations d'identification, avertir les utilisateurs, reconstruire un périphérique, appeler un régulateur, arrêter un flux de travail ou accepter une incertitude résiduelle.

Un conseil d'administration veut savoir si la direction disposait de suffisamment de preuves pour faire ces choix lorsque l'événement évoluait. Un régulateur veut les dates, les catégories, les populations affectées et les devoirs. Un fournisseur veut distinguer le contrôle de sa propre plateforme, produit ou service de la configuration du client. Aucune de ces questions n'est illégitime. Le problème de responsabilité apparaît lorsque chaque public reçoit un fragment différent du dossier et que personne ne peut voir comment les fragments s'assemblent.

Une limite de source pour cette section esthttps://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html. Elle est utile pour le dossier de preuves public, mais elle ne peut pas répondre à toutes les questions internes de propriété. Le but n'est pas de gonfler la source. Le but est de dire ce qu'elle peut prouver, ce qu'elle ne peut que contextualiser et ce qui reste en dehors du dossier public. Cette discipline est particulièrement importante lorsque la copie publique utilise des expressions telles que incident, compromission, accès, affecté, restauré, sécurisé ou corrigé. Ces mots peuvent être précis et encore trop vagues pour soutenir une décision à moins qu'ils ne soient liés à des dates, des systèmes, des personnes, des publics affectés et des exceptions restantes.

Un dossier plus solide relierait donc des journaux techniques, une visibilité du conseil d'administration, des jalons de correction et la gestion des exceptions. Il montrerait quand l'organisation est passée du soupçon à la confirmation, quand elle a averti les parties affectées, quand elle a modifié le contrôle pertinent et quand elle a pu prouver que le changement avait atteint l'environnement affecté. Il préserverait également les contre-preuves. Si un fournisseur dit que l'environnement produit n'a pas été affecté, l'examen devrait expliquer la preuve de cette limite.

Si une entreprise dit que seuls certains domaines ont été impliqués, l'examen devrait expliquer comment cette portée a été établie. Si une agence publique dit que le service s'est poursuivi, l'examen devrait encore demander quelles solutions de contournement manuelles ont été créées et comment elles ont été réconciliées plus tard.

La documentation actuelle du produit est utile pour la conception du contrôle présent et le vocabulaire du lecteur, pas comme preuve qu'une fonctionnalité a été déployée de la même manière pendant la fenêtre d'incident. Une deuxième limite de source esthttps://nvd.nist.gov/vuln/detail/CVE-2023-20198. Lues ensemble, les sources soutiennent un style d'examen responsable: pas un verdict, pas une assurance marketing, et pas une reconstruction médico-légale que le dossier public ne permet pas, mais une carte de ce qu'un lecteur peut savoir de manière responsable. C'est pourquoi cet article revient sans cesse au contrôle pratique. La responsabilité n'est pas la même chose que l'omniscience. C'est l'obligation de dire quelle preuve a changé quelle décision, qui avait le pouvoir de modifier le contrôle pertinent et quelles personnes ont supporté le coût pendant que l'institution rassemblait encore des preuves.

La réparation doit être mesurable après l'annonce

La réparation doit être mesurable après l'annonce pour Cisco Systems, Inc. car le problème de responsabilité est qu'un routeur ou un commutateur peut continuer à transmettre du trafic après une compromission, donc la récupération ne peut pas s'arrêter aux numéros de version; elle doit prouver que le plan de gestion, les utilisateurs, la configuration et l'image du périphérique sont dignes de confiance. Un examen faible commencerait par le nom le plus dramatique de l'incident, puis demanderait qui peut être blâmé. Un examen utile commence plus tôt.

Il demande qui possédait la surface de contrôle pratique avant que l'événement ne soit visible, qui pouvait voir le signal faible pendant qu'il était encore exploitable, et qui avait l'autorité de modifier la condition qui rendait le signal important. Dans ce cas, cette surface de contrôle comprend l'interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, la création de comptes privilégiés, l'écriture d'implants, l'exposition du serveur HTTP, les directives de la CISA, les versions corrigées et les preuves de récupération post-exploitation. Ces éléments ne sont pas une liste décorative.

Ce sont les endroits où la responsabilité devient soit observable, soit se dissout dans la mémoire institutionnelle.

Le dossier public autour de l'exploitation de l'interface Web IOS XE, de la création de comptes privilégiés, de la récupération d'implants, de l'interface de gestion exposée et du dossier de responsabilité des périphériques réseau montre également pourquoi le même incident peut être mal interprété par différents publics. Un client veut savoir s'il doit faire pivoter les informations d'identification, avertir les utilisateurs, reconstruire un périphérique, appeler un régulateur, arrêter un flux de travail ou accepter une incertitude résiduelle.

Un conseil d'administration veut savoir si la direction disposait de suffisamment de preuves pour faire ces choix lorsque l'événement évoluait. Un régulateur veut les dates, les catégories, les populations affectées et les devoirs. Un fournisseur veut distinguer le contrôle de sa propre plateforme, produit ou service de la configuration du client. Aucune de ces questions n'est illégitime. Le problème de responsabilité apparaît lorsque chaque public reçoit un fragment différent du dossier et que personne ne peut voir comment les fragments s'assemblent.

Une limite de source pour cette section esthttps://nvd.nist.gov/vuln/detail/CVE-2023-20273. Elle est utile pour le dossier de preuves public, mais elle ne peut pas répondre à toutes les questions internes de propriété. Le but n'est pas de gonfler la source. Le but est de dire ce qu'elle peut prouver, ce qu'elle ne peut que contextualiser et ce qui reste en dehors du dossier public. Cette discipline est particulièrement importante lorsque la copie publique utilise des expressions telles que incident, compromission, accès, affecté, restauré, sécurisé ou corrigé. Ces mots peuvent être précis et encore trop vagues pour soutenir une décision à moins qu'ils ne soient liés à des dates, des systèmes, des personnes, des publics affectés et des exceptions restantes.

Un dossier plus solide relierait donc une visibilité du conseil d'administration, des jalons de correction, la gestion des exceptions et les tests post-incident. Il montrerait quand l'organisation est passée du soupçon à la confirmation, quand elle a averti les parties affectées, quand elle a modifié le contrôle pertinent et quand elle a pu prouver que le changement avait atteint l'environnement affecté. Il préserverait également les contre-preuves. Si un fournisseur dit que l'environnement produit n'a pas été affecté, l'examen devrait expliquer la preuve de cette limite.

Si une entreprise dit que seuls certains domaines ont été impliqués, l'examen devrait expliquer comment cette portée a été établie. Si une agence publique dit que le service s'est poursuivi, l'examen devrait encore demander quelles solutions de contournement manuelles ont été créées et comment elles ont été réconciliées plus tard.

Lorsque des documents juridiques ou des procédures publiques apparaissent, ils sont traités comme des enregistrements procéduraux ou de divulgation, sauf si une conclusion finale est explicite dans la source citée. Une deuxième limite de source esthttps://www.cve.org/CVERecord?id=CVE-2023-20198. Lues ensemble, les sources soutiennent un style d'examen responsable: pas un verdict, pas une assurance marketing, et pas une reconstruction médico-légale que le dossier public ne permet pas, mais une carte de ce qu'un lecteur peut savoir de manière responsable. C'est pourquoi cet article revient sans cesse au contrôle pratique. La responsabilité n'est pas la même chose que l'omniscience. C'est l'obligation de dire quelle preuve a changé quelle décision, qui avait le pouvoir de modifier le contrôle pertinent et quelles personnes ont supporté le coût pendant que l'institution rassemblait encore des preuves.

Le prochain audit devrait préserver l'incertitude au lieu de la lisser

Le prochain audit devrait préserver l'incertitude au lieu de la lisser pour Cisco Systems, Inc. car le problème de responsabilité est qu'un routeur ou un commutateur peut continuer à transmettre du trafic après une compromission, donc la récupération ne peut pas s'arrêter aux numéros de version; elle doit prouver que le plan de gestion, les utilisateurs, la configuration et l'image du périphérique sont dignes de confiance. Un examen faible commencerait par le nom le plus dramatique de l'incident, puis demanderait qui peut être blâmé. Un examen utile commence plus tôt.

Il demande qui possédait la surface de contrôle pratique avant que l'événement ne soit visible, qui pouvait voir le signal faible pendant qu'il était encore exploitable, et qui avait l'autorité de modifier la condition qui rendait le signal important. Dans ce cas, cette surface de contrôle comprend l'interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, la création de comptes privilégiés, l'écriture d'implants, l'exposition du serveur HTTP, les directives de la CISA, les versions corrigées et les preuves de récupération post-exploitation. Ces éléments ne sont pas une liste décorative.

Ce sont les endroits où la responsabilité devient soit observable, soit se dissout dans la mémoire institutionnelle.

Le dossier public autour de l'exploitation de l'interface Web IOS XE, de la création de comptes privilégiés, de la récupération d'implants, de l'interface de gestion exposée et du dossier de responsabilité des périphériques réseau montre également pourquoi le même incident peut être mal interprété par différents publics. Un client veut savoir s'il doit faire pivoter les informations d'identification, avertir les utilisateurs, reconstruire un périphérique, appeler un régulateur, arrêter un flux de travail ou accepter une incertitude résiduelle.

Un conseil d'administration veut savoir si la direction disposait de suffisamment de preuves pour faire ces choix lorsque l'événement évoluait. Un régulateur veut les dates, les catégories, les populations affectées et les devoirs. Un fournisseur veut distinguer le contrôle de sa propre plateforme, produit ou service de la configuration du client. Aucune de ces questions n'est illégitime. Le problème de responsabilité apparaît lorsque chaque public reçoit un fragment différent du dossier et que personne ne peut voir comment les fragments s'assemblent.

Une limite de source pour cette section esthttps://www.cve.org/CVERecord?id=CVE-2023-20273. Elle est utile pour le dossier de preuves public, mais elle ne peut pas répondre à toutes les questions internes de propriété. Le but n'est pas de gonfler la source. Le but est de dire ce qu'elle peut prouver, ce qu'elle ne peut que contextualiser et ce qui reste en dehors du dossier public. Cette discipline est particulièrement importante lorsque la copie publique utilise des expressions telles que incident, compromission, accès, affecté, restauré, sécurisé ou corrigé. Ces mots peuvent être précis et encore trop vagues pour soutenir une décision à moins qu'ils ne soient liés à des dates, des systèmes, des personnes, des publics affectés et des exceptions restantes.

Un dossier plus solide relierait donc des jalons de correction, la gestion des exceptions, les tests post-incident et la cartographie des publics affectés. Il montrerait quand l'organisation est passée du soupçon à la confirmation, quand elle a averti les parties affectées, quand elle a modifié le contrôle pertinent et quand elle a pu prouver que le changement avait atteint l'environnement affecté. Il préserverait également les contre-preuves. Si un fournisseur dit que l'environnement produit n'a pas été affecté, l'examen devrait expliquer la preuve de cette limite.

Si une entreprise dit que seuls certains domaines ont été impliqués, l'examen devrait expliquer comment cette portée a été établie. Si une agence publique dit que le service s'est poursuivi, l'examen devrait encore demander quelles solutions de contournement manuelles ont été créées et comment elles ont été réconciliées plus tard.

L'article préserve les questions non résolues car les questions non résolues font partie du dossier de responsabilité plutôt qu'un défaut d'écriture à cacher. Une deuxième limite de source esthttps://www.cisa.gov/known-exploited-vulnerabilities-catalog. Lues ensemble, les sources soutiennent un style d'examen responsable: pas un verdict, pas une assurance marketing, et pas une reconstruction médico-légale que le dossier public ne permet pas, mais une carte de ce qu'un lecteur peut savoir de manière responsable. C'est pourquoi cet article revient sans cesse au contrôle pratique. La responsabilité n'est pas la même chose que l'omniscience. C'est l'obligation de dire quelle preuve a changé quelle décision, qui avait le pouvoir de modifier le contrôle pertinent et quelles personnes ont supporté le coût pendant que l'institution rassemblait encore des preuves.

À quoi ressemblerait une meilleure preuve

Une conception de preuve publique plus solide pour Cisco Systems, Inc. maintiendrait trois fichiers alignés. Le premier fichier serait le journal des décisions: qui a modifié un contrôle, qui a approuvé une déclaration publique, qui a accepté une exception et qui a reçu l'avertissement. Le second serait le fichier de preuve technique: horodatages, systèmes affectés, identités pertinentes, catégories de données exposées, vérifications de récupération et les tests qui ont montré si la réparation a atteint l'environnement dont les lecteurs dépendent réellement.

Le troisième serait le fichier du lecteur: un compte rendu simple de ce que les personnes concernées devraient faire, de ce que l'organisation a déjà fait pour elles, de ce qu'elle ne peut pas encore prouver et de quand la prochaine mise à jour réduira l'incertitude.

Cette conception est importante car la responsabilité se dégrade lorsque ces fichiers divergent. Un avis techniquement précis peut encore laisser les clients incapables d'agir. Un avis juridique prudent peut encore omettre les preuves opérationnelles dont les équipes de sécurité ont besoin. Une déclaration de restauration confiante peut encore cacher des solutions de contournement manuelles qui n'ont jamais été réconciliées. La norme d'examen devrait donc demander si le dossier public relie le contrôle, la preuve et la conséquence dans la même chronologie.

Pour cet article, la preuve requise est pratique plutôt que cérémonielle: Qui avait le contrôle pratique sur la gestion Web exposée à Internet, l'état du serveur HTTP, la sélection des versions corrigées, les nouveaux utilisateurs créés, la chasse aux implants, la récupération de configuration et la preuve qu'un périphérique réseau était digne de confiance après exploitation?

Dossier de preuves du lecteur

L'article utilise les sources publiques suivantes comme dossier de lecture pour l'exploitation de l'interface Web IOS XE, la création de comptes privilégiés, la récupération d'implants, l'interface de gestion exposée et le dossier de responsabilité des périphériques réseau.

Chaque source est traitée avec des limites: les déclarations de l'entreprise prouvent ce que l'entreprise a dit ou rapporté, les enregistrements gouvernementaux et réglementaires prouvent une action ou un devoir officiel, les articles techniques prouvent les mécanismes observés dans leur portée, les documents juridiques prouvent la position procédurale sauf si une conclusion finale est explicite, et les documents de normalisation fournissent des références de contrôle plutôt que des résultats rétroactifs.

1. Source publique utilisée pour le dossier de preuve:https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z
2. Source publique utilisée pour le dossier de preuve:https://www.cisa.gov/guidance-addressing-cisco-ios-xe-web-ui-vulnerabilities
3. Source publique utilisée pour le dossier de preuve:https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/
4. Source publique utilisée pour le dossier de preuve:https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xe-dublin-17121/221128-software-fix-availability-for-cisco-ios.html
5. Source publique utilisée pour le dossier de preuve:https://sec.cloudapps.cisco.com/security/center/softwarechecker.x
6. Source publique utilisée pour le dossier de preuve:https://sec.cloudapps.cisco.com/security/center/resources/IOS_XE_hardening
7. Source publique utilisée pour le dossier de preuve:https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html
8. Source publique utilisée pour le dossier de preuve:https://nvd.nist.gov/vuln/detail/CVE-2023-20198
9. Source publique utilisée pour le dossier de preuve:https://nvd.nist.gov/vuln/detail/CVE-2023-20273
10. Source publique utilisée pour le dossier de preuve:https://www.cve.org/CVERecord?id=CVE-2023-20198
11. Source publique utilisée pour le dossier de preuve:https://www.cve.org/CVERecord?id=CVE-2023-20273
12. Source publique utilisée pour le dossier de preuve:https://www.cisa.gov/known-exploited-vulnerabilities-catalog
13. Source publique utilisée pour le dossier de preuve:https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
14. Source publique utilisée pour le dossier de preuve:https://www.cisa.gov/news-events/directives/bod-23-02-mitigating-risk-internet-exposed-management-interfaces
15. Source publique utilisée pour le dossier de preuve:https://www.cisa.gov/securebydesign
16. Source publique utilisée pour le dossier de preuve:https://csrc.nist.gov/pubs/sp/800/61/r2/final
17. Source publique utilisée pour le dossier de preuve:https://csrc.nist.gov/pubs/sp/800/40/r4/final
18. Source publique utilisée pour le dossier de preuve:https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/cisco-ios-xe-software-web-ui-zero-day-vulnerability
19. Source publique utilisée pour le dossier de preuve:https://www.cyber.gc.ca/en/alerts-advisories/vulnerability-impacting-cisco-devices-cve-2023-20198

Ce dossier de preuves est délibérément plus large qu'un simple avis d'incident car l'exploitation de l'interface Web IOS XE, la création de comptes privilégiés, la récupération d'implants, l'interface de gestion exposée et le dossier de responsabilité des périphériques réseau ont affecté plus d'un public. Le dossier public doit soutenir les personnes qui ont besoin d'une action pratique, les gestionnaires qui ont besoin d'un plan de réparation, les régulateurs qui ont besoin d'une portée et les lecteurs qui ont besoin de savoir quelles affirmations restent incertaines.

Questions pour l'examen du conseil d'administration

Le dossier d'examen devrait nommer le propriétaire pratique de chaque décision, la date à laquelle la décision a été prise, la preuve utilisée et le public qui en dépendait. Sans cette structure, le même incident peut être raconté plus tard comme une panne technique, un différend juridique, un problème de service client ou un problème financier sans base stable pour décider quel compte est complet.

Un dossier de responsabilité utile préserve également l'incertitude. Il devrait dire ce qui est connu des déclarations de l'entreprise, ce qui est connu des enregistrements gouvernementaux ou judiciaires, ce qui est connu des intervenants externes en incident et ce qui reste déduit. Cette séparation protège les lecteurs d'une fausse précision et protège l'organisation de traiter une confiance précoce comme une preuve.

Le contrôle important n'est pas une réponse héroïque après coup. C'est la capacité de montrer, pendant que l'événement est encore en mouvement, quelle preuve changerait une décision. Si un avis client, un rapport au conseil, une réclamation d'assurance, une mise à jour réglementaire ou un message de service public serait différent après un examen de journal supplémentaire, cette dépendance devrait être visible dans le dossier.

Pour ce cas spécifique, un examen du conseil d'administration devrait demander qui avait le contrôle pratique sur la gestion Web exposée à Internet, l'état du serveur HTTP, la sélection des versions corrigées, les nouveaux utilisateurs créés, la chasse aux implants, la récupération de configuration et la preuve qu'un périphérique réseau était digne de confiance après exploitation? La réponse ne devrait pas être un simple récit.

Elle devrait inclure des preuves datées, des propriétaires nommés, des publics affectés, des engagements clients et une liste de faits que l'organisation ne pouvait toujours pas prouver lorsque le dossier public a été constitué.