Cibersegurança e risco tecnológico no setor público

Por que razão isto importa para o valor público

Quando os sistemas de um hospital são cifrados por um atacante, os clínicos não conseguem ver os historiais de medicação, as ambulâncias são desviadas e as operações são canceladas. Quando os sistemas de controlo de uma empresa de águas são comprometidos, o valor público em jogo não é uma avaria de servidor mas a segurança da água potável. Quando a base de dados de uma agência de prestações é violada, as pessoas mais expostas são muitas vezes as menos capazes de absorver as consequências: um pagamento atrasado, uma identidade roubada, uma família que não consegue provar quem é ao Estado que lhe deve apoio. A segurança informática, vulgarmente chamada cibersegurança, é a prática de proteger sistemas informáticos, redes e dados contra o acesso não autorizado, a perturbação ou o dano. Nas instituições públicas, essa prática situa-se diretamente no caminho entre o Estado e o cidadão que serve.

É por isso que o tópico enquadra o risco cibernético como uma questão de valor público e não apenas técnica. A legitimidade e o apoio dependem de os cidadãos acreditarem que as instituições que detêm os seus dados e gerem os seus serviços essenciais merecem confiança para manter ambos em segurança (ver Tópico 1.2 — O triângulo estratégico: legitimidade, valor e capacidade). Uma única violação amplamente noticiada pode causar um dano duradouro a essa confiança, da mesma forma que uma emergência mal gerida, porque os cidadãos julgam as instituições pela forma como se comportam sob ataque tanto como pela forma como têm desempenho no dia a dia (ver Tópico 3.12 — Gestão de crises, emergências e resiliência, que trata os incidentes cibernéticos como uma categoria dentro da disciplina mais ampla da resiliência). A cibersegurança é também inseparável da governação de dados: uma instituição não pode proteger o que não sabe que detém, e a interoperabilidade e a abertura que criam valor público a partir dos dados alargam também a superfície que um atacante pode explorar (ver Tópico 5.4 — Dados do setor público, interoperabilidade e dados abertos).

O problema de recursos é agudo e específico dos setores público e social. As grandes agências nacionais têm cada vez mais equipas de segurança dedicadas e orçamentos empresariais; a junta de águas que serve uma pequena cidade, o centro hospitalar regional e a organização sem fins lucrativos local que gere um abrigo para vítimas de violência doméstica tipicamente não têm, apesar de deterem dados cuja sensibilidade rivaliza ou excede a de qualquer banco. Os atacantes sabem-no. Os organismos públicos subdotados de recursos não são um caso marginal neste tópico; estão perto do seu centro, porque a instituição pública mediana que enfrenta hoje este risco não é um ministério nacional mas uma pequena autoridade local, uma empresa regional de serviços de utilidade pública ou uma instituição de solidariedade com um punhado de técnicos de tecnologias de informação e nenhum especialista em segurança.

Por fim, este é um problema vivo e em agravamento, e não hipotético. As campanhas de ransomware visam cada vez mais governos locais, hospitais, escolas e organizações do setor social precisamente porque combinam dados sensíveis, serviços essenciais, baixa tolerância à interrupção e defesas comparativamente fracas — uma combinação que os torna mais propensos a pagar e menos propensos a ter prevenido o ataque em primeiro lugar. Tratar a cibersegurança como um complemento especializado e não como um compromisso de valor público ao nível da governação é, para esta classe de organização, quase um convite.

Conceitos fundamentais

As infraestruturas críticas são o conjunto de sistemas e ativos — energia, água, transportes, saúde, finanças, comunicações — tão essenciais que a sua incapacidade ou destruição teria um efeito debilitante sobre a segurança, a economia ou a confiança pública. A proteção das infraestruturas críticas é a disciplina de as proteger contra ameaças físicas e digitais; importa aqui porque muitos dos incidentes cibernéticos mais consequentes do setor público não são ataques a dados abstratos mas ataques à tecnologia operacional que mantém em funcionamento as infraestruturas físicas, distinta da tecnologia da informação que mantém os registos e processa as transações.

Um ator de ameaça é qualquer indivíduo, grupo ou Estado que possa tentar comprometer um sistema; no setor público vão desde grupos criminosos com motivação financeira a atores patrocinados por Estados que prosseguem espionagem ou perturbação, e a mesma instituição pode enfrentar ambos em simultâneo com objetivos muito diferentes. O ransomware é software malicioso que cifra os dados ou sistemas de uma organização e exige pagamento pela sua libertação; tornou-se a principal ameaça aos organismos públicos precisamente porque os serviços essenciais não toleram uma interrupção prolongada, o que aumenta a pressão para pagar. O phishing é uma forma de engenharia social em que os atacantes enganam o pessoal para revelar credenciais ou instalar software malicioso, tipicamente através de correio eletrónico enganador, e continua a ser a forma mais comum de um atacante obter a primeira posição, porque visa as pessoas e não a tecnologia.

Uma violação de dados é o acesso, divulgação ou perda não autorizados de informação, seja através de um ataque externo, de um membro interno ou de um simples erro humano, como uma base de dados mal configurada deixada aberta à internet. Um ataque à cadeia de abastecimento compromete uma organização indiretamente, visando um fornecedor, um fornecedor de software ou um prestador de serviços geridos menos seguro em que a organização-alvo confia; são especialmente perigosos para o setor público porque tantos organismos públicos partilham o mesmo punhado de fornecedores de software, o que significa que o comprometimento de um só fornecedor pode propagar-se em cascata a centenas de instituições em simultâneo.

A higiene cibernética é o conjunto de práticas de rotina — aplicar prontamente as correções de software, impor autenticação forte, limitar quem pode aceder a quê, fazer cópias de segurança dos dados e testar a restauração dessas cópias — que previnem a grande maioria dos ataques bem-sucedidos sem exigir ferramentas exóticas. A maior parte das violações explora vulnerabilidades conhecidas e sem correção ou credenciais fracas, e não técnicas novas, pelo que a distância entre a higiene cibernética efetiva de uma organização e a sua política declarada é normalmente um melhor preditor do seu risco do que a sofisticação das ameaças que nomeia no seu registo de riscos.

A arquitetura de confiança zero (zero trust) é um princípio de conceção de segurança que defende que nenhum utilizador ou dispositivo deve ser considerado de confiança por defeito, mesmo dentro da própria rede de uma organização, e que cada pedido de acesso tem de ser verificado independentemente da sua origem. Tornou-se influente nas orientações do setor público porque se ajusta melhor à forma como o trabalho governamental moderno efetivamente decorre — pessoal, contratantes e cidadãos a aceder a serviços a partir de muitos dispositivos e locais — do que um modelo mais antigo que confiava em tudo o que já estivesse dentro do perímetro.

A gestão de incidentes de segurança informática, normalmente chamada resposta a incidentes, é o processo organizado de detetar, conter, erradicar e recuperar de um incidente de segurança, seguido de uma revisão do que permitiu que acontecesse. Uma obrigação de divulgação é um dever legal ou regulatório de notificar as pessoas afetadas, os reguladores ou o público quando dados pessoais ou serviços críticos foram comprometidos, dentro de um prazo especificado e segundo um padrão especificado, com a lógica de que os cidadãos e os órgãos de supervisão têm o direito de saber quando os seus dados ou os seus serviços essenciais foram postos em risco, e de que a divulgação atempada permite às pessoas protegerem-se.

Boas práticas

1. Trate a cibersegurança como uma responsabilidade do órgão de governo, e não como uma função técnica delegada. Os conselhos, câmaras e equipas executivas devem receber briefings regulares, em linguagem simples, sobre o risco cibernético e aprovar diretamente o respetivo orçamento, em vez de o deixar negociar dentro de uma rubrica mais ampla de tecnologias de informação onde é a coisa mais fácil de cortar.
2. Inventarie o que detém e o que depende disso antes de decidir como o proteger. Uma organização não pode proteger dados ou sistemas que não mapeou; um inventário atual de ativos e de dados, cruzado com o trabalho de interoperabilidade e de governação de dados tratado noutro lugar (ver Tópico 5.4 — Dados do setor público, interoperabilidade e dados abertos), é a condição prévia de todas as outras práticas desta lista.
3. Aplique o essencial em toda a parte antes de gastar em qualquer coisa avançada. A gestão de correções, a autenticação multifator, as cópias de segurança testadas e o controlo de acesso com privilégio mínimo travam a esmagadora maioria dos ataques reais; um organismo público sem estas medidas não deve priorizar assinaturas de informação sobre ameaças nem ferramentas de monitorização à medida.
4. Adote um quadro reconhecido em vez de inventar um à medida. Quadros como o Cybersecurity Framework do National Institute of Standards and Technology dão um vocabulário partilhado e uma estrutura — identificar, proteger, detetar, responder, recuperar — que uma pequena organização pode adotar de forma simplificada e uma grande pode adotar por inteiro, sem reinventar a taxonomia básica.
5. Agrupe recursos entre pequenas organizações em vez de cada uma comprar sozinha. Um serviço partilhado de centro de operações de segurança, um conjunto regional de resposta a incidentes cibernéticos ou um quadro setorial de contratação podem dar a um grupo de pequenas autoridades locais ou organizações sem fins lucrativos uma proteção que nenhuma delas poderia custear individualmente — a resposta mais direta ao problema de subdotação de recursos em que este tópico se centra.
6. Redija o plano de resposta a incidentes antes do incidente, e ensaie-o. Um plano redigido pela primeira vez durante um ataque em direto é um plano mal redigido, sob pânico, por pessoas que nunca testaram se ele realmente funciona; um plano exercitado pelo menos anualmente transforma uma primeira hora caótica numa sequência ensaiada de passos conhecidos (ver Tópico 3.12 — Gestão de crises, emergências e resiliência quanto à disciplina mais ampla em que se baseia).
7. Decida antecipadamente a política de divulgação e de pagamento, e não durante o incidente. Se a organização considerará pagar um resgate, quem tem autoridade para tomar essa decisão e como e quando as pessoas afetadas serão informadas devem ser política aprovada pelo conselho, e não uma decisão improvisada sob a pressão de uma exigência de extorsão em curso.
8. Segmente as redes para que um comprometimento não se torne todos os comprometimentos. Manter a tecnologia operacional que controla a infraestrutura física separada das tecnologias de informação gerais de escritório, e separar os sistemas de elevada sensibilidade dos de menor sensibilidade, limita quão longe pode viajar um intruso que entra por um ponto fraco.
9. Gira o risco de terceiros e da cadeia de abastecimento com o mesmo rigor que o risco interno. Exija garantias de segurança, cláusulas de direito de auditoria e obrigações de notificação de incidentes nos contratos com fornecedores de software e prestadores de serviços geridos, uma vez que uma parte crescente dos principais incidentes do setor público tem origem num fornecedor de confiança e não num ataque direto.
10. Invista nas pessoas, e não apenas nas ferramentas. A formação regular e realista — incluindo exercícios simulados de phishing — reduz mensuravelmente os ataques de engenharia social bem-sucedidos, e reter mesmo um ou dois técnicos de segurança qualificados numa pequena organização vale normalmente mais do que uma despesa equivalente em licenças de software adicionais.
11. Reporte os incidentes com honestidade e use os quase-acidentes como lições gratuitas. Uma cultura que pune o pessoal por reportar uma suspeita de violação garante que a seguinte é reportada tarde ou de todo não reportada; as organizações que melhoram mais depressa são as que tratam cada quase-acidente como evidência de que aprender e não como razão para atribuir culpas.
12. Incorpore a ciber-resiliência nas condições de contratação e de subvenção, e não apenas na política interna. Os financiadores e os organismos de contratualização podem exigir um nível de base de prática de segurança das organizações que financiam ou contratam, estendendo o alcance das boas práticas aos parceiros de entrega mais pequenos que de outro modo não teriam pressão externa para investir nelas (ver Tópico 3.7 — Contratação pública e contratualização).

Perguntas para discutir com a sua equipa

Sabemos que dados e sistemas realmente detemos, e quais deles fariam mal a alguém se fossem comprometidos? Muitas organizações descobrem a verdadeira extensão dos seus ativos de dados apenas durante uma investigação de violação, que é o pior momento possível para o aprender. Percorra os seus principais serviços e pergunte, para cada um, que dados pessoais ou operacionalmente sensíveis toca e o que aconteceria a uma pessoa real se esses dados fossem roubados, alterados ou tornados indisponíveis. Se a resposta honesta for «não temos a certeza», essa incerteza é em si mesma a conclusão, e eliminá-la é o primeiro ponto da sua agenda. Esta pergunta importa mais para as organizações que cresceram por aquisição, fusão ou acumulação de sistemas legados, onde a memória institucional do que existe se tornou ténue.

Se fôssemos atingidos amanhã por ransomware, conseguiríamos restaurar a partir da cópia de segurança sem pagar? O valor de uma cópia de segurança não é existir, mas ter sido testada para efetivamente restaurar, com rapidez suficiente, a partir de uma versão suficientemente recente para importar. Pergunte quando foram testadas pela última vez as cópias de segurança com um exercício real de restauração, e não apenas um registo de conclusão, e quanto tempo demoraria uma restauração completa face ao tempo de interrupção que a sua organização consegue tolerar. Se esses números não coincidirem, tem uma decisão de recursos a tomar agora, e não durante um incidente. Este é também o momento para discutir se as próprias cópias de segurança estão isoladas da rede que um atacante que chegue aos seus sistemas principais também poderia alcançar.

Quem tem autoridade para decidir se pagamos um resgate, e alguma vez o discutimos antes de nos ser pedido? Esta é uma das decisões de maior importância que uma equipa executiva pode enfrentar, muitas vezes exigida em horas e com informação incompleta sobre o que o atacante realmente tem. Decidir de antemão o processo, as pessoas autorizadoras e os princípios — mesmo que a decisão final ainda dependa dos pormenores do incidente — evita uma decisão improvisada sob pressão de extorsão. Discuta o que dizem a lei da sua jurisdição e as condições dos seus financiadores sobre o pagamento de resgates e a quem teria de notificar.

Os nossos parceiros e fornecedores mais pequenos são um risco maior para nós do que nós próprios? Uma organização central bem protegida pode ainda assim ser comprometida através de um fornecedor, contratante ou parceiro de entrega mal protegido com acesso legítimo aos seus sistemas ou dados. Mapeie os terceiros que podem alcançar os seus sistemas ou deter os seus dados e seja honesto quanto à garantia que realmente tem sobre as suas práticas de segurança por oposição à que presume ter. Decida que norma mínima lhes exigirá daqui em diante e como a verificará em vez de simplesmente pedir uma garantia escrita.

Saberíamos que fomos violados, e com que rapidez? Alguns dos incidentes mais danosos não são os que acontecem depressa mas os que passam sem ser detetados durante meses, tempo durante o qual um atacante explorou discretamente, escalou privilégios e exfiltrou dados. Discuta como detetaria hoje, na prática, atividade invulgar, quem a vigia e se essa monitorização funciona fora do horário de expediente, uma vez que muitos ataques são lançados deliberadamente à noite ou num fim de semana prolongado, quando a resposta é mais lenta. Se a deteção depende inteiramente de um cidadão ou de uma organização parceira nos dizer que algo está errado, essa é uma lacuna crítica.

O nosso conselho ou órgão de governo compreende este risco suficientemente bem para o governar, ou delegámos discretamente esse juízo na equipa de tecnologias de informação? As decisões de risco cibernético envolvem compromissos reais entre custo, continuidade do serviço e proteção dos cidadãos que são propriamente da competência do órgão de governo, e não uma matéria técnica delegada a aprovar sem discussão. Discuta como o risco cibernético é atualmente reportado ao seu conselho ou câmara, se está numa linguagem sobre a qual um não especialista possa efetivamente agir e se o respetivo orçamento é decidido com o mesmo rigor que qualquer outro risco importante. Se o seu órgão de governo não conseguisse atualmente explicar com as suas próprias palavras os três principais riscos cibernéticos da organização, essa é a lacuna a colmatar primeiro.

Na prática: um exemplo de valor público

Uma autoridade regional de transportes de média dimensão — fictícia, ilustrativa de um padrão e não um relato de qualquer organização real — gerava sistemas envelhecidos de escalonamento e de pagamentos que tinham sido corrigidos aos bocados durante uma década em vez de modernizados. A sua equipa de tecnologias de informação tinha três pessoas, responsáveis por tudo, desde os pedidos de apoio informático à segurança da rede, e a cibersegurança nunca tivera uma rubrica própria no orçamento; vivia dentro de uma dotação geral de «manutenção de sistemas» que não crescia em termos reais havia anos.

Um atacante obteve acesso através de uma mensagem de phishing enviada a um funcionário financeiro, usando uma fatura falsificada de um fornecedor que a autoridade genuinamente usava. Uma vez dentro, o atacante passou seis semanas a mover-se discretamente pela rede antes de lançar o ransomware que cifrou o sistema de escalonamento, a plataforma de pagamento de tarifas e as cópias de segurança da autoridade, que nunca tinham sido isoladas da rede principal. Os autocarros continuaram a circular no primeiro dia com base na memória dos motoristas das suas rotas, mas as tarifas não podiam ser cobradas eletronicamente, os ecrãs de informação em tempo real ficaram às escuras e os sistemas financeiros da autoridade ficaram inutilizáveis para o processamento salarial.

A equipa executiva enfrentou a decisão do resgate sem política previamente acordada: ninguém decidira de antemão quem tinha autoridade para aprovar um pagamento, qual era a posição legal ou o que diriam aos passageiros. A restauração a partir da cópia de segurança não era uma opção, porque as cópias estavam cifradas juntamente com tudo o resto. Após nove dias de perturbação, de restabelecimento parcial do serviço e de um pagamento que o conselho da autoridade descreveu mais tarde como a opção menos má disponível na altura, a autoridade encomendou uma revisão independente.

As conclusões da revisão foram pouco glamorosas e inteiramente coerentes com o padrão que este tópico descreve: nenhuma autenticação multifator nos sistemas financeiros, nenhuma segmentação de rede entre os sistemas de escritório e a infraestrutura de pagamentos, nenhuma restauração de cópia de segurança testada há mais de dois anos e nenhuma visibilidade ao nível do conselho do risco cibernético antes do incidente. A resposta da autoridade foi igualmente pouco glamorosa — um plano faseado para corrigir o essencial, um arranjo partilhado de monitorização de segurança com duas autoridades de transportes vizinhas para repartir o custo de uma cobertura especializada que nenhuma delas podia custear sozinha e um ponto permanente da agenda do conselho sobre o risco cibernético. Nada disto foi caro pelos padrões de um grande programa de tecnologias de informação; tudo fora omitido durante anos porque nunca fora tarefa claramente atribuída de ninguém insistir nisso.

Quatro perspetivas setoriais

Poder local

As autarquias situam-se numa intersecção desconfortável: detêm dados altamente sensíveis — registos de ação social, informação de habitação e prestações, cadernos eleitorais — e gerem serviços de que os cidadãos dificilmente podem prescindir, mas têm tipicamente os menores orçamentos de segurança e o pessoal menos especializado de qualquer nível de governo. Um grande ministério nacional pode construir um centro interno de operações de segurança; uma pequena câmara distrital normalmente não pode, o que faz dos serviços partilhados, do agrupamento regional e dos programas nacionais de apoio a via prática para uma proteção adequada e não um acrescento facultativo. Os eleitos locais são também, muitas vezes, os menos equipados, de qualquer nível de governo, para interrogar um briefing técnico de risco, o que torna a comunicação em linguagem simples aos membros eleitos um desafio distinto de governação a este nível.

Governo nacional

Os governos nacionais têm geralmente os recursos para construir agências de cibersegurança dedicadas e quadros nacionais — organismos como o National Cyber Security Centre (Reino Unido) ou a Cybersecurity and Infrastructure Security Agency dos Estados Unidos existem para fixar normas, coordenar a resposta e apoiar os organismos públicos menos dotados de recursos dentro da sua jurisdição. O desafio distintivo ao nível nacional tem menos a ver com a higiene básica e mais com os atores de ameaça patrocinados por Estados e altamente capazes, com a interdependência das infraestruturas críticas nacionais entre setores e operadores privados e com as dimensões diplomática e jurídica da atribuição e da resposta, que raramente surgem ao nível local ou organizacional.

Setor social e organizações sem fins lucrativos

As organizações sem fins lucrativos e as ONG detêm muitas vezes alguns dos dados mais sensíveis de qualquer setor — registos de saúde, registos de sobreviventes de violência ou perseguição, processos de refugiados e de asilo — enquanto operam com os orçamentos de segurança mais ténues de qualquer tipo de organização neste livro, porque os financiadores raramente consignam dinheiro para a segurança e as condições das subvenções raramente a exigem. Muitas organizações do setor social dependem também de voluntários e de uma elevada rotação de pessoal, o que torna mais difícil sustentar uma formação de segurança e um controlo de acessos consistentes do que numa organização estável e profissionalmente dotada de pessoal; um incidente de segurança pode ser existencial para uma pequena instituição de solidariedade de uma forma que raramente o é para um departamento governamental, porque o dano reputacional e a perda de confiança dos doadores podem pôr fim à organização (ver Tópico 3.8 — Gestão do setor social e de organizações sem fins lucrativos).

Organismos multilaterais e internacionais

Os organismos multilaterais e internacionais operam em jurisdições com leis de divulgação diferentes, definições diferentes de infraestruturas críticas e níveis diferentes de capacidade cibernética nacional, o que faz da própria coordenação um problema distinto: os sistemas de um organismo internacional podem estar bem protegidos enquanto os seus organismos nacionais membros variam enormemente, e um organismo como a Organização para a Cooperação e Desenvolvimento Económicos ou a Agência da União Europeia para a Cibersegurança desempenha tanto um papel de fixação de normas e de reforço de capacidades como operacional. A perspetiva multilateral é também onde os arranjos transfronteiriços de resposta a incidentes e de partilha de informação mais importam, já que um ataque que começa na infraestrutura de um país pode propagar-se à de outro em horas, mais depressa do que a maioria dos mecanismos internacionais de coordenação foi construída para se mover.

Modos de falha comuns

Teatro da segurança sem substância operacional. Uma organização adota um documento de política de aspeto impressionante, um certificado de conformidade ou uma única ferramenta cara e trata a caixa como assinalada, enquanto a higiene básica — correções, autenticação multifator, cópias de segurança testadas — continua inconsistente. Isto custa dinheiro real pela aparência de segurança e não pela segurança em si, e só é muitas vezes descoberto como teatro depois de um incidente expor a distância entre a política e a prática.

O risco sem dono. Presume-se que a cibersegurança é trabalho de outrem — da equipa de tecnologias de informação, de um fornecedor, de um regulador — e não existe nenhum responsável único com obrigação de prestar contas ao nível do órgão de governo. Isto produz um risco que é discutido em toda a parte e decidido em lado nenhum, e é precisamente o padrão que deixa as organizações incapazes de responder a perguntas básicas sobre a sua própria exposição quando lhas fazem.

Subinvestimento justificado pela ausência de um incidente anterior. Como um programa de segurança bem gerido não produz nenhum acontecimento visível quando tem êxito, é fácil desfinanciá-lo numa ronda orçamental apertada a favor de algo com um produto visível, e a ausência de uma violação até agora é tomada por evidência de proteção adequada e não por evidência de que ainda não foi testada. Isto espelha a mesma lógica orçamental que mina o investimento em resiliência de forma mais ampla (ver Tópico 3.12 — Gestão de crises, emergências e resiliência).

Sistemas legados mantidos em funcionamento para além da sua vida suportável. Os organismos públicos mantêm frequentemente em funcionamento software ou hardware muito depois de o fornecedor ter deixado de emitir correções de segurança para ele, porque a substituição é cara, perturbadora ou politicamente impopular, e o sistema «ainda funciona». Um sistema sem correções e sem suporte não é um incómodo herdado; é uma porta aberta por onde um atacante entra a custo nulo.

Cultura de incidentes que começa pela culpa. Quando o pessoal que reporta uma suspeita de violação ou um erro é disciplinado em vez de apoiado, os incidentes futuros são reportados tarde, minimizados ou não reportados de todo, e a organização perde o sinal de alerta precoce que o reporte atempado proporciona. Esta falha agrava todas as outras desta lista, porque nenhuma das correções acima funciona se a organização não consegue ver com honestidade os seus próprios problemas.

Modelo de maturidade

Lista de verificação

• Um indivíduo ou comissão nomeado ao nível do órgão de governo detém o risco cibernético e reporta sobre ele regularmente, em linguagem simples.
• Existe um inventário atual dos dados e sistemas que a organização detém e dos que são mais sensíveis ou mais críticos para um serviço.
• A autenticação multifator é imposta em todos os sistemas que detêm dados sensíveis ou controlam serviços críticos.
• As cópias de segurança são feitas regularmente, armazenadas isoladas da rede principal e a restauração foi testada nos últimos doze meses.
• O software e os sistemas são corrigidos num calendário definido, e qualquer sistema que já não possa ser corrigido tem um plano documentado para o substituir ou isolar.
• Existe um plano escrito de resposta a incidentes, que nomeia quem tem autoridade para tomar as decisões-chave, e que foi ensaiado através de um exercício realista no último ano.
• Existe uma política aprovada pelo conselho sobre o pagamento de resgates e sobre como e quando as pessoas afetadas, os reguladores e o público serão notificados.
• Os contratos com fornecedores de software e prestadores de serviços geridos incluem garantias de segurança e obrigações de notificação de incidentes.
• O pessoal recebe formação de segurança regular e realista, incluindo exercícios simulados de phishing.
• Reportar uma suspeita de incidente ou quase-acidente é tratado como informação valiosa, e não como motivo de culpa.
• Foram exploradas com organizações pares de dimensão e orçamento semelhantes soluções de segurança partilhadas ou agrupadas.
• O risco cibernético figura explicitamente no planeamento mais amplo de crise e resiliência da organização, e não como um plano separado e desligado.

Fontes principais

Este tópico recorre ao Cybersecurity Framework do National Institute of Standards and Technology como principal quadro estruturado para organizar a prática de cibersegurança; à missão publicada da Agência da União Europeia para a Cibersegurança e às suas orientações para alcançar um nível comum de cibersegurança em toda a União Europeia; ao trabalho de política de segurança digital da Organização para a Cooperação e Desenvolvimento Económicos, que enquadra a segurança digital como uma questão de gestão de riscos económicos e sociais e não puramente técnica; e às orientações operacionais publicadas por agências nacionais de cibersegurança como o National Cyber Security Centre do Reino Unido e a Cybersecurity and Infrastructure Security Agency dos Estados Unidos, ambos os quais fornecem orientações gratuitas especificamente dirigidas aos organismos públicos subdotados de recursos.

Referências

1. Computer security — Wikipedia — https://en.wikipedia.org/wiki/Computer_security
2. Critical infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Critical_infrastructure
3. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
4. Phishing — Wikipedia — https://en.wikipedia.org/wiki/Phishing
5. Data breach — Wikipedia — https://en.wikipedia.org/wiki/Data_breach
6. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
7. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
8. Computer security incident management — Wikipedia — https://en.wikipedia.org/wiki/Computer_security_incident_management
9. National Cyber Security Center (United Kingdom) — Wikipedia — https://en.wikipedia.org/wiki/National_Cyber_Security_Centre_(United_Kingdom)
10. Cybersecurity and Infrastructure Security Agency — Wikipedia — https://en.wikipedia.org/wiki/Cybersecurity_and_Infrastructure_Security_Agency
11. Cybersecurity Framework — National Institute of Standards and Technology — https://www.nist.gov/cyberframework
12. Who we are — European Union Agency for Cybersecurity (ENISA) — https://www.enisa.europa.eu/about-enisa/who-we-are
13. Digital security — Organisation for Economic Co-operation and Development (OECD) — https://www.oecd.org/en/topics/digital-security.html
14. What we do at the NCSC — National Cyber Security Center (United Kingdom) — https://www.ncsc.gov.uk/section/about-ncsc/what-we-do
15. About CISA — Cybersecurity and Infrastructure Security Agency (United States) — https://www.cisa.gov/about