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.
Serviços em Nuvem da América do Norte
A oferta da Proofpoint pela Varonis testará a ligação entre ameaças e acesso a dados
Um alerta só vira proteção efetiva quando a equipe consegue relacionar quem agiu, quais dados estavam ao alcance, que permissão tornou a ação possível e se a resposta realmente reduziu a exposição. A Proofpoint diz que a compra da Varonis pode aproximar essas peças. O negócio…
Reportagens
No FIRST junto à LACNIC 46, CEDIA deixa decisões críticas com pessoas
Uma sessão de 21 de outubro vai apresentar a triagem e a correlação de sinais do DALIA com apoio de IA, mas manter decisões críticas e contenção sob responsabilidade humana. O resumo ainda não explica como esse limite funciona.
IETF
O filtro encontrou a palavra. Não provou o que o remetente disse.
Uma correspondência pode nascer do texto visível, de uma fronteira MIME, de uma sequência ainda codificada ou de um OCR que outro servidor nem possui. O RFC 5173 define essas superfícies separadamente. O erro operacional começa quando o resultado booleano é promovido a…
IETF
O token filho era válido. A cadeia ainda precisava autorizá-lo.
Uma cadeia de delegação pode retirar o servidor de autorização de cada salto sem retirar a necessidade de autoridade. A proposta OAuth só funciona se toda chave, toda restrição e toda decisão local continuar verificável da raiz até o efeito.
IETF
O fabricante assinou as novas raízes. O servidor de entrega continuou sem autenticação.
Uma assinatura instalada de fábrica pode autorizar um pacote de CAs operacionais mesmo quando o dispositivo ainda não reconhece o servidor que o entrega. A solução só permanece segura se objeto, transporte, política local, nova sessão, emissão e resultado nunca forem reduzidos a…
IETF
A data parecia óbvia. A biblioteca ainda era parte da decisão.
Uma equipe lê um literal de data ou endereço e aprova o arquivo porque a intenção está clara. Só depois descobre que homologação e produção carregavam bibliotecas de extensão diferentes. O texto era idêntico; a revisão humana também. O que faltou no pacote de aprovação foi a…
IETF
O formato recusou a frase “urgente”. A urgência continuou fora dele
DUJ não aceita que um serviço esconda uma mensagem persuasiva ao lado da alteração DNS. Essa escolha protege a estrutura contra um tipo de pressão, mas não elimina a pressão da página, do e-mail ou da relação comercial. A decisão ainda precisa de contexto, autoridade e prova do…
IETF
A chave passou na validação; a relação comercial ainda precisava aprová-la
Uma equipe pode instalar um certificado novo, completar o handshake, validar a assinatura e receber um MDN perfeito. Ainda assim, se não houver registro de quem vinculou aquela chave ao parceiro certo, a operação terá comprovado a matemática antes de comprovar o mandato.
Arquivo de Caso
O inventário contou oito algoritmos. A operação ainda não podia contar oito capacidades
Uma planilha de migração pós-quântica tende a transformar identificadores em ativos: 37 existe, 38 existe, e assim por diante. Em 1º de outubro de 2026, porém, a revisão 05 de um Internet-Draft OpenPGP usava 37–44 para oito composições NIST/Brainpool enquanto o registro público…
IETF
A chave ACME foi trocada. A autorização DNS de ontem continua válida
A nova revisão do desafio DNS persistente do ACME separa duas ações que muitos painéis tratam como uma só. Girar a chave encerra a assinatura antiga; não necessariamente retira a autorização que aquela chave deixou registrada no DNS.
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…