
No dia 12 de maio, o governo Biden divulgou sua tão esperada “Ordem Executiva para Melhorar a Segurança Cibernética da Nação”. É tentador bocejar; afinal, toda administração na memória recente fez algo desse tipo, e nem sempre com efeito significativo. Mas esta ordem executiva merece sua atenção. Ele contém medidas concretas adaptadas para responder às lições aprendidas em crises recentes, especialmente os comprometimentos do SolarWinds e Microsoft Exchange.
Há mais trabalho a fazer? Obviamente sim. Mas, em uma extensão significativa, isso é um trabalho para o Congresso. A questão no momento é se o governo Biden, com essa ordem executiva, fez bom uso das ferramentas limitadas que controla diretamente. Como explicamos abaixo, a resposta é basicamente sim.
1. Contextualizando: O que um Presidente pode fazer com uma mera Ordem Executiva?
Vamos começar destacando um ponto crítico: o cenário da cibersegurança está se espalhando e os presidentes só podem ir até certo ponto com uma mera ordem executiva (EO). Afinal, as tais EOs não são estatutos. Como uma proposição geral, os presidentes não podem apenas fazer regras que o setor privado deva obedecer; esse é o trabalho do Congresso.
Então, para que servem as EOs? Para começar, os presidentes podem usá-los para transmitir diretrizes de política que obriguem o resto do poder executivo a tomar certas ações (desde que a própria diretriz não seja ilegal). Uma EO, portanto, pode ser usada para exigir que as entidades federais tomem ações que seriam úteis do ponto de vista da segurança cibernética. Isso pode soar sem importância, dado que a Agência de Segurança Cibernética e Infraestrutura (CISA) do Departamento de Segurança Interna (DHS) já tem autoridades legais que lhe conferem poderes para emitir diretivas vinculativas de segurança cibernética para o resto da parte civil do ramo executivo. Mas quando se trata de garantir que as agências estejam totalmente motivadas para cumprir uma diretiva, simplesmente não há substituto para o poder da caneta presidencial. Muito da nova EO é um exercício desse tipo de poder.
Na mesma linha, EOs também são úteis como um meio de expressar a vontade do presidente quando se trata de moldar os procedimentos de cooperação e coordenação entre agências. Vemos uma boa quantidade disso nas EOs também.
Os presidentes também podem insistir na inclusão de certos termos em contratos federais e podem usar EOs para colocar essas mudanças em movimento. Dependendo dos termos – e, dependendo do desejo das entidades do setor privado de competir por contratos sob essas condições – esse “poder de aquisição” pode ser uma alavanca significativa para impactar o comportamento fora do ramo executivo. Conforme ilustrado pela nova EO, o poder de aquisição não só pode ajudar o governo a se proteger, mas também pode ter benefícios indiretos para outras entidades (na medida em que as contrapartes contratuais são motivadas a alterar produtos ou serviços adquiridos por terceiros).
2. A cibersegurança é um problema generalizado. Quais partes específicas desse problema a EO pretende abordar?
A EO não visa abordar todo o panorama da cibersegurança. Em vez disso, ele se concentra em um punhado de aspectos importantes desse desafio maior, com uma ênfase clara (e esperada) naqueles que eram centrais para as bagunças causadas com o SolarWinds/Sunburst e do Microsoft Exchange. Aqui está uma visão geral resumida de quais partes do pedido cobrem quais tópicos gerais:
Estágios do ciclo de segurança cibernética e contribuições correspondentes da EO
Prevenção de intrusão
• Seção 3 (serviços em nuvem; autenticação multifator)
• Seção 4 (padrões da cadeia de suprimentos de software; transparência da “Internet das coisas” (IoT))
Minimizando o impacto da intrusão (pré-detecção)
• Seção 3 (criptografia de dados; ambiente de confiança zero)
Detectando e respondendo à intrusão
• Seção 2 (requisitos de notificação; cooperação do fornecedor habilitada / necessária)
• Seção 3 (compartilhamento de informações adicionais)
• Seção 6 (manual de resposta uniforme a incidentes)
• Seção 7 (detecção e resposta de endpoint; busca centralizada de ameaças)
• Seção 8 (requisitos de registro)
Aprendendo (e disseminando) lições de intrusão
• Seção 5 (Conselho de revisão de segurança cibernética)
Esse é o quadro geral. Mas lembre-se: a EO é amplamente focada na postura de segurança cibernética do próprio governo federal. Isso faz sentido, dados os limites do que o Presidente pode realizar unilateralmente e o papel que a SolarWinds/Sunburst – uma intrusão que penetrou profundamente nos sistemas do governo e do setor privado – desempenhou para dar origem a esse esforço.
3. Vamos aos detalhes. O que exatamente está nas seções operativas da EO?
As partes operativas da EO são as Seções 2-9. Aqui está o que você precisa saber sobre cada um.
Seção 2: Garantir que as entidades privadas que fornecem serviços de TI/TO para agências federais possam e que irão compartilhar informações sobre ameaças com a CISA, o FBI, etc.
A Seção 2 aborda um aspecto do problema de compartilhamento de informações que foi destacado – não de uma boa maneira – pela bagunça do SolarWinds/Sunburst. Muitos sistemas de informação federais são administrados ou apoiados por um provedor de serviços do setor privado. Esses arranjos às vezes são baseados em contratos escritos de forma que não exijam que o fornecedor privado compartilhe informações sobre ameaças e incidentes com outras agências federais, como a CISA ou o FBI. Alguns desses contratos podem até proibir esse compartilhamento. De qualquer forma, a experiência com SolarWinds / Sunburst demonstrou que tais complicações contratuais realmente interferem na capacidade da CISA e do FBI de obter cooperação rápida de fornecedores externos.
Se os contratos são o problema, o poder de compra é a solução. E é disso que trata a Seção 2. Ele coloca em movimento um processo de dois meses para revisar as regras de contratação conhecidas como o Regulamento de Aquisição Federal (FAR) e o Suplemento de Regulamento de Aquisição Federal de Defesa (DFARS) com um olhar para uma série de mudanças destinadas a resolver o problema mencionado. As regras de divulgação cobrem produtos de software, bem como, criticamente, qualquer “sistema de suporte para um produto ou serviço de software”. Isso cobre uma lacuna potencial de relatórios para sistemas de tecnologia centrais, como gerenciamento de identidade (os tipos de sistemas que sofreram abusos repetidamente na crise SolarWinds / Sunburst).
Eventualmente, o FAR e o DFARS obrigarão os provedores de serviço a fazer o que se resume a três coisas: Primeiro, eles terão que coletar e preservar uma ampla gama de informações (incluindo informações relacionadas à “prevenção de eventos”, não apenas resposta a incidentes). Em segundo lugar, eles terão que compartilhar essas informações com o governo quando as informações se relacionarem a um incidente (ou incidente potencial) que seja relevante para o contrato em questão. E, por fim, terão que cooperar com as entidades federais envolvidas no tratamento ou investigação de incidentes ou potenciais incidentes.
Outra parte da Seção 2 estabelece uma mudança separada no FAR que eventualmente resultará na exigência de que tais provedores também relatem afirmativa e “prontamente” incidentes de segurança cibernética envolvendo um produto ou serviço fornecido ao governo (ou os sistemas de suporte para tais serviços /produtos). Isso também reflete claramente as preocupações trazidas à luz pela experiência recente.
Embora os dados de incidentes tenham o papel principal aqui, observe que a administração parece interessada em mais do que isso. Também há linguagem sobre as informações necessárias para o governo “responder a ameaças, incidentes e riscos cibernéticos”. Isso implica em uma gama potencial muito mais ampla de dados e pode envolver empresas que vendem esse tipo de inteligência de ameaças e dados de segurança cibernética diretamente ao governo federal. Não está claro se a nova regra virá com isenções para permitir esse tipo de venda ou se será coberta por essas novas diretrizes de divulgação. Há um curinga na Seção (3) (e), além disso, com uma direção aberta ao DHS e ao Escritório de Gestão e Orçamento (OMB) para garantir que os prestadores de serviços compartilhem esses dados “na maior medida possível”. Muito do impacto prático desta seção virá na implementação dessas regras, portanto, fique atento.
Seção 3: Colocando a casa do governo em ordem (também conhecida como Nuvem, Mais Nuvem e o princípio do “Não Confie em Ninguém”)
É oficial: a nuvem chegou. Embora as políticas para incentivar e apoiar a adoção da nuvem tenham se espalhado pela tecnologia da informação federal na última década, a governança da segurança da nuvem permaneceu relativamente imatura. A “Seção 3. Modernização da segurança cibernética do governo federal” visa diretamente a este problema, cobrando da CISA o desenvolvimento de práticas e diretrizes de adoção de nuvem segura, oferecendo respostas a incidentes de nuvem para o .gov e definindo políticas sobre como as agências devem trabalhar com parceiros como a CISA e a FBI em resposta a incidentes na nuvem. De acordo com a ordem executiva, o OMB também desempenhará um papel importante, esboçando uma estratégia federal de segurança em nuvem com orientação associada para agências. O desafio para a CISA (e OMB) é que o cronograma para desenvolver essas políticas complexas é apertado, 90 dias ou menos em cada caso.
A Seção 3 também inclui um pequeno, mas significativo conjunto de ações para modernizar o FedRAMP (o principal programa de autorização de segurança do governo federal para serviços em nuvem). A linguagem parece quase tirada do manual do Provedor de Serviços em Nuvem, com ênfase em análises mais automatizadas, mais rápidas e menos duplicadas de novos serviços em nuvem. O diabo está nos detalhes (a palavra “automação” é bastante fungível), mas a inclusão de todo o ciclo do FedRAMP (incluindo monitoramento contínuo) empurra o escopo dessas mudanças em perspectiva para o ciclo de vida completo da nuvem Serviços. Mais expansiva é a possibilidade de mapear outras certificações de segurança e estruturas de conformidade para o FedRAMP, a fim de acelerar a autorização dos provedores de serviços em nuvem. Isso abre oportunidades significativas para estruturas de conformidade lideradas pelo setor, visando, por exemplo, apenas software como serviço (SaaS), a fim de suplantar processos FedRAMP de movimentação mais lenta.
Juntamente com o festival de aproximação com a nuvem, está o conceito de “Zero Trust” ou “arquitetura de confiança zero”. A confiança zero é uma coleção de conceitos de tecnologia e filosofias de design de segurança com base na suposição de que uma violação é inevitável e que, portanto, deve haver limites estritos de acesso e autorização dentro de uma rede. Nesse modelo, cada dispositivo e cada interação são presumivelmente suspeitos e devem ser examinados adequadamente, e o acesso deve ser estritamente limitado em relação a um conjunto de condições e “funções” (por exemplo, CEO, administrador do sistema e convidado). O efeito prático da confiança zero é exigir novos processos para definir e aplicar regras para quase tudo o que ocorre – desde a abertura de arquivos em uma unidade de compartilhamento até a inscrição de um novo telefone móvel para Wi-Fi. A EO enfatiza a confiança zero como um meio de garantir defesas mais robustas, mesmo quando as cadeias de suprimentos estão comprometidas ou as organizações violadas. Implementar esse tipo de filosofia de design é difícil e exige muito tempo. Não existe uma solução única para “comprar” a confiança zero no momento, pois trata-se tanto de mudar a cultura quanto o tipo de tecnologia que os usuários têm. Resta ver se um conjunto de ações nesses 60 dias poderá dar o pontapé inicial com sucesso nessa transformação.
Uma nota final sobre a Seção 3: também define um prazo de 180 dias para que todas as entidades do Poder Executivo Civil Federal (FCEB) adotem autenticação multifatorial e práticas de criptografia de dados, e eles deverão enviar relatórios de progresso à CISA (e com a ajuda da CISA) pelo caminho.
Seção 4: Levando a sério a segurança da cadeia de suprimentos de software
Se você veio pela segurança do software, pegue sua pipoca porque “Seção. 4 Melhorar a segurança da cadeia de suprimentos de software” não decepciona. Ela apresenta uma visão técnica incomum e específica em alguns locais e vai quase até o final do alfabeto para cabeçalhos de subseções. Tudo se resume a quatro grandes áreas:
- Orientação de segurança da cadeia de suprimentos de software do Instituto Nacional de Padrões e Tecnologia (informada por uma grande ênfase na segurança do ambiente de desenvolvimento e verificação de integridade / vulnerabilidade), com eventual fiscalização do OMB para garantir que as agências insistem na conformidade.
- Inclusão de um requisito de lista de materiais de software (SBOM) nessa orientação (e uma diretriz para o Departamento de Comércio (neste momento da NTIA) para produzir especificações mínimas para SBOMs).
- Uma definição (e um conjunto posterior de ações com base no) conceito de “software crítico”, incluindo a aplicação pelo OMB, juntamente com o suporte e a orientação do DHS e do NIST.
- Incentivo à segurança e rotulagem de IoT.
A orientação de segurança da cadeia de suprimentos de software principal está nas mãos do NIST, que é um personagem recorrente popular em toda a seção. Este é um território complicado para o NIST, com sede em Maryland, cuja missão geralmente segue o desenvolvimento das melhores práticas e a construção de um amplo consenso em torno de diretrizes voluntárias e publicações especiais. A segurança da cadeia de suprimentos de software tem sido um desafio para os formuladores de políticas, em parte devido à lacuna entre o desenvolvimento de software em padrões e o desenvolvimento na prática. Colocar a maior parte da responsabilidade pela segurança da cadeia de suprimentos de software em um órgão de pesquisa de padrões e tecnologia pode ser desafiador.
O desenvolvimento de software recebe muita atenção nesta seção, mas o foco está amplamente alinhado com a garantia da integridade do código na raiz da cadeia de suprimentos de software. Existem também vários requisitos para os fornecedores atestarem os padrões de desenvolvimento e segurança exigidos deles, incluindo uma divulgação pública limitada. Injetar no mercado esse tipo de informação sobre a postura de segurança do fornecedor é uma coisa boa e um sinal útil para clientes em potencial dessas empresas fora do espaço federal. E o SBOM estará finalmente pronto; mais voltado na forma de uma especificação mínima viável do Departamento de Comércio nos próximos 60 dias.
Todas essas diretrizes e práticas da cadeia de suprimentos serão aplicadas aos fornecedores de “software crítico”, um termo que a EO introduz, mas precisará do DHS, do Escritório do Diretor de Inteligência Nacional e outros para definir com precisão. As agências também terão novas restrições e orientações sobre como operam “softwares críticos”, mas não está claro como isso irá interagir com programas existentes, como o programa DHS / NIST High Value Asset (HVA).
Nos estágios posteriores da Seção 4, há uma sequência de ações sobre a segurança da cadeia de suprimentos da IoT, abordando a segurança básica e as práticas de desenvolvimento de fornecedores com informações do NIST e um programa de rotulagem apoiado pela Federal Trade Commission. Isso inclui uma grande função para o NIST identificar e ingerir todos os esquemas de rotulagem de desenvolvimento de software seguro e cibersegurança existentes e práticas recomendadas e, no caso de software, possivelmente produzir um “sistema de classificação de segurança de software em camadas”. A perspectiva de movimento na rotulagem de cibersegurança para IoT é empolgante, respondendo a várias chamadas para esse programa nos Estados Unidos e combinando com as políticas do Reino Unido, Cingapura e outros lugares. Ainda pode ser necessário para o Congresso agir neste espaço, no entanto, antes que haja uma adoção generalizada de tais medidas de transparência.
Seção 5: Um NTSB para incidentes cibernéticos significativos
Outra ideia muito esperada trazida à vida pela EO é o Conselho de Revisão de Segurança Cibernética. O conselho será um grupo interagências convocado pelo DHS e apresentando representantes do Departamento de Defesa, Departamento de Justiça, CISA, Agência de Segurança Nacional (NSA) e FBI, bem como nomeados do setor privado (adaptados às circunstâncias do incidente particular sob revisão). A ideia é revisar “incidentes cibernéticos significativos” (que podem envolver violação de sistemas federais, mas também podem abranger certos incidentes do setor privado), a fim de extrair lições aprendidas e, em seguida, disseminar essas lições de forma adequada. O modelo é inspirado pelo National Transportation Safety Board, que analisa os principais acidentes de transporte, como acidentes aéreos, e cujos relatórios investigativos detalhados ajudam a informar as avaliações de risco, avaliações de fornecedores e práticas operacionais.
A EO especifica um primeiro trabalho específico para o Conselho de Revisão de Segurança Cibernética: extrair lições aprendidas com SolarWinds / Sunburst. Claro, a própria EO mostra que esse processo de aprendizado já está em andamento. Dito isso, a EO também deixa claro que a prancha neste primeiro trote pela pista também deve aproveitar a ocasião para identificar lições aprendidas sobre si mesma, permitindo que o processo da prancha funcione melhor no futuro.
Seções 6, 7 e 8: colocando em ordem a Segurança Cibernética no âmbito federal, parte II
As Seções 6, 7 e 8 voltam ao tema de obrigar as agências federais a melhorar sua postura de segurança cibernética.
A sequência começa com a “Seção 6. Padronizando o Manual do Governo Federal para Responder a Vulnerabilidades e Incidentes de Cibersegurança”, abordando o fato de que a enorme gama de agências FCEB aparentemente tem uma variedade infinita de manuais de resposta a incidentes. Sem dúvida, a variação reflete, pelo menos parcialmente, a adaptação às circunstâncias locais. Mas o resultado líquido da variedade tornou mais difícil para a CISA, como líder defensivo centralizado, garantir a conformidade de maneira eficaz. Portanto, a Seção 6 incumbe a CISA de desenvolver um manual padrão de resposta a incidentes (em consulta com uma série de outras agências e organizações). Também incumbe a CISA de revisar e atualizar o documento anualmente com a NSA e esclarece a autoridade da CISA para revisar os planos de resposta da agência para garantir a conformidade. Desta forma, a Seção 6 contribui para o processo contínuo de levar a CISA ainda mais à frente como a organização central de segurança cibernética para as agências federais (FCEB).
Este é um momento tão bom quanto qualquer outro para lembrar que, nas palavras de um ex-funcionário da Câmara, a CISA está “sobrecarregada, com falta de pessoal e, em certo sentido, lutando com os olhos vendados”. Em outras palavras, autoridade maior é bom, mas precisa ser acompanhada por mais recursos. Os próximos dois anos serão críticos para a CISA, já que Jen Easterly assume o comando e uma possível injeção de orçamento associada a um aumento nas contratações pode remodelar a agência para sempre.
Já a “Seção 7. Melhorando a detecção de vulnerabilidades e incidentes de segurança cibernética em redes do governo federal”, responde a problemas que surgiram com base no ataques SolarWinds / Sunburst: a falta de detecção e resposta (EDR), de endpoint forte (e consistente), de capacidades em muitas entidades FCEB e limites que existiam (pelo menos até recentemente) na capacidade do CISA de conduzir a caça de ameaças nos sistemas dessas entidades (com ou sem a sua permissão). A Seção 7 orienta todas as agências a lançar iniciativas para melhorar seus recursos de EDR em um cronograma apertado, bem como outras iniciativas para aprimorar os recursos centralizados de caça a ameaças da CISA. Da mesma forma, a Seção 7 também obriga as agências a firmar acordos para fornecer à CISA acesso a dados em nível de objeto em apoio ao Programa de Diagnóstico e Mitigação Contínua da CISA.
Os aficionados da caça às ameaças se lembrarão de que o Congresso realmente concedeu à CISA uma autoridade ampliada (e esclarecida) de caça às ameaças centralizada na Seção 1705 da Lei de Autorização de Defesa Nacional fiscal de 2021. Em um sinal da importância dessa nova autoridade, a EO pede que a CISA produza um relatório em 90 dias explicando como eles estão colocando essa autoridade para funcionar e também exige relatórios adicionais a cada trimestre descrevendo seu uso contínuo. Previsão: Esses relatórios confirmarão que a CISA está tentando aproveitar ao máximo a Seção 1705, mas precisará de mais recursos para fazer uso completo dela.
O próximo conteúdo é a “Seção 8. Melhorando as Capacidades de Investigação e Remediação do Governo Federal”. A Seção 8 é uma espécie de provisão mais fácil, pois se concentra na falta de registros de rede em muitos sistemas FCEB. Conforme enfatizado por algumas das críticas mais incisivas de fornecedores após o SolarWinds / Sunburst, a quantidade (e a natureza) dos dados registrados nos registros da rede e como esses dados são retidos e acessados podem ter uma grande influência na velocidade e sucesso da resposta a incidentes cibernéticos. O DHS, portanto, é encarregado de desenvolver práticas padronizadas, enquanto o OMB tem a responsabilidade de fazer cumprir essas práticas nas agências civis.
Notavelmente, alguns das análises referentes ao SolarWinds / Sunburst sugeriram que os problemas de registro do FCEB às vezes resultam de restrições financeiras que levaram as agências a contratar serviços de fornecedores em níveis de preço que não incluíam um registro robusto. Talvez em resposta a isso, a EO direcione especificamente o OMB para trabalhar com os líderes da agência para garantir que eles tenham os recursos necessários para atender aos novos requisitos.
Seção 9: Não se esqueça dos sistemas de segurança nacional!
Neste ponto, deve estar claro que a maior parte da EO se concentra no .gov – ou seja, as agências civis e os personagens que você conhece e ama, como a Receita Federal, a Agência de Proteção Ambiental, o Departamento de Estado e muito mais. Entretanto, o Departamento de Defesa e a comunidade de inteligência gostam da nuvem e da computação também, muito obrigado. Então, o que acontece com eles?
Requisitos dispersos no corpo principal da EO, e especialmente na “Seção 9. Sistemas de Segurança Nacional”, garantem que haja processos para o secretário de defesa incorporar todas as normas e diretrizes desenvolvidas na ordem para sistemas de segurança nacional, quando aplicável e apropriado. Os sistemas de segurança nacional (e o ambiente .mil mais amplamente), portanto, não são o foco desta EO, mas recebem alguma atenção limitada (com ênfase na sincronização com os controles de segurança das agências civis e práticas de coleta de dados).
4. Mais de 8.000 palavras depois, onde estamos?
Se você queria um documento que tratasse de infraestrutura crítica ou levando contra a luta para franquias de ransomware estrangeiras, esta EO não é para você. E isso não deve ser surpresa. Apesar do momento do incidente do Colonial Pipeline na semana passada, a EO é o culminar de um período intensivo de trabalho da equipe cibernética Biden desencadeado pelo duro golpe duplo de vulnerabilidades SolarWinds / Sunburst e Microsoft Exchange. A palavra de ordem que se segue a partir desses episódios é segurança de software, com um grande foco na resposta, investigação e remediação de incidentes federais.
Esse é o Centro de Gravidade da nova EO. Não é revolucionária, mas não deve ser a medida do sucesso. A questão importante é se ele responde de maneira inteligente às lições importantes aprendidas com experiências recentes e dolorosas, e parece que sim. As entidades FCEB serão forçadas a realizar uma variedade de etapas importantes (talvez mais notavelmente, coisas básicas como a nova criptografia e os mandatos de autenticação multifator). A CISA será empurrada um pouco mais para o centro do palco, como o órgão central de segurança cibernética do .gov. Ao longo do caminho, a EO cobre muito terreno no desenvolvimento de software seguro e tratamento mais ciente de risco de “software crítico” junto com novas políticas de segurança em nuvem e tentativas de mudar o ambiente .gov para um novo modelo de confiança. Há até mesmo um empurrãozinho para a transparência da segurança da IoT.
Muitas questões e desafios permanecem, o que é esperado. Por exemplo, a EO não luta com desafios de criar um “organograma”, como colocar no papel tudo isso para o Conselho de Segurança de Aquisições Federal ou o oficial de segurança da informação federal, que não são mencionados. Também não lida diretamente com o futuro papel do diretor cibernético nacional (NCD), que em breve será preenchido pelo estimado Chris Inglis. Resta ver como (se é que o fazem) os novos programas e linhas de reporte – muitos dos quais incluem relatórios para, ou decisões do assistente do presidente para assuntos de segurança nacional – mudarão nesse ponto (enquanto o NCD não é mencionada no corpo principal da EO, há a opção de permitir que “partes desta ordem possam ser modificadas para permitir que o DNT cumpra integralmente suas funções e responsabilidades”). Isso também pode influenciar os cronogramas de algumas dessas atividades.
Conclusão: A EO vai longe no sentido de colher os “frutos” mais fáceis (e alguns não tão fáceis) destacados pelos desafios recentes. Em termos de melhorias sistemáticas para a segurança cibernética do país, a atenção agora deve se voltar para o Congresso. Os elementos prescritivos da EO podem ser um modelo útil de como o Congresso pode tomar medidas para reforçar a segurança em pelo menos alguns subsetores de infraestrutura crítica, por exemplo. E apenas o Congresso pode fornecer os aumentos de recursos que, em última análise, são necessários para realizar o impacto total dessas novas políticas.
Posts relacionados: Vulnerabilidade injetada em sistemas da SolarWinds viabiliza ataques de grandes proporções nos EUA. / Agências dos EUA sofrem ataque de espionagem cibernética e Explicando o Ransomware DarkSide: Como funciona e quem está por trás
Informações obtidas/adaptadas de: Everything You Need to Know About the New Executive Order on Cybersecurity / Executive Order on Improving the Nation’s Cybersecurity