Domínio principal
Segurança
Na faceta Domínio principal, Segurança grupos de inteligência são organizados por domínio principal para que os leitores possam acompanhar uma área de foco em infraestrutura da internet, governança, mercados de conectividade ou capital digital. A página reúne artigos relacionados, evidências públicas, instituições, empresas, pessoas, exposição regional, dependências operacionais e contexto de mercado que, de outra forma, poderiam estar espalhados por páginas de categorias separadas. Ela explica o domínio, a provável classe de atores, o contexto de mercado ou de governança e o material de origem que os leitores devem usar ao comparar sinais. Operadores, analistas e leitores de governança podem ver como o mesmo domínio aparece em eventos, perfis, mudanças de mercado, evidências de fontes públicas, dependências regionais e decisões de infraestrutura de ciclos mais longos ao longo do tempo.
IETF
A prova passou. Quem responde pelo rótulo agora?
A transparência de chaves consegue demonstrar que uma resposta pertence a uma história consistente. Ela não define, sozinha, quem tinha autoridade, quem confiou no resultado e quem precisa continuar observando. A revisão mais recente do IETF levou justamente essa lacuna de papéis…
História
Quando a orientação sobrevive ao órgão que a criou: o legado do grupo grip da IETF e a BCP 21
Há quase três décadas, um pequeno grupo de trabalho da IETF definiu o que as organizações podem esperar de uma equipe de resposta a incidentes de segurança. O grupo foi encerrado em 2001, mas o documento que produziu continua sendo a prática recomendada vigente — e a…
Arquivo de Caso
O valor era o mesmo. Os bytes reconstruídos não
O assinante e o verificador registraram o mesmo mapa CBOR, com os mesmos campos e valores. Ainda assim, calcularam entradas de assinatura diferentes. Ninguém havia alterado o conteúdo: cada codificador apenas exerceu uma liberdade válida que o protocolo deixou sem responsável.
Arquivo de Caso
A prova escondia a assinatura. O pacote inteiro continuava reconhecível
Duas provas BBS chegaram com bytes independentes; nenhuma denunciava que ambas nasceram da mesma assinatura. Ainda assim, repetiam um cabeçalho raro, dez posições de mensagem, a mesma combinação de índices e uma chave usada por apenas doze titulares. A promessa criptográfica foi…
Arquivo de Caso
O DNS anunciou `co`; o DTLS ainda precisava escolhê-lo: RFC 9952
Descoberta e handshake usam a mesma etiqueta em camadas de autoridade diferentes. O DNS pode publicar `co` como uma opção de serviço. Só os dois endpoints podem transformar essa opção em oferta e seleção dentro de uma conexão DTLS concreta.
Arquivo de Caso
A cifra manteve o nome; a regra de reúso mudou: RFC 10032
Uma migração de desempenho preserva o campo “AEGIS” em todos os painéis. Mesmo assim, muda o significado operacional da saída: um caminho autentica antes de liberar, outro joga a tag fora e um terceiro admite um reúso de nonce que seria desastroso no primeiro. O nome sobreviveu à…
IETF
O 204 do IDMEFv2 confirma custódia, não resolve o alerta
O gestor pode persistir um alerta e perder a conexão antes que a resposta chegue ao analisador. A proposta HTTPS do IDMEFv2 transforma 2xx em uma confirmação relevante; cabe ao consórcio decidir se o próximo POST é repetição, correção ou conflito.
Arquivo de Caso
A assinatura era válida; os aprovadores continuavam invisíveis: RFC 9591
Quatro dispositivos colaboraram, o limite foi atingido e a assinatura passou. Meses depois, a auditoria perguntou quais quatro responsáveis participaram e qual regra cada um aplicou. A assinatura não tinha essa lista. A RFC 9591 descreve exatamente como o FROST transforma…
Arquivo de Caso
A lista dizia EdDSA, mas ainda não dizia qual curva: RFC 9864
Uma linha de metadados pode parecer uma capacidade e ainda exigir adivinhação. `EdDSA` não informa se o outro lado executa Ed25519, Ed448 ou uma interpretação local. A RFC 9864 coloca escolhas obrigatórias no identificador. Isso melhora a negociação, sem transformar o nome em…
Arquivo de Caso
O backup restaurou a chave — e também o estado de ontem: RFC 9802
Dois equipamentos podem sair da mesma cópia, possuir o segredo correto e produzir assinaturas válidas. Se ambos gastarem o mesmo índice de uso único, porém, a recuperação terá quebrado a premissa de segurança sem deixar aviso no certificado. A RFC 9802 torna HSS e XMSS…
IETF
Rascunhos sob custódia: RFC 9787 e a fronteira de compromisso criada pelo envio
Criptografar um rascunho resolve apenas parte do problema: o desafio é preservar, entre dispositivos, a diferença entre texto em elaboração, acesso do autor e compromisso efetivamente criado pelo envio.
Tendências de Serviços de Nuvem da América do Norte
PaperCut substitui correções emergenciais no fim do prazo da CISA
As novas compilações de manutenção do PaperCut oferecem aos administradores registros de versão mais claros, mas os servidores de site e secundários ainda precisam ser verificados.
Tendências de Serviços de Nuvem da América do Norte
Expira o prazo da CISA para falha explorada no ScreenConnect
A ConnectWise afirma que a falha afeta o software cliente do ScreenConnect, não os servidores, cabendo aos provedores verificar as atualizações nos endpoints sob seu suporte.
Tendências Institucionais da Europa e Oriente Médio
Notificações cibernéticas na UE começam com prazo de 24 horas
Fabricantes deverão notificar as autoridades antes de concluir a investigação e, em seguida, apresentar análises mais completas e detalhes de remediação à medida que o quadro técnico evolui.
IETF
A mensagem ganhou um selo; as partes não ganharam a mesma autoridade: RFC 9787
O leitor vê uma mensagem. O analisador vê uma árvore de objetos. O RFC 9787 permite resumir a proteção num único estado, mas somente para as camadas contíguas que cercam a carga criptográfica. O restante continua sujeito a provas próprias.
Arquivo de Caso
Cinco grafias, um objeto: quais bytes a RFC 9804 fez assinar?
A RFC 9804 organiza a passagem das S-expressions de SPKI entre notação legível, transporte seguro para o canal, bytes canônicos e memória local. Mas aparência equivalente não preserva autoridade sozinha. Para provar o que foi assinado e depois autorizado, cada mudança de…
Reportagens
A honeynet da APNIC registrou 1,27 milhão de eventos — não 1,27 milhão de ataques
Uma apresentação da APNIC 62 transforma um servidor exposto de propósito em um instrumento útil de segurança. O número principal, porém, recebe três rótulos diferentes: ataques, eventos de ataque e eventos.
IETF
A correção da renegociação TLS consertou o protocolo, não o registro de implantação
A vulnerabilidade de renegociação do TLS foi corrigida no padrão, mas a publicação da correção não demonstra que o comportamento legado desapareceu de todos os endpoints, bibliotecas, appliances e caminhos de aplicação.
IETF
O transform foi acordado. O replay ainda não tinha sido rejeitado: RFC 9827
A RFC 9827 amplia o Transform Type 5 do IKEv2 para descrever propriedades de números de sequência. O contrato alcança os pacotes de uma SA quando eles entram na rede; não comprova a coordenação do emissor, a política anti-replay do receptor, os pacotes que chegaram nem o descarte…
IETF
A linha do log foi lida. A autoridade sobre a conexão, não: RFC 9850
O RFC 9850 dá aos segredos de diagnóstico TLS uma sintaxe comum. O registro pode ser tecnicamente perfeito e, ainda assim, não provar autorização, limite de uso, cadeia de custódia ou retorno à confidencialidade.