Cisco transformou a caça ao plano de gerenciamento IOS XE em um

Resumo

A Cisco divulgou a exploração ativa de vulnerabilidades da interface Web IOS XE em 2023, e a CISA instou as organizações a desativar as interfaces de gerenciamento expostas, procurar atividades maliciosas e atualizar para versões corrigidas.
Quem tinha o controle prático sobre o gerenciamento Web exposto à Internet, o estado do servidor HTTP, a seleção de versões corrigidas, os novos usuários criados, a caça a implantes, a recuperação de configuração e a prova de que um dispositivo de rede era confiável após a exploração?
O problema de responsabilidade é que um roteador ou switch pode continuar transmitindo tráfego após um comprometimento, portanto a recuperação não pode parar nos números de versão; ela deve provar que o plano de gerenciamento, os usuários, a configuração e a imagem do dispositivo são confiáveis.
Os operadores de rede, agências públicas, empresas, equipes de resposta, compradores de equipamentos e clientes a montante precisavam de provas de que o risco do gerenciamento exposto foi tratado e recuperado, em vez de apenas corrigido.
Este artigo mantém as declarações da empresa, registros governamentais ou regulatórios, pesquisas de segurança, documentos legais e diretrizes de padronização em vias de prova separadas para que o registro público não superestime o que é conhecido.

Por que este caso pertence a um dossiê de risco e responsabilidade

A Cisco transformou a caça ao plano de gerenciamento IOS XE em um teste de responsabilidade de dispositivos de rede porque o incidente visível é apenas a superfície de uma questão institucional mais profunda. A Cisco divulgou a exploração ativa de vulnerabilidades da interface Web IOS XE em 2023, e a CISA instou as organizações a desativar as interfaces de gerenciamento expostas, procurar atividades maliciosas e atualizar para versões corrigidas.

Esse gatilho criou um padrão público familiar: uma empresa ou órgão público teve que publicar rapidamente um comunicado, as equipes técnicas tiveram que trabalhar com evidências incompletas, as pessoas afetadas tiveram que decidir o que fazer e os observadores externos tiveram que separar a confiança da prova. O risco não era apenas o comprometimento ou a perturbação inicial. Era a possibilidade de que cada público recebesse uma narrativa diferente do controle prático.

Para a Cisco Systems, Inc., a questão diz respeito à interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, criação de contas privilegiadas, escrita de implantes, exposição do servidor HTTP, diretrizes da CISA, versões corrigidas e evidências de recuperação pós-exploração. Esses são nomes operacionais, mas também são nomes de governança. Eles nomeiam quem poderia ter evitado o evento, quem poderia ter limitado seu raio de impacto, quem poderia ter tornado o evento mais fácil de detectar e quem poderia ter tornado o reparo visível para aqueles que dependiam dele.

Um dossiê de responsabilidade maduro não se contenta com uma declaração de que uma investigação foi conduzida ou que os sistemas foram restaurados. Ele pergunta quais evidências tornaram essa declaração verdadeira, quais evidências permaneceram incompletas e quem teve que agir antes que essas evidências estivessem disponíveis.

Portanto, a questão central é direta: Quem tinha o controle prático sobre o gerenciamento Web exposto à Internet, o estado do servidor HTTP, a seleção de versões corrigidas, os novos usuários criados, a caça a implantes, a recuperação de configuração e a prova de que um dispositivo de rede era confiável após a exploração? Uma resposta pública não deve obrigar os leitores a deduzir controles privados a partir de uma linguagem de incidente polida. Ela deve identificar o ponto de controle, a fonte de prova, o público afetado e a incerteza remanescente. Essa estrutura protege tanto a organização quanto o público.

Ela impede que especulações preencham lacunas que poderiam ter sido descritas honestamente, e impede que garantias gerais sejam tratadas como evidências de um reparo específico.

O primeiro dever de prova é o controle, não a culpa para a Cisco Systems, Inc. porque o problema de responsabilidade é que um roteador ou switch pode continuar transmitindo tráfego após um comprometimento, portanto a recuperação não pode parar nos números de versão; ela deve provar que o plano de gerenciamento, os usuários, a configuração e a imagem do dispositivo são confiáveis. Um exame fraco começaria pelo nome mais dramático do incidente e depois perguntaria quem é o culpado. Um exame útil começa mais cedo.

Ele pergunta quem possuía a superfície de controle prática antes que o evento se tornasse visível, quem poderia ver o sinal fraco enquanto ainda era acionável e quem tinha autoridade para modificar a condição que tornava o sinal importante. Neste caso, essa superfície de controle inclui a interface Web IOS XE, CVE-2023-20198, CVE-2023-20273, criação de contas privilegiadas, escrita de implantes, exposição do servidor HTTP, diretrizes da CISA, versões corrigidas e evidências de recuperação pós-exploração. Esses elementos não são uma lista decorativa.

São os lugares onde a responsabilidade se torna observável ou se dissolve na memória institucional.

O registro público em torno da exploração da interface Web IOS XE, da criação de contas privilegiadas, da recuperação de implantes, da interface de gerenciamento exposta e do dossiê de responsabilidade de dispositivos de rede também mostra por que o mesmo incidente pode ser mal interpretado por diferentes públicos. Um cliente quer saber se deve girar credenciais, notificar usuários, reconstruir um dispositivo, chamar um regulador, interromper um fluxo de trabalho ou aceitar incerteza residual. Um conselho de administração quer saber se a administração possuía evidências suficientes para fazer essas escolhas enquanto o evento evoluía.

Um regulador quer as datas, categorias, populações afetadas e deveres. Um fornecedor quer distinguir o controle de sua própria plataforma, produto ou serviço da configuração do cliente. Nenhuma dessas perguntas é ilegítima. O problema de responsabilidade surge quando cada público recebe um fragmento diferente do registro e ninguém consegue ver como os fragmentos se encaixam.

Um limite de fonte para esta seção éhttps://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z. Ela é útil para o registro de provas público, mas não pode responder a todas as perguntas internas de propriedade. O objetivo não é inflar a fonte. O objetivo é dizer o que ela pode provar, o que ela só pode contextualizar e o que permanece fora do registro público. Essa disciplina é particularmente importante quando a cópia pública usa expressões como incidente, comprometimento, acesso, afetado, restaurado, protegido ou corrigido. Essas palavras podem ser precisas e ainda assim vagas demais para apoiar uma decisão, a menos que estejam ligadas a datas, sistemas, pessoas, públicos afetados e exceções remanescentes.

Um registro mais sólido tenderia, portanto, a proprietários nomeados, evidências datadas, linguagem destinada aos clientes e logs técnicos. Mostraria quando a organização passou da suspeita à confirmação, quando notificou as partes afetadas, quando modificou o controle relevante e quando pôde provar que a mudança alcançou o ambiente afetado. Também preservaria as contraditas. Se um fornecedor diz que o ambiente de produção não foi afetado, o exame deve explicar a prova desse limite. Se uma empresa diz que apenas alguns domínios foram envolvidos, o exame deve explicar como esse escopo foi estabelecido.

Se uma agência pública diz que o serviço continuou, o exame deve ainda perguntar quais soluções alternativas manuais foram criadas e como foram reconciliadas posteriormente.

Este artigo trata as declarações da empresa como evidências do que a empresa disse e relatou, não como evidências independentes de cada fato forense privado. Um segundo limite de fonte éhttps://www.cisa.gov/guidance-addressing-cisco-ios-xe-web-ui-vulnerabilities. Lidas em conjunto, as fontes sustentam um estilo de exame responsável: não um veredito, não uma garantia de marketing e não uma reconstrução forense que o registro público não permite, mas um mapa do que um leitor pode saber de forma responsável. É por isso que este artigo retorna constantemente ao controle prático. Responsabilidade não é o mesmo que onisciência. É a obrigação de dizer qual prova mudou qual decisão, quem tinha o poder de modificar o controle relevante e quais pessoas arcaram com o custo enquanto a instituição ainda reunia evidências.

O registro de provas deve corresponder à superfície operacional

O registro de provas deve corresponder à superfície operacional para a Cisco Systems, Inc. porque o problema de responsabilidade é que um roteador ou switch pode continuar transmitindo tráfego após um comprometimento, portanto a recuperação não pode parar nos números de versão; ela deve provar que o plano de gerenciamento, os usuários, a configuração e a imagem do dispositivo são confiáveis. Um exame fraco começaria pelo nome mais dramático do incidente e depois perguntaria quem é o culpado. Um exame útil começa mais cedo.

São os lugares onde a responsabilidade se torna observável ou se dissolve na memória institucional.

Um limite de fonte para esta seção éhttps://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/. Ela é útil para o registro de provas público, mas não pode responder a todas as perguntas internas de propriedade. O objetivo não é inflar a fonte. O objetivo é dizer o que ela pode provar, o que ela só pode contextualizar e o que permanece fora do registro público. Essa disciplina é particularmente importante quando a cópia pública usa expressões como incidente, comprometimento, acesso, afetado, restaurado, protegido ou corrigido. Essas palavras podem ser precisas e ainda assim vagas demais para apoiar uma decisão, a menos que estejam ligadas a datas, sistemas, pessoas, públicos afetados e exceções remanescentes.

Um registro mais sólido tenderia, portanto, a evidências datadas, linguagem destinada aos clientes, logs técnicos e visibilidade do conselho. Mostraria quando a organização passou da suspeita à confirmação, quando notificou as partes afetadas, quando modificou o controle relevante e quando pôde provar que a mudança alcançou o ambiente afetado. Também preservaria as contraditas. Se um fornecedor diz que o ambiente de produção não foi afetado, o exame deve explicar a prova desse limite. Se uma empresa diz que apenas alguns domínios foram envolvidos, o exame deve explicar como esse escopo foi estabelecido.

Se uma agência pública diz que o serviço continuou, o exame deve ainda perguntar quais soluções alternativas manuais foram criadas e como foram reconciliadas posteriormente.

Os registros governamentais e regulatórios são usados para deveres públicos, avisos e classes de controle, mas não são tratados como reconstruções técnicas vítima por vítima. Um segundo limite de fonte é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. Lidas em conjunto, as fontes sustentam um estilo de exame responsável: não um veredito, não uma garantia de marketing e não uma reconstrução forense que o registro público não permite, mas um mapa do que um leitor pode saber de forma responsável. É por isso que este artigo retorna constantemente ao controle prático. Responsabilidade não é o mesmo que onisciência. É a obrigação de dizer qual prova mudou qual decisão, quem tinha o poder de modificar o controle relevante e quais pessoas arcaram com o custo enquanto a instituição ainda reunia evidências.

A ação do cliente só é justa quando as evidências do fornecedor são utilizáveis

A ação do cliente só é justa quando as evidências do fornecedor são utilizáveis para a Cisco Systems, Inc. porque o problema de responsabilidade é que um roteador ou switch pode continuar transmitindo tráfego após um comprometimento, portanto a recuperação não pode parar nos números de versão; ela deve provar que o plano de gerenciamento, os usuários, a configuração e a imagem do dispositivo são confiáveis. Um exame fraco começaria pelo nome mais dramático do incidente e depois perguntaria quem é o culpado. Um exame útil começa mais cedo.

São os lugares onde a responsabilidade se torna observável ou se dissolve na memória institucional.

Um limite de fonte para esta seção éhttps://sec.cloudapps.cisco.com/security/center/softwarechecker.x. Ela é útil para o registro de provas público, mas não pode responder a todas as perguntas internas de propriedade. O objetivo não é inflar a fonte. O objetivo é dizer o que ela pode provar, o que ela só pode contextualizar e o que permanece fora do registro público. Essa disciplina é particularmente importante quando a cópia pública usa expressões como incidente, comprometimento, acesso, afetado, restaurado, protegido ou corrigido. Essas palavras podem ser precisas e ainda assim vagas demais para apoiar uma decisão, a menos que estejam ligadas a datas, sistemas, pessoas, públicos afetados e exceções remanescentes.

Um registro mais sólido tenderia, portanto, a linguagem destinada aos clientes, logs técnicos, visibilidade do conselho e marcos de correção. Mostraria quando a organização passou da suspeita à confirmação, quando notificou as partes afetadas, quando modificou o controle relevante e quando pôde provar que a mudança alcançou o ambiente afetado. Também preservaria as contraditas. Se um fornecedor diz que o ambiente de produção não foi afetado, o exame deve explicar a prova desse limite. Se uma empresa diz que apenas alguns domínios foram envolvidos, o exame deve explicar como esse escopo foi estabelecido.

Se uma agência pública diz que o serviço continuou, o exame deve ainda perguntar quais soluções alternativas manuais foram criadas e como foram reconciliadas posteriormente.

A análise do fornecedor de segurança é usada para técnicas observadas, conselhos aos defensores e cronologia, mas o artigo não transforma a linguagem geral da campanha em uma afirmação sobre cada cliente ou instalação. Um segundo limite de fonte éhttps://sec.cloudapps.cisco.com/security/center/resources/IOS_XE_hardening. Lidas em conjunto, as fontes sustentam um estilo de exame responsável: não um veredito, não uma garantia de marketing e não uma reconstrução forense que o registro público não permite, mas um mapa do que um leitor pode saber de forma responsável. É por isso que este artigo retorna constantemente ao controle prático. Responsabilidade não é o mesmo que onisciência. É a obrigação de dizer qual prova mudou qual decisão, quem tinha o poder de modificar o controle relevante e quais pessoas arcaram com o custo enquanto a instituição ainda reunia evidências.

Um exame confiável separa o que era conhecido do que era deduzido

Um exame confiável separa o que era conhecido do que era deduzido para a Cisco Systems, Inc. porque o problema de responsabilidade é que um roteador ou switch pode continuar transmitindo tráfego após um comprometimento, portanto a recuperação não pode parar nos números de versão; ela deve provar que o plano de gerenciamento, os usuários, a configuração e a imagem do dispositivo são confiáveis. Um exame fraco começaria pelo nome mais dramático do incidente e depois perguntaria quem é o culpado. Um exame útil começa mais cedo.

São os lugares onde a responsabilidade se torna observável ou se dissolve na memória institucional.

Um limite de fonte para esta seção éhttps://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html. Ela é útil para o registro de provas público, mas não pode responder a todas as perguntas internas de propriedade. O objetivo não é inflar a fonte. O objetivo é dizer o que ela pode provar, o que ela só pode contextualizar e o que permanece fora do registro público. Essa disciplina é particularmente importante quando a cópia pública usa expressões como incidente, comprometimento, acesso, afetado, restaurado, protegido ou corrigido. Essas palavras podem ser precisas e ainda assim vagas demais para apoiar uma decisão, a menos que estejam ligadas a datas, sistemas, pessoas, públicos afetados e exceções remanescentes.

Um registro mais sólido tenderia, portanto, a logs técnicos, visibilidade do conselho, marcos de correção e gestão de exceções. Mostraria quando a organização passou da suspeita à confirmação, quando notificou as partes afetadas, quando modificou o controle relevante e quando pôde provar que a mudança alcançou o ambiente afetado. Também preservaria as contraditas. Se um fornecedor diz que o ambiente de produção não foi afetado, o exame deve explicar a prova desse limite. Se uma empresa diz que apenas alguns domínios foram envolvidos, o exame deve explicar como esse escopo foi estabelecido.

Se uma agência pública diz que o serviço continuou, o exame deve ainda perguntar quais soluções alternativas manuais foram criadas e como foram reconciliadas posteriormente.

A documentação atual do produto é útil para a concepção do controle presente e o vocabulário do leitor, não como prova de que uma funcionalidade foi implantada da mesma forma durante a janela do incidente. Um segundo limite de fonte éhttps://nvd.nist.gov/vuln/detail/CVE-2023-20198. Lidas em conjunto, as fontes sustentam um estilo de exame responsável: não um veredito, não uma garantia de marketing e não uma reconstrução forense que o registro público não permite, mas um mapa do que um leitor pode saber de forma responsável. É por isso que este artigo retorna constantemente ao controle prático. Responsabilidade não é o mesmo que onisciência. É a obrigação de dizer qual prova mudou qual decisão, quem tinha o poder de modificar o controle relevante e quais pessoas arcaram com o custo enquanto a instituição ainda reunia evidências.

O reparo deve ser mensurável após o anúncio

O reparo deve ser mensurável após o anúncio para a Cisco Systems, Inc. porque o problema de responsabilidade é que um roteador ou switch pode continuar transmitindo tráfego após um comprometimento, portanto a recuperação não pode parar nos números de versão; ela deve provar que o plano de gerenciamento, os usuários, a configuração e a imagem do dispositivo são confiáveis. Um exame fraco começaria pelo nome mais dramático do incidente e depois perguntaria quem é o culpado. Um exame útil começa mais cedo.

São os lugares onde a responsabilidade se torna observável ou se dissolve na memória institucional.

Um limite de fonte para esta seção éhttps://nvd.nist.gov/vuln/detail/CVE-2023-20273. Ela é útil para o registro de provas público, mas não pode responder a todas as perguntas internas de propriedade. O objetivo não é inflar a fonte. O objetivo é dizer o que ela pode provar, o que ela só pode contextualizar e o que permanece fora do registro público. Essa disciplina é particularmente importante quando a cópia pública usa expressões como incidente, comprometimento, acesso, afetado, restaurado, protegido ou corrigido. Essas palavras podem ser precisas e ainda assim vagas demais para apoiar uma decisão, a menos que estejam ligadas a datas, sistemas, pessoas, públicos afetados e exceções remanescentes.

Um registro mais sólido tenderia, portanto, a visibilidade do conselho, marcos de correção, gestão de exceções e testes pós-incidente. Mostraria quando a organização passou da suspeita à confirmação, quando notificou as partes afetadas, quando modificou o controle relevante e quando pôde provar que a mudança alcançou o ambiente afetado. Também preservaria as contraditas. Se um fornecedor diz que o ambiente de produção não foi afetado, o exame deve explicar a prova desse limite. Se uma empresa diz que apenas alguns domínios foram envolvidos, o exame deve explicar como esse escopo foi estabelecido.

Se uma agência pública diz que o serviço continuou, o exame deve ainda perguntar quais soluções alternativas manuais foram criadas e como foram reconciliadas posteriormente.

Quando documentos legais ou procedimentos públicos aparecem, eles são tratados como registros processuais ou de divulgação, a menos que uma conclusão final seja explícita na fonte citada. Um segundo limite de fonte éhttps://www.cve.org/CVERecord?id=CVE-2023-20198. Lidas em conjunto, as fontes sustentam um estilo de exame responsável: não um veredito, não uma garantia de marketing e não uma reconstrução forense que o registro público não permite, mas um mapa do que um leitor pode saber de forma responsável. É por isso que este artigo retorna constantemente ao controle prático. Responsabilidade não é o mesmo que onisciência. É a obrigação de dizer qual prova mudou qual decisão, quem tinha o poder de modificar o controle relevante e quais pessoas arcaram com o custo enquanto a instituição ainda reunia evidências.

O próximo exame deve preservar a incerteza em vez de alisá-la

O próximo exame deve preservar a incerteza em vez de alisá-la para a Cisco Systems, Inc. porque o problema de responsabilidade é que um roteador ou switch pode continuar transmitindo tráfego após um comprometimento, portanto a recuperação não pode parar nos números de versão; ela deve provar que o plano de gerenciamento, os usuários, a configuração e a imagem do dispositivo são confiáveis. Um exame fraco começaria pelo nome mais dramático do incidente e depois perguntaria quem é o culpado. Um exame útil começa mais cedo.

São os lugares onde a responsabilidade se torna observável ou se dissolve na memória institucional.

Um limite de fonte para esta seção éhttps://www.cve.org/CVERecord?id=CVE-2023-20273. Ela é útil para o registro de provas público, mas não pode responder a todas as perguntas internas de propriedade. O objetivo não é inflar a fonte. O objetivo é dizer o que ela pode provar, o que ela só pode contextualizar e o que permanece fora do registro público. Essa disciplina é particularmente importante quando a cópia pública usa expressões como incidente, comprometimento, acesso, afetado, restaurado, protegido ou corrigido. Essas palavras podem ser precisas e ainda assim vagas demais para apoiar uma decisão, a menos que estejam ligadas a datas, sistemas, pessoas, públicos afetados e exceções remanescentes.

Um registro mais sólido tenderia, portanto, a marcos de correção, gestão de exceções, testes pós-incidente e mapeamento de públicos afetados. Mostraria quando a organização passou da suspeita à confirmação, quando notificou as partes afetadas, quando modificou o controle relevante e quando pôde provar que a mudança alcançou o ambiente afetado. Também preservaria as contraditas. Se um fornecedor diz que o ambiente de produção não foi afetado, o exame deve explicar a prova desse limite. Se uma empresa diz que apenas alguns domínios foram envolvidos, o exame deve explicar como esse escopo foi estabelecido.

Se uma agência pública diz que o serviço continuou, o exame deve ainda perguntar quais soluções alternativas manuais foram criadas e como foram reconciliadas posteriormente.

O artigo preserva as perguntas não resolvidas porque as perguntas não resolvidas fazem parte do dossiê de responsabilidade, em vez de um defeito de escrita a ser escondido. Um segundo limite de fonte éhttps://www.cisa.gov/known-exploited-vulnerabilities-catalog. Lidas em conjunto, as fontes sustentam um estilo de exame responsável: não um veredito, não uma garantia de marketing e não uma reconstrução forense que o registro público não permite, mas um mapa do que um leitor pode saber de forma responsável. É por isso que este artigo retorna constantemente ao controle prático. Responsabilidade não é o mesmo que onisciência. É a obrigação de dizer qual prova mudou qual decisão, quem tinha o poder de modificar o controle relevante e quais pessoas arcaram com o custo enquanto a instituição ainda reunia evidências.

Com que se pareceria uma prova melhor

Uma concepção de prova pública mais sólida para a Cisco Systems, Inc. manteria três arquivos alinhados. O primeiro arquivo seria o diário de decisões: quem modificou um controle, quem aprovou uma declaração pública, quem aceitou uma exceção e quem recebeu o aviso. O segundo seria o arquivo de prova técnica: carimbos de data/hora, sistemas afetados, identidades relevantes, categorias de dados expostos, verificações de recuperação e os testes que mostraram se o reparo alcançou o ambiente do qual os leitores realmente dependem.

O terceiro seria o arquivo do leitor: um relato simples do que as pessoas afetadas devem fazer, do que a organização já fez por elas, do que ainda não pode provar e de quando a próxima atualização reduzirá a incerteza.

Essa concepção é importante porque a responsabilidade se degrada quando esses arquivos divergem. Um aviso tecnicamente preciso ainda pode deixar clientes incapazes de agir. Um aviso juridicamente prudente ainda pode omitir as provas operacionais de que as equipes de segurança precisam. Uma declaração de restauração confiante ainda pode esconder soluções alternativas manuais que nunca foram reconciliadas. A norma de exame deve, portanto, perguntar se o registro público liga o controle, a prova e a consequência na mesma cronologia.

Para este artigo, a prova exigida é prática, não cerimonial: Quem tinha o controle prático sobre o gerenciamento Web exposto à Internet, o estado do servidor HTTP, a seleção de versões corrigidas, os novos usuários criados, a caça a implantes, a recuperação de configuração e a prova de que um dispositivo de rede era confiável após a exploração?

Dossiê de provas do leitor

Este artigo utiliza as seguintes fontes públicas como dossiê de leitura para a exploração da interface Web IOS XE, criação de contas privilegiadas, recuperação de implantes, interface de gerenciamento exposta e dossiê de responsabilidade de dispositivos de rede.

Cada fonte é tratada com limites: as declarações da empresa provam o que a empresa disse ou relatou, os registros governamentais e regulatórios provam uma ação ou dever oficial, os artigos técnicos provam os mecanismos observados em seu escopo, os documentos legais provam a posição processual, a menos que uma conclusão final seja explícita, e os documentos de padronização fornecem referências de controle em vez de resultados retroativos.

Fonte pública utilizada para o dossiê de prova:https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z
Fonte pública utilizada para o dossiê de prova:https://www.cisa.gov/guidance-addressing-cisco-ios-xe-web-ui-vulnerabilities
Fonte pública utilizada para o dossiê de prova:https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/
Fonte pública utilizada para o dossiê de prova: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
Fonte pública utilizada para o dossiê de prova:https://sec.cloudapps.cisco.com/security/center/softwarechecker.x
Fonte pública utilizada para o dossiê de prova:https://sec.cloudapps.cisco.com/security/center/resources/IOS_XE_hardening
Fonte pública utilizada para o dossiê de prova:https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html
Fonte pública utilizada para o dossiê de prova:https://nvd.nist.gov/vuln/detail/CVE-2023-20198
Fonte pública utilizada para o dossiê de prova:https://nvd.nist.gov/vuln/detail/CVE-2023-20273
Fonte pública utilizada para o dossiê de prova:https://www.cve.org/CVERecord?id=CVE-2023-20198
Fonte pública utilizada para o dossiê de prova:https://www.cve.org/CVERecord?id=CVE-2023-20273
Fonte pública utilizada para o dossiê de prova:https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Fonte pública utilizada para o dossiê de prova:https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
Fonte pública utilizada para o dossiê de prova:https://www.cisa.gov/news-events/directives/bod-23-02-mitigating-risk-internet-exposed-management-interfaces
Fonte pública utilizada para o dossiê de prova:https://www.cisa.gov/securebydesign
Fonte pública utilizada para o dossiê de prova:https://csrc.nist.gov/pubs/sp/800/61/r2/final
Fonte pública utilizada para o dossiê de prova:https://csrc.nist.gov/pubs/sp/800/40/r4/final
Fonte pública utilizada para o dossiê de prova:https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/cisco-ios-xe-software-web-ui-zero-day-vulnerability
Fonte pública utilizada para o dossiê de prova:https://www.cyber.gc.ca/en/alerts-advisories/vulnerability-impacting-cisco-devices-cve-2023-20198

Este dossiê de provas é deliberadamente mais amplo do que um simples aviso de incidente, porque a exploração da interface Web IOS XE, a criação de contas privilegiadas, a recuperação de implantes, a interface de gerenciamento exposta e o dossiê de responsabilidade de dispositivos de rede afetaram mais de um público. O registro público deve apoiar as pessoas que precisam de ação prática, os gestores que precisam de um plano de reparo, os reguladores que precisam de escopo e os leitores que precisam saber quais afirmações permanecem incertas.

Perguntas para o exame do conselho

O dossiê de exame deve nomear o proprietário prático de cada decisão, a data em que a decisão foi tomada, a prova utilizada e o público que dependia dela. Sem essa estrutura, o mesmo incidente pode ser narrado posteriormente como uma falha técnica, uma disputa jurídica, um problema de atendimento ao cliente ou uma questão financeira, sem uma base estável para decidir qual relato está completo.

Um dossiê de responsabilidade útil também preserva a incerteza. Deve dizer o que é conhecido a partir das declarações da empresa, o que é conhecido a partir de registros governamentais ou judiciais, o que é conhecido a partir de respondedores externos de incidentes e o que permanece deduzido. Essa separação protege os leitores de uma falsa precisão e protege a organização de tratar a confiança precoce como prova.

O controle importante não é uma resposta heroica posterior. É a capacidade de mostrar, enquanto o evento ainda está em movimento, que prova mudaria uma decisão. Se um aviso ao cliente, um relatório ao conselho, uma reclamação de seguro, uma atualização regulatória ou uma mensagem de serviço público seriam diferentes após um exame adicional de registros, essa dependência deve ser visível no dossiê.

Para este caso específico, um exame do conselho deve perguntar quem tinha o controle prático sobre o gerenciamento Web exposto à Internet, o estado do servidor HTTP, a seleção de versões corrigidas, os novos usuários criados, a caça a implantes, a recuperação de configuração e a prova de que um dispositivo de rede era confiável após a exploração? A resposta não deve ser uma mera narrativa. Deve incluir provas datadas, proprietários nomeados, públicos afetados, compromissos com clientes e uma lista de fatos que a organização ainda não conseguia provar quando o registro público foi constituído.